When using MacPorts GCC on OS X and enlisting the Clang Integrated Assembler via -Wa,-q, the assembler produces a stream of warnings for each file. A simple test case is shown below (but a real project produces thousands of them). I found LLVM Commit r250349, Stop generating coal sections. Here's the code responsible, but its not clear to me how to disable the warning. + // Issue a warning if the target is not powerpc and Section is a *coal* section. + Triple TT = getParser().getContext().getObjectFileInfo()->getTargetTriple(); + Triple::ArchType ArchTy = TT.getArch(); + + if (ArchTy != Triple::ppc && ArchTy != Triple::ppc64) { + StringRef NonCoalSection = StringSwitch<StringRef>(Section) + .Case("__textcoal_nt", "__text") + .Case("__const_coal", "__const") + .Case("__datacoal_nt", "__data") + .Default(Section); + + if (!Section.equals(NonCoalSection)) { + StringRef SectionVal(Loc.getPointer()); + size_t B = SectionVal.find(',') + 1, E = SectionVal.find(',', B); + SMLoc BLoc = SMLoc::getFromPointer(SectionVal.data() + B); + SMLoc ELoc = SMLoc::getFromPointer(SectionVal.data() + E); + getParser().Warning(Loc, "section \"" + Section + "\" is deprecated", + SMRange(BLoc, ELoc)); + getParser().Note(Loc, "change section name to \"" + NonCoalSection + + "\"", SMRange(BLoc, ELoc)); + } + } + ********** The test case depends upon -g2 and -O2. if I omit them, then the warnings are not present. $ cat test.cxx #include <iostream> #include <algorithm> int main(int argc, char* argv[]) { std::for_each(argv, argv+argc, [](char* str) {std::cout << str << std::endl;}); return 0; } $ /opt/local/bin/g++-mp-6 -march=native -g2 -O2 -std=c++11 -Wa,-q test.cxx -o test.exe /var/folders/mk/y7lk0xrx72lcn_2q3d12jcch0000gn/T//cc1dR6yG.s:3:11: warning: section "__textcoal_nt" is deprecated .section __TEXT,__textcoal_nt,coalesced,pure_instructions ^ ~~~~~~~~~~~~~ /var/folders/mk/y7lk0xrx72lcn_2q3d12jcch0000gn/T//cc1dR6yG.s:3:11: note: change section name to "__text" .section __TEXT,__textcoal_nt,coalesced,pure_instructions ^ ~~~~~~~~~~~~~ ********** When the MacPorts GCC compiler encounters -Wa,-q, it uses /opt/local/bin/clang as the assembler rather than /opt/local/bin/as. Here are the relevant versions. $ /opt/local/bin/g++-mp-6 --version g++-mp-6 (MacPorts gcc6 6.1.0_0) 6.1.0 Copyright (C) 2016 Free Software Foundation, Inc. $ /opt/local/bin/clang --version clang version 3.8.0 (branches/release_38 262722) Target: x86_64-apple-darwin12.6.0 $ /opt/local/bin/as -version Apple Inc version cctools-877.8, GNU assembler version 1.38
Also see LLVM Issue 28427, "Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler", https://llvm.org/bugs/show_bug.cgi?id=28427.
Note darwin GCC emits them for weak symbols still: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/darwin.c;h=0055d8054415ffa229bc69b22e02b9678ecc2c56;hb=HEAD 3616 /* Otherwise, default to the 'normal' non-reordered sections. */ 3617 default_function_sections: 3618 return (weak) ? darwin_sections[text_coal_section] 3619 : text_section; If the coal section is deprecated, what is the replacement ones?
http://llvm.org/viewvc/llvm-project?view=revision&revision=250349
I see the problem after having updated to Xcode 8.0. I am currently testing the following patch --- ../_clean/gcc/config/darwin-sections.def 2016-01-04 19:51:16.000000000 +0100 +++ gcc/config/darwin-sections.def 2016-09-14 12:01:44.000000000 +0200 @@ -29,7 +29,7 @@ along with GCC; see the file COPYING3. /* The .text section is generated in varasm.c */ DEF_SECTION (text_coal_section, SECTION_CODE|SECTION_NO_ANCHOR, - ".section __TEXT,__textcoal_nt,coalesced,pure_instructions", 0) + ".section __TEXT,__text,coalesced,pure_instructions", 0) DEF_SECTION (text_hot_section, SECTION_CODE, ".section __TEXT,__text_hot,regular,pure_instructions", 0) @@ -52,7 +52,7 @@ DEF_SECTION (text_exit_coal_section, SEC /* const */ DEF_SECTION (const_section, 0, ".const", 0) DEF_SECTION (const_coal_section, SECTION_NO_ANCHOR, - ".section __TEXT,__const_coal,coalesced", 0) + ".section __TEXT,__const,coalesced", 0) /* Place to put zero-sized to avoid issues with section anchors. */ DEF_SECTION (zobj_const_section, SECTION_NO_ANCHOR, ".section\t__DATA,__zobj_const", 0) @@ -60,7 +60,7 @@ DEF_SECTION (zobj_const_section, SECTION /* Write-able data. '.data' handled in varasm.c */ DEF_SECTION (static_data_section, SECTION_WRITE, ".static_data", 0) DEF_SECTION (data_coal_section, SECTION_WRITE|SECTION_NO_ANCHOR, - ".section __DATA,__datacoal_nt,coalesced", 0) + ".section __DATA,__data,coalesced", 0) /* Place to put zero-sized to avoid issues with section anchors. */ DEF_SECTION (zobj_data_section, SECTION_WRITE|SECTION_NO_ANCHOR, ".section\t__DATA,__zobj_data", 0) @@ -73,7 +73,7 @@ DEF_SECTION (zobj_bss_section, SECTION_W /* const data */ DEF_SECTION (const_data_section, 0, ".const_data", 0) DEF_SECTION (const_data_coal_section, SECTION_NO_ANCHOR, - ".section __DATA,__const_coal,coalesced", 0) + ".section __DATA,__const,coalesced", 0) /* Place to put zero-sized to avoid issues with section anchors. */ DEF_SECTION (zobj_const_data_section, SECTION_NO_ANCHOR, ".section\t__DATA,__zobj_cnst_data", 0) --- ../_clean/libffi/src/x86/sysv.S 2015-01-19 23:40:03.000000000 +0100 +++ libffi/src/x86/sysv.S 2016-09-14 12:04:05.000000000 +0200 @@ -790,7 +790,7 @@ ENDF(C(ffi_closure_raw_THISCALL)) #ifdef X86_DARWIN # define COMDAT(X) \ - .section __TEXT,__textcoal_nt,coalesced,pure_instructions; \ + .section __TEXT,__text,coalesced,pure_instructions; \ .weak_definition X; \ .private_extern X #elif defined __ELF__ && !(defined(__sun__) && defined(__svr4__)) --- ../_clean/gcc/testsuite/g++.dg/abi/key2.C 2014-05-10 23:18:30.000000000 +0200 +++ gcc/testsuite/g++.dg/abi/key2.C 2016-09-14 12:03:17.000000000 +0200 @@ -2,9 +2,9 @@ // PR darwin/25908 // { dg-do compile { target *-*-darwin* } } -// { dg-final { scan-assembler ".globl __ZTV1f\\n .weak_definition __ZTV1f(\\n .section __DATA,__const_coal,coalesced)?\\n .align" } } -// { dg-final { scan-assembler ".globl __ZTS1f\\n .weak_definition __ZTS1f\\n .section __TEXT,__const_coal,coalesced" } } -// { dg-final { scan-assembler ".globl __ZTI1f\\n .weak_definition __ZTI1f(\\n .section __DATA,__const_coal,coalesced)?\\n .align" } } +// { dg-final { scan-assembler ".globl __ZTV1f\\n .weak_definition __ZTV1f(\\n .section __DATA,__const,coalesced)?\\n .align" } } +// { dg-final { scan-assembler ".globl __ZTS1f\\n .weak_definition __ZTS1f\\n .section __TEXT,__const,coalesced" } } +// { dg-final { scan-assembler ".globl __ZTI1f\\n .weak_definition __ZTI1f(\\n .section __DATA,__const,coalesced)?\\n .align" } } class f {
(In reply to Dominique d'Humieres from comment #4) > I see the problem after having updated to Xcode 8.0. I am currently testing > the following patch > Just an FYI... Clang 3.7 and below do not witness the problem. Clang 3.8 and above do. If you are working on OS X and want to avoid iTunes accounts and the App Store, then you can duplicate with MacPorts: # port install clang-3.8 # port install gcc6 # ln -s /opt/local/bin/clang /opt/local/bin/clang-3.8 (My apologies if I got the link backwards; I always do it in real life, too). Then: CC=/opt/local/bin/gcc-mp-6 CFLAGS="-Wa,-q" make Creating the link and using the full path allows you to keep MacPorts off-path. I keep it off-path to avoid cross-pollination in a testing environment.
> Just an FYI... Clang 3.7 and below do not witness the problem. > Clang 3.8 and above do. > ... Thanks for the tip, but I don't use MacPorts. I am building and testing gcc myself with the Apple's tools with a previous version of gcc (currently r240001) as the bootstrap compiler (to build Ada).
(In reply to Dominique d'Humieres from comment #4) > I see the problem after having updated to Xcode 8.0. I am currently testing > the following patch > /* The .text section is generated in varasm.c */ > DEF_SECTION (text_coal_section, SECTION_CODE|SECTION_NO_ANCHOR, > - ".section __TEXT,__textcoal_nt,coalesced,pure_instructions", 0) > + ".section __TEXT,__text,coalesced,pure_instructions", 0) actually, we need to come up with a patch that simply emits the text/etc. section whenever it would have emitted the text_coal/etc. one.. So rather than adjusting section definitions - we need to change which ones are selected in config/darwin.c .. but this should be conditional on a new enough linker to support it, or we will break support for folks on ancient systems. Is this repeatable without xcode8? I have some patches in progress to detect the linker features at configuration time, so that we don't need to rely on guessing from the host system version. If this is not detectable by a linker feature, them perhaps we can determine the earliest linker that can manage without the separate sections (most likely considerably older than the one from Xcode8).
(In reply to Iain Sandoe from comment #7) > (In reply to Dominique d'Humieres from comment #4) > > I see the problem after having updated to Xcode 8.0. I am currently testing > > the following patch > > > /* The .text section is generated in varasm.c */ > > DEF_SECTION (text_coal_section, SECTION_CODE|SECTION_NO_ANCHOR, > > - ".section __TEXT,__textcoal_nt,coalesced,pure_instructions", 0) > > + ".section __TEXT,__text,coalesced,pure_instructions", 0) > > actually, we need to come up with a patch that simply emits the text/etc. > section whenever it would have emitted the text_coal/etc. one.. So rather > than adjusting section definitions - we need to change which ones are > selected in config/darwin.c > > .. but this should be conditional on a new enough linker to support it, or > we will break support for folks on ancient systems. Is this repeatable > without xcode8? Yes, it is repeatable with Xcode 8. Someone else mentioned they duplicatd with it. > I have some patches in progress to detect the linker features at > configuration time, be careful here. You use the new linker when -wa,-q is present. The new linker is the one in Clang Integrated Assembler. You use the old Apple ld when -Wa,-q is _not_present. Or maybe mor correctly, you just use ld. > so that we don't need to rely on guessing from the host > system version. I _think_ you can detect which linker at runtime with something like the following: IS_GAS := $(shell $(CXX) -xc -c /dev/null -Wa,-v -o/dev/null 2>&1 | $(EGREP) -c "GNU assembler") Now, ld returns the string "GNU assembler". Clang returns the string "clang: error: unsupported argument '--version' to option 'Wa,'". The LLVM folks may have fixed it in https://llvm.org/bugs/show_bug.cgi?id=24200. A quick check with Clang-3.8 using MacPort compiler shows its not fixed: $ /opt/local/bin/clang-mp-3.8 -xc -c /dev/null -Wa,--version -o/dev/null 2>&1 clang: error: unsupported argument '--version' to option 'Wa,' > If this is not detectable by a linker feature, them perhaps > we can determine the earliest linker that can manage without the separate > sections (most likely considerably older than the one from Xcode8). I don't know about some of the other options available to you. Maybe the "safety valve" should be another option? I'm already doing "-Wa,-q"; another `-Wa,-x` won't other me. Jeff
(In reply to Jeffrey Walton from comment #8) > (In reply to Iain Sandoe from comment #7) > > (In reply to Dominique d'Humieres from comment #4) > > > I see the problem after having updated to Xcode 8.0. I am currently testing > > > the following patch > > > > > /* The .text section is generated in varasm.c */ > > > DEF_SECTION (text_coal_section, SECTION_CODE|SECTION_NO_ANCHOR, > > > - ".section __TEXT,__textcoal_nt,coalesced,pure_instructions", 0) > > > + ".section __TEXT,__text,coalesced,pure_instructions", 0) > > > > actually, we need to come up with a patch that simply emits the text/etc. > > section whenever it would have emitted the text_coal/etc. one.. So rather > > than adjusting section definitions - we need to change which ones are > > selected in config/darwin.c > > > > .. but this should be conditional on a new enough linker to support it, or > > we will break support for folks on ancient systems. Is this repeatable > > without xcode8? > > Yes, it is repeatable with Xcode 8. Someone else mentioned they duplicatd > with it. without xcode8 - I don't have Xcode8 installed on any system presently. > > I have some patches in progress to detect the linker features at > > configuration time, > > be careful here. You use the new linker when -wa,-q is present. The new > linker is the one in Clang Integrated Assembler. You use the old Apple ld > when -Wa,-q is _not_present. Or maybe mor correctly, you just use ld. > > > so that we don't need to rely on guessing from the host > > system version. > > I _think_ you can detect which linker at runtime with something like the > following: > > IS_GAS := $(shell $(CXX) -xc -c /dev/null -Wa,-v -o/dev/null 2>&1 | $(EGREP) > -c "GNU assembler") > > Now, ld returns the string "GNU assembler". Clang returns the string "clang: > error: unsupported argument '--version' to option 'Wa,'". you are conflating two things (and coming to a mixed conclusion as a result): 1. a version of the linker (ld64) that's capable of responding to the relevant flags and operating correctly without coalesced sections to help it deal (see the description of operation that Andrew pointed to in c #3). 2. a version of the LLVM back-end which is invoked by the cctools as (effectively calling clang). Which emits a warning when the section types are emitted that are no longer needed by 1 (but, note, _are_ needed by older linkers); the LLVM test added to gate the warning should really have been on the target linker version, not on the arch type. ==== So .. IFF we have a ld64 which is sufficiently modern (number / feature test TBD) we don't need to emit the old _coal sections. If we have an old linker (say ld64-85.2.1 since the LLVM commit discussion mentions ppc), then we need to continue to emit the coal sections. Essentially, the test and changes needed are to determine the linker (ld64's) capability; we ought not be in a position where we detect that the ld64 is too old at the same time as trying to use the LLVM back end as the assembler.
> than adjusting section definitions - we need to change which ones are >> > selected in config/darwin.c >> > >> I _think_ you can detect which linker at runtime with something like the >> following: >> >> IS_GAS := $(shell $(CXX) -xc -c /dev/null -Wa,-v -o/dev/null 2>&1 | $(EGREP) >> -c "GNU assembler") >> >> Now, ld returns the string "GNU assembler". Clang returns the string "clang: >> error: unsupported argument '--version' to option 'Wa,'". > > you are conflating two things (and coming to a mixed conclusion as a result): Ah, you're right Ian. I mixed up the assembler and linker. I expereinced so many problem in the past with Clang's integrated assembler, its burned into my frontal lobe. Sorry about that. Jeff
(In reply to Jeffrey Walton from comment #5) > # port install clang-3.8 > # port install gcc6 > # ln -s /opt/local/bin/clang /opt/local/bin/clang-3.8 You probably meant: $ ln -s clang-mp-3.8 /opt/local/bin/clang However, don't create the symlink yourself. Use 'sudo port select clang mp-clang-3.8'
(In reply to Iain Sandoe from comment #9) > we ought not be in a position where we detect that the ld64 is too old at > the same time as trying to use the LLVM back end as the assembler. It is possible for someone to manually force themselves into such a situation, but that is not a configuration we (Apple, MacPorts, LLVM, GCC) should support.
Test failures with the patch in comment 4 FAIL: g++.old-deja/g++.pt/static11.C -std=c++11 (test for excess errors) FAIL: g++.old-deja/g++.pt/static11.C -std=c++14 (test for excess errors) FAIL: g++.old-deja/g++.pt/static11.C -std=c++98 (test for excess errors) -m32 only FAIL: obj-c++.dg/qual-types-1.mm -fgnu-runtime (test for excess errors) for both -m32 and -m64 FAIL: libgomp.c++/taskloop-6.C (test for excess errors) -m32 only === libstdc++ tests === Running target unix/-m32 FAIL: 20_util/scoped_allocator/1.cc (test for excess errors) FAIL: 20_util/scoped_allocator/2.cc (test for excess errors) FAIL: 21_strings/basic_string/allocator/char/copy.cc (test for excess errors) ... FAIL: tr1/6_containers/unordered_set/swap/1.cc (test for excess errors) FAIL: tr1/6_containers/unordered_set/swap/2.cc (test for excess errors) === libstdc++ Summary for unix/-m32 === # of expected passes 9965 # of unexpected failures 426 # of expected failures 65 # of unsupported tests 663 Running target unix/-m64 === libstdc++ Summary for unix/-m64 === # of expected passes 10389 # of expected failures 65 # of unsupported tests 664 === libstdc++ Summary === # of expected passes 20354 # of unexpected failures 426 # of expected failures 130 # of unsupported tests 1327 The failures are of the kind [Book15] f90/bug% /opt/gcc/gcc7w/bin/g++ /opt/gcc/_clean/gcc/testsuite/g++.old-deja/g++.pt/static11.C -std=c++98 -m32 ld: warning: direct access in function '__static_initialization_and_destruction_0(int, int)' from file '/var/folders/8q/sh_swgz96r7f5vnn08f7fxr00000gn/T//ccPdDjOW.o' to global weak symbol 'guard variable for C<int>::a' from file '/var/folders/8q/sh_swgz96r7f5vnn08f7fxr00000gn/T//ccPdDjOW.o' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
Created attachment 39638 [details] exhaustive results for libstdc++ with Xcode 8 + patch Silenced with + # Ignore harmless warnings from Xcode 8.0. + regsub -all "(^|\n)ld: warning: direct access in function\[^\n\]* means the weak symbol cannot be overridden\[^\n\]*" $text "" text in libstdc++-v3/testsuite/lib/prune.exp.
Created attachment 39639 [details] assembly for g++.old-deja/g++.pt/static11.C with Xcode 8 + patch and -m32
(In reply to Dominique d'Humieres from comment #14) > Created attachment 39638 [details] > exhaustive results for libstdc++ with Xcode 8 + patch > > Silenced with > > + # Ignore harmless warnings from Xcode 8.0. > + regsub -all "(^|\n)ld: warning: direct access in function\[^\n\]* means > the weak symbol cannot be overridden\[^\n\]*" $text "" text > > in libstdc++-v3/testsuite/lib/prune.exp. Unfortunately, these are not really harmless - since they flag that ld64 is getting confused by GCC's output (another atom problem).
So.. we need a patch that implements what Dominique was trying (but in a way that doesn't involve discarding the original section defs. since they are needed for "older linker" - for some def. of "older"). 1. a patch that changes the section usage depending on the capability of ld64. ... I have a patch under test for this. 2. configury to detect if we have a ld64 that doesn't cope (and we need to find one that doesn't to test that). My initial tests suggest that even 85.2.1 can do the week symbol coalescing without the sections, so we might have to poke at a 10.4 system to find this. ... TODO 3. The fallout that Dominique sees with his patch is caused by two latent issues: .data weak symbol ... L_xxxxxxx$non_lazy_ptr
(In reply to Iain Sandoe from comment #17) oops hit send at the wrong moment: > So.. we need a patch that implements what Dominique was trying (but in a way > that doesn't involve discarding the original section defs. since they are > needed for "older linker" - for some def. of "older"). > 1. a patch that changes the section usage depending on the capability of ld64. ... I have a patch under test for this. 2. configury to detect if we have a ld64 that doesn't cope (and we need to find one that doesn't to test that). My initial tests suggest that even 85.2.1 can do the week symbol coalescing without the sections, so we might have to poke at a 10.4 system to find this. ... TODO 3. The fallout that Dominique sees with his patch is caused by two latent issues: .data weak symbol ... L_xxxxxxx$non_lazy_ptr .yyyyy _symbol now - ld64 can't split L_xxxxxxx$non_lazy_ptr from the weak symbol (since it's L_xxx) and it means that the atom containing the indirection is now marked weak - and we are accessing it directly. This is what ld64's warming is about. .... I have a patch that sorts this one out (and squashes most of the libstdc++ fallout) ... but there's a similar problem with weak constants followed by non-weak ones (which are local and legitimately directly referenced in the tu). ... TODO. I'll attach a WIP in patch here, when 1 && 3 are solved (it's testable without 2).
Created attachment 39659 [details] proposed patch set. So I think this is working reasonably, but haven't tested fully across the range of Darwins yet == have a go please! There are 4 patches here: 1. A patch that solves a latent problem with atom-recognition where a non-weak-local follows a weak-global in a data or const sections. This is exposed by the fixes for the actual bug. (needed once patch 3 is applied) 2a. A patch that allows ld64 to be recognized as a linker, and picks up its version (and as an example also checks support for -export_dynamic) - this was part of another patch set but is needed now to support patch 3 (which actually solves the PR) 2b - just the regenerated config files for 2a. 3. This is the one that does the actual fix, by switching section use when the linker supports merging of weak stuff without special sections - we might be able to refine the 'earliest linker' version somewhat - this only represents what I could test reasonably quickly. The patch provides a target flag "-mtarget-linker" (after the similarly-named LLVM one) and uses it to determine if the linker needs coalesced sections to deal with weak symbols. If not, then we emit in the regular sections. - needed a tweak to config/i386.c to allow for PICbase thunk output to be switched to a non-coalesced section too.
Created attachment 39661 [details] patchset cf 240230 patchset rebased to 240230 - should apply cleanly.
(In reply to Iain Sandoe from comment #20) > Created attachment 39661 [details] > patchset cf 240230 > > > patchset rebased to 240230 - should apply cleanly. As Dominique pointed out last night, g++.dg/abi/key2.C needs adjustment. This is supposed to test that we emit the right sections for things that need coalescing - which now only applies to older linkers. So the fix here is to make it test for correct output with a forced old linker. We could add a new test to see that the non _coal,coalesced sections are emitted for new linkers, but that's probably a moot point since many other tests would fails (as per this PR). --- diff --git a/gcc/testsuite/g++.dg/abi/key2.C b/gcc/testsuite/g++.dg/abi/key2.C index 0d1347a..c79b3b2 100644 --- a/gcc/testsuite/g++.dg/abi/key2.C +++ b/gcc/testsuite/g++.dg/abi/key2.C @@ -2,6 +2,7 @@ // PR darwin/25908 // { dg-do compile { target *-*-darwin* } } +// { dg-options "-mtarget-linker 85.2" } // { dg-final { scan-assembler ".globl __ZTV1f\\n .weak_definition __ZTV1f(\\n .section __DATA,__const_coal,coalesced)?\\n .align" } } // { dg-final { scan-assembler ".globl __ZTS1f\\n .weak_definition __ZTS1f\\n .section __TEXT,__const_coal,coalesced" } } // { dg-final { scan-assembler ".globl __ZTI1f\\n .weak_definition __ZTI1f(\\n .section __DATA,__const_coal,coalesced)?\\n .align" } }
When a fix is designed, could you please backport it to the 6 branch (so it can make it into 6.3 for example)? It is also affected.
(In reply to Francois-Xavier Coudert from comment #22) > When a fix is designed, could you please backport it to the 6 branch (so it > can make it into 6.3 for example)? It is also affected. sure, "all open branches" would be the intent.
The patch in comment 20 (and SDK 10.9) causes the failures of the tests gcc.dg/torture/darwin-cfstring-3.c and g++.dg/torture/darwin-cfstring-3.C with -m32, see https://gcc.gnu.org/ml/gcc-testresults/2016-09/msg02290.html. These failures are due to the fact that lC is now emitted instead of LC and are silenced with the following patch --- ../_clean/gcc/testsuite/gcc.dg/torture/darwin-cfstring-3.c 2014-05-10 23:16:48.000000000 +0200 +++ gcc/testsuite/gcc.dg/torture/darwin-cfstring-3.c 2016-09-24 17:03:58.000000000 +0200 @@ -24,7 +24,7 @@ void foo(void) { s0 = s1; } -/* { dg-final { scan-assembler "\\.long\[ \\t\]+___CFConstantStringClassReference\n\[ \\t\]*\\.long\[ \\t\]+1992\n\[ \\t\]*\\.long\[ \\t\]+LC.*\n\[ \\t\]*\\.long\[ \\t\]+4\n" { target { *-*-darwin* && { ! lp64 } } } } } */ -/* { dg-final { scan-assembler "\\.long\[ \\t\]+___CFConstantStringClassReference\n\[ \\t\]*\\.long\[ \\t\]+1992\n\[ \\t\]*\\.long\[ \\t\]+LC.*\n\[ \\t\]*\\.long\[ \\t\]+10\n" { target { *-*-darwin* && { ! lp64 } } } } } */ +/* { dg-final { scan-assembler "\\.long\[ \\t\]+___CFConstantStringClassReference\n\[ \\t\]*\\.long\[ \\t\]+1992\n\[ \\t\]*\\.long\[ \\t\]+\[lL\]C.*\n\[ \\t\]*\\.long\[ \\t\]+4\n" { target { *-*-darwin* && { ! lp64 } } } } } */ +/* { dg-final { scan-assembler "\\.long\[ \\t\]+___CFConstantStringClassReference\n\[ \\t\]*\\.long\[ \\t\]+1992\n\[ \\t\]*\\.long\[ \\t\]+\[lL\]C.*\n\[ \\t\]*\\.long\[ \\t\]+10\n" { target { *-*-darwin* && { ! lp64 } } } } } */ /* { dg-final { scan-assembler ".quad\t___CFConstantStringClassReference\n\t.long\t1992\n\t.space 4\n\t.quad\t.*\n\t.quad\t4\n" { target { *-*-darwin* && { lp64 } } } } } */ /* { dg-final { scan-assembler ".quad\t___CFConstantStringClassReference\n\t.long\t1992\n\t.space 4\n\t.quad\t.*\n\t.quad\t10\n" { target { *-*-darwin* && { lp64 } } } } } */ --- ../_clean/gcc/testsuite/g++.dg/torture/darwin-cfstring-3.C 2014-05-10 23:18:01.000000000 +0200 +++ gcc/testsuite/g++.dg/torture/darwin-cfstring-3.C 2016-09-24 17:02:39.000000000 +0200 @@ -24,7 +24,7 @@ void foo(void) { s0 = s1; } -/* { dg-final { scan-assembler "\\.long\[ \\t\]+___CFConstantStringClassReference\n\[ \\t\]*\\.long\[ \\t\]+1992\n\[ \\t\]*\\.long\[ \\t\]+LC.*\n\[ \\t\]*\\.long\[ \\t\]+4\n" { target { *-*-darwin* && { ! lp64 } } } } } */ -/* { dg-final { scan-assembler "\\.long\[ \\t\]+___CFConstantStringClassReference\n\[ \\t\]*\\.long\[ \\t\]+1992\n\[ \\t\]*\\.long\[ \\t\]+LC.*\n\[ \\t\]*\\.long\[ \\t\]+10\n" { target { *-*-darwin* && { ! lp64 } } } } } */ +/* { dg-final { scan-assembler "\\.long\[ \\t\]+___CFConstantStringClassReference\n\[ \\t\]*\\.long\[ \\t\]+1992\n\[ \\t\]*\\.long\[ \\t\]+\[lL\]C.*\n\[ \\t\]*\\.long\[ \\t\]+4\n" { target { *-*-darwin* && { ! lp64 } } } } } */ +/* { dg-final { scan-assembler "\\.long\[ \\t\]+___CFConstantStringClassReference\n\[ \\t\]*\\.long\[ \\t\]+1992\n\[ \\t\]*\\.long\[ \\t\]+\[lL\]C.*\n\[ \\t\]*\\.long\[ \\t\]+10\n" { target { *-*-darwin* && { ! lp64 } } } } } */ /* { dg-final { scan-assembler ".quad\t___CFConstantStringClassReference\n\t.long\t1992\n\t.space 4\n\t.quad\t.*\n\t.quad\t4\n" { target { *-*-darwin* && { lp64 } } } } } */ /* { dg-final { scan-assembler ".quad\t___CFConstantStringClassReference\n\t.long\t1992\n\t.space 4\n\t.quad\t.*\n\t.quad\t10\n" { target { *-*-darwin* && { lp64 } } } } } */ I don't know if the replacement of LC with lC is really intended and if yes, a better fix would be to use "-mtarget-linker 85.2".
(In reply to Dominique d'Humieres from comment #24) > The patch in comment 20 (and SDK 10.9) causes the failures of the tests > gcc.dg/torture/darwin-cfstring-3.c and g++.dg/torture/darwin-cfstring-3.C > with -m32, see https://gcc.gnu.org/ml/gcc-testresults/2016-09/msg02290.html. > These failures are due to the fact that lC is now emitted instead of LC and > are silenced with the following patch > > --- ../_clean/gcc/testsuite/gcc.dg/torture/darwin-cfstring-3.c 2014-05-10 > 23:16:48.000000000 +0200 > +++ gcc/testsuite/gcc.dg/torture/darwin-cfstring-3.c 2016-09-24 > 17:03:58.000000000 +0200 thanks. \n\t.quad\t.*\n\t.quad\t10\n" { target { *-*-darwin* && { lp64 } } } } } */ > > I don't know if the replacement of LC with lC is really intended and if yes, > a better fix would be to use "-mtarget-linker 85.2". Yes, that's the intention of the patch (to make the some of the internal labels visible to the linker - but not public); that's what using "l" instead of "L" does. There are almost certainly other instances that need to be fixed up (I didn't yet review all the test-suite output). As for using "-mtarget-linker 85.2" It would be better to test the most common configurations in use (or both cases). So I'd suggest your patch is a better solution than the changing the target linker. However, we should probably have at least one test somewhere that checks we don't regress for older toolchains (so maybe add one for legacy toolchains, with -mtarget-linker 85.2).
(In reply to Iain Sandoe from comment #23) > (In reply to Francois-Xavier Coudert from comment #22) > > When a fix is designed, could you please backport it to the 6 branch (so it > > can make it into 6.3 for example)? It is also affected. > > sure, "all open branches" would be the intent. I can confirm that 5.3 is also affected.
(In reply to Jonathan Ross from comment #26) > (In reply to Iain Sandoe from comment #23) > > (In reply to Francois-Xavier Coudert from comment #22) > > > When a fix is designed, could you please backport it to the 6 branch (so it > > > can make it into 6.3 for example)? It is also affected. > > > > sure, "all open branches" would be the intent. > > I can confirm that 5.3 is also affected. OK. so the status is - we're checking for other test-cases that need amendment. - IMO this is a sufficiently invasive change that it needs testing on some bigger chunks of code - likewise across a representative set of the *darwin* patch * I will check ppc-d9 when I'm back in the office; with both ld-85.2.1 and my back ported ld64-253.9 * I think Dominique will check x86_64-d10. feel free to volunteer to do some similar testing of builds of larger codes (e.g. python or LLVM etc). * I'll do back-ports for 6.x and 5.x early next week, traveling until then.
Two other tests needing to replace 'L' with '\[lL\]': gcc.dg/const-uniq-1.c gcc.target/i386/pr70799-1.c
I tried testing this patchset on i386-apple-darwin9.8.0, but I think something went wrong with the parallelism in the testsuite (I did `make -j2 check-gcc RUNTESTFLAGS="-v -v"`), and I ended up having to restart my computer... but anyways, the results are here: https://gcc.gnu.org/ml/gcc-testresults/2016-10/msg00537.html I think the failures are mostly unrelated...
(In reply to Eric Gallager from comment #29) > I tried testing this patchset on i386-apple-darwin9.8.0, thanks! - I got reasonable results on ppc-d9 with both ld64-85.2 and ld64-253.9 > but I think > something went wrong with the parallelism in the testsuite (I did `make -j2 > check-gcc RUNTESTFLAGS="-v -v"`), you probably need a"-k" in there too ... (and the -v -v is a bit excessive for running the whole suite, best used if you need to chase a test suite problem with a small set of tests). I'm going to rebase and post the patches
Created attachment 39773 [details] Test adjustments required by the patches in comment 20
(In reply to Iain Sandoe from comment #30) oblem with a small set of tests). > > I'm going to rebase and post the patches Any ETA on the rebased patches being posted?
I'm not sure if this is due to the patches from this bug report, or if it's due to some other change made to GCC recently, but my fork of Emacs now fails to build with LTO due to a bunch of undefined local symbols: /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_toggleFullScreen$.lto_priv.1027 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_window.lto_priv.394 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_setFSValue$.lto_priv.1033 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_fsIsNative.lto_priv.1034 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_windowDidBecomeKey$.lto_priv.1035 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_ClassRefs_4.lto_priv.333 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_deleteWorkingText.lto_priv.1043 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_frame.lto_priv.350 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_windowWillResize$toSize$.lto_priv.1039 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_screens.lto_priv.474 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_ClassRefs_8.lto_priv.431 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_objectAtIndex$.lto_priv.358 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_mouseMoved$.lto_priv.1048 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_mouseDown$.lto_priv.1051 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_isFullscreen.lto_priv.1046 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_toolbar.lto_priv.434 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_retain.lto_priv.405 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_release.lto_priv.312 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_subviews.lto_priv.1056 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_count.lto_priv.355 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_class.lto_priv.440 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_ClassRefs_15.lto_priv.391 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_isKindOfClass$.lto_priv.442 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_condemn.lto_priv.1059 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_judge.lto_priv.1057 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_updateFrameSize$.lto_priv.1032 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_display.lto_priv.399 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_Class_EmacsView.lto_priv.1044 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_viewDidEndLiveResize.lto_priv.1045 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_stringWithUTF8String$.lto_priv.323 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_ClassRefs_3.lto_priv.285 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_dealloc.lto_priv.367 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_modifierFlags.lto_priv.472 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_keyDown$.lto_priv.464 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_visibleRect.lto_priv.1053 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_setOnMouseEntered$.lto_priv.1055 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_arrowCursor.lto_priv.480 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_ClassRefs_27.lto_priv.1052 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_addCursorRect$cursor$.lto_priv.1054 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_UTF8String.lto_priv.294 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_objectEnumerator.lto_priv.304 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_nextObject.lto_priv.308 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_isEqualToString$.lto_priv.316 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_invalidate.lto_priv.331 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_ClassRefs_17.lto_priv.374 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_context.lto_priv.336 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_windowNumber.lto_priv.341 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_contentView.lto_priv.353 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_windowWillExitFullScreen$.lto_priv.1030 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_windowDidExitFullScreen$.lto_priv.1031 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_windowWillEnterFullScreen$.lto_priv.1028 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_windowDidEnterFullScreen$.lto_priv.1029 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_initWithFrame$.lto_priv.377 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_setAutoresizingMask$.lto_priv.1040 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_ClassRefs_28.lto_priv.1041 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_addSubview$.lto_priv.381 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_toggleToolbar$.lto_priv.1042 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_currentEvent.lto_priv.446 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_timestamp.lto_priv.448 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_reprieve.lto_priv.1058 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_setFrame$.lto_priv.408 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_windowDidMove$.lto_priv.1047 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_locationInWindow.lto_priv.1049 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_convertPoint$fromView$.lto_priv.1050 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_delegate.lto_priv.478 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_convertRect$toView$.lto_priv.1071 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_handleFS.lto_priv.1068 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_scheduledTimerWithTimeInterval$target$selector$userInfo$repeats$.lto_priv.403 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_ClassRefs_9.lto_priv.424 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_getMouseMotionPart$window$x$y$.lto_priv.1065 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_mouseLocationOutsideOfEventStream.lto_priv.1066 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_checkSamePosition$portion$whole$.lto_priv.1060 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_removeFromSuperview.lto_priv.1061 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_initFrame$window$.lto_priv.1062 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_setPosition$portion$whole$.lto_priv.1063 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_menuDown$.lto_priv.462 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_ClassRefs_16.lto_priv.369 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_containsObject$.lto_priv.1067 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_setRows$andColumns$.lto_priv.1069 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_setWindowClosing$.lto_priv.1070 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_METH_VAR_TYPE_35.lto_priv.1072 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_METH_VAR_TYPE_1.lto_priv.609 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_METH_VAR_TYPE_5.lto_priv.611 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_METH_VAR_TYPE_40.lto_priv.1073 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_METH_VAR_TYPE_36.lto_priv.759 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_METH_VAR_TYPE_11.lto_priv.599 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_ClassName_NSObject.lto_priv.596 make[2]: *** [/var/tmp//ccDlVUTQ.ltrans1.ltrans.o] Error 1 make[2]: *** Waiting for unfinished jobs.... lto-wrapper: fatal error: make returned 2 exit status compilation terminated. collect2: fatal error: lto-wrapper returned 1 exit status compilation terminated. I was figuring it might have something to do with this patch because this patch messed with the "L_" prefixing of symbols. GCC's LTO worked with my fork of Emacs a few months ago.
(In reply to Eric Gallager from comment #33) > I'm not sure if this is due to the patches from this bug report, or if it's > due to some other change made to GCC recently, but my fork of Emacs now > fails to build with LTO due to a bunch of undefined local symbols: honestly, rather hard to tell from the info given, please can you identify what you've built (and what version) and on what Darwin etc. > I was figuring it might have something to do with this patch because this > patch messed with the "L_" prefixing of symbols. GCC's LTO worked with my > fork of Emacs a few months ago. yeah, it's possible - although if you look at the logic that adds the "L" onto objc local syms it wasn't touched (and they shouldn't pass equality test with "LC" either). Can you find any reproducer smaller than "emacs" ? I have a current build of 241437 under test with rebased patches and it doesn't show this in the LTO tests in the test-suite. However it might be being hidden by some other error. [I'll re-test with my work-around for instancetype applied].
(In reply to Eric Gallager from comment #33) > I'm not sure if this is due to the patches from this bug report, or if it's > due to some other change made to GCC recently, but my fork of Emacs now > fails to build with LTO due to a bunch of undefined local symbols: Did you actually add the patches for this bug report to your local gcc build? The patches haven't been posted to gcc-patches yet or committed into trunk.
(In reply to Jack Howarth from comment #35) > (In reply to Eric Gallager from comment #33) > > I'm not sure if this is due to the patches from this bug report, or if it's > > due to some other change made to GCC recently, but my fork of Emacs now > > fails to build with LTO due to a bunch of undefined local symbols: > > Did you actually add the patches for this bug report to your local gcc > build? The patches haven't been posted to gcc-patches yet or committed into > trunk. I can't reproduce that particular failure in a build of emacs 25.1 against gcc 6.2.0 (with or without patchiest cf 240230 applied) because I run into a linker bug when linking temacs using the Xcode 8 linker). https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78077
(In reply to Eric Gallager from comment #33) > I'm not sure if this is due to the patches from this bug report, or if it's > due to some other change made to GCC recently, but my fork of Emacs now > fails to build with LTO due to a bunch of undefined local symbols: This issue exists in stock gcc 6.2.0 on x86_64-apple-darwin15. I can reproduce the issue building emacs 25.1 configured with... ../configure --without-ns --prefix=/Users/howarth/emacs-dist CC=/sw/bin/gcc-fsf-6 CXX=/sw/bin/g++-fsf-6 CPPFLAGS="-I/sw/include" LDFLAGS="-flto -fno-pie -L/sw/lib" CFLAGS="-O0 -g -fno-pie -flto" which produces a build that fails at... CCLD temacs /var/folders/vh/xthx1f251nqfj804049zl1wm0000gn/T//cc5Viitn.s:288358:1: error: assembler local symbol 'L1' not defined ... /var/folders/vh/xthx1f251nqfj804049zl1wm0000gn/T//cc5Viitn.s:288358:1: error: assembler local symbol 'L174' not defined
(In reply to Iain Sandoe from comment #34) > (In reply to Eric Gallager from comment #33) > > I'm not sure if this is due to the patches from this bug report, or if it's > > due to some other change made to GCC recently, but my fork of Emacs now > > fails to build with LTO due to a bunch of undefined local symbols: > > honestly, rather hard to tell from the info given, please can you identify > what you've built (and what version) and on what Darwin etc. $ /usr/local/bin/gcc -v Using built-in specs. COLLECT_GCC=/usr/local/bin/gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i386-apple-darwin9.8.0/7.0.0/lto-wrapper Target: i386-apple-darwin9.8.0 Configured with: ../configure --disable-werror --disable-werror-always --enable-languages=c,c++,lto,objc,obj-c++ --enable-stage1-checking=release -C --with-system-libunwind --enable-secureplt --enable-frame-pointer --enable-debug --with-isl --enable-objc-gc --enable-host-shared --enable-maintainer-mode --with-ld64 CC=/usr/local/bin/gcc CXX=/usr/local/bin/g++ : (reconfigured) ../configure --disable-werror --disable-werror-always --enable-languages=c,c++,lto,objc,obj-c++ --enable-stage1-checking=release -C --with-system-libunwind --enable-secureplt --enable-frame-pointer --enable-debug --with-isl --enable-objc-gc --enable-host-shared --enable-maintainer-mode --with-ld64 CC=/usr/local/bin/gcc CXX=/usr/local/bin/g++ Thread model: posix gcc version 7.0.0 20161005 (experimental) (GCC) $ uname -a Darwin ian-gallagers-macbook.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386 There were also a bunch of -Wlto-type-mismatch warnings when linking, but they were there before, so I trimmed them off. > > > I was figuring it might have something to do with this patch because this > > patch messed with the "L_" prefixing of symbols. GCC's LTO worked with my > > fork of Emacs a few months ago. > > yeah, it's possible - although if you look at the logic that adds the "L" > onto objc local syms it wasn't touched (and they shouldn't pass equality > test with "LC" either). > > Can you find any reproducer smaller than "emacs" ? > > I have a current build of 241437 under test with rebased patches and it > doesn't show this in the LTO tests in the test-suite. However it might be > being hidden by some other error. [I'll re-test with my work-around for > instancetype applied]. (In reply to Jack Howarth from comment #35) > (In reply to Eric Gallager from comment #33) > > I'm not sure if this is due to the patches from this bug report, or if it's > > due to some other change made to GCC recently, but my fork of Emacs now > > fails to build with LTO due to a bunch of undefined local symbols: > > Did you actually add the patches for this bug report to your local gcc > build? The patches haven't been posted to gcc-patches yet or committed into > trunk. Yes, I did, I posted test results with them above in this bug, too. I had also applied a few other patches from gcc-patches that hadn't been committed to trunk yet. This actually caused a conflict with the patch from this bug that touched the gcc subdirectory's configure script, so I had to regenerate that manually.
(In reply to Eric Gallager from comment #38) Your issue of undefined symbols under FSF gcc is orthogonal to the problem discussed in this PR. As I mentioned before, the same issue is observed for a build of stock emacs 25.1 with '-O0 -flto' using a stock (unpatched) gcc 6.2.0 compiler. You should open a separate PR for that bug.
(In reply to Jack Howarth from comment #39) > (In reply to Eric Gallager from comment #38) > > Your issue of undefined symbols under FSF gcc is orthogonal to the problem > discussed in this PR. As I mentioned before, the same issue is observed for > a build of stock emacs 25.1 with '-O0 -flto' using a stock (unpatched) gcc > 6.2.0 compiler. You should open a separate PR for that bug. Your bug might be reproducible on linux using a gcc build that doesn't have build_lto_plugin set by configure so the same LTO code path is used as on darwin.
(In reply to Jack Howarth from comment #40) > (In reply to Jack Howarth from comment #39) > > (In reply to Eric Gallager from comment #38) > > > > Your issue of undefined symbols under FSF gcc is orthogonal to the problem > > discussed in this PR. As I mentioned before, the same issue is observed for > > a build of stock emacs 25.1 with '-O0 -flto' using a stock (unpatched) gcc > > 6.2.0 compiler. You should open a separate PR for that bug. > > Your bug might be reproducible on linux using a gcc build that doesn't have > build_lto_plugin set by configure so the same LTO code path is used as on > darwin. FYI, I was able to reproduce the same bug on x86_64 linux when building emacs 25.1 with -flto using a build of gcc 6.2.0 with configure manually edited to set build_lto_plugin=no on linux. CCLD temacs /tmp/cc7ZBmmQ.ltrans0.ltrans.o:(.rodata+0x135a0): undefined reference to `.L1' ... /tmp/cc7ZBmmQ.ltrans0.ltrans.o:(.rodata+0x13bc8): more undefined references to `.L174' follow collect2: fatal error: ld returned 1 exit status
Filed Bug lto/78087 for the linkage failure of temacs in the emacs 25.1 build when '-O0 -flto' is used on x86_64 darwin and x86_64 linux (for a build without the LTO linker plugin).
(In reply to Eric Gallager from comment #33) > I'm not sure if this is due to the patches from this bug report, or if it's > due to some other change made to GCC recently, but my fork of Emacs now > fails to build with LTO due to a bunch of undefined local symbols: > This issue appears to be PR57438 because passing -D__builtin_unreachable=__builtin_trap to the build on OS X 10.11 allows emac 25.1 to build against the Xcode 8.1 GM linker using stock gcc 6.2.0 compiler with... $ ../configure --enable-link-time-optimization --without-ns CC=/sw/bin/gcc-fsf-6 CXX=/sw/bin/g++-fsf-6 CPPFLAGS="-D__builtin_unreachable=__builtin_trap -I/sw/include" LDFLAGS="-L/sw/lib"
posted: https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00536.html https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00537.html https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00538.html https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00539.html https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00540.html I have back-ports to 6.x and 5.x if anyone needs then urgently
Author: iains Date: Sun Nov 27 14:21:51 2016 New Revision: 242893 URL: https://gcc.gnu.org/viewcvs?rev=242893&root=gcc&view=rev Log: [Darwin, ld64] Make PIC indirections and constant labels linker-visible. Indirections: If we have a situation like: global_weak_symbol: .... Lnon_weak_local: .... ld64 will be unable to split this into two atoms (because the "L" makes the second symbol 'invisible'). This means that legitimate direct accesses to the second symbol will appear to be non-allowed direct accesses to an atom of type weak, global which are not allowed. To avoid this, we make the indirections have a leading 'l' (lower-case L) which has a special meaning: linker can see this and use it to determine atoms, but it is not placed into the final symbol table. The implementation here is somewhat heavy-handed in that it will also mark indirections to the __IMPORT,__pointers section the same way which is really unnecessary, since ld64 _can_ split those into atoms as they are fixed size. FIXME: determine if this is a penalty worth extra code to fix. Similarly, with: .const weak_global_constant: .... LCxx: ... ld64 can't split the second, causing a warning when it's directly accessed. gcc/ 2016-11-27 Iain Sandoe <iain@codesourcery.com> PR target/71767 * config/darwin.c (imachopic_indirection_name): Make data section indirections linker-visible. * config/darwin.h (ASM_GENERATE_INTERNAL_LABEL): Make local constant labels linker-visible. Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin.c trunk/gcc/config/darwin.h
Author: iains Date: Sun Nov 27 14:29:36 2016 New Revision: 242894 URL: https://gcc.gnu.org/viewcvs?rev=242894&root=gcc&view=rev Log: [Darwin, config] Arrange for ld64 to be detected as Darwin's linker. This is an initial patch in a series that converts Darwin's configury to detect ld64 features, rather than the current process of hard-coding them on target system version. A ld64-compatible linker is currently required and assumed by Darwin. If a DEFAULT_LINKER is set via --with-ld= then this will be tested to see if it is ld64. The ld64 version is determined for the chosen ld and this is exported for use in setting a default value for -mtarget-linker (needed for run-time code-gen changes to section choices). The support for -rdynamic is converted to be detected at config time, or by the ld64 version if that is found. gcc/ 2016-11-27 Iain Sandoe <iain@codesourcery.com> PR target/71767 * configure.ac (with-ld64): New var, set for Darwin, set on detection of ld64, gcc_cv_ld64_export_dynamic: New, New test. * config/darwin.h: Use LD64_HAS_DYNAMIC export. DEF_LD64: New, define. * config/darwin10.h(DEF_LD64): Update for this target version. * config/darwin12.h(LINK_GCC_C_SEQUENCE_SPEC): Remove rdynamic test. (DEF_LD64): Update for this target version. * configure: Regenerated. * config.in: Regenerated. Modified: trunk/gcc/ChangeLog trunk/gcc/config.in trunk/gcc/config/darwin.h trunk/gcc/config/darwin10.h trunk/gcc/config/darwin12.h trunk/gcc/configure trunk/gcc/configure.ac
Author: iains Date: Sun Nov 27 14:34:54 2016 New Revision: 242895 URL: https://gcc.gnu.org/viewcvs?rev=242895&root=gcc&view=rev Log: [Darwin] Fix PR71767 - adjust the sections used where necessary. (much) Older Darwin linkers needed separate sections marked "coalesce" to allow for weak symbol coalescing. This has not been needed for some time and is now deprecated, newer assemblers warn if the old coalesced sections are used. gcc/ 2016-11-27 Iain Sandoe <iain@codesourcery.com> PR target/71767 * config/darwin-sections.def (picbase_thunk_section): New. * config/darwin.c (darwin_init_sections): Set up picbase thunk section. (darwin_rodata_section, darwin_objc2_section, machopic_select_section, darwin_asm_declare_constant_name, darwin_emit_weak_or_comdat, darwin_function_section): Don’t use coalesced with newer linkers. (darwin_override_options): Decide on usage of coalesed sections on the basis of the target linker version. * config/darwin.h (MIN_LD64_NO_COAL_SECTS): New. * config/darwin.opt (mtarget-linker): New. * config/i386/i386.c (ix86_code_end): Do not force the thunks into a coalesced section, instead use a thunks section. Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin-sections.def trunk/gcc/config/darwin.c trunk/gcc/config/darwin.h trunk/gcc/config/darwin.opt trunk/gcc/config/i386/i386.c
Author: iains Date: Sun Nov 27 14:41:22 2016 New Revision: 242896 URL: https://gcc.gnu.org/viewcvs?rev=242896&root=gcc&view=rev Log: [Testsuite] pr71767 Changes. Update Darwin tests to reflect the differences in symbol names and section usage. gcc/testsuite/ 2016-11-27 Dominique d'Humieres <dominiq@lps.ens.fr> Iain Sandoe <iain@codesourcery.com> PR target/71767 * g++.dg/abi/key2.C: Adjust for changed Darwin sections and linker-visible symbols. * g++.dg/torture/darwin-cfstring-3.C: Likewise. * gcc.dg/const-uniq-1.c: Likewise. * gcc.dg/torture/darwin-cfstring-3.c: Likewise. * gcc.target/i386/pr70799-1.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/abi/key2.C trunk/gcc/testsuite/g++.dg/torture/darwin-cfstring-3.C trunk/gcc/testsuite/gcc.dg/const-uniq-1.c trunk/gcc/testsuite/gcc.dg/torture/darwin-cfstring-3.c trunk/gcc/testsuite/gcc.target/i386/pr70799-1.c
(In reply to Iain Sandoe from comment #46) > Author: iains > Date: Sun Nov 27 14:29:36 2016 > New Revision: 242894 > > URL: https://gcc.gnu.org/viewcvs?rev=242894&root=gcc&view=rev > Log: > [Darwin, config] Arrange for ld64 to be detected as Darwin's linker. > > This is an initial patch in a series that converts Darwin's configury > to detect ld64 features, rather than the current process of hard-coding > them on target system version. > > A ld64-compatible linker is currently required and assumed by Darwin. > If a DEFAULT_LINKER is set via --with-ld= then this will be tested to > see if it is ld64. > > The ld64 version is determined for the chosen ld and this is exported for > use in setting a default value for -mtarget-linker (needed for run-time > code-gen changes to section choices). > The support for -rdynamic is converted to be detected at config time, or > by the ld64 version if that is found. > > gcc/ > > 2016-11-27 Iain Sandoe <iain@codesourcery.com> > > PR target/71767 > * configure.ac (with-ld64): New var, set for Darwin, set on > detection of ld64, gcc_cv_ld64_export_dynamic: New, New test. > * config/darwin.h: Use LD64_HAS_DYNAMIC export. DEF_LD64: New, > define. > * config/darwin10.h(DEF_LD64): Update for this target version. > * config/darwin12.h(LINK_GCC_C_SEQUENCE_SPEC): Remove rdynamic > test. (DEF_LD64): Update for this target version. > * configure: Regenerated. > * config.in: Regenerated. > > > Modified: > trunk/gcc/ChangeLog > trunk/gcc/config.in > trunk/gcc/config/darwin.h > trunk/gcc/config/darwin10.h > trunk/gcc/config/darwin12.h > trunk/gcc/configure > trunk/gcc/configure.ac The change breaks bootstrap on hppa64-*-*. checking linker for compressed debug sections... 0 /xxx/gnu/gcc/gcc/gcc/configure[28336]: Syntax error at line 28360 : `<' is not e xpected.
Created attachment 40169 [details] configure fix please could you confirm if this fixes bootstrap. very sorry for the breaskage
Fixes the configure for FreeBSD. Thanks, Andreas
On 2016-11-27, at 4:18 PM, iains at gcc dot gnu.org wrote: > please could you confirm if this fixes bootstrap. Yes, it fixes the configure error on hppa64-hp-hpux11.11. Thanks, Dave -- John David Anglin dave.anglin@bell.net
Author: iains Date: Mon Nov 28 10:29:19 2016 New Revision: 242912 URL: https://gcc.gnu.org/viewcvs?rev=242912&root=gcc&view=rev Log: [Darwin, config] Fix version number extraction to portable method The method used in the applied patch caused configuration errors on freeBSD and hppa. 2016-11-28 Iain Sandoe <iain@codesourcery.com> PR target/71767 * configure.ac (with_ld64): Use portable method to extract the major part of the version number. * configure: Regenerated. Modified: trunk/gcc/ChangeLog trunk/gcc/configure trunk/gcc/configure.ac
Shouldn't this be closed now as resolved?
(In reply to Jack Howarth from comment #54) > Shouldn't this be closed now as resolved? nope, it needs back-porting to 6.x and 5.x - will do that after it's been on trunk a while.
Author: iains Date: Sun Dec 11 16:01:35 2016 New Revision: 243524 URL: https://gcc.gnu.org/viewcvs?rev=243524&root=gcc&view=rev Log: [Darwin] Back-port fix for PR71767. gcc/ 2016-12-11 Iain Sandoe <iain@codesourcery.com> Backport from mainline 2016-11-27 Iain Sandoe <iain@codesourcery.com> PR target/71767 * config/darwin-sections.def (picbase_thunk_section): New. * config/darwin.c (darwin_init_sections): Set up picbase thunk section. (darwin_rodata_section, darwin_objc2_section, machopic_select_section, darwin_asm_declare_constant_name, darwin_emit_weak_or_comdat, darwin_function_section): Don’t use coalesced with newer linkers. (darwin_override_options): Decide on usage of coalesed sections on the basis of the target linker version. * config/darwin.h (MIN_LD64_NO_COAL_SECTS): New. * config/darwin.opt (mtarget-linker): New. * config/i386/i386.c (ix86_code_end): Do not force the thunks into a coalesced section, instead use a thunks section. Backport from mainline 2016-11-28 Iain Sandoe <iain@codesourcery.com> PR target/71767 * configure.ac (with_ld64): Use portable method to extract the major part of the version number. * configure: Regenerated. Backport from mainline 2016-11-27 Iain Sandoe <iain@codesourcery.com> PR target/71767 * configure.ac (with-ld64): New var, set for Darwin, set on detection of ld64, gcc_cv_ld64_export_dynamic: New, New test. * config/darwin.h: Use LD64_HAS_DYNAMIC export. DEF_LD64: New, define. * config/darwin10.h(DEF_LD64): Update for this target version. * config/darwin12.h(LINK_GCC_C_SEQUENCE_SPEC): Remove rdynamic test. (DEF_LD64): Update for this target version. * configure: Regenerated. * config.in: Regenerated. Backport from mainline 2016-11-27 Iain Sandoe <iain@codesourcery.com> PR target/71767 * config/darwin.c (imachopic_indirection_name): Make data section indirections linker-visible. * config/darwin.h (ASM_GENERATE_INTERNAL_LABEL): Make local constant labels linker-visible. gcc/testsuite/ 2016-12-11 Iain Sandoe <iain@codesourcery.com> Backport from mainline 2016-11-27 Dominique d'Humieres <dominiq@lps.ens.fr> Iain Sandoe <iain@codesourcery.com> PR target/71767 * g++.dg/abi/key2.C: Adjust for changed Darwin sections and linker-visible symbols. * g++.dg/torture/darwin-cfstring-3.C: Likewise. * gcc.dg/const-uniq-1.c: Likewise. * gcc.dg/torture/darwin-cfstring-3.c: Likewise. * gcc.target/i386/pr70799-1.c: Likewise. Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/config.in branches/gcc-6-branch/gcc/config/darwin-sections.def branches/gcc-6-branch/gcc/config/darwin.c branches/gcc-6-branch/gcc/config/darwin.h branches/gcc-6-branch/gcc/config/darwin.opt branches/gcc-6-branch/gcc/config/darwin10.h branches/gcc-6-branch/gcc/config/darwin12.h branches/gcc-6-branch/gcc/config/i386/i386.c branches/gcc-6-branch/gcc/configure branches/gcc-6-branch/gcc/configure.ac branches/gcc-6-branch/gcc/testsuite/ChangeLog branches/gcc-6-branch/gcc/testsuite/g++.dg/abi/key2.C branches/gcc-6-branch/gcc/testsuite/g++.dg/torture/darwin-cfstring-3.C branches/gcc-6-branch/gcc/testsuite/gcc.dg/const-uniq-1.c branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/darwin-cfstring-3.c
(In reply to Iain Sandoe from comment #55) > nope, it needs back-porting to 6.x and 5.x - will do that after it's been on > trunk a while. Is backport to 5.x still planned?
(In reply to Francois-Xavier Coudert from comment #57) > (In reply to Iain Sandoe from comment #55) > > nope, it needs back-porting to 6.x and 5.x - will do that after it's been on > > trunk a while. > > Is backport to 5.x still planned? Yes, when time permits.
*** Bug 80782 has been marked as a duplicate of this bug. ***
(In reply to Iain Sandoe from comment #58) > (In reply to Francois-Xavier Coudert from comment #57) > > (In reply to Iain Sandoe from comment #55) > > > nope, it needs back-porting to 6.x and 5.x - will do that after it's been on > > > trunk a while. > > > > Is backport to 5.x still planned? > > Yes, when time permits. But 5.x branch is closed now. So I'm closing this bug, too.