Please consider this patch. It adds support for obtaining file basename via
__FILE_BASENAME__.
This would be used by GNU GRUB. I'll provide some explanation on why this is
very necessary for us:
- Bootloader code is very critical; a bug can render system unbootable.
Additionally, it needs to
--- Comment #1 from rmh dot gcc at aybabtu dot com 2010-01-02 10:12 ---
Created an attachment (id=19445)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19445&action=view)
__FILE_BASENAME__
Attaching the patch. Also sent to gcc-patches.
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #6 from bonzini at gnu dot org 2010-01-02 10:28 ---
I don't know but I found a tree that generates the 9-instruction sequence, and
it was "GCC: (GNU) 4.4.0 20090314 (experimental)".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39871
--- Comment #7 from bonzini at gnu dot org 2010-01-02 10:31 ---
(That would be r144855 or r144857).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39871
--- Comment #5 from debian-gcc at lists dot debian dot org 2010-01-02
10:42 ---
not applying the pr40521-revert-workaround patch shows the ICE as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42564
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-02 11:06 ---
__BASE_FILE__ could be enough for what you want.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42579
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-01-02 11:11 ---
Subject: Bug 41597
Author: rguenth
Date: Sat Jan 2 11:11:37 2010
New Revision: 155563
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155563
Log:
2010-01-02 Richard Guenther
PR lto/41597
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-01-02 11:18 ---
You may also want to try -fsched-pressure -fschedule-insns which is new
in GCC 4.5 and might decrease register pressure (no idea if it ever moves
things into loops though - the haifa scheduler might not consider it a
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-01-02 11:25 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #17 from rguenth at gcc dot gnu dot org 2010-01-02 11:29
---
Yeah, that looks like a good first step.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41564
--- Comment #3 from rmh dot gcc at aybabtu dot com 2010-01-02 11:39 ---
(In reply to comment #2)
> __BASE_FILE__ could be enough for what you want.
Hi,
I tried already, but __BASE_FILE__ seems to be something unrelated. It's
like __FILE__ but when used in an #include'd source it picks
--- Comment #22 from dominiq at lps dot ens dot fr 2010-01-02 11:49 ---
Backtrace of the ICE in comment #21 with the patch in
http://gcc.gnu.org/ml/fortran/2010-01/msg0.html
#0 fancy_abort (file=0x100987a08 "../../for_work/gcc/fortran/trans-array.c",
line=4196, function=0x1009f0560
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-01-02 12:01 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|dnovillo a
--- Comment #9 from davek at gcc dot gnu dot org 2010-01-02 13:25 ---
(In reply to comment #7)
> (In reply to comment #6)
> > I have a hard way thinking of a way this is a regression.
>
>
> Well it is partly a regression as if you have libelf installed in /usr/local
> or
> /usr, confi
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-01-02 13:42
---
FAIL: gcc.dg/lto/20081201-2 c_lto_20081201-2_0.o-c_lto_20081201-2_1.o execute
-O3 -fwhopr
this means you do not get any LTO optimization (it's really the only test
that tests this )
So LTO is not working for
--- Comment #11 from davek at gcc dot gnu dot org 2010-01-02 13:51 ---
(In reply to comment #10)
> FAIL: gcc.dg/lto/20081201-2 c_lto_20081201-2_0.o-c_lto_20081201-2_1.o execute
> -O3 -fwhopr
>
> this means you do not get any LTO optimization (it's really the only test
> that tests this
--- Comment #12 from rguenther at suse dot de 2010-01-02 13:56 ---
Subject: Re: LTO configuration should detect if the
target is ELF
On Sat, 2 Jan 2010, davek at gcc dot gnu dot org wrote:
> --- Comment #11 from davek at gcc dot gnu dot org 2010-01-02 13:51
> ---
> (In repl
--- Comment #13 from davek at gcc dot gnu dot org 2010-01-02 13:59 ---
(In reply to comment #12)
> The collect2 stuff should in principle work with non-ELF targets
> as well if you circumvent that first problem somehow (for
> example by not producing regular object code from cc1 but only
--- Comment #6 from steven at gcc dot gnu dot org 2010-01-02 14:08 ---
Created an attachment (id=19446)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19446&action=view)
Classic GCSE, resurrected (with some improvements)
With this patch (not bootstrapped/tested/etc.), I get the fol
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu
|org
--- Comment #7 from steven at gcc dot gnu dot org 2010-01-02 14:10 ---
For the record, options for compiler to get the asm output of the comments:
"-march=armv5te -mthumb -mthumb-interwork -fpic -Os"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42574
--- Comment #14 from rguenth at gcc dot gnu dot org 2010-01-02 14:13
---
Subject: Bug 41529
Author: rguenth
Date: Sat Jan 2 14:13:37 2010
New Revision: 155565
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155565
Log:
2010-01-02 Richard Guenther
PR lto/41529
--- Comment #15 from rguenth at gcc dot gnu dot org 2010-01-02 14:16
---
Fixed. The way to support LTO on non-ELF targets is to wrap all LTO sections
in an ELF container that is wrapped in a native section. We then have to
have code to open a native object format section and direct li
--- Comment #4 from uros at gcc dot gnu dot org 2010-01-02 14:18 ---
Subject: Bug 42448
Author: uros
Date: Sat Jan 2 14:18:41 2010
New Revision: 155566
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155566
Log:
PR target/42448
* config/alpha/predicates.md (align
--- Comment #4 from mikpe at it dot uu dot se 2010-01-02 14:21 ---
(In reply to comment #3)
> However, the goal is to compile gcc for the coff format and
> I'm having it difficulties.
Consider the following two facts:
1. binutils-2.17 removed m68k-coff support, that was 3.5 years ago
2.
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-02 14:22 ---
http://gcc.gnu.org/ml/gcc-testresults/2009-12/msg02393.html says this is fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-02 14:23 ---
Fixed as of http://gcc.gnu.org/ml/gcc-testresults/2009-12/msg02393.html.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-02 14:27 ---
Yes, this is a known issue with LTO and combining C and Fortran code which
accesses commons in both languages.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from uros at gcc dot gnu dot org 2010-01-02 14:28 ---
Subject: Bug 42448
Author: uros
Date: Sat Jan 2 14:28:25 2010
New Revision: 155567
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155567
Log:
PR target/42448
* config/alpha/predicates.md (align
--- Comment #2 from jakub at gcc dot gnu dot org 2010-01-02 14:30 ---
With 3 register vars in the function (ebx, edi, esi) on the register starved
ix86 the error is tollerable. From the 8 registers the programmer takes 3,
%esp is fixed, without -fomit-frame-pointer %ebp is fixed too, wh
--- Comment #6 from uros at gcc dot gnu dot org 2010-01-02 14:32 ---
Subject: Bug 42448
Author: uros
Date: Sat Jan 2 14:32:23 2010
New Revision: 155568
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155568
Log:
PR target/42448
* config/alpha/predicates.md (align
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-02 14:32 ---
Related to PR41227. But from that it seems we need to fix this up during LTO.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #16 from davek at gcc dot gnu dot org 2010-01-02 14:33 ---
JFTR: I'll be working on this later in January. I'll do it on the
cygwin-improvements branch for visibility.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41529
--- Comment #7 from ubizjak at gmail dot com 2010-01-02 14:34 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-02 14:39 ---
Subject: Bug 41651
Author: rguenth
Date: Sat Jan 2 14:38:57 2010
New Revision: 155569
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155569
Log:
2010-01-02 Richard Guenther
PR testsuite/41651
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-02 14:39 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-02 14:57 ---
I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|
--- Comment #9 from ami_stuff at o2 dot pl 2010-01-02 15:02 ---
GCC 4.5.0 (20091224): 840KB
When I use "-O3 -fno-inline-functions -fno-unswitch-loops
-fno-predictive-commoning -fno-gcse-after-reload -fno-tree-vectorize", size
increases to 944KB.
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #17 from joseph at codesourcery dot com 2010-01-02 15:04
---
Subject: Re: LTO configuration should detect if the
target is ELF
On Sat, 2 Jan 2010, rguenth at gcc dot gnu dot org wrote:
> Fixed. The way to support LTO on non-ELF targets is to wrap all LTO sections
> in a
--- Comment #4 from jakub at gcc dot gnu dot org 2010-01-02 15:05 ---
Yeah, PR41371.
*** This bug has been marked as a duplicate of 41371 ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from jakub at gcc dot gnu dot org 2010-01-02 15:05 ---
*** Bug 42565 has been marked as a duplicate of this bug. ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #18 from davek at gcc dot gnu dot org 2010-01-02 15:20 ---
(In reply to comment #17)
> I don't really see the point of the ELF container if you also have code to
> parse a native object format. Either add a separate COFF etc. (or
> BFD-using if you so wish) implementation
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-01-02 15:57
---
Can you try with --without-build-config? It might be just a compare-debug
failure.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41862
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42258
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-01-02 16:00
---
I'd like to see 1a) for obvious reasons (we'll need that for proper LTO
debuginfo support). But 2) is also sensible.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42388
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42393
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42395
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Priority|P3 |P2
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42398
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-02 16:05 ---
Huh, but this looks like a target problem if we generate invalid assembly.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-02 16:06 ---
Testcaese?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42450
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42461
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42462
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42482
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42485
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-02 16:13 ---
Confirmed. Doesn't happen on i?86-linux or with -m32.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42521
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Component|middle-end |tree-optimization
Priority|P3 |P1
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42574
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-01-02 16:23 ---
Fascinating indeed. If someone can bisect where during 4.4 development we
fixed this again or where during 4.3 development we broke it that would be
nice.
--
rguenth at gcc dot gnu dot org changed:
W
--- Comment #1 from ghazi at gcc dot gnu dot org 2010-01-02 16:24 ---
I was able to do a C-only bootstrap of mainline with all three libraries
in-tree on x86_64-unknown-linux-gnu. I used mpc-0.8, mpfr-2.4.2, gmp-4.3.1 and
bootstrapped with gcc-4.3.2. I cannot reproduce this problem, so
--- Comment #12 from rguenth at gcc dot gnu dot org 2010-01-02 16:25
---
Wontfix on the 4.3 branch, we usually do not backport accepts-invalid fixes.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail|4.3.4 |4.3.4 4.4.0
Priority|P3 |P2
http
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known to
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail|4.3.4 |4.3.4 4.4.2
Priority|P3 |P2
http
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.3.5 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42289
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-01-02 16:41 ---
It's at least a regression towards where we didn't have array bound warnings.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from developer at sandoe-acoustics dot co dot uk 2010-01-02
16:41 ---
(In reply to comment #1)
> I was able to do a C-only bootstrap of mainline with all three libraries
> in-tree on x86_64-unknown-linux-gnu. I used mpc-0.8, mpfr-2.4.2, gmp-4.3.1
> and
...
> 1. Is thi
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42577
--- Comment #3 from jakub at gcc dot gnu dot org 2010-01-02 16:44 ---
Reduced testcase:
/* { dg-do compile { target { { i?86-*-* x86_64-*-* } && ilp32 } } } */
/* { dg-options "-O2 -fno-gcse" } */
struct C;
struct B { struct C *b; };
struct C { void (*baz) (struct B *, void *, int); };
When I debug lto1, the missing command line option file generates
a misleading error message and causes ICE:
[...@gnu-34 gcc]$ touch x.s
[...@gnu-34 gcc]$ gcc -c x.s
[...@gnu-34 gcc]$ /export/build/gnu/gcc/build-x86_64-linux/gcc/lto1 -quiet
-dumpbase x.o -mtune=generic -auxbase-strip /tmp/cc0mkdy
--- Comment #1 from hjl dot tools at gmail dot com 2010-01-02 17:06 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00064.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #18 from hjl dot tools at gmail dot com 2010-01-02 17:09
---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00065.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-01-02 17:12 ---
Subject: Bug 42337
Author: rguenth
Date: Sat Jan 2 17:12:15 2010
New Revision: 155573
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155573
Log:
2010-01-02 Richard Guenther
Backport from mainlin
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-01-02 17:12 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from hjl at gcc dot gnu dot org 2010-01-02 17:30 ---
Subject: Bug 42580
Author: hjl
Date: Sat Jan 2 17:30:12 2010
New Revision: 155575
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155575
Log:
Stop if the command line option file is missing
2010-01-02 H.J. Lu
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2010-01-02 17:33
---
I can reproduce on native (and with a cross by stealing the native
auto-host.h).
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from hjl dot tools at gmail dot com 2010-01-02 17:39 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|---
--prefix=/usr/gcc-4.5.0 --with-local-prefix=/usr/local
--with-plugin-ld=ld.gold --enable-gold
Thread model: posix
gcc version 4.5.0 20100102 (experimental) (GCC)
COMPILER_PATH=./
LIBRARY_PATH=./:/lib/../lib64/:/usr/lib/../lib64/:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-B.' '-o' '
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-01-02 19:15 ---
Subject: Bug 42577
Author: rguenth
Date: Sat Jan 2 19:14:52 2010
New Revision: 155577
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155577
Log:
2010-01-02 Richard Guenther
PR middle-end/42577
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-01-02 19:15 ---
Fixed on the trunk sofar.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
A
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-02 19:19 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-01-02 19:24 ---
Similar to PR35392 this only happens with -funsigned-char, thus these may
as well be dups.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-02 19:27 ---
Works for me with gcc 4.3.3.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-01-02 19:30 ---
Works with 4.4 and 4.5.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-01-02 19:35 ---
Re-confirmed. The issue is that we fold __builtin_constant_p only after
VRP1 so the dead code remains and we warn about it.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #12 from rguenth at gcc dot gnu dot org 2010-01-02 19:40
---
Looks like invalid code in the first place.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-02 19:42 ---
Fixed in 4.5.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UN
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2010-01-02 19:53
---
OK, I can reproduce the issue.
1. I have a GCC trunk (rev. 155544). In there I put symlinks to gmp-4.3.1,
mpfr-2.4.2 and mpc-0.8.1
2. From an empty build directory, I configure with: ../trunk/configure
--prefix=/
realpath() built with >=gcc-4.3 (where FORTIFY is enabled by default) and -Ox
where x>0 cause application to abort.
Test case: the following code built with gcc -O2:
==
#include
#include
#include
int
main (int argc, char *
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2010-01-02 20:02
---
Can you give us:
1. The results of "grep '^CXX' Makefile" in directories
/Users/ed/obj/powerpc-apple-darwin7.9.0/libstdc++-v3/include and
/Users/ed/obj/powerpc-apple-darwin7.9.0/libstdc++-v3
2. The long comma
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-02 20:26 ---
Confirmed. But -save-temps also doesn't work completely for -fwhopr (and you
need to set the collect2 env vars for -fwhopr).
The proper fix for 4.6 is to move most of the LTO handling to the gcc driver,
away from c
--- Comment #1 from truedfx at gentoo dot org 2010-01-02 20:26 ---
The buffer should be at least PATH_MAX bytes. If PATH_MAX > 1024, then 1024
bytes need not be enough. But anyway, realpath() comes from glibc, so even if
this is a bug, you're reporting it to the wrong folks.
--
http
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-02 20:27 ---
You also need to attach preprocessed source as it will be very glibc
specific.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42582
--- Comment #4 from 3dw4rd at verizon dot net 2010-01-02 20:32 ---
Created an attachment (id=19447)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19447&action=view)
Greps for '^CXX' in the libstdc++ build directory and sibdirectories.
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Comment #9 from manu at gcc dot gnu dot org 2010-01-02 20:33 ---
(In reply to comment #8)
> Re-confirmed. The issue is that we fold __builtin_constant_p only after
> VRP1 so the dead code remains and we warn about it.
Perhaps this is the root cause of both PR35392 and PR35903.
-
--- Comment #5 from 3dw4rd at verizon dot net 2010-01-02 20:34 ---
Created an attachment (id=19448)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19448&action=view)
Grep for '^CXX' in the libstdc++ include directory.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42566
--- Comment #6 from 3dw4rd at verizon dot net 2010-01-02 20:37 ---
Created an attachment (id=19449)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19449&action=view)
Grep for '^CXX' in the libstdc++ src directory.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42566
1 - 100 of 150 matches
Mail list logo
