Bug 71767 - Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler
Summary: Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated As...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 6.1.0
: P3 minor
Target Milestone: ---
Assignee: Iain Sandoe
URL:
Keywords: assemble-failure
Depends on:
Blocks:
 
Reported: 2016-07-05 16:19 UTC by Jeffrey Walton
Modified: 2019-02-27 01:04 UTC (History)
12 users (show)

See Also:
Host:
Target: x86_64-apple-darwin12.6.0
Build:
Known to work:
Known to fail:
Last reconfirmed: 2016-09-14 00:00:00


Attachments
exhaustive results for libstdc++ with Xcode 8 + patch (2.87 KB, text/plain)
2016-09-17 15:57 UTC, Dominique d'Humieres
Details
assembly for g++.old-deja/g++.pt/static11.C with Xcode 8 + patch and -m32 (3.58 KB, text/plain)
2016-09-17 16:00 UTC, Dominique d'Humieres
Details
proposed patch set. (8.33 KB, application/octet-stream)
2016-09-20 14:17 UTC, Iain Sandoe
Details
patchset cf 240230 (8.35 KB, application/x-bzip)
2016-09-20 16:01 UTC, Iain Sandoe
Details
Test adjustments required by the patches in comment 20 (816 bytes, patch)
2016-10-08 09:21 UTC, Dominique d'Humieres
Details | Diff
configure fix (627 bytes, patch)
2016-11-27 21:18 UTC, Iain Sandoe
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jeffrey Walton 2016-07-05 16:19:33 UTC
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
Comment 1 Jeffrey Walton 2016-07-05 16:22:40 UTC
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.
Comment 2 Andrew Pinski 2016-07-05 18:19:34 UTC
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?
Comment 4 Dominique d'Humieres 2016-09-14 11:40:49 UTC
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
 {
Comment 5 Jeffrey Walton 2016-09-14 12:09:43 UTC
(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.
Comment 6 Dominique d'Humieres 2016-09-14 12:51:49 UTC
> 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).
Comment 7 Iain Sandoe 2016-09-14 19:37:58 UTC
(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).
Comment 8 Jeffrey Walton 2016-09-14 19:52:27 UTC
(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
Comment 9 Iain Sandoe 2016-09-14 20:10:28 UTC
(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.
Comment 10 Jeffrey Walton 2016-09-14 21:34:03 UTC
> 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
Comment 11 Jeremy Huddleston Sequoia 2016-09-14 22:19:56 UTC
(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'
Comment 12 Jeremy Huddleston Sequoia 2016-09-14 22:23:56 UTC
(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.
Comment 13 Dominique d'Humieres 2016-09-17 15:53:03 UTC
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.
Comment 14 Dominique d'Humieres 2016-09-17 15:57:55 UTC
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.
Comment 15 Dominique d'Humieres 2016-09-17 16:00:03 UTC
Created attachment 39639 [details]
assembly for g++.old-deja/g++.pt/static11.C with Xcode 8 + patch and -m32
Comment 16 Iain Sandoe 2016-09-18 18:44:10 UTC
(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).
Comment 17 Iain Sandoe 2016-09-18 18:50:41 UTC
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
Comment 18 Iain Sandoe 2016-09-18 18:56:10 UTC
(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).
Comment 19 Iain Sandoe 2016-09-20 14:17:10 UTC
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.
Comment 20 Iain Sandoe 2016-09-20 16:01:43 UTC
Created attachment 39661 [details]
patchset cf 240230


patchset rebased to 240230 - should apply cleanly.
Comment 21 Iain Sandoe 2016-09-21 08:07:52 UTC
(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" } }
Comment 22 Francois-Xavier Coudert 2016-09-21 11:51:09 UTC
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.
Comment 23 Iain Sandoe 2016-09-21 12:43:21 UTC
(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.
Comment 24 Dominique d'Humieres 2016-09-25 07:20:23 UTC
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".
Comment 25 Iain Sandoe 2016-09-25 17:27:26 UTC
(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).
Comment 26 Jonathan Ross 2016-09-28 15:12:22 UTC
(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.
Comment 27 Iain Sandoe 2016-09-28 15:33:35 UTC
(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.
Comment 28 Dominique d'Humieres 2016-10-01 09:56:45 UTC
Two other tests needing to replace 'L' with '\[lL\]':

gcc.dg/const-uniq-1.c
gcc.target/i386/pr70799-1.c
Comment 29 Eric Gallager 2016-10-06 21:28:50 UTC
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...
Comment 30 Iain Sandoe 2016-10-06 23:08:50 UTC
(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
Comment 31 Dominique d'Humieres 2016-10-08 09:21:52 UTC
Created attachment 39773 [details]
Test adjustments required by the patches in comment 20
Comment 32 Jack Howarth 2016-10-12 14:55:59 UTC
(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?
Comment 33 Eric Gallager 2016-10-22 15:25:36 UTC
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.
Comment 34 Iain Sandoe 2016-10-22 15:43:40 UTC
(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].
Comment 35 Jack Howarth 2016-10-22 18:59:39 UTC
(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.
Comment 36 Jack Howarth 2016-10-22 20:23:18 UTC
(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
Comment 37 Jack Howarth 2016-10-22 20:47:49 UTC
(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
Comment 38 Eric Gallager 2016-10-23 19:14:12 UTC
(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.
Comment 39 Jack Howarth 2016-10-23 19:39:56 UTC
(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.
Comment 40 Jack Howarth 2016-10-23 19:54:52 UTC
(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.
Comment 41 Jack Howarth 2016-10-24 00:56:42 UTC
(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
Comment 42 Jack Howarth 2016-10-24 01:21:22 UTC
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).
Comment 43 Jack Howarth 2016-10-24 21:07:59 UTC
(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"
Comment 45 Iain Sandoe 2016-11-27 14:22:23 UTC
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
Comment 46 Iain Sandoe 2016-11-27 14:30:08 UTC
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
Comment 47 Iain Sandoe 2016-11-27 14:35:26 UTC
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
Comment 48 Iain Sandoe 2016-11-27 14:41:53 UTC
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
Comment 49 John David Anglin 2016-11-27 20:52:53 UTC
(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.
Comment 50 Iain Sandoe 2016-11-27 21:18:09 UTC
Created attachment 40169 [details]
configure fix

please could you confirm if this fixes bootstrap.
very sorry for the breaskage
Comment 51 Andreas Tobler 2016-11-27 21:37:48 UTC
Fixes the configure for FreeBSD.
Thanks,
Andreas
Comment 52 dave.anglin 2016-11-27 21:47:25 UTC
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
Comment 53 Iain Sandoe 2016-11-28 10:29:51 UTC
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
Comment 54 Jack Howarth 2016-12-01 22:30:33 UTC
Shouldn't this be closed now as resolved?
Comment 55 Iain Sandoe 2016-12-01 22:53:44 UTC
(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.
Comment 56 Iain Sandoe 2016-12-11 16:02:08 UTC
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
Comment 57 Francois-Xavier Coudert 2017-01-24 14:49:53 UTC
(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?
Comment 58 Iain Sandoe 2017-01-24 15:10:08 UTC
(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.
Comment 59 Andrew Pinski 2017-05-16 17:00:36 UTC
*** Bug 80782 has been marked as a duplicate of this bug. ***
Comment 60 Eric Gallager 2017-11-02 00:43:32 UTC
(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.