BUILD_SHARED_LIBS=True breaks some tests

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

BUILD_SHARED_LIBS=True breaks some tests

David Blaikie via cfe-dev
Hi,

Sometime this past summer or fall, a set of Clang tests on master started failing for me when using BUILD_SHARED_LIBS=True, but they behave without it:

    Clang :: CXX/modules-ts/basic/basic.link/p2/module.cpp
    Clang :: Modules/ExtDebugInfo.cpp
    Clang :: Modules/using-directive-redecl.cpp
    Clang :: Modules/using-directive.cpp
    Clang :: PCH/chain-late-anonymous-namespace.cpp
    Clang :: PCH/cxx-namespaces.cpp
    Clang :: PCH/namespaces.cpp

I heard recently that BUILD_SHARED_LIBS=True might not be as widely used or tested as I expected [1].  I prefer it as it significantly decreases build sizes and, more importantly, accelerates incremental builds for me, at least under Ubuntu 18.04.1 [2].  For example, after I touch clang/lib/Sema/SemaOpenMP.cpp, an incremental build runs 7.5x faster if BUILD_SHARED_LIBS=True.  I prefer to recompile and test frequently during development, so this difference has a big impact.

Do other Clang developers find BUILD_SHARED_LIBS=True useful?  Do you see the above failures?  Should there be a bot to test that build configuration?

I have not attempted to debug the above failures yet, and I'm happy to provide more details, but I thought I should ask the larger questions about BUILD_SHARED_LIBS=True first.

Thanks.

Joel



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: BUILD_SHARED_LIBS=True breaks some tests

David Blaikie via cfe-dev
"Joel E. Denny via cfe-dev" <[hidden email]> writes:

> Do other Clang developers find BUILD_SHARED_LIBS=True useful? Do you
> see the above failures? Should there be a bot to test that build
> configuration?

I don't use BUILD_SHARED_LIBS=True but if that's a supported option, it
should be tested.

This argument will, of course, lead to an explosion of builders, as the
set of combinations of cmake variables is very large.  It would be
useful to gather the various configurations people use and see if there
is a set of common-ish combinations that is small enough to regularly
test.

We build with RTTI and exceptions enabled and I'll bet there are others
out there that do the same.  But AFAIK there are no bots testing those
options.

                             -David

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: BUILD_SHARED_LIBS=True breaks some tests

David Blaikie via cfe-dev
On Tue, Jan 8, 2019 at 5:14 PM David Greene <[hidden email]> wrote:
"Joel E. Denny via cfe-dev" <[hidden email]> writes:

> Do other Clang developers find BUILD_SHARED_LIBS=True useful? Do you
> see the above failures? Should there be a bot to test that build
> configuration?

I don't use BUILD_SHARED_LIBS=True

One point I'd like to understand is why more people don't use it.  Were you not aware of it, or is it just not beneficial enough to you?  I was very happy to reduce a nearly 4-minute rebuild after a minor change to ~31 sec.  Especially when I have to do that repeatedly, that time difference can determine whether I decide to switch contexts or stay focused.
 
but if that's a supported option, it
should be tested.

This argument will, of course, lead to an explosion of builders, as the
set of combinations of cmake variables is very large.  It would be
useful to gather the various configurations people use and see if there
is a set of common-ish combinations that is small enough to regularly
test.

We build with RTTI and exceptions enabled and I'll bet there are others
out there that do the same.  But AFAIK there are no bots testing those
options.

To reduce the configuration space, we could consider combining orthogonal options under a single builder.  That could make debugging some fails a little harder, but it might be worthwhile as it would provide more coverage with less builders.

Thanks.

Joel
 

                             -David


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: BUILD_SHARED_LIBS=True breaks some tests

David Blaikie via cfe-dev


On Jan 8, 2019, at 2:44 PM, Joel E. Denny via cfe-dev <[hidden email]> wrote:

On Tue, Jan 8, 2019 at 5:14 PM David Greene <[hidden email]> wrote:
"Joel E. Denny via cfe-dev" <[hidden email]> writes:

> Do other Clang developers find BUILD_SHARED_LIBS=True useful? Do you
> see the above failures? Should there be a bot to test that build
> configuration?

I don't use BUILD_SHARED_LIBS=True

One point I'd like to understand is why more people don't use it.  Were you not aware of it, or is it just not beneficial enough to you?  I was very happy to reduce a nearly 4-minute rebuild after a minor change to ~31 sec.  Especially when I have to do that repeatedly, that time difference can determine whether I decide to switch contexts or stay focused.

How much of that rebuild time is actually link time? I'd guess most. What linker are you using? ld64, lld and gold are all much faster than bfd, so the performance implications may be smaller to other people. Also, using `BUILD_SHARED_LIBS` has a significant impact on execution performance of the final binaries, which impacts test execution speed. So if you aren't struggling with link time, it can be overall better to generate faster loading binaries for the test suite.

There are a lot of tradeoffs on performance, but I've strongly advocated that BUILD_SHARED_LIBS should never be used when building distributions for performance reasons, which means it is only really supported as a developer workflow.

Additionally BUILD_SHARED_LIBS is problematic with some of LLVM's design patterns, like cl::opt's global registration, which can deter its usefulness.

Hope this helps explain why it is less widely used than you might have anticipated.

-Chris

 
but if that's a supported option, it
should be tested.

This argument will, of course, lead to an explosion of builders, as the
set of combinations of cmake variables is very large.  It would be
useful to gather the various configurations people use and see if there
is a set of common-ish combinations that is small enough to regularly
test.

We build with RTTI and exceptions enabled and I'll bet there are others
out there that do the same.  But AFAIK there are no bots testing those
options.

To reduce the configuration space, we could consider combining orthogonal options under a single builder.  That could make debugging some fails a little harder, but it might be worthwhile as it would provide more coverage with less builders.

Thanks.

Joel
 

                             -David

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: BUILD_SHARED_LIBS=True breaks some tests

David Blaikie via cfe-dev
Can you dig out more details around why it fails? We have a recurring request to add a dependency on clangSerialization from IWYU because it's missing under BUILD_SHARED_LIBS. I wonder if this might be an in-tree repro of that problem.

Thanks, 
- Kim 

On Wed, Jan 9, 2019, 00:04 Chris Bieneman via cfe-dev <[hidden email] wrote:


On Jan 8, 2019, at 2:44 PM, Joel E. Denny via cfe-dev <[hidden email]> wrote:

On Tue, Jan 8, 2019 at 5:14 PM David Greene <[hidden email]> wrote:
"Joel E. Denny via cfe-dev" <[hidden email]> writes:

> Do other Clang developers find BUILD_SHARED_LIBS=True useful? Do you
> see the above failures? Should there be a bot to test that build
> configuration?

I don't use BUILD_SHARED_LIBS=True

One point I'd like to understand is why more people don't use it.  Were you not aware of it, or is it just not beneficial enough to you?  I was very happy to reduce a nearly 4-minute rebuild after a minor change to ~31 sec.  Especially when I have to do that repeatedly, that time difference can determine whether I decide to switch contexts or stay focused.

How much of that rebuild time is actually link time? I'd guess most. What linker are you using? ld64, lld and gold are all much faster than bfd, so the performance implications may be smaller to other people. Also, using `BUILD_SHARED_LIBS` has a significant impact on execution performance of the final binaries, which impacts test execution speed. So if you aren't struggling with link time, it can be overall better to generate faster loading binaries for the test suite.

There are a lot of tradeoffs on performance, but I've strongly advocated that BUILD_SHARED_LIBS should never be used when building distributions for performance reasons, which means it is only really supported as a developer workflow.

Additionally BUILD_SHARED_LIBS is problematic with some of LLVM's design patterns, like cl::opt's global registration, which can deter its usefulness.

Hope this helps explain why it is less widely used than you might have anticipated.

-Chris

 
but if that's a supported option, it
should be tested.

This argument will, of course, lead to an explosion of builders, as the
set of combinations of cmake variables is very large.  It would be
useful to gather the various configurations people use and see if there
is a set of common-ish combinations that is small enough to regularly
test.

We build with RTTI and exceptions enabled and I'll bet there are others
out there that do the same.  But AFAIK there are no bots testing those
options.

To reduce the configuration space, we could consider combining orthogonal options under a single builder.  That could make debugging some fails a little harder, but it might be worthwhile as it would provide more coverage with less builders.

Thanks.

Joel
 

                             -David

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: BUILD_SHARED_LIBS=True breaks some tests

David Blaikie via cfe-dev
On Wed, Jan 9, 2019 at 1:59 AM Kim Gräsman <[hidden email]> wrote:
Can you dig out more details around why it fails?

Sure, here's the lit output for the first three:

```
FAIL: Clang :: CXX/modules-ts/basic/basic.link/p2/module.cpp (1149 of 13760)
******************** TEST 'Clang :: CXX/modules-ts/basic/basic.link/p2/module.cpp' FAILED ********************
Script:
--
: 'RUN: at line 1';   /home/jdenny/ornl/llvm-mono-git-build/bin/clang -cc1 -internal-isystem /home/jdenny/ornl/llvm-mono-git-build/lib/clang/8.0.0/include -nostdsysteminc -std=c++1z -fmodules-ts /home/jdenny/ornl/llvm-mono-git/clang/test/CXX/modules-ts/basic/basic.link/p2/module.cppm -emit-module-interface -o /home/jdenny/ornl/llvm-mono-git-build/tools/clang/test/CXX/modules-ts/basic/basic.link/p2/Output/module.cpp.tmp
: 'RUN: at line 2';   /home/jdenny/ornl/llvm-mono-git-build/bin/clang -cc1 -internal-isystem /home/jdenny/ornl/llvm-mono-git-build/lib/clang/8.0.0/include -nostdsysteminc -std=c++1z -fmodules-ts -fmodule-file=/home/jdenny/ornl/llvm-mono-git-build/tools/clang/test/CXX/modules-ts/basic/basic.link/p2/Output/module.cpp.tmp /home/jdenny/ornl/llvm-mono-git/clang/test/CXX/modules-ts/basic/basic.link/p2/module.cpp -verify
--
Exit Code: 1

Command Output (stderr):
--
error: 'error' diagnostics seen but not expected:
  File /home/jdenny/ornl/llvm-mono-git/clang/test/CXX/modules-ts/basic/basic.link/p2/module.cpp Line 13: expected ';' after expression
  File /home/jdenny/ornl/llvm-mono-git/clang/test/CXX/modules-ts/basic/basic.link/p2/module.cpp Line 13: use of undeclared identifier 'internal_linkage_class'
2 errors generated.

--

********************
FAIL: Clang :: Modules/ExtDebugInfo.cpp (5908 of 13760)
******************** TEST 'Clang :: Modules/ExtDebugInfo.cpp' FAILED ********************
Script:
--
: 'RUN: at line 1';   rm -rf /home/jdenny/ornl/llvm-mono-git-build/tools/clang/test/Modules/Output/ExtDebugInfo.cpp.tmp
: 'RUN: at line 5';   /home/jdenny/ornl/llvm-mono-git-build/bin/clang -cc1 -internal-isystem /home/jdenny/ornl/llvm-mono-git-build/lib/clang/8.0.0/include -nostdsysteminc -x objective-c++ -std=c++11 -debug-info-kind=standalone      -dwarf-ext-refs -fmodules                                        -fmodule-format=obj -fimplicit-module-maps -DMODULES      -triple x86_64-unknown-linux-gnu      -fmodules-cache-path=/home/jdenny/ornl/llvm-mono-git-build/tools/clang/test/Modules/Output/ExtDebugInfo.cpp.tmp /home/jdenny/ornl/llvm-mono-git/clang/test/Modules/ExtDebugInfo.cpp -I /home/jdenny/ornl/llvm-mono-git/clang/test/Modules/Inputs -I /home/jdenny/ornl/llvm-mono-git-build/tools/clang/test/Modules/Output/ExtDebugInfo.cpp.tmp -emit-llvm -o /home/jdenny/ornl/llvm-mono-git-build/tools/clang/test/Modules/Output/ExtDebugInfo.cpp.tmp-mod.ll
: 'RUN: at line 10';   cat /home/jdenny/ornl/llvm-mono-git-build/tools/clang/test/Modules/Output/ExtDebugInfo.cpp.tmp-mod.ll |  /home/jdenny/ornl/llvm-mono-git-build/bin/FileCheck /home/jdenny/ornl/llvm-mono-git/clang/test/Modules/ExtDebugInfo.cpp
: 'RUN: at line 13';   /home/jdenny/ornl/llvm-mono-git-build/bin/clang -cc1 -internal-isystem /home/jdenny/ornl/llvm-mono-git-build/lib/clang/8.0.0/include -nostdsysteminc -x c++ -std=c++11 -fmodule-format=obj -emit-pch -I/home/jdenny/ornl/llvm-mono-git/clang/test/Modules/Inputs      -triple x86_64-unknown-linux-gnu      -o /home/jdenny/ornl/llvm-mono-git-build/tools/clang/test/Modules/Output/ExtDebugInfo.cpp.tmp.pch /home/jdenny/ornl/llvm-mono-git/clang/test/Modules/Inputs/DebugCXX.h
: 'RUN: at line 16';   /home/jdenny/ornl/llvm-mono-git-build/bin/clang -cc1 -internal-isystem /home/jdenny/ornl/llvm-mono-git-build/lib/clang/8.0.0/include -nostdsysteminc -std=c++11 -debug-info-kind=standalone      -dwarf-ext-refs -fmodule-format=obj      -triple x86_64-unknown-linux-gnu      -include-pch /home/jdenny/ornl/llvm-mono-git-build/tools/clang/test/Modules/Output/ExtDebugInfo.cpp.tmp.pch /home/jdenny/ornl/llvm-mono-git/clang/test/Modules/ExtDebugInfo.cpp -emit-llvm -o /home/jdenny/ornl/llvm-mono-git-build/tools/clang/test/Modules/Output/ExtDebugInfo.cpp.tmp-pch.ll
: 'RUN: at line 20';   cat /home/jdenny/ornl/llvm-mono-git-build/tools/clang/test/Modules/Output/ExtDebugInfo.cpp.tmp-pch.ll |  /home/jdenny/ornl/llvm-mono-git-build/bin/FileCheck /home/jdenny/ornl/llvm-mono-git/clang/test/Modules/ExtDebugInfo.cpp
: 'RUN: at line 21';   cat /home/jdenny/ornl/llvm-mono-git-build/tools/clang/test/Modules/Output/ExtDebugInfo.cpp.tmp-pch.ll |  /home/jdenny/ornl/llvm-mono-git-build/bin/FileCheck /home/jdenny/ornl/llvm-mono-git/clang/test/Modules/ExtDebugInfo.cpp --check-prefix=CHECK-PCH
--
Exit Code: 1

Command Output (stderr):
--
/home/jdenny/ornl/llvm-mono-git/clang/test/Modules/ExtDebugInfo.cpp:54:1: error: unknown type name 'InAnonymousNamespace'
InAnonymousNamespace anon;
^
1 error generated.

--

********************
FAIL: Clang :: Modules/using-directive-redecl.cpp (6305 of 13760)
******************** TEST 'Clang :: Modules/using-directive-redecl.cpp' FAILED ********************
Script:
--
: 'RUN: at line 1';   /home/jdenny/ornl/llvm-mono-git-build/bin/clang -cc1 -internal-isystem /home/jdenny/ornl/llvm-mono-git-build/lib/clang/8.0.0/include -nostdsysteminc -fmodules -fmodules-local-submodule-visibility -verify /home/jdenny/ornl/llvm-mono-git/clang/test/Modules/using-directive-redecl.cpp
--
Exit Code: 1

Command Output (stderr):
--
error: 'error' diagnostics seen but not expected:
  File /home/jdenny/ornl/llvm-mono-git/clang/test/Modules/using-directive-redecl.cpp Line 35: unknown type name 'TLoopManager'; did you mean 'Detail::TDF::TLoopManager'?
error: 'note' diagnostics seen but not expected:
  File /home/jdenny/ornl/llvm-mono-git-build/tools/clang/test/Modules/M.map Line 7: 'Detail::TDF::TLoopManager' declared here
2 errors generated.

--
```

I'm happy to provide more if you like.

Joel
 
We have a recurring request to add a dependency on clangSerialization from IWYU because it's missing under BUILD_SHARED_LIBS. I wonder if this might be an in-tree repro of that problem.

Thanks, 
- Kim 

On Wed, Jan 9, 2019, 00:04 Chris Bieneman via cfe-dev <[hidden email] wrote:


On Jan 8, 2019, at 2:44 PM, Joel E. Denny via cfe-dev <[hidden email]> wrote:

On Tue, Jan 8, 2019 at 5:14 PM David Greene <[hidden email]> wrote:
"Joel E. Denny via cfe-dev" <[hidden email]> writes:

> Do other Clang developers find BUILD_SHARED_LIBS=True useful? Do you
> see the above failures? Should there be a bot to test that build
> configuration?

I don't use BUILD_SHARED_LIBS=True

One point I'd like to understand is why more people don't use it.  Were you not aware of it, or is it just not beneficial enough to you?  I was very happy to reduce a nearly 4-minute rebuild after a minor change to ~31 sec.  Especially when I have to do that repeatedly, that time difference can determine whether I decide to switch contexts or stay focused.

How much of that rebuild time is actually link time? I'd guess most. What linker are you using? ld64, lld and gold are all much faster than bfd, so the performance implications may be smaller to other people. Also, using `BUILD_SHARED_LIBS` has a significant impact on execution performance of the final binaries, which impacts test execution speed. So if you aren't struggling with link time, it can be overall better to generate faster loading binaries for the test suite.

There are a lot of tradeoffs on performance, but I've strongly advocated that BUILD_SHARED_LIBS should never be used when building distributions for performance reasons, which means it is only really supported as a developer workflow.

Additionally BUILD_SHARED_LIBS is problematic with some of LLVM's design patterns, like cl::opt's global registration, which can deter its usefulness.

Hope this helps explain why it is less widely used than you might have anticipated.

-Chris

 
but if that's a supported option, it
should be tested.

This argument will, of course, lead to an explosion of builders, as the
set of combinations of cmake variables is very large.  It would be
useful to gather the various configurations people use and see if there
is a set of common-ish combinations that is small enough to regularly
test.

We build with RTTI and exceptions enabled and I'll bet there are others
out there that do the same.  But AFAIK there are no bots testing those
options.

To reduce the configuration space, we could consider combining orthogonal options under a single builder.  That could make debugging some fails a little harder, but it might be worthwhile as it would provide more coverage with less builders.

Thanks.

Joel
 

                             -David

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: BUILD_SHARED_LIBS=True breaks some tests

David Blaikie via cfe-dev
In reply to this post by David Blaikie via cfe-dev
On Tue, 8 Jan 2019 at 22:14, David Greene via cfe-dev
<[hidden email]> wrote:

>
> "Joel E. Denny via cfe-dev" <[hidden email]> writes:
>
> > Do other Clang developers find BUILD_SHARED_LIBS=True useful? Do you
> > see the above failures? Should there be a bot to test that build
> > configuration?
>
> I don't use BUILD_SHARED_LIBS=True but if that's a supported option, it
> should be tested.
>
> This argument will, of course, lead to an explosion of builders, as the
> set of combinations of cmake variables is very large.  It would be
> useful to gather the various configurations people use and see if there
> is a set of common-ish combinations that is small enough to regularly
> test.

I suspect the set is fairly small - particularly if you limit yourself
to options that are "likely" to catch issues (searching the
llvm-commits archives demonstrates that a BUILD_SHARED_LIBS builder
would be useful).

Best,

Alex
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: BUILD_SHARED_LIBS=True breaks some tests

David Blaikie via cfe-dev
In reply to this post by David Blaikie via cfe-dev
On Tue, Jan 8, 2019 at 6:04 PM Chris Bieneman <[hidden email]> wrote:


On Jan 8, 2019, at 2:44 PM, Joel E. Denny via cfe-dev <[hidden email]> wrote:

On Tue, Jan 8, 2019 at 5:14 PM David Greene <[hidden email]> wrote:
"Joel E. Denny via cfe-dev" <[hidden email]> writes:

> Do other Clang developers find BUILD_SHARED_LIBS=True useful? Do you
> see the above failures? Should there be a bot to test that build
> configuration?

I don't use BUILD_SHARED_LIBS=True

One point I'd like to understand is why more people don't use it.  Were you not aware of it, or is it just not beneficial enough to you?  I was very happy to reduce a nearly 4-minute rebuild after a minor change to ~31 sec.  Especially when I have to do that repeatedly, that time difference can determine whether I decide to switch contexts or stay focused.

How much of that rebuild time is actually link time? I'd guess most.

Yes.  Even more so because I forgot I have ccache enabled.
 
What linker are you using? ld64, lld and gold are all much faster than bfd, so the performance implications may be smaller to other people.

I just tried LLVM_USE_LINKER=gold and then lld, and lld gave me a better incremental build time, so I'll stick with it.

The aforementioned ~4 min shrank to ~35s.  However, BUILD_SHARED_LIBS=True shrank that to 3s!

Continuing to use lld, when I disable ccache (or make a change ccache hasn't seen), it's ~40s and BUILD_SHARED_LIBS=True shrinks it to ~13s.

The gap is certainly closing, but BUILD_SHARED_LIBS=True still seems appealing.
 
Also, using `BUILD_SHARED_LIBS` has a significant impact on execution performance of the final binaries, which impacts test execution speed. So if you aren't struggling with link time, it can be overall better to generate faster loading binaries for the test suite.

Indeed, ninja check-clang grows from ~10 min to ~20 min when I use BUILD_SHARED_LIBS=True.  Either way, I'd switch contexts instead of waiting, so my development time wouldn't necessarily grow with the latter.

Nevertheless, whether to use BUILD_SHARED_LIBS=True is definitely a harder choice to make now.
 

There are a lot of tradeoffs on performance, but I've strongly advocated that BUILD_SHARED_LIBS should never be used when building distributions for performance reasons, which means it is only really supported as a developer workflow.

Seems fine to me except that, if it is supported as a developer workflow, the broken tests are a problem.
 

Additionally BUILD_SHARED_LIBS is problematic with some of LLVM's design patterns, like cl::opt's global registration, which can deter its usefulness.

Could you explain a little more, or point to a previous discussion?
 

Hope this helps explain why it is less widely used than you might have anticipated.

Definitely.  Thanks!

Joel
 

-Chris

 
but if that's a supported option, it
should be tested.

This argument will, of course, lead to an explosion of builders, as the
set of combinations of cmake variables is very large.  It would be
useful to gather the various configurations people use and see if there
is a set of common-ish combinations that is small enough to regularly
test.

We build with RTTI and exceptions enabled and I'll bet there are others
out there that do the same.  But AFAIK there are no bots testing those
options.

To reduce the configuration space, we could consider combining orthogonal options under a single builder.  That could make debugging some fails a little harder, but it might be worthwhile as it would provide more coverage with less builders.

Thanks.

Joel
 

                             -David

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: BUILD_SHARED_LIBS=True breaks some tests

David Blaikie via cfe-dev
In reply to this post by David Blaikie via cfe-dev
"Joel E. Denny" <[hidden email]> writes:

> On Tue, Jan 8, 2019 at 5:14 PM David Greene <[hidden email]> wrote:
>
>     "Joel E. Denny via cfe-dev" <[hidden email]> writes:
>    
>     > Do other Clang developers find BUILD_SHARED_LIBS=True useful? Do
>     you
>     > see the above failures? Should there be a bot to test that build
>     > configuration?
>    
>     I don't use BUILD_SHARED_LIBS=True
>
> One point I'd like to understand is why more people don't use it.

We've argued shared-vs.-static libraries many, many times at Cray and
there are tradeoffs for each.  Some of our customers actually require
the use of static libraries as much as possible for security and other
reasons.  They generally want to know that what they ran yesterday is
the same thing they ran today.  Yes, there are security arguments the
other way as well (security fixes via new shared library versions).

So there's definitely need for static and well as dynamic options.

Mostly we build they way we do because we want to use default options as
much as possible under the assumption that that's what gets the most
upstream testing.

>     This argument will, of course, lead to an explosion of builders,
>     as the set of combinations of cmake variables is very large. It
>     would be useful to gather the various configurations people use
>     and see if there is a set of common-ish combinations that is small
>     enough to regularly test.

> To reduce the configuration space, we could consider combining
> orthogonal options under a single builder. That could make debugging
> some fails a little harder, but it might be worthwhile as it would
> provide more coverage with less builders.

Yeah, that's kind of what I was trying to get at.  See if there are
frequently-used combinations of non-default options and test them.

A small set of builders that set all options to non-default values could
certainly be useful and could be set up without doing a survey of use.
The survey could be used to fine-tune builders in order to make tracking
down errors in the most common situations easier.

                          -David
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: BUILD_SHARED_LIBS=True breaks some tests

David Blaikie via cfe-dev
In reply to this post by David Blaikie via cfe-dev
On Wed, Jan 9, 2019 at 4:40 PM Joel E. Denny <[hidden email]> wrote:

>
> On Wed, Jan 9, 2019 at 1:59 AM Kim Gräsman <[hidden email]> wrote:
>>
>> Can you dig out more details around why it fails?
>
> Sure, here's the lit output for the first three:
>
> ```
> FAIL: Clang :: CXX/modules-ts/basic/basic.link/p2/module.cpp (1149 of 13760)
> ******************** TEST 'Clang :: CXX/modules-ts/basic/basic.link/p2/module.cpp' FAILED ********************
> Script:
> --
> : 'RUN: at line 1';   /home/jdenny/ornl/llvm-mono-git-build/bin/clang -cc1 -internal-isystem /home/jdenny/ornl/llvm-mono-git-build/lib/clang/8.0.0/include -nostdsysteminc -std=c++1z -fmodules-ts /home/jdenny/ornl/llvm-mono-git/clang/test/CXX/modules-ts/basic/basic.link/p2/module.cppm -emit-module-interface -o /home/jdenny/ornl/llvm-mono-git-build/tools/clang/test/CXX/modules-ts/basic/basic.link/p2/Output/module.cpp.tmp
> : 'RUN: at line 2';   /home/jdenny/ornl/llvm-mono-git-build/bin/clang -cc1 -internal-isystem /home/jdenny/ornl/llvm-mono-git-build/lib/clang/8.0.0/include -nostdsysteminc -std=c++1z -fmodules-ts -fmodule-file=/home/jdenny/ornl/llvm-mono-git-build/tools/clang/test/CXX/modules-ts/basic/basic.link/p2/Output/module.cpp.tmp /home/jdenny/ornl/llvm-mono-git/clang/test/CXX/modules-ts/basic/basic.link/p2/module.cpp -verify
> --
> Exit Code: 1
>
> Command Output (stderr):
> --
> error: 'error' diagnostics seen but not expected:
>   File /home/jdenny/ornl/llvm-mono-git/clang/test/CXX/modules-ts/basic/basic.link/p2/module.cpp Line 13: expected ';' after expression
>   File /home/jdenny/ornl/llvm-mono-git/clang/test/CXX/modules-ts/basic/basic.link/p2/module.cpp Line 13: use of undeclared identifier 'internal_linkage_class'
> 2 errors generated.

This doesn't make sense to me -- why would a shared build have
different runtime behavior from a static build? I was expecting a
symbol resolution failure of some kind, but this looks like the
compiler comes out broken somehow.

The IWYU build fails on a plain undefined reference:
https://github.com/include-what-you-use/include-what-you-use/pull/632#issuecomment-452011176

Not sure if these are at all related, but the PCH failures piqued my interest.

- Kim
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: BUILD_SHARED_LIBS=True breaks some tests

David Blaikie via cfe-dev
In reply to this post by David Blaikie via cfe-dev


On Jan 9, 2019, at 10:52 AM, Joel E. Denny <[hidden email]> wrote:

On Tue, Jan 8, 2019 at 6:04 PM Chris Bieneman <[hidden email]> wrote:


On Jan 8, 2019, at 2:44 PM, Joel E. Denny via cfe-dev <[hidden email]> wrote:

On Tue, Jan 8, 2019 at 5:14 PM David Greene <[hidden email]> wrote:
"Joel E. Denny via cfe-dev" <[hidden email]> writes:

> Do other Clang developers find BUILD_SHARED_LIBS=True useful? Do you
> see the above failures? Should there be a bot to test that build
> configuration?

I don't use BUILD_SHARED_LIBS=True

One point I'd like to understand is why more people don't use it.  Were you not aware of it, or is it just not beneficial enough to you?  I was very happy to reduce a nearly 4-minute rebuild after a minor change to ~31 sec.  Especially when I have to do that repeatedly, that time difference can determine whether I decide to switch contexts or stay focused.

How much of that rebuild time is actually link time? I'd guess most.

Yes.  Even more so because I forgot I have ccache enabled.
 
What linker are you using? ld64, lld and gold are all much faster than bfd, so the performance implications may be smaller to other people.

I just tried LLVM_USE_LINKER=gold and then lld, and lld gave me a better incremental build time, so I'll stick with it.

The aforementioned ~4 min shrank to ~35s.  However, BUILD_SHARED_LIBS=True shrank that to 3s!

Continuing to use lld, when I disable ccache (or make a change ccache hasn't seen), it's ~40s and BUILD_SHARED_LIBS=True shrinks it to ~13s.

The gap is certainly closing, but BUILD_SHARED_LIBS=True still seems appealing.
 
Also, using `BUILD_SHARED_LIBS` has a significant impact on execution performance of the final binaries, which impacts test execution speed. So if you aren't struggling with link time, it can be overall better to generate faster loading binaries for the test suite.

Indeed, ninja check-clang grows from ~10 min to ~20 min when I use BUILD_SHARED_LIBS=True.  Either way, I'd switch contexts instead of waiting, so my development time wouldn't necessarily grow with the latter.

Nevertheless, whether to use BUILD_SHARED_LIBS=True is definitely a harder choice to make now.
 

There are a lot of tradeoffs on performance, but I've strongly advocated that BUILD_SHARED_LIBS should never be used when building distributions for performance reasons, which means it is only really supported as a developer workflow.

Seems fine to me except that, if it is supported as a developer workflow, the broken tests are a problem.
 

Additionally BUILD_SHARED_LIBS is problematic with some of LLVM's design patterns, like cl::opt's global registration, which can deter its usefulness.

Could you explain a little more, or point to a previous discussion?

cl::opt options are generally globally scoped. When you define one, they are added to a global list of options. No two options can have the same name.

When you link against a shared library, all the globals for that shared library become part of your binary. When you link against a static archive only the globals for any translation units that you need get pulled into your binary.

In the past this has resulted in BUILD_SHARED_LIBS and LLVM_USE_LLVM_DYLIB causing duplicate options to be registered which results in a fatal error (see CommandLine.cpp, addLiteralOption).

-Chris

 

Hope this helps explain why it is less widely used than you might have anticipated.

Definitely.  Thanks!

Joel
 

-Chris

 
but if that's a supported option, it
should be tested.

This argument will, of course, lead to an explosion of builders, as the
set of combinations of cmake variables is very large.  It would be
useful to gather the various configurations people use and see if there
is a set of common-ish combinations that is small enough to regularly
test.

We build with RTTI and exceptions enabled and I'll bet there are others
out there that do the same.  But AFAIK there are no bots testing those
options.

To reduce the configuration space, we could consider combining orthogonal options under a single builder.  That could make debugging some fails a little harder, but it might be worthwhile as it would provide more coverage with less builders.

Thanks.

Joel
 

                             -David

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: BUILD_SHARED_LIBS=True breaks some tests

David Blaikie via cfe-dev
In reply to this post by David Blaikie via cfe-dev


On Jan 9, 2019, at 12:34 PM, Kim Gräsman <[hidden email]> wrote:

On Wed, Jan 9, 2019 at 4:40 PM Joel E. Denny <[hidden email]> wrote:

On Wed, Jan 9, 2019 at 1:59 AM Kim Gräsman <[hidden email]> wrote:

Can you dig out more details around why it fails?

Sure, here's the lit output for the first three:

```
FAIL: Clang :: CXX/modules-ts/basic/basic.link/p2/module.cpp (1149 of 13760)
******************** TEST 'Clang :: CXX/modules-ts/basic/basic.link/p2/module.cpp' FAILED ********************
Script:
--
: 'RUN: at line 1';   /home/jdenny/ornl/llvm-mono-git-build/bin/clang -cc1 -internal-isystem /home/jdenny/ornl/llvm-mono-git-build/lib/clang/8.0.0/include -nostdsysteminc -std=c++1z -fmodules-ts /home/jdenny/ornl/llvm-mono-git/clang/test/CXX/modules-ts/basic/basic.link/p2/module.cppm -emit-module-interface -o /home/jdenny/ornl/llvm-mono-git-build/tools/clang/test/CXX/modules-ts/basic/basic.link/p2/Output/module.cpp.tmp
: 'RUN: at line 2';   /home/jdenny/ornl/llvm-mono-git-build/bin/clang -cc1 -internal-isystem /home/jdenny/ornl/llvm-mono-git-build/lib/clang/8.0.0/include -nostdsysteminc -std=c++1z -fmodules-ts -fmodule-file=/home/jdenny/ornl/llvm-mono-git-build/tools/clang/test/CXX/modules-ts/basic/basic.link/p2/Output/module.cpp.tmp /home/jdenny/ornl/llvm-mono-git/clang/test/CXX/modules-ts/basic/basic.link/p2/module.cpp -verify
--
Exit Code: 1

Command Output (stderr):
--
error: 'error' diagnostics seen but not expected:
 File /home/jdenny/ornl/llvm-mono-git/clang/test/CXX/modules-ts/basic/basic.link/p2/module.cpp Line 13: expected ';' after expression
 File /home/jdenny/ornl/llvm-mono-git/clang/test/CXX/modules-ts/basic/basic.link/p2/module.cpp Line 13: use of undeclared identifier 'internal_linkage_class'
2 errors generated.

This doesn't make sense to me -- why would a shared build have
different runtime behavior from a static build? I was expecting a
symbol resolution failure of some kind, but this looks like the
compiler comes out broken somehow.

I don't know about this specific case, but the difference in linker semantics for shared and static libraries is significant and can have an impact on runtime behavior. In my last email I just pointed out how llvm::cl::opt behaves differently between static and shared libs.

-Chris


The IWYU build fails on a plain undefined reference:
https://github.com/include-what-you-use/include-what-you-use/pull/632#issuecomment-452011176

Not sure if these are at all related, but the PCH failures piqued my interest.

- Kim


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: BUILD_SHARED_LIBS=True breaks some tests

David Blaikie via cfe-dev
In reply to this post by David Blaikie via cfe-dev
On Wed, Jan 9, 2019 at 3:34 PM Kim Gräsman <[hidden email]> wrote:
On Wed, Jan 9, 2019 at 4:40 PM Joel E. Denny <[hidden email]> wrote:
>
> On Wed, Jan 9, 2019 at 1:59 AM Kim Gräsman <[hidden email]> wrote:
>>
>> Can you dig out more details around why it fails?
>
> Sure, here's the lit output for the first three:
>
> ```
> FAIL: Clang :: CXX/modules-ts/basic/basic.link/p2/module.cpp (1149 of 13760)
> ******************** TEST 'Clang :: CXX/modules-ts/basic/basic.link/p2/module.cpp' FAILED ********************
> Script:
> --
> : 'RUN: at line 1';   /home/jdenny/ornl/llvm-mono-git-build/bin/clang -cc1 -internal-isystem /home/jdenny/ornl/llvm-mono-git-build/lib/clang/8.0.0/include -nostdsysteminc -std=c++1z -fmodules-ts /home/jdenny/ornl/llvm-mono-git/clang/test/CXX/modules-ts/basic/basic.link/p2/module.cppm -emit-module-interface -o /home/jdenny/ornl/llvm-mono-git-build/tools/clang/test/CXX/modules-ts/basic/basic.link/p2/Output/module.cpp.tmp
> : 'RUN: at line 2';   /home/jdenny/ornl/llvm-mono-git-build/bin/clang -cc1 -internal-isystem /home/jdenny/ornl/llvm-mono-git-build/lib/clang/8.0.0/include -nostdsysteminc -std=c++1z -fmodules-ts -fmodule-file=/home/jdenny/ornl/llvm-mono-git-build/tools/clang/test/CXX/modules-ts/basic/basic.link/p2/Output/module.cpp.tmp /home/jdenny/ornl/llvm-mono-git/clang/test/CXX/modules-ts/basic/basic.link/p2/module.cpp -verify
> --
> Exit Code: 1
>
> Command Output (stderr):
> --
> error: 'error' diagnostics seen but not expected:
>   File /home/jdenny/ornl/llvm-mono-git/clang/test/CXX/modules-ts/basic/basic.link/p2/module.cpp Line 13: expected ';' after expression
>   File /home/jdenny/ornl/llvm-mono-git/clang/test/CXX/modules-ts/basic/basic.link/p2/module.cpp Line 13: use of undeclared identifier 'internal_linkage_class'
> 2 errors generated.

This doesn't make sense to me -- why would a shared build have
different runtime behavior from a static build? I was expecting a
symbol resolution failure of some kind, but this looks like the
compiler comes out broken somehow.

The IWYU build fails on a plain undefined reference:
https://github.com/include-what-you-use/include-what-you-use/pull/632#issuecomment-452011176

Not sure if these are at all related, but the PCH failures piqued my interest.

I'm not sure if it helps you at this point, but here's the lit output for the remaining failures, most of which are PCH, and all of which represent behavior changes:

```
FAIL: Clang :: Modules/using-directive.cpp (6307 of 13760)
******************** TEST 'Clang :: Modules/using-directive.cpp' FAILED ********************
Script:
--
: 'RUN: at line 1';   /home/jdenny/ornl/llvm-mono-git-build/bin/clang -cc1 -internal-isystem /home/jdenny/ornl/llvm-mono-git-build/lib/clang/8.0.0/include -nostdsysteminc -fmodules -fmodules-local-submodule-visibility -fno-modules-error-recovery -fno-spell-checking -verify /home/jdenny/ornl/llvm-mono-git/clang/test/Modules/using-directive.cpp
--
Exit Code: 1

Command Output (stderr):
--
error: 'error' diagnostics seen but not expected:
  File /home/jdenny/ornl/llvm-mono-git/clang/test/Modules/using-directive.cpp Line 41: no member named 'n' in namespace 'c'
  File /home/jdenny/ornl/llvm-mono-git/clang/test/Modules/using-directive.cpp Line 47: use of undeclared identifier 'n'
  File /home/jdenny/ornl/llvm-mono-git/clang/test/Modules/using-directive.cpp Line 52: use of undeclared identifier 'n'
  File /home/jdenny/ornl/llvm-mono-git/clang/test/Modules/using-directive.cpp Line 53: no member named 'n' in the global namespace
  File /home/jdenny/ornl/llvm-mono-git/clang/test/Modules/using-directive.cpp Line 55: no member named 'n' in namespace 'c'
  File /home/jdenny/ornl/llvm-mono-git/clang/test/Modules/using-directive.cpp Line 61: use of undeclared identifier 'n'
6 errors generated.

--

********************
FAIL: Clang :: PCH/chain-late-anonymous-namespace.cpp (7180 of 13760)
******************** TEST 'Clang :: PCH/chain-late-anonymous-namespace.cpp' FAILED ********************
Script:
--
: 'RUN: at line 2';   /home/jdenny/ornl/llvm-mono-git-build/bin/clang -cc1 -internal-isystem /home/jdenny/ornl/llvm-mono-git-build/lib/clang/8.0.0/include -nostdsysteminc -include /home/jdenny/ornl/llvm-mono-git/clang/test/PCH/chain-late-anonymous-namespace.cpp -include /home/jdenny/ornl/llvm-mono-git/clang/test/PCH/chain-late-anonymous-namespace.cpp -fsyntax-only /home/jdenny/ornl/llvm-mono-git/clang/test/PCH/chain-late-anonymous-namespace.cpp
: 'RUN: at line 4';   /home/jdenny/ornl/llvm-mono-git-build/bin/clang -cc1 -internal-isystem /home/jdenny/ornl/llvm-mono-git-build/lib/clang/8.0.0/include -nostdsysteminc -chain-include /home/jdenny/ornl/llvm-mono-git/clang/test/PCH/chain-late-anonymous-namespace.cpp -chain-include /home/jdenny/ornl/llvm-mono-git/clang/test/PCH/chain-late-anonymous-namespace.cpp -fsyntax-only /home/jdenny/ornl/llvm-mono-git/clang/test/PCH/chain-late-anonymous-namespace.cpp
: 'RUN: at line 6';   /home/jdenny/ornl/llvm-mono-git-build/bin/clang -cc1 -internal-isystem /home/jdenny/ornl/llvm-mono-git-build/lib/clang/8.0.0/include -nostdsysteminc -chain-include /home/jdenny/ornl/llvm-mono-git/clang/test/PCH/chain-late-anonymous-namespace.cpp -chain-include /home/jdenny/ornl/llvm-mono-git/clang/test/PCH/chain-late-anonymous-namespace.cpp -fsyntax-only -fmodules /home/jdenny/ornl/llvm-mono-git/clang/test/PCH/chain-late-anonymous-namespace.cpp
--
Exit Code: 1

Command Output (stderr):
--
/home/jdenny/ornl/llvm-mono-git/clang/test/PCH/chain-late-anonymous-namespace.cpp:43:11: error: use of undeclared identifier 'x'
    (void)x;
          ^
/home/jdenny/ornl/llvm-mono-git/clang/test/PCH/chain-late-anonymous-namespace.cpp:51:9: error: use of undeclared identifier 'y'
  (void)y;
        ^
/home/jdenny/ornl/llvm-mono-git/clang/test/PCH/chain-late-anonymous-namespace.cpp:59:11: error: use of undeclared identifier 'z'
    (void)z;
          ^
3 errors generated.

--

********************
FAIL: Clang :: PCH/cxx-namespaces.cpp (7215 of 13760)
******************** TEST 'Clang :: PCH/cxx-namespaces.cpp' FAILED ********************
Script:
--
: 'RUN: at line 2';   /home/jdenny/ornl/llvm-mono-git-build/bin/clang -cc1 -internal-isystem /home/jdenny/ornl/llvm-mono-git-build/lib/clang/8.0.0/include -nostdsysteminc -include /home/jdenny/ornl/llvm-mono-git/clang/test/PCH/cxx-namespaces.h -fsyntax-only -verify /home/jdenny/ornl/llvm-mono-git/clang/test/PCH/cxx-namespaces.cpp
: 'RUN: at line 5';   /home/jdenny/ornl/llvm-mono-git-build/bin/clang -cc1 -internal-isystem /home/jdenny/ornl/llvm-mono-git-build/lib/clang/8.0.0/include -nostdsysteminc -x c++-header -emit-pch -o /home/jdenny/ornl/llvm-mono-git-build/tools/clang/test/PCH/Output/cxx-namespaces.cpp.tmp /home/jdenny/ornl/llvm-mono-git/clang/test/PCH/cxx-namespaces.h
: 'RUN: at line 6';   /home/jdenny/ornl/llvm-mono-git-build/bin/clang -cc1 -internal-isystem /home/jdenny/ornl/llvm-mono-git-build/lib/clang/8.0.0/include -nostdsysteminc -include-pch /home/jdenny/ornl/llvm-mono-git-build/tools/clang/test/PCH/Output/cxx-namespaces.cpp.tmp -fsyntax-only -verify /home/jdenny/ornl/llvm-mono-git/clang/test/PCH/cxx-namespaces.cpp
: 'RUN: at line 7';   /home/jdenny/ornl/llvm-mono-git-build/bin/clang -cc1 -internal-isystem /home/jdenny/ornl/llvm-mono-git-build/lib/clang/8.0.0/include -nostdsysteminc -include-pch /home/jdenny/ornl/llvm-mono-git-build/tools/clang/test/PCH/Output/cxx-namespaces.cpp.tmp -fsyntax-only -ast-dump-lookups -ast-dump-filter N /home/jdenny/ornl/llvm-mono-git/clang/test/PCH/cxx-namespaces.cpp | /home/jdenny/ornl/llvm-mono-git-build/bin/FileCheck /home/jdenny/ornl/llvm-mono-git/clang/test/PCH/cxx-namespaces.cpp
: 'RUN: at line 10';   /home/jdenny/ornl/llvm-mono-git-build/bin/clang -cc1 -internal-isystem /home/jdenny/ornl/llvm-mono-git-build/lib/clang/8.0.0/include -nostdsysteminc -fmodules -x c++-header -emit-pch -o /home/jdenny/ornl/llvm-mono-git-build/tools/clang/test/PCH/Output/cxx-namespaces.cpp.tmp /home/jdenny/ornl/llvm-mono-git/clang/test/PCH/cxx-namespaces.h
: 'RUN: at line 11';   /home/jdenny/ornl/llvm-mono-git-build/bin/clang -cc1 -internal-isystem /home/jdenny/ornl/llvm-mono-git-build/lib/clang/8.0.0/include -nostdsysteminc -fmodules -include-pch /home/jdenny/ornl/llvm-mono-git-build/tools/clang/test/PCH/Output/cxx-namespaces.cpp.tmp -fsyntax-only -verify /home/jdenny/ornl/llvm-mono-git/clang/test/PCH/cxx-namespaces.cpp
: 'RUN: at line 12';   /home/jdenny/ornl/llvm-mono-git-build/bin/clang -cc1 -internal-isystem /home/jdenny/ornl/llvm-mono-git-build/lib/clang/8.0.0/include -nostdsysteminc -fmodules -include-pch /home/jdenny/ornl/llvm-mono-git-build/tools/clang/test/PCH/Output/cxx-namespaces.cpp.tmp -fsyntax-only -ast-dump-lookups -ast-dump-filter N /home/jdenny/ornl/llvm-mono-git/clang/test/PCH/cxx-namespaces.cpp | /home/jdenny/ornl/llvm-mono-git-build/bin/FileCheck /home/jdenny/ornl/llvm-mono-git/clang/test/PCH/cxx-namespaces.cpp
--
Exit Code: 1

Command Output (stderr):
--
error: 'error' diagnostics seen but not expected:
  File /home/jdenny/ornl/llvm-mono-git/clang/test/PCH/cxx-namespaces.cpp Line 17: no member named 'x' in namespace 'N'
1 error generated.

--

********************
FAIL: Clang :: PCH/namespaces.cpp (7294 of 13760)
******************** TEST 'Clang :: PCH/namespaces.cpp' FAILED ********************
Script:
--
: 'RUN: at line 2';   /home/jdenny/ornl/llvm-mono-git-build/bin/clang -cc1 -internal-isystem /home/jdenny/ornl/llvm-mono-git-build/lib/clang/8.0.0/include -nostdsysteminc -x c++ -include /home/jdenny/ornl/llvm-mono-git/clang/test/PCH/Inputs/namespaces.h -fsyntax-only /home/jdenny/ornl/llvm-mono-git/clang/test/PCH/namespaces.cpp
: 'RUN: at line 5';   /home/jdenny/ornl/llvm-mono-git-build/bin/clang -cc1 -internal-isystem /home/jdenny/ornl/llvm-mono-git-build/lib/clang/8.0.0/include -nostdsysteminc -x c++ -emit-pch -o /home/jdenny/ornl/llvm-mono-git-build/tools/clang/test/PCH/Output/namespaces.cpp.tmp /home/jdenny/ornl/llvm-mono-git/clang/test/PCH/Inputs/namespaces.h
: 'RUN: at line 6';   /home/jdenny/ornl/llvm-mono-git-build/bin/clang -cc1 -internal-isystem /home/jdenny/ornl/llvm-mono-git-build/lib/clang/8.0.0/include -nostdsysteminc -x c++ -include-pch /home/jdenny/ornl/llvm-mono-git-build/tools/clang/test/PCH/Output/namespaces.cpp.tmp -fsyntax-only /home/jdenny/ornl/llvm-mono-git/clang/test/PCH/namespaces.cpp
--
Exit Code: 1

Command Output (stderr):
--
/home/jdenny/ornl/llvm-mono-git/clang/test/PCH/namespaces.cpp:18:1: error: unknown type name 't3'; did you mean 'N2::Inner::t3'?
t3 *ip5 = &int_val;
^~
N2::Inner::t3
/home/jdenny/ornl/llvm-mono-git/clang/test/PCH/Inputs/namespaces.h:19:17: note: 'N2::Inner::t3' declared here
    typedef int t3;
                ^
/home/jdenny/ornl/llvm-mono-git/clang/test/PCH/namespaces.cpp:20:18: error: use of undeclared identifier 'anon'
void(*funp1)() = anon;
                 ^
/home/jdenny/ornl/llvm-mono-git/clang/test/PCH/namespaces.cpp:25:1: error: unknown type name 'C'
C* cp1;
^
/home/jdenny/ornl/llvm-mono-git/clang/test/PCH/namespaces.cpp:33:5: error: no type named 'C' in namespace 'N3'
N3::C *cp2;
~~~~^
4 errors generated.

--
```

Joel


- Kim

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: BUILD_SHARED_LIBS=True breaks some tests

David Blaikie via cfe-dev
In reply to this post by David Blaikie via cfe-dev
On Wed, Jan 9, 2019 at 9:49 PM Chris Bieneman <[hidden email]> wrote:
>
> > This doesn't make sense to me -- why would a shared build have
> > different runtime behavior from a static build? I was expecting a
> > symbol resolution failure of some kind, but this looks like the
> > compiler comes out broken somehow.
>
> I don't know about this specific case, but the difference in linker semantics for shared and static
> libraries is significant and can have an impact on runtime behavior. In my last email I just pointed
> out how llvm::cl::opt behaves differently between static and shared libs.

Sure, but the only problems I can think of off-hand are global
initialization order/duplication and possible fallout from ODR
violations. Both seem like latent bugs, especially the latter. But
maybe I'm missing something more subtle...

It's just curious that IWYU has a link failure on
PCHContainerOperations and Clang's test suite fails for stuff related
to it, both under BUILD_SHARED_LIBS.

Thanks,
- Kim
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev