[Bug target/65780] New: [5 Regression] Uninitialized common handling in executables

[Bug target/65780] New: [5 Regression] Uninitialized common handling in executables

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

            Bug ID: 65780
           Summary: [5 Regression] Uninitialized common handling in
                    executables
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org

int optopt;

int
main ()
{
  optopt = 4;
  return 0;
}

fails to link with GCC 5 on powerpc64{,le}-linux:
gcc -O2 -o a a.c
/usr/bin/ld: /tmp/cckV8RvX.o: In function `main':
a.c:(.text.startup+0x6): unresolvable R_PPC64_TOC16_HA against
`optopt@@GLIBC_2.3'
/usr/bin/ld: a.c:(.text.startup+0xe): unresolvable R_PPC64_TOC16_LO against
`optopt@@GLIBC_2.3'
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status

The problem seems to be that targetm.binds_local_p now returns true for !shlib
DECL_COMMON with NULL (or error_mark_node) DECL_INITIAL.
Looking at the difference between 4.9 and 5, there is:
  if (defined_locally && weak_dominate && !shlib)
    resolved_locally = true;
and finally (similar to 4.9)
  /* Uninitialized COMMON variable may be unified with symbols
     resolved from other modules.  */
  if (DECL_COMMON (exp)
      && !resolved_locally
      && (DECL_INITIAL (exp) == NULL
          || (!in_lto_p && DECL_INITIAL (exp) == error_mark_node)))
    return false;
Looking at what x86_64-linux linker does in this case, assuming that an
unitialized common binds locally in the executable if it is defined there works
fine, but clearly not on ppc*.  Either it is a linker bug there, or we for
powerpc* (some other targets too) should treat the uninitialized DECL_COMMON
defined_locally && weak_dominate && !shlib differently - not set
resolved_locally in that case?
Can people try other targets?  The testcase relies on optopt being an integer
variable defined in libc shared library, if that is not the case, create a
shared library with that symbol and link it to the binary.

[Bug target/65780] [5 Regression] Uninitialized common handling in executables

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amodra at gcc dot gnu.org,
                   |                            |hjl.tools at gmail dot com,
                   |                            |rth at gcc dot gnu.org
   Target Milestone|---                         |5.0

[Bug target/65780] [5 Regression] Uninitialized common handling in executables

[james410 at cowgill dot org.uk]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

james410 at cowgill dot org.uk changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |james410 at cowgill dot org.uk

--- Comment #1 from james410 at cowgill dot org.uk ---
The testcase fails on mipsel-linux-gnu with:

$ gcc-5 test.c
/usr/bin/ld: non-dynamic relocations refer to dynamic symbol optopt@@GLIBC_2.0
/usr/bin/ld: failed to set dynamic section sizes: Bad value
collect2: error: ld returned 1 exit status

It works with 4.9.

[Bug target/65780] [5 Regression] Uninitialized common handling in executables

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

--- Comment #2 from H.J. Lu <hjl.tools at gmail dot com> ---
Please provide the output of "readelf -sW a.o" to verify
if optopt is COMMON:

[hjl@gnu-6 gcc]$ ./xgcc -B./ -O2 -c /tmp/a.c 
[hjl@gnu-6 gcc]$ readelf -sW a.o 

Symbol table '.symtab' contains 12 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS a.c
     2: 0000000000000000     0 SECTION LOCAL  DEFAULT    1 
     3: 0000000000000000     0 SECTION LOCAL  DEFAULT    2 
     4: 0000000000000000     0 SECTION LOCAL  DEFAULT    3 
     5: 0000000000000000     0 SECTION LOCAL  DEFAULT    4 
     6: 0000000000000000     0 SECTION LOCAL  DEFAULT    5 
     7: 0000000000000000     0 SECTION LOCAL  DEFAULT    8 
     8: 0000000000000000     0 SECTION LOCAL  DEFAULT    9 
     9: 0000000000000000     0 SECTION LOCAL  DEFAULT    7 
    10: 0000000000000000    13 FUNC    GLOBAL DEFAULT    5 main
    11: 0000000000000004     4 OBJECT  GLOBAL DEFAULT  COM optopt
[hjl@gnu-6 gcc]$

[Bug target/65780] [5 Regression] Uninitialized common handling in executables

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

--- Comment #3 from H.J. Lu <hjl.tools at gmail dot com> ---
Also does -fno-common make a difference?

[Bug target/65780] [5 Regression] Uninitialized common handling in executables

[amodra at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

Alan Modra <amodra at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-04-16
                 CC|                            |amodra at gmail dot com
     Ever confirmed|0                           |1

--- Comment #4 from Alan Modra <amodra at gmail dot com> ---
optopt is common, and from a linker perspective I believe the correct
resolution of a common symbol in the executable and a strong definition in a
shared library, is the shared library symbol.  Therefore the change to
binds_local_p is wrong.

What's going on here is that HJ has made changes for x86 to always copy
variables defined in a shared library into the executable's .dynbss if
referenced by the executable.  This is necessary to support non-PIC without
text relocations, but isn't necessary for PIC.  It is certainly possible to do
this for PIC but I think only x86 does so.

[Bug target/65780] [5 Regression] Uninitialized common handling in executables

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

--- Comment #5 from H.J. Lu <hjl.tools at gmail dot com> ---
I can reproduce it with binutils 2.24 on x86-64:

[hjl@gnu-tools-1 gcc]$ ./xgcc -B./ -fPIE -pie /tmp/a.c 
/export/build/gnu/binutils/release/usr/local/bin/ld: /tmp/ccazj1RF.o:
relocation R_X86_64_PC32 against undefined symbol `optopt@@GLIBC_2.2.5' can not
be used when making a shared object; recompile with -fPIC
/export/build/gnu/binutils/release/usr/local/bin/ld: final link failed: Bad
value
collect2: error: ld returned 1 exit status
[hjl@gnu-tools-1 gcc]$

[Bug target/65780] [5 Regression] Uninitialized common handling in executables

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

--- Comment #6 from H.J. Lu <hjl.tools at gmail dot com> ---
Created attachment 35325
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35325&action=edit
A patch

Please try this.

[Bug target/65780] [5 Regression] Uninitialized common handling in PIE

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #35325|0                           |1
        is obsolete|                            |

--- Comment #7 from H.J. Lu <hjl.tools at gmail dot com> ---
Created attachment 35326
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35326&action=edit
An updated patch

Copy reloc in PIE only works for x86-64.  It isn't allowed for -m32.

[Bug target/65780] [5 Regression] Uninitialized common handling in executables

[amodra at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

Alan Modra <amodra at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|amodra at gcc dot gnu.org          |
            Summary|[5 Regression]              |[5 Regression]
                   |Uninitialized common        |Uninitialized common
                   |handling in PIE             |handling in executables

--- Comment #8 from Alan Modra <amodra at gmail dot com> ---
Changing the summary back to as it was.  -fPIE is not necessary to show this
bug on powerpc64 (or mips by the look of comment #1).

[Bug target/65780] [5 Regression] Uninitialized common handling in executables

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #35326|0                           |1
        is obsolete|                            |

--- Comment #9 from H.J. Lu <hjl.tools at gmail dot com> ---
Created attachment 35327
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35327&action=edit
A different patch

On x86, this issue only shows up with PIE. Here is a different
patch to treat common symbol defined locally only if the backend
passes true common_maybe_local.  For x86-64, it is true only if
HAVE_LD_PIE_COPYRELOC is 1.  For i386, it is always false.  If
we aren't building PIE, common_maybe_local is true or false
doesn't make a difference for x86 since the common symbol is
always referenced normally with copy reloc.  For PIE on x86-64,
common symbol is local only if HAVE_LD_PIE_COPYRELOC is 1.

[Bug target/65780] [5 Regression] Uninitialized common handling in executables

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to H.J. Lu from comment #9)
> Created attachment 35327 [details]
> A different patch
> 
> On x86, this issue only shows up with PIE. Here is a different
> patch to treat common symbol defined locally only if the backend
> passes true common_maybe_local.  For x86-64, it is true only if
> HAVE_LD_PIE_COPYRELOC is 1.  For i386, it is always false.  If
> we aren't building PIE, common_maybe_local is true or false
> doesn't make a difference for x86 since the common symbol is
> always referenced normally with copy reloc.  For PIE on x86-64,
> common symbol is local only if HAVE_LD_PIE_COPYRELOC is 1.

+
+  /* For common symbol, it is defined locally only if common_maybe_local
+     is true.  */
+  bool defined_locally = (!DECL_EXTERNAL (exp)
+              && (!DECL_COMMON (exp) || common_maybe_local));

I think better would be:
  bool uninited_common = (DECL_COMMON (exp)
                          && (DECL_INITIAL (exp) == NULL
                              || (!in_lto_p && DECL_INITIAL (exp) ==
error_mark_node)));
  /* For common symbol, it is defined locally only if common_maybe_local
     is true.  */
  bool defined_locally = (!DECL_EXTERNAL (exp) && (!uninited_common ||
common_maybe_local));
...
and then use
  /* Uninitialized COMMON variable may be unified with symbols
     resolved from other modules.  */
  if (uninited_common && !resolved_locally)
    return false;

[Bug target/65780] [5/6 Regression] Uninitialized common handling in executables

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

[Bug target/65780] [5/6 Regression] Uninitialized common handling in executables

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
And, shouldn't common_maybe_local for i?86/x86_64 be
  !flag_pic || (TARGET_64BIT && HAVE_LD_PIE_COPYRELOC != 0)
?  What about other targets that are known to generate COPY relocations in this
case for non-PIE executables?  Should they pass !flag_pic?
Perhaps there should be a generic default_binds_local_p* entry point that
passes
!flag_pic as common_maybe_local, that those targets could (after maintainers
test it properly with various vintage linkers?) use as their
TARGET_BINDS_LOCAL_P ?
Clearly rs6000 should pass always false though, perhaps many others too.

[Bug target/65780] [5/6 Regression] Uninitialized common handling in executables

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I've tried the #c0 testcase with gcc 5.1 rc and binutils 2.25 on various linux
architectures.  On armv7hl, x86_64, s390 and s390x no errors are reported for
both normal executable and PIE, for i686 PIE link fails, normal works, for
powerpc64{,le} expectedly both normal and PIE link fail, aarch64 I'm still
waiting for results.

[Bug target/65780] [5/6 Regression] Uninitialized common handling in executables

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

--- Comment #13 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Jakub Jelinek from comment #11)
> And, shouldn't common_maybe_local for i?86/x86_64 be
>   !flag_pic || (TARGET_64BIT && HAVE_LD_PIE_COPYRELOC != 0)
> ?  What about other targets that are known to generate COPY relocations in
> this case for non-PIE executables?  Should they pass !flag_pic?
> Perhaps there should be a generic default_binds_local_p* entry point that
> passes
> !flag_pic as common_maybe_local, that those targets could (after maintainers
> test it properly with various vintage linkers?) use as their
> TARGET_BINDS_LOCAL_P ?

Check flag_pic isn't necessary.  For non-PIC, the same code sequence
and relocation are used to access defined and undefined symbols, common
or not.

[Bug target/65780] [5/6 Regression] Uninitialized common handling in executables

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

--- Comment #14 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Jakub Jelinek from comment #10)
> (In reply to H.J. Lu from comment #9)
> > Created attachment 35327 [details]
> > A different patch
> > 
> > On x86, this issue only shows up with PIE. Here is a different
> > patch to treat common symbol defined locally only if the backend
> > passes true common_maybe_local.  For x86-64, it is true only if
> > HAVE_LD_PIE_COPYRELOC is 1.  For i386, it is always false.  If
> > we aren't building PIE, common_maybe_local is true or false
> > doesn't make a difference for x86 since the common symbol is
> > always referenced normally with copy reloc.  For PIE on x86-64,
> > common symbol is local only if HAVE_LD_PIE_COPYRELOC is 1.
> 
> +
> +  /* For common symbol, it is defined locally only if common_maybe_local
> +     is true.  */
> +  bool defined_locally = (!DECL_EXTERNAL (exp)
> +			  && (!DECL_COMMON (exp) || common_maybe_local));
> 
> I think better would be:
>   bool uninited_common = (DECL_COMMON (exp)
>                           && (DECL_INITIAL (exp) == NULL
>                               || (!in_lto_p && DECL_INITIAL (exp) ==
> error_mark_node)));
>   /* For common symbol, it is defined locally only if common_maybe_local
>      is true.  */
>   bool defined_locally = (!DECL_EXTERNAL (exp) && (!uninited_common ||
> common_maybe_local));
> ...
> and then use
>   /* Uninitialized COMMON variable may be unified with symbols
>      resolved from other modules.  */
>   if (uninited_common && !resolved_locally)
>     return false;

What does initialized COMMON look like to linker?  If it is marked
as COMMON symbol to linker, it will be treated the same as
uninitialized COMMON symbol.
>From gcc-bugs-return-483779-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Apr 16 11:31:42 2015
Return-Path: <gcc-bugs-return-483779-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 7502 invoked by alias); 16 Apr 2015 11:31:42 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 7459 invoked by uid 48); 16 Apr 2015 11:31:38 -0000
From: "schwab@linux-m68k.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/65774] [6.0 regression] FAIL: gcc.dg/builtin-arith-overflow-1.c (internal compiler error)
Date: Thu, 16 Apr 2015 11:31:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: schwab@linux-m68k.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 6.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65774-4-xy8wk0odaA@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65774-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65774-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-04/txt/msg01331.txt.bz2
Content-length: 167

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide774

--- Comment #3 from Andreas Schwab <schwab@linux-m68k.org> ---
wi::sext has undefined behaviour with offset == 0.

[Bug target/65780] [5/6 Regression] Uninitialized common handling in executables

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

--- Comment #15 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Jakub Jelinek from comment #10)
> (In reply to H.J. Lu from comment #9)
> > Created attachment 35327 [details]
> > A different patch
> > 
> > On x86, this issue only shows up with PIE. Here is a different
> > patch to treat common symbol defined locally only if the backend
> > passes true common_maybe_local.  For x86-64, it is true only if
> > HAVE_LD_PIE_COPYRELOC is 1.  For i386, it is always false.  If
> > we aren't building PIE, common_maybe_local is true or false
> > doesn't make a difference for x86 since the common symbol is
> > always referenced normally with copy reloc.  For PIE on x86-64,
> > common symbol is local only if HAVE_LD_PIE_COPYRELOC is 1.
> 
> +
> +  /* For common symbol, it is defined locally only if common_maybe_local
> +     is true.  */
> +  bool defined_locally = (!DECL_EXTERNAL (exp)
> +			  && (!DECL_COMMON (exp) || common_maybe_local));
> 
> I think better would be:
>   bool uninited_common = (DECL_COMMON (exp)
>                           && (DECL_INITIAL (exp) == NULL
>                               || (!in_lto_p && DECL_INITIAL (exp) ==
> error_mark_node)));
>   /* For common symbol, it is defined locally only if common_maybe_local
>      is true.  */
>   bool defined_locally = (!DECL_EXTERNAL (exp) && (!uninited_common ||
> common_maybe_local));
> ...
> and then use
>   /* Uninitialized COMMON variable may be unified with symbols
>      resolved from other modules.  */
>   if (uninited_common && !resolved_locally)
>     return false;

Can we find a tectase with initialized COMMON variable and compile
it as PIE?
>From gcc-bugs-return-483782-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Apr 16 11:41:36 2015
Return-Path: <gcc-bugs-return-483782-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 37628 invoked by alias); 16 Apr 2015 11:41:36 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 37588 invoked by uid 48); 16 Apr 2015 11:41:33 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/65780] [5/6 Regression] Uninitialized common handling in executables
Date: Thu, 16 Apr 2015 11:41:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65780-4-QpeEqwMpS8@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65780-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65780-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-04/txt/msg01334.txt.bz2
Content-length: 492

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide780

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to H.J. Lu from comment #13)
> Check flag_pic isn't necessary.  For non-PIC, the same code sequence
> and relocation are used to access defined and undefined symbols, common
> or not.

What do you mean by is not necessary?  Without that, you'll return false from
targetm.binds_local_p for DECL_COMMON in the testcase say on i686-linux, or if
you have old linker.

[Bug target/65780] [5/6 Regression] Uninitialized common handling in executables

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

--- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to H.J. Lu from comment #15)
> Can we find a tectase with initialized COMMON variable and compile
> it as PIE?

I don't know where initialized DECL_COMMON could come from, but this spot
certainly isn't the only one that is counting with that, e.g. when deciding
what section to use comm_section is used only if it is bbs_initializer_p, etc.
At least for GCC 5, I'd strongly prefer small provably correct changes at this
point.

[Bug target/65780] [5/6 Regression] Uninitialized common handling in executables

[hjl.tools at gmail dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 4103 bytes --]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

--- Comment #18 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Jakub Jelinek from comment #10)
> (In reply to H.J. Lu from comment #9)
> > Created attachment 35327 [details]
> > A different patch
> > 
> > On x86, this issue only shows up with PIE. Here is a different
> > patch to treat common symbol defined locally only if the backend
> > passes true common_maybe_local.  For x86-64, it is true only if
> > HAVE_LD_PIE_COPYRELOC is 1.  For i386, it is always false.  If
> > we aren't building PIE, common_maybe_local is true or false
> > doesn't make a difference for x86 since the common symbol is
> > always referenced normally with copy reloc.  For PIE on x86-64,
> > common symbol is local only if HAVE_LD_PIE_COPYRELOC is 1.
> 
> +
> +  /* For common symbol, it is defined locally only if common_maybe_local
> +     is true.  */
> +  bool defined_locally = (!DECL_EXTERNAL (exp)
> +			  && (!DECL_COMMON (exp) || common_maybe_local));
> 
> I think better would be:
>   bool uninited_common = (DECL_COMMON (exp)
>                           && (DECL_INITIAL (exp) == NULL
>                               || (!in_lto_p && DECL_INITIAL (exp) ==
> error_mark_node)));
>   /* For common symbol, it is defined locally only if common_maybe_local
>      is true.  */
>   bool defined_locally = (!DECL_EXTERNAL (exp) && (!uninited_common ||
> common_maybe_local));
> ...
> and then use
>   /* Uninitialized COMMON variable may be unified with symbols
>      resolved from other modules.  */
>   if (uninited_common && !resolved_locally)
>     return false;

Here is a testcase:

---
int optopt = 5;
int optopt;

int
main ()
{
  optopt = 4;
  return 0;
}
----
~
>From gcc-bugs-return-483786-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Apr 16 11:48:38 2015
Return-Path: <gcc-bugs-return-483786-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 51302 invoked by alias); 16 Apr 2015 11:48:37 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 51253 invoked by uid 48); 16 Apr 2015 11:48:32 -0000
From: "hjl.tools at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/65780] [5/6 Regression] Uninitialized common handling in executables
Date: Thu, 16 Apr 2015 11:48:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hjl.tools at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.isobsolete attachments.created
Message-ID: <bug-65780-4-6dmNRTir22@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65780-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65780-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-04/txt/msg01338.txt.bz2
Content-length: 504

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide780

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #35327|0                           |1
        is obsolete|                            |

--- Comment #19 from H.J. Lu <hjl.tools at gmail dot com> ---
Created attachment 35330
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id5330&actioníit
A new patch

[Bug target/65780] [5/6 Regression] Uninitialized common handling in executables

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

--- Comment #20 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Jakub Jelinek from comment #16)
> (In reply to H.J. Lu from comment #13)
> > Check flag_pic isn't necessary.  For non-PIC, the same code sequence
> > and relocation are used to access defined and undefined symbols, common
> > or not.
> 
> What do you mean by is not necessary?  Without that, you'll return false
> from targetm.binds_local_p for DECL_COMMON in the testcase say on
> i686-linux, or if you have old linker.

I guess it won't hurt.

[Bug target/65780] [5/6 Regression] Uninitialized common handling in executables

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

--- Comment #21 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I've repeated my test on the various architectures, this time with additional
readelf -Ws test | grep optopt
if the link succeeds.  And indeed, x86_64 with recent linker is the only one
where optopt is defined, rather than SHN_UNDEF in the PIE.  armv7hl, s390,
s390x, i686 and x86_64 with old linker all have optopt defined in the binary
for normal executable (!flag_pic) and SHN_UNDEF for PIE.

Thus, based on this I'd say that i386 backend should pass
!flag_pic || (TARGET_64BIT && HAVE_LD_PIE_COPYRELOC != 0)
to the new param (in ix86_binds_local_p).
Then, perhaps you should make default_binds_local_p_3 also non-static and
declared in output.h, ix86_binds_local_p should perhaps use it directly, and
default_binds_local_p_2 should have just a single argument, so that arm and
s390 backends (dunno, maybe aarch64 and a few others too) could use it directly
as their TARGET_BINDS_LOCAL_P definition.  default_binds_local_p_2 would then
call
default_binds_local_p_3 with
exp, flag_shlib != 0, true, false, !flag_pic
arguments.  And obviously all the two (default_binds_local_p{,2}) should have
better documentation on how they differ.

[Bug target/65780] [5/6 Regression] Uninitialized common handling in executables

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #35330|0                           |1
        is obsolete|                            |

--- Comment #22 from H.J. Lu <hjl.tools at gmail dot com> ---
Created attachment 35331
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35331&action=edit
A patch

I am testing this.

[Bug target/65780] [5/6 Regression] Uninitialized common handling in executables

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

--- Comment #23 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to H.J. Lu from comment #22)
> Created attachment 35331 [details]
> A patch
> 
> I am testing this.

+static bool
+ix86_binds_local_p (const_tree exp)
+{
+  return default_binds_local_p_3 (exp, flag_shlib != 0, true, false,
+                  (!flag_pic
+                   || (TARGET_64BIT
+                       && HAVE_LD_PIE_COPYRELOC != 0)));
+}

shouldn't the 4th argument be true?  At least before this patch, i386 backend
was the only one that passed true as extern_protected_data, but after this
patch you never pass true to that parameter, making it dead again.

Also, a typo:

lcoal -> local

[Bug target/65780] [5/6 Regression] Uninitialized common handling in executables

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

--- Comment #24 from H.J. Lu <hjl.tools at gmail dot com> ---
Created attachment 35332
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35332&action=edit
A patch

[Bug target/65780] [5/6 Regression] Uninitialized common handling in executables

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

--- Comment #25 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Comment on attachment 35332
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35332
A patch

An non-external
shouldn't this be
A non-external
?
Other than that LGTM, but I'd prefer another pair of eyes on this.

[Bug target/65780] [5/6 Regression] Uninitialized common handling in executables

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #35332|0                           |1
        is obsolete|                            |

--- Comment #26 from H.J. Lu <hjl.tools at gmail dot com> ---
Created attachment 35333
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35333&action=edit
A patch with updated comments

[Bug target/65780] [5/6 Regression] Uninitialized common handling in executables

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

--- Comment #27 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to H.J. Lu from comment #26)
> Created attachment 35333 [details]
> A patch with updated comments

Found a couple of issues, here is incremental diff, mostly formatting
improvements,
and in the case of default_binds_local_p_2 (right now unused, hopefully
incrementally used
by arm, s390 and perhaps other backends later), passing true to
common_maybe_local unconditionally,
when only in non-PIE binaries (thus !flag_pic) it works fine.

--- gcc/varasm.c
+++ gcc/varasm.c
@@ -6811,8 +6811,7 @@

 bool
 default_binds_local_p_3 (const_tree exp, bool shlib, bool weak_dominate,
-             bool extern_protected_data,
-             bool common_maybe_local)
+             bool extern_protected_data, bool common_maybe_local)
 {
   /* A non-decl is an entry in the constant pool.  */
   if (!DECL_P (exp))
@@ -6902,8 +6901,7 @@
 bool
 default_binds_local_p (const_tree exp)
 {
-  return default_binds_local_p_3 (exp, flag_shlib != 0, true, false,
-                  false);
+  return default_binds_local_p_3 (exp, flag_shlib != 0, true, false, false);
 }

 /* Similar to default_binds_local_p, but common symbol may be local.  */
@@ -6912,14 +6910,13 @@
 default_binds_local_p_2 (const_tree exp)
 {
   return default_binds_local_p_3 (exp, flag_shlib != 0, true, false,
-                  true);
+                  !flag_pic);
 }

 bool
 default_binds_local_p_1 (const_tree exp, int shlib)
 {
-  return default_binds_local_p_3 (exp, shlib != 0, false, false,
-                  false);
+  return default_binds_local_p_3 (exp, shlib != 0, false, false, false);
 }

 /* Return true when references to DECL must bind to current definition in

[Bug target/65780] [5/6 Regression] Uninitialized common handling in executables

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #35333|0                           |1
        is obsolete|                            |

--- Comment #28 from H.J. Lu <hjl.tools at gmail dot com> ---
Created attachment 35335
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35335&action=edit
The final patch

[Bug target/65780] [5/6 Regression] Uninitialized common handling in executables

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

--- Comment #29 from Jeffrey A. Law <law at redhat dot com> ---
Oh how I wish all this stuff was better documented, both in the GCC sources and
at a higher level in some linkers/loaders documentation.

ix86_binds_local_p needs a function comment.  I think with a function comment,
no comments would be needed in the function body.

I think it's also advisable to get a function comment for the
default_binds_local* that don't currently have one. 

What I'm trying to wrap my head around is what "defined_locally" really means. 
Is it a "must" or "maybe" property when it gets set in default_binds_local_p_3?

If it's a must property, then "common_maybe_local" seems mis-named and/or
mis-used (the former seems most likely to me).

If it's a maybe property, then why is a common uninit local filtered out?  At
this point we don't know if a common uninit local will be defined locally or
not, so it's a maybe.

I can probably go forward with an approval or specific change recommendations
that would lead to approval once someone can tell me if defined_locally is a
maybe or must property.

[Bug target/65780] [5/6 Regression] Uninitialized common handling in executables

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #35335|0                           |1
        is obsolete|                            |

--- Comment #30 from H.J. Lu <hjl.tools at gmail dot com> ---
Created attachment 35336
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35336&action=edit
The final patch

[Bug target/65780] [5/6 Regression] Uninitialized common handling in executables

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

--- Comment #31 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Jeffrey A. Law from comment #29)
> Oh how I wish all this stuff was better documented, both in the GCC sources
> and at a higher level in some linkers/loaders documentation.
> 
> ix86_binds_local_p needs a function comment.  I think with a function
> comment, no comments would be needed in the function body.

Updated.

> I think it's also advisable to get a function comment for the
> default_binds_local* that don't currently have one. 

That can be done in a flow-up patch.

> What I'm trying to wrap my head around is what "defined_locally" really
> means.  Is it a "must" or "maybe" property when it gets set in
> default_binds_local_p_3?
> 
> If it's a must property, then "common_maybe_local" seems mis-named and/or
> mis-used (the former seems most likely to me).
> 
> If it's a maybe property, then why is a common uninit local filtered out? 
> At this point we don't know if a common uninit local will be defined locally
> or not, so it's a maybe.
> 
> I can probably go forward with an approval or specific change
> recommendations that would lead to approval once someone can tell me if
> defined_locally is a maybe or must property.

A common symbol in PIC will never be local, for any targets, unless
it has hidden/internal visibility.

[Bug target/65780] [5/6 Regression] Uninitialized common handling in executables

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

--- Comment #32 from Jeffrey A. Law <law at redhat dot com> ---
HJ, you're missing my point.  I need to understand the meaning of the variable
defined_locally to move forward with the patch.  Is it a must property (ie, if
true, the symbol is always defined locally), or is it a may property (ie, if
set, the symbol may be defined locally, but might also be defined externally).

Much of the correctness of the patch hinges on that question.

[Bug target/65780] [5/6 Regression] Uninitialized common handling in executables

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

--- Comment #33 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Jeffrey A. Law from comment #32)
> HJ, you're missing my point.  I need to understand the meaning of the
> variable defined_locally to move forward with the patch.  Is it a must
> property (ie, if true, the symbol is always defined locally), or is it a may
> property (ie, if set, the symbol may be defined locally, but might also be
> defined externally).
> 
> Much of the correctness of the patch hinges on that question.

There are 2 variables, defined_locally and resolved_locally.
A symbol can be defined locally, but not resolved locally,
depending on PIC and/or visibility.

[Bug target/65780] [5/6 Regression] Uninitialized common handling in executables

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

--- Comment #34 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Jeffrey A. Law from comment #29)
> What I'm trying to wrap my head around is what "defined_locally" really
> means.  Is it a "must" or "maybe" property when it gets set in
> default_binds_local_p_3?

I'd say it is a "must" property, the decl must be defined locally.
A common var is of course a corner case, because uninitialized common var
"maybe" defined locally if it doesn't have a strong definition elsewhere.
And, for executables (normal and PIE), if the linker arranges for the
definition to be present (through COPY relocation) in the executable, it "must"
be defined locally too, even if it has a strong definition in a dependent
shared library.

> If it's a must property, then "common_maybe_local" seems mis-named and/or
> mis-used (the former seems most likely to me).

I'd say mis-named; so what about common_local_p, with a comment describing it -
if the linker can guarantee that an uninited common symbol in the executable
will still be defined (through COPY relocation) in the executable, then this
flag should be set.

[Bug target/65780] [5/6 Regression] Uninitialized common handling in executables

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

--- Comment #35 from H.J. Lu <hjl.tools at gmail dot com> ---
Created attachment 35341
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35341&action=edit
The final patch with variable name change and updated comments

[Bug target/65780] [5/6 Regression] Uninitialized common handling in executables

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

--- Comment #36 from Jeffrey A. Law <law at redhat dot com> ---
Patch in c#35 is approved.

[Bug target/65780] [5 Regression] Uninitialized common handling in executables

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[5/6 Regression]            |[5 Regression]
                   |Uninitialized common        |Uninitialized common
                   |handling in executables     |handling in executables

--- Comment #38 from H.J. Lu <hjl.tools at gmail dot com> ---
Fixed on trunk so far.

[Bug target/65780] [5 Regression] Uninitialized common handling in executables

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

--- Comment #39 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Please commit it to the branch too, I'll do another RC tomorrow.

[Bug target/65780] [5 Regression] Uninitialized common handling in executables

[hjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

--- Comment #40 from hjl at gcc dot gnu.org <hjl at gcc dot gnu.org> ---
Author: hjl
Date: Fri Apr 17 16:36:22 2015
New Revision: 222185

URL: https://gcc.gnu.org/viewcvs?rev=222185&root=gcc&view=rev
Log:
Properly handle uninitialized common symbol

Uninitialized common symbol behavior in executables is target and linker
dependent.  default_binds_local_p_3 is made public and updated to take an
argument to indicate if the linker can guarantee that an uninitialized
common symbol in the executable will still be defined (through COPY
relocation) in the executable.  If common symbol is local to executable,
default_binds_local_p_3 will treat non-external variable as defined
locally.  default_binds_local_p_2 is changed to treat common symbol as
local for non-PIE binaries.

For i386, common symbol is local only for non-PIE binaries.  For x86-64,
common symbol is local only for non-PIE binaries or linker supports copy
reloc in PIE binaries.  If a target treats common symbol as local only
for non-PIE binaries, it can define TARGET_BINDS_LOCAL_P as
default_binds_local_p_2.

gcc/

    PR target/65780
    * output.h (default_binds_local_p_3): New.
    * varasm.c (default_binds_local_p_3): Make it public.  Take an
    argument to indicate if common symbol may be local.  If common
    symbol may be local, treat non-external variable as defined
    locally.
    (default_binds_local_p_2): Pass !flag_pic to default_binds_local_p_3.
    (default_binds_local_p_1): Pass false to default_binds_local_p_3.
    * config/i386/i386.c (ix86_binds_local_p): New.
    (TARGET_BINDS_LOCAL_P): Replace default_binds_local_p_2 with
    ix86_binds_local_p.

gcc/testsuite/

    PR target/65780
    * gcc.dg/pr65780-1.c: New test.
    * gcc.dg/pr65780-2.c: Likewise.
    * gcc.target/i386/pr32219-9.c: Likewise.
    * gcc.target/i386/pr32219-1.c (xxx): Make it initialized common
    symbol.
    * gcc.target/i386/pr64317.c (c): Initialize.

Added:
    branches/gcc-5-branch/gcc/testsuite/gcc.dg/pr65780-1.c
    branches/gcc-5-branch/gcc/testsuite/gcc.dg/pr65780-2.c
    branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr32219-9.c
Modified:
    branches/gcc-5-branch/gcc/ChangeLog
    branches/gcc-5-branch/gcc/config/i386/i386.c
    branches/gcc-5-branch/gcc/output.h
    branches/gcc-5-branch/gcc/testsuite/ChangeLog
    branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr32219-1.c
    branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr64317.c
    branches/gcc-5-branch/gcc/varasm.c

[Bug target/65780] [5 Regression] Uninitialized common handling in executables

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #41 from H.J. Lu <hjl.tools at gmail dot com> ---
Fixed for 5.1.

[Bug target/65780] [5 Regression] Uninitialized common handling in executables

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |---

--- Comment #42 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Revision r222184 breaks bootstrap on x86_64-apple-darwin14:

/opt/gcc/build_w/./prev-gcc/xg++ -B/opt/gcc/build_w/./prev-gcc/
-B/opt/gcc/gcc6w/x86_64-apple-darwin14.3.0/bin/ -nostdinc++
-B/opt/gcc/build_w/prev-x86_64-apple-darwin14.3.0/libstdc++-v3/src/.libs
-B/opt/gcc/build_w/prev-x86_64-apple-darwin14.3.0/libstdc++-v3/libsupc++/.libs 
-I/opt/gcc/build_w/prev-x86_64-apple-darwin14.3.0/libstdc++-v3/include/x86_64-apple-darwin14.3.0
 -I/opt/gcc/build_w/prev-x86_64-apple-darwin14.3.0/libstdc++-v3/include 
-I/opt/gcc/work/libstdc++-v3/libsupc++
-L/opt/gcc/build_w/prev-x86_64-apple-darwin14.3.0/libstdc++-v3/src/.libs
-L/opt/gcc/build_w/prev-x86_64-apple-darwin14.3.0/libstdc++-v3/libsupc++/.libs
-c  -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -O2   -gtoggle -DIN_GCC   
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror
-fno-common  -DHAVE_CONFIG_H -I. -Icp -I../../work/gcc -I../../work/gcc/cp
-I../../work/gcc/../include -I./../intl -I../../work/gcc/../libcpp/include
-I/opt/mp-new/include  -I../../work/gcc/../libdecnumber
-I../../work/gcc/../libdecnumber/dpd -I../libdecnumber
-I../../work/gcc/../libbacktrace -I/opt/mp-new/include  -o cp/optimize.o -MT
cp/optimize.o -MMD -MP -MF cp/.deps/optimize.TPo ../../work/gcc/cp/optimize.c
../../work/gcc/config/i386/i386.c:51747:1: error: 'bool
ix86_binds_local_p(const_tree)' defined but not used [-Werror=unused-function]
 ix86_binds_local_p (const_tree exp)
 ^
cc1plus: all warnings being treated as errors
Makefile:2071: recipe for target 'i386.o' failed
make[3]: *** [i386.o] Error 1

Bootstrap is restored if I comment the block

static bool
ix86_binds_local_p (const_tree exp)
{
  return default_binds_local_p_3 (exp, flag_shlib != 0, true, true,
                                  (!flag_pic
                                   || (TARGET_64BIT
                                       && HAVE_LD_PIE_COPYRELOC != 0)));
}

[Bug target/65780] [5 Regression] Uninitialized common handling in executables

[hjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

--- Comment #43 from hjl at gcc dot gnu.org <hjl at gcc dot gnu.org> ---
Author: hjl
Date: Fri Apr 17 21:54:22 2015
New Revision: 222201

URL: https://gcc.gnu.org/viewcvs?rev=222201&root=gcc&view=rev
Log:
Don't define ix86_binds_local_p for MacOS nor Windows

    PR target/65780
    * config/i386/i386.c (ix86_binds_local_p): Define only if
    TARGET_MACHO and TARGET_DLLIMPORT_DECL_ATTRIBUTES are false.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/i386.c

[Bug target/65780] [5 Regression] Uninitialized common handling in executables

[hjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

--- Comment #44 from hjl at gcc dot gnu.org <hjl at gcc dot gnu.org> ---
Author: hjl
Date: Fri Apr 17 21:55:05 2015
New Revision: 222202

URL: https://gcc.gnu.org/viewcvs?rev=222202&root=gcc&view=rev
Log:
Don't define ix86_binds_local_p for MacOS nor Windows

    PR target/65780
    * config/i386/i386.c (ix86_binds_local_p): Define only if
    TARGET_MACHO and TARGET_DLLIMPORT_DECL_ATTRIBUTES are false.

Modified:
    branches/gcc-5-branch/gcc/ChangeLog
    branches/gcc-5-branch/gcc/config/i386/i386.c

[Bug target/65780] [5 Regression] Uninitialized common handling in executables

[howarth.at.gcc at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

Jack Howarth <howarth.at.gcc at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |howarth.at.gcc at gmail dot com

--- Comment #45 from Jack Howarth <howarth.at.gcc at gmail dot com> ---
Is this considered fixed now for 5.1?

[Bug target/65780] [5 Regression] Uninitialized common handling in executables

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #46 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I think so.

[Bug target/65780] [5 Regression] Uninitialized common handling in executables

[evstupac at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

Stupachenko Evgeny <evstupac at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |evstupac at gmail dot com

--- Comment #47 from Stupachenko Evgeny <evstupac at gmail dot com> ---
The patch caused significant regressions (see below) on spec2000 INT benchmarks
compiled with options “-fPIE -pie -O2 -ffast-math -mfpmath=sse -m32
-march=corei7-avx” or “-fPIE -pie -O2 -ffast-math -mfpmath=sse -m32
-march=slm”.

Sandybridge:
164.gzip    1635.0000  1602.0000 -2.01% 
197.parser  2159.0000  2117.0000 -1.94% 
254.gap     2909.0000  2886.0000 -0.79% 
256.bzip2   2232.0000  2154.0000 -3.49%

Silvermont:
164.gzip     964.0000   945.0000 -1.97% 
197.parser   951.0000   940.0000 -1.15% 
254.gap     1328.0000  1296.0000 -2.40% 
256.bzip2    952.0000   898.0000 -5.67%
>From gcc-bugs-return-484183-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Apr 21 14:15:18 2015
Return-Path: <gcc-bugs-return-484183-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 113101 invoked by alias); 21 Apr 2015 14:15:18 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 112883 invoked by uid 48); 21 Apr 2015 14:15:13 -0000
From: "mm at mezzarobba dot net" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/65833] New: Attempting to convert 128 bit integers to 128 bit decimal floating-point results in an unresolved symbol
Date: Tue, 21 Apr 2015 14:15:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mm at mezzarobba dot net
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc
Message-ID: <bug-65833-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-04/txt/msg01735.txt.bz2
Content-length: 6963

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide833

            Bug ID: 65833
           Summary: Attempting to convert 128 bit integers to 128 bit
                    decimal floating-point results in an unresolved symbol
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mm at mezzarobba dot net
                CC: christoph.lauter at lip6 dot fr

The following code

$ cat stitd.c
int main(void) {
    __uint128_t foo = 42;
    _Decimal128 bar = foo;
    (void) bar;
    return 0;
}

fails to link with

$ gcc -Wall -Wextra -std=gnu11 stitd.c
/tmp/ccY4noUz.o: In function `main':
stitd.c:(.text+0x27): undefined reference to `__bid_floatunstitd'
collect2: error: ld returned 1 exit status
(exit 1)

Changing __uint128_t to __int128_t results in a similar error. Replacing
_Decimal128 by __float128 works.

~/docs/vrac/c$ gcc -v --version
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
gcc (Debian 4.9.2-10) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10'
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.2 (Debian 4.9.2-10)
COLLECT_GCC_OPTIONS='-v' '--version' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/4.9/cc1 -quiet -v -imultiarch x86_64-linux-gnu
help-dummy -quiet -dumpbase help-dummy -mtune=generic -march=x86-64 -auxbase
help-dummy -version --version -o /tmp/cc2dxKl2.s
GNU C (Debian 4.9.2-10) version 4.9.2 (x86_64-linux-gnu)
        compiled by GNU C version 4.9.2, GMP version 6.0.0, MPFR version
3.1.2-p3, MPC version 1.0.2
warning: MPFR header version 3.1.2-p3 differs from library version 3.1.2-p11.
warning: MPC header version 1.0.2 differs from library version 1.0.3.
GGC heuristics: --param ggc-min-expand\x100 --param ggc-min-heapsize\x131072
COLLECT_GCC_OPTIONS='-v' '--version' '-mtune=generic' '-march=x86-64'
 as -v --64 --version -o /tmp/ccNgVCKN.o /tmp/cc2dxKl2.s
GNU assembler version 2.25 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Debian) 2.25
GNU assembler (GNU Binutils for Debian) 2.25
Copyright (C) 2014 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `x86_64-linux-gnu'.
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.9/:/usr/lib/gcc/x86_64-linux-gnu/4.9/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.9/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.9/:/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '--version' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/4.9/collect2 -plugin
/usr/lib/gcc/x86_64-linux-gnu/4.9/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
-plugin-opt=-fresolution=/tmp/cc8TwP9y.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --sysroot=/
--build-id --eh-frame-hdr -m elf_x86_64 --hash-style=gnu -dynamic-linker
/lib64/ld-linux-x86-64.so.2 --version
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crt1.o
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crti.o
/usr/lib/gcc/x86_64-linux-gnu/4.9/crtbegin.o
-L/usr/lib/gcc/x86_64-linux-gnu/4.9
-L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu
-L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../lib -L/lib/x86_64-linux-gnu
-L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib
-L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../.. /tmp/ccNgVCKN.o -lgcc --as-needed
-lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
/usr/lib/gcc/x86_64-linux-gnu/4.9/crtend.o
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crtn.o
collect2 version 4.9.2
/usr/bin/ld -plugin /usr/lib/gcc/x86_64-linux-gnu/4.9/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
-plugin-opt=-fresolution=/tmp/cc8TwP9y.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --sysroot=/
--build-id --eh-frame-hdr -m elf_x86_64 --hash-style=gnu -dynamic-linker
/lib64/ld-linux-x86-64.so.2 --version
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crt1.o
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crti.o
/usr/lib/gcc/x86_64-linux-gnu/4.9/crtbegin.o
-L/usr/lib/gcc/x86_64-linux-gnu/4.9
-L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu
-L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../lib -L/lib/x86_64-linux-gnu
-L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib
-L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../.. /tmp/ccNgVCKN.o -lgcc --as-needed
-lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
/usr/lib/gcc/x86_64-linux-gnu/4.9/crtend.o
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crtn.o
GNU ld (GNU Binutils for Debian) 2.25
Copyright (C) 2014 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.

[Bug target/65780] [5 Regression] Uninitialized common handling in executables

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

--- Comment #48 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Stupachenko Evgeny from comment #47)
> The patch caused significant regressions (see below) on spec2000 INT
> benchmarks compiled with options “-fPIE -pie -O2 -ffast-math -mfpmath=sse
> -m32 -march=corei7-avx” or “-fPIE -pie -O2 -ffast-math -mfpmath=sse -m32
> -march=slm”.
> 
> Sandybridge:
> 164.gzip    1635.0000  1602.0000 -2.01% 
> 197.parser  2159.0000  2117.0000 -1.94% 
> 254.gap     2909.0000  2886.0000 -0.79% 
> 256.bzip2   2232.0000  2154.0000 -3.49%
> 
> Silvermont:
> 164.gzip     964.0000   945.0000 -1.97% 
> 197.parser   951.0000   940.0000 -1.15% 
> 254.gap     1328.0000  1296.0000 -2.40% 
> 256.bzip2    952.0000   898.0000 -5.67%

That is the price to pay for correctness.  If you want to avoid that penalty,
I'd say change ld.bfd as well as ld.gold on i?86 to use COPY relocations for
PIEs like x86_64 has been changed some time ago, then when configured against
improved linker and with small patch to gcc you can recover not just that cost,
but some more on top of that.
>From gcc-bugs-return-484185-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Apr 21 14:40:30 2015
Return-Path: <gcc-bugs-return-484185-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 56716 invoked by alias); 21 Apr 2015 14:40:30 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 56656 invoked by uid 48); 21 Apr 2015 14:40:26 -0000
From: "hjl.tools at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/65780] [5 Regression] Uninitialized common handling in executables
Date: Tue, 21 Apr 2015 14:40:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hjl.tools at gmail dot com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65780-4-xqa06SnBqg@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65780-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65780-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-04/txt/msg01737.txt.bz2
Content-length: 1070

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

--- Comment #49 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Stupachenko Evgeny from comment #47)
> The patch caused significant regressions (see below) on spec2000 INT
> benchmarks compiled with options “-fPIE -pie -O2 -ffast-math -mfpmath=sse
> -m32 -march=corei7-avx” or “-fPIE -pie -O2 -ffast-math -mfpmath=sse -m32
> -march=slm”.
> 
> Sandybridge:
> 164.gzip    1635.0000  1602.0000 -2.01% 
> 197.parser  2159.0000  2117.0000 -1.94% 
> 254.gap     2909.0000  2886.0000 -0.79% 
> 256.bzip2   2232.0000  2154.0000 -3.49%
> 
> Silvermont:
> 164.gzip     964.0000   945.0000 -1.97% 
> 197.parser   951.0000   940.0000 -1.15% 
> 254.gap     1328.0000  1296.0000 -2.40% 
> 256.bzip2    952.0000   898.0000 -5.67%

As Jakub pointed out, this commit is for correctness.  Please open
a new bug report to optimize undefined/common symbol access in PIE
if linker supports copy reloc in PIE:

https://sourceware.org/bugzilla/show_bug.cgi?id=18289
>From gcc-bugs-return-484186-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Apr 21 15:20:11 2015
Return-Path: <gcc-bugs-return-484186-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 84704 invoked by alias); 21 Apr 2015 15:20:11 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 84677 invoked by uid 48); 21 Apr 2015 15:20:06 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug preprocessor/65834] New: give error for #if with no expression at the previous location
Date: Tue, 21 Apr 2015 15:20:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: preprocessor
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-65834-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-04/txt/msg01738.txt.bz2
Content-length: 1090

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65834

            Bug ID: 65834
           Summary: give error for #if with no expression at the previous
                    location
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: preprocessor
          Assignee: unassigned at gcc dot gnu.org
          Reporter: manu at gcc dot gnu.org

Distilled from:
http://www.linuxquestions.org/questions/linux-from-scratch-13/replace-gcc-with-clang-4175491981/#post5108443

extern void foo(void);
#define TEST

int bar(void)
{
#if TEST
  foo();
#endif
  return 0;
}

Currently:

test.c:6:9: error: #if with no expression
 #if TEST
         ^

Expected something like:

test.c:6:9: error: #if with no expression
 #if TEST
     ^
test.c:2:14: note: in expansion of macro ‘TEST’

I think this could be possible by giving the error at the location of TEST
(which should be the previously encoded source_location) rather that at the
current one.

 #define TEST 
              ^
>From gcc-bugs-return-484187-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Apr 21 15:27:02 2015
Return-Path: <gcc-bugs-return-484187-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 94679 invoked by alias); 21 Apr 2015 15:27:01 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 94628 invoked by uid 48); 21 Apr 2015 15:26:56 -0000
From: "vries at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/65823] [6 Regression] ICE in gcc.c-torture/execute/stdarg-2.c -O0/-O1 for arm
Date: Tue, 21 Apr 2015 15:27:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: vries at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 6.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65823-4-SIe4SC6Rjs@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65823-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65823-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-04/txt/msg01739.txt.bz2
Content-length: 371

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide823

--- Comment #6 from vries at gcc dot gnu.org ---
(In reply to vries from comment #5)
> The nop introduced during gimplification is not meant to be there. This
> patch gets rid of it:

I've build an arm compiler with the patch, and tested execute.exp=stdarg-2.c.
Indeed the failure is gone, and the execution succeeds.

[Bug target/65780] [5 Regression] Uninitialized common handling in executables

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

--- Comment #50 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Mon May 11 07:09:04 2015
New Revision: 222992

URL: https://gcc.gnu.org/viewcvs?rev=222992&root=gcc&view=rev
Log:
        PR target/65780
        * config/s390/linux.h (TARGET_BINDS_LOCAL_P): Define to
        default_binds_local_p_2.
        * config/arm/linux-elf.h (TARGET_BINDS_LOCAL_P): Likewise.
        * config/aarch64/aarch64-linux.h (TARGET_BINDS_LOCAL_P): Likewise.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/aarch64/aarch64-linux.h
    trunk/gcc/config/arm/linux-elf.h
    trunk/gcc/config/s390/linux.h

[Bug target/65780] [5 Regression] Uninitialized common handling in executables

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

--- Comment #51 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Mon May 11 07:14:10 2015
New Revision: 222993

URL: https://gcc.gnu.org/viewcvs?rev=222993&root=gcc&view=rev
Log:
        PR target/65780
        * config/s390/linux.h (TARGET_BINDS_LOCAL_P): Define to
        default_binds_local_p_2.
        * config/arm/linux-elf.h (TARGET_BINDS_LOCAL_P): Likewise.
        * config/aarch64/aarch64-linux.h (TARGET_BINDS_LOCAL_P): Likewise.

Modified:
    branches/gcc-5-branch/gcc/ChangeLog
    branches/gcc-5-branch/gcc/config/aarch64/aarch64-linux.h
    branches/gcc-5-branch/gcc/config/arm/linux-elf.h
    branches/gcc-5-branch/gcc/config/s390/linux.h