* [Bug target/65780] [5 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
@ 2015-04-15 22:30 ` jakub at gcc dot gnu.org
2015-04-15 23:01 ` james410 at cowgill dot org.uk
` (47 subsequent siblings)
48 siblings, 0 replies; 50+ messages in thread
From: jakub at gcc dot gnu.org @ 2015-04-15 22:30 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
2015-04-15 22:30 ` [Bug target/65780] " jakub at gcc dot gnu.org
@ 2015-04-15 23:01 ` james410 at cowgill dot org.uk
2015-04-15 23:13 ` hjl.tools at gmail dot com
` (46 subsequent siblings)
48 siblings, 0 replies; 50+ messages in thread
From: james410 at cowgill dot org.uk @ 2015-04-15 23:01 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
2015-04-15 22:30 ` [Bug target/65780] " jakub at gcc dot gnu.org
2015-04-15 23:01 ` james410 at cowgill dot org.uk
@ 2015-04-15 23:13 ` hjl.tools at gmail dot com
2015-04-15 23:41 ` hjl.tools at gmail dot com
` (45 subsequent siblings)
48 siblings, 0 replies; 50+ messages in thread
From: hjl.tools at gmail dot com @ 2015-04-15 23:13 UTC (permalink / raw)
To: gcc-bugs
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]$
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
` (2 preceding siblings ...)
2015-04-15 23:13 ` hjl.tools at gmail dot com
@ 2015-04-15 23:41 ` hjl.tools at gmail dot com
2015-04-16 0:37 ` amodra at gmail dot com
` (44 subsequent siblings)
48 siblings, 0 replies; 50+ messages in thread
From: hjl.tools at gmail dot com @ 2015-04-15 23:41 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
` (3 preceding siblings ...)
2015-04-15 23:41 ` hjl.tools at gmail dot com
@ 2015-04-16 0:37 ` amodra at gmail dot com
2015-04-16 2:10 ` hjl.tools at gmail dot com
` (43 subsequent siblings)
48 siblings, 0 replies; 50+ messages in thread
From: amodra at gmail dot com @ 2015-04-16 0:37 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
` (4 preceding siblings ...)
2015-04-16 0:37 ` amodra at gmail dot com
@ 2015-04-16 2:10 ` hjl.tools at gmail dot com
2015-04-16 2:38 ` hjl.tools at gmail dot com
` (42 subsequent siblings)
48 siblings, 0 replies; 50+ messages in thread
From: hjl.tools at gmail dot com @ 2015-04-16 2:10 UTC (permalink / raw)
To: gcc-bugs
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]$
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
` (5 preceding siblings ...)
2015-04-16 2:10 ` hjl.tools at gmail dot com
@ 2015-04-16 2:38 ` hjl.tools at gmail dot com
2015-04-16 3:22 ` [Bug target/65780] [5 Regression] Uninitialized common handling in PIE hjl.tools at gmail dot com
` (41 subsequent siblings)
48 siblings, 0 replies; 50+ messages in thread
From: hjl.tools at gmail dot com @ 2015-04-16 2:38 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5 Regression] Uninitialized common handling in PIE
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
` (6 preceding siblings ...)
2015-04-16 2:38 ` hjl.tools at gmail dot com
@ 2015-04-16 3:22 ` hjl.tools at gmail dot com
2015-04-16 3:28 ` [Bug target/65780] [5 Regression] Uninitialized common handling in executables amodra at gmail dot com
` (40 subsequent siblings)
48 siblings, 0 replies; 50+ messages in thread
From: hjl.tools at gmail dot com @ 2015-04-16 3:22 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
` (7 preceding siblings ...)
2015-04-16 3:22 ` [Bug target/65780] [5 Regression] Uninitialized common handling in PIE hjl.tools at gmail dot com
@ 2015-04-16 3:28 ` amodra at gmail dot com
2015-04-16 4:32 ` hjl.tools at gmail dot com
` (39 subsequent siblings)
48 siblings, 0 replies; 50+ messages in thread
From: amodra at gmail dot com @ 2015-04-16 3:28 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
` (8 preceding siblings ...)
2015-04-16 3:28 ` [Bug target/65780] [5 Regression] Uninitialized common handling in executables amodra at gmail dot com
@ 2015-04-16 4:32 ` hjl.tools at gmail dot com
2015-04-16 7:33 ` jakub at gcc dot gnu.org
` (38 subsequent siblings)
48 siblings, 0 replies; 50+ messages in thread
From: hjl.tools at gmail dot com @ 2015-04-16 4:32 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
` (9 preceding siblings ...)
2015-04-16 4:32 ` hjl.tools at gmail dot com
@ 2015-04-16 7:33 ` jakub at gcc dot gnu.org
2015-04-16 7:39 ` [Bug target/65780] [5/6 " rguenth at gcc dot gnu.org
` (37 subsequent siblings)
48 siblings, 0 replies; 50+ messages in thread
From: jakub at gcc dot gnu.org @ 2015-04-16 7:33 UTC (permalink / raw)
To: gcc-bugs
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;
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5/6 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
` (10 preceding siblings ...)
2015-04-16 7:33 ` jakub at gcc dot gnu.org
@ 2015-04-16 7:39 ` rguenth at gcc dot gnu.org
2015-04-16 7:46 ` jakub at gcc dot gnu.org
` (36 subsequent siblings)
48 siblings, 0 replies; 50+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-04-16 7:39 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5/6 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
` (11 preceding siblings ...)
2015-04-16 7:39 ` [Bug target/65780] [5/6 " rguenth at gcc dot gnu.org
@ 2015-04-16 7:46 ` jakub at gcc dot gnu.org
2015-04-16 11:09 ` jakub at gcc dot gnu.org
` (35 subsequent siblings)
48 siblings, 0 replies; 50+ messages in thread
From: jakub at gcc dot gnu.org @ 2015-04-16 7:46 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5/6 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
` (12 preceding siblings ...)
2015-04-16 7:46 ` jakub at gcc dot gnu.org
@ 2015-04-16 11:09 ` jakub at gcc dot gnu.org
2015-04-16 11:12 ` hjl.tools at gmail dot com
` (34 subsequent siblings)
48 siblings, 0 replies; 50+ messages in thread
From: jakub at gcc dot gnu.org @ 2015-04-16 11:09 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5/6 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
` (13 preceding siblings ...)
2015-04-16 11:09 ` jakub at gcc dot gnu.org
@ 2015-04-16 11:12 ` hjl.tools at gmail dot com
2015-04-16 11:20 ` hjl.tools at gmail dot com
` (33 subsequent siblings)
48 siblings, 0 replies; 50+ messages in thread
From: hjl.tools at gmail dot com @ 2015-04-16 11:12 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5/6 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
` (14 preceding siblings ...)
2015-04-16 11:12 ` hjl.tools at gmail dot com
@ 2015-04-16 11:20 ` hjl.tools at gmail dot com
2015-04-16 11:40 ` hjl.tools at gmail dot com
` (32 subsequent siblings)
48 siblings, 0 replies; 50+ messages in thread
From: hjl.tools at gmail dot com @ 2015-04-16 11:20 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5/6 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
` (15 preceding siblings ...)
2015-04-16 11:20 ` hjl.tools at gmail dot com
@ 2015-04-16 11:40 ` hjl.tools at gmail dot com
2015-04-16 11:44 ` jakub at gcc dot gnu.org
` (31 subsequent siblings)
48 siblings, 0 replies; 50+ messages in thread
From: hjl.tools at gmail dot com @ 2015-04-16 11:40 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5/6 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
` (16 preceding siblings ...)
2015-04-16 11:40 ` hjl.tools at gmail dot com
@ 2015-04-16 11:44 ` jakub at gcc dot gnu.org
2015-04-16 11:46 ` hjl.tools at gmail dot com
` (30 subsequent siblings)
48 siblings, 0 replies; 50+ messages in thread
From: jakub at gcc dot gnu.org @ 2015-04-16 11:44 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5/6 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
` (17 preceding siblings ...)
2015-04-16 11:44 ` jakub at gcc dot gnu.org
@ 2015-04-16 11:46 ` hjl.tools at gmail dot com
2015-04-16 11:53 ` hjl.tools at gmail dot com
` (29 subsequent siblings)
48 siblings, 0 replies; 50+ messages in thread
From: hjl.tools at gmail dot com @ 2015-04-16 11:46 UTC (permalink / raw)
To: gcc-bugs
[-- 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
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5/6 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
` (18 preceding siblings ...)
2015-04-16 11:46 ` hjl.tools at gmail dot com
@ 2015-04-16 11:53 ` hjl.tools at gmail dot com
2015-04-16 12:12 ` jakub at gcc dot gnu.org
` (28 subsequent siblings)
48 siblings, 0 replies; 50+ messages in thread
From: hjl.tools at gmail dot com @ 2015-04-16 11:53 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5/6 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
` (19 preceding siblings ...)
2015-04-16 11:53 ` hjl.tools at gmail dot com
@ 2015-04-16 12:12 ` jakub at gcc dot gnu.org
2015-04-16 12:33 ` hjl.tools at gmail dot com
` (27 subsequent siblings)
48 siblings, 0 replies; 50+ messages in thread
From: jakub at gcc dot gnu.org @ 2015-04-16 12:12 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5/6 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
` (20 preceding siblings ...)
2015-04-16 12:12 ` jakub at gcc dot gnu.org
@ 2015-04-16 12:33 ` hjl.tools at gmail dot com
2015-04-16 12:41 ` jakub at gcc dot gnu.org
` (26 subsequent siblings)
48 siblings, 0 replies; 50+ messages in thread
From: hjl.tools at gmail dot com @ 2015-04-16 12:33 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5/6 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
` (21 preceding siblings ...)
2015-04-16 12:33 ` hjl.tools at gmail dot com
@ 2015-04-16 12:41 ` jakub at gcc dot gnu.org
2015-04-16 13:08 ` hjl.tools at gmail dot com
` (25 subsequent siblings)
48 siblings, 0 replies; 50+ messages in thread
From: jakub at gcc dot gnu.org @ 2015-04-16 12:41 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5/6 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
` (22 preceding siblings ...)
2015-04-16 12:41 ` jakub at gcc dot gnu.org
@ 2015-04-16 13:08 ` hjl.tools at gmail dot com
2015-04-16 13:10 ` jakub at gcc dot gnu.org
` (24 subsequent siblings)
48 siblings, 0 replies; 50+ messages in thread
From: hjl.tools at gmail dot com @ 2015-04-16 13:08 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5/6 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
` (23 preceding siblings ...)
2015-04-16 13:08 ` hjl.tools at gmail dot com
@ 2015-04-16 13:10 ` jakub at gcc dot gnu.org
2015-04-16 13:16 ` hjl.tools at gmail dot com
` (23 subsequent siblings)
48 siblings, 0 replies; 50+ messages in thread
From: jakub at gcc dot gnu.org @ 2015-04-16 13:10 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5/6 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
` (24 preceding siblings ...)
2015-04-16 13:10 ` jakub at gcc dot gnu.org
@ 2015-04-16 13:16 ` hjl.tools at gmail dot com
2015-04-16 15:36 ` jakub at gcc dot gnu.org
` (22 subsequent siblings)
48 siblings, 0 replies; 50+ messages in thread
From: hjl.tools at gmail dot com @ 2015-04-16 13:16 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5/6 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
` (25 preceding siblings ...)
2015-04-16 13:16 ` hjl.tools at gmail dot com
@ 2015-04-16 15:36 ` jakub at gcc dot gnu.org
2015-04-16 16:09 ` hjl.tools at gmail dot com
` (21 subsequent siblings)
48 siblings, 0 replies; 50+ messages in thread
From: jakub at gcc dot gnu.org @ 2015-04-16 15:36 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5/6 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
` (26 preceding siblings ...)
2015-04-16 15:36 ` jakub at gcc dot gnu.org
@ 2015-04-16 16:09 ` hjl.tools at gmail dot com
2015-04-16 18:14 ` law at redhat dot com
` (20 subsequent siblings)
48 siblings, 0 replies; 50+ messages in thread
From: hjl.tools at gmail dot com @ 2015-04-16 16:09 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5/6 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
` (27 preceding siblings ...)
2015-04-16 16:09 ` hjl.tools at gmail dot com
@ 2015-04-16 18:14 ` law at redhat dot com
2015-04-16 18:33 ` hjl.tools at gmail dot com
` (19 subsequent siblings)
48 siblings, 0 replies; 50+ messages in thread
From: law at redhat dot com @ 2015-04-16 18:14 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5/6 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
` (28 preceding siblings ...)
2015-04-16 18:14 ` law at redhat dot com
@ 2015-04-16 18:33 ` hjl.tools at gmail dot com
2015-04-16 18:36 ` hjl.tools at gmail dot com
` (18 subsequent siblings)
48 siblings, 0 replies; 50+ messages in thread
From: hjl.tools at gmail dot com @ 2015-04-16 18:33 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5/6 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
` (29 preceding siblings ...)
2015-04-16 18:33 ` hjl.tools at gmail dot com
@ 2015-04-16 18:36 ` hjl.tools at gmail dot com
2015-04-16 19:20 ` law at redhat dot com
` (17 subsequent siblings)
48 siblings, 0 replies; 50+ messages in thread
From: hjl.tools at gmail dot com @ 2015-04-16 18:36 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5/6 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
` (30 preceding siblings ...)
2015-04-16 18:36 ` hjl.tools at gmail dot com
@ 2015-04-16 19:20 ` law at redhat dot com
2015-04-16 19:28 ` hjl.tools at gmail dot com
` (16 subsequent siblings)
48 siblings, 0 replies; 50+ messages in thread
From: law at redhat dot com @ 2015-04-16 19:20 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5/6 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
` (31 preceding siblings ...)
2015-04-16 19:20 ` law at redhat dot com
@ 2015-04-16 19:28 ` hjl.tools at gmail dot com
2015-04-16 21:03 ` jakub at gcc dot gnu.org
` (15 subsequent siblings)
48 siblings, 0 replies; 50+ messages in thread
From: hjl.tools at gmail dot com @ 2015-04-16 19:28 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5/6 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
` (32 preceding siblings ...)
2015-04-16 19:28 ` hjl.tools at gmail dot com
@ 2015-04-16 21:03 ` jakub at gcc dot gnu.org
2015-04-16 22:02 ` hjl.tools at gmail dot com
` (14 subsequent siblings)
48 siblings, 0 replies; 50+ messages in thread
From: jakub at gcc dot gnu.org @ 2015-04-16 21:03 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5/6 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
` (33 preceding siblings ...)
2015-04-16 21:03 ` jakub at gcc dot gnu.org
@ 2015-04-16 22:02 ` hjl.tools at gmail dot com
2015-04-17 16:12 ` law at redhat dot com
` (13 subsequent siblings)
48 siblings, 0 replies; 50+ messages in thread
From: hjl.tools at gmail dot com @ 2015-04-16 22:02 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5/6 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
` (34 preceding siblings ...)
2015-04-16 22:02 ` hjl.tools at gmail dot com
@ 2015-04-17 16:12 ` law at redhat dot com
2015-04-17 16:26 ` [Bug target/65780] [5 " hjl.tools at gmail dot com
` (12 subsequent siblings)
48 siblings, 0 replies; 50+ messages in thread
From: law at redhat dot com @ 2015-04-17 16:12 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
` (35 preceding siblings ...)
2015-04-17 16:12 ` law at redhat dot com
@ 2015-04-17 16:26 ` hjl.tools at gmail dot com
2015-04-17 16:30 ` jakub at gcc dot gnu.org
` (11 subsequent siblings)
48 siblings, 0 replies; 50+ messages in thread
From: hjl.tools at gmail dot com @ 2015-04-17 16:26 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
` (36 preceding siblings ...)
2015-04-17 16:26 ` [Bug target/65780] [5 " hjl.tools at gmail dot com
@ 2015-04-17 16:30 ` jakub at gcc dot gnu.org
2015-04-17 16:36 ` hjl at gcc dot gnu.org
` (10 subsequent siblings)
48 siblings, 0 replies; 50+ messages in thread
From: jakub at gcc dot gnu.org @ 2015-04-17 16:30 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
` (37 preceding siblings ...)
2015-04-17 16:30 ` jakub at gcc dot gnu.org
@ 2015-04-17 16:36 ` hjl at gcc dot gnu.org
2015-04-17 16:37 ` hjl.tools at gmail dot com
` (9 subsequent siblings)
48 siblings, 0 replies; 50+ messages in thread
From: hjl at gcc dot gnu.org @ 2015-04-17 16:36 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
` (38 preceding siblings ...)
2015-04-17 16:36 ` hjl at gcc dot gnu.org
@ 2015-04-17 16:37 ` hjl.tools at gmail dot com
2015-04-17 21:14 ` dominiq at lps dot ens.fr
` (8 subsequent siblings)
48 siblings, 0 replies; 50+ messages in thread
From: hjl.tools at gmail dot com @ 2015-04-17 16:37 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
` (39 preceding siblings ...)
2015-04-17 16:37 ` hjl.tools at gmail dot com
@ 2015-04-17 21:14 ` dominiq at lps dot ens.fr
2015-04-17 21:54 ` hjl at gcc dot gnu.org
` (7 subsequent siblings)
48 siblings, 0 replies; 50+ messages in thread
From: dominiq at lps dot ens.fr @ 2015-04-17 21:14 UTC (permalink / raw)
To: gcc-bugs
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)));
}
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
` (40 preceding siblings ...)
2015-04-17 21:14 ` dominiq at lps dot ens.fr
@ 2015-04-17 21:54 ` hjl at gcc dot gnu.org
2015-04-17 21:55 ` hjl at gcc dot gnu.org
` (6 subsequent siblings)
48 siblings, 0 replies; 50+ messages in thread
From: hjl at gcc dot gnu.org @ 2015-04-17 21:54 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
` (41 preceding siblings ...)
2015-04-17 21:54 ` hjl at gcc dot gnu.org
@ 2015-04-17 21:55 ` hjl at gcc dot gnu.org
2015-04-17 23:16 ` howarth.at.gcc at gmail dot com
` (5 subsequent siblings)
48 siblings, 0 replies; 50+ messages in thread
From: hjl at gcc dot gnu.org @ 2015-04-17 21:55 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
` (42 preceding siblings ...)
2015-04-17 21:55 ` hjl at gcc dot gnu.org
@ 2015-04-17 23:16 ` howarth.at.gcc at gmail dot com
2015-04-18 5:36 ` jakub at gcc dot gnu.org
` (4 subsequent siblings)
48 siblings, 0 replies; 50+ messages in thread
From: howarth.at.gcc at gmail dot com @ 2015-04-17 23:16 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
` (43 preceding siblings ...)
2015-04-17 23:16 ` howarth.at.gcc at gmail dot com
@ 2015-04-18 5:36 ` jakub at gcc dot gnu.org
2015-04-21 14:14 ` evstupac at gmail dot com
` (3 subsequent siblings)
48 siblings, 0 replies; 50+ messages in thread
From: jakub at gcc dot gnu.org @ 2015-04-18 5:36 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
` (44 preceding siblings ...)
2015-04-18 5:36 ` jakub at gcc dot gnu.org
@ 2015-04-21 14:14 ` evstupac at gmail dot com
2015-04-21 14:18 ` jakub at gcc dot gnu.org
` (2 subsequent siblings)
48 siblings, 0 replies; 50+ messages in thread
From: evstupac at gmail dot com @ 2015-04-21 14:14 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
` (45 preceding siblings ...)
2015-04-21 14:14 ` evstupac at gmail dot com
@ 2015-04-21 14:18 ` jakub at gcc dot gnu.org
2015-05-11 7:09 ` jakub at gcc dot gnu.org
2015-05-11 7:14 ` jakub at gcc dot gnu.org
48 siblings, 0 replies; 50+ messages in thread
From: jakub at gcc dot gnu.org @ 2015-04-21 14:18 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
` (46 preceding siblings ...)
2015-04-21 14:18 ` jakub at gcc dot gnu.org
@ 2015-05-11 7:09 ` jakub at gcc dot gnu.org
2015-05-11 7:14 ` jakub at gcc dot gnu.org
48 siblings, 0 replies; 50+ messages in thread
From: jakub at gcc dot gnu.org @ 2015-05-11 7:09 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug target/65780] [5 Regression] Uninitialized common handling in executables
2015-04-15 22:29 [Bug target/65780] New: [5 Regression] Uninitialized common handling in executables jakub at gcc dot gnu.org
` (47 preceding siblings ...)
2015-05-11 7:09 ` jakub at gcc dot gnu.org
@ 2015-05-11 7:14 ` jakub at gcc dot gnu.org
48 siblings, 0 replies; 50+ messages in thread
From: jakub at gcc dot gnu.org @ 2015-05-11 7:14 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 50+ messages in thread