[Bug c/42579] New: [PATCH] support for obtaining file basename

[rmh dot gcc at aybabtu dot com]

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 support a wide range of hardware and firmware. 
Because of this, we put extensive debugging support into GRUB.  Debug
statements currently rely on __FILE__.

  - We want to support $srcdir != $objdir build setups, and continue supporting
them.

  - Some parts of bootstrap code tend to be very size constrained.  Every byte
counts, and each debug statement is taking unnecessary space because accessing
a file in $srcdir requires either an absolute path or at least a number of
'../' components (in Debian, that would be two of them).

Because of this, I would find it very useful if GCC provided __FILE_BASENAME__,
or at least an equivalent facility.


-- 
   Summary: [PATCH] support for obtaining file basename
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rmh dot gcc at aybabtu dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42579

[Bug c/42579] [PATCH] support for obtaining file basename

[rmh dot gcc at aybabtu dot com]

--- 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.cgi?id=42579

[Bug rtl-optimization/39871] [4.3/4.4/4.5 regression] Code size increase on ARM due to inferior CSE

[bonzini at gnu dot org]

--- 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

[Bug rtl-optimization/39871] [4.3/4.4/4.5 regression] Code size increase on ARM due to inferior CSE

[bonzini at gnu dot org]

--- 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

[Bug target/42564] ICE on sparc - unrecognizable insn

[debian-gcc at lists dot debian dot org]

--- 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

[Bug c/42579] [PATCH] support for obtaining file basename

[rguenth at gcc dot gnu dot org]

--- 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

[Bug lto/41597] Bad .comm directive

[rguenth at gcc dot gnu dot org]

--- 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
* toplev.c (compile_file): Emit LTO marker properly.  Change
it to __gnu_lto_v1.
* collect2.c (scan_prog_file): Adjust for changed LTO marker.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/collect2.c
trunk/gcc/toplev.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41597

[Bug tree-optimization/39839] [4.3/4.4/4.5 regression] loop invariant motion causes stack spill

[rguenth at gcc dot gnu dot org]

--- 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
region to work on).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39839

[Bug lto/41597] Bad .comm directive

[rguenth at gcc dot gnu dot org]

--- 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|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41597

[Bug driver/41564] -fdump-tree-all for lto does not work as expected

[rguenth at gcc dot gnu dot org]

--- 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

[Bug c/42579] [PATCH] support for obtaining file basename

[rmh dot gcc at aybabtu dot com]

--- 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 the includer
rather than the included file.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42579

[Bug fortran/40472] Simplification of spread intrinsic takes a long time

[dominiq at lps dot ens dot fr]

--- 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 "gfc_conv_array_initializer") at
../../for_work/gcc/diagnostic.c:727
#1  0x0001000ac661 in gfc_conv_array_initializer (type=0x100987a08,
expr=0x1064) at ../../for_work/gcc/fortran/trans-array.c:4196
#2  0x0001000cda9b in gfc_conv_initializer (expr=0x141814a80, ts=, type=0x141df7150, array=1
'\001', pointer=) at
../../for_work/gcc/fortran/trans-expr.c:3757
#3  0x0001000bc472 in gfc_get_symbol_decl (sym=0x141814740) at
../../for_work/gcc/fortran/trans-decl.c:1273
#4  0x0001000cb60b in gfc_conv_variable (se=0x7fff5fbfe870,
expr=0x1418163b0) at ../../for_work/gcc/fortran/trans-expr.c:566
#5  0x0001000cacbd in gfc_conv_expr_reference (se=0x7fff5fbfe870,
expr=) at
../../for_work/gcc/fortran/trans-expr.c:4348
#6  0x0001000dfaa3 in gfc_trans_transfer (code=) at
../../for_work/gcc/fortran/trans-io.c:2243
#7  0x0001000a5958 in gfc_trans_code (code=0x141816760) at
../../for_work/gcc/fortran/trans.c:1250
#8  0x0001000dd744 in build_dt (function=, code=) at ../../for_work/gcc/fortran/trans-io.c:1814
#9  0x0001000a5978 in gfc_trans_code (code=0x141816970) at
../../for_work/gcc/fortran/trans.c:1222
#10 0x0001000c1bf7 in gfc_generate_function_code (ns=) at
../../for_work/gcc/fortran/trans-decl.c:4371
#11 0x0001000691bf in gfc_parse_file () at
../../for_work/gcc/fortran/parse.c:4239
#12 0x0001000a0ccc in gfc_be_parse_file (set_yydebug=) at
../../for_work/gcc/fortran/f95-lang.c:239
#13 0x0001006cf1fa in toplev_main (argc=2, argv=0x7fff5fbfeda0) at
../../for_work/gcc/toplev.c:1049
#14 0x000119c4 in start ()


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40472

[Bug bootstrap/41529] LTO configuration should detect if the target is ELF

[rguenth at gcc dot gnu dot org]

--- 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 at gcc dot gnu dot |rguenth at gcc dot gnu dot
   |org |org
URL|http://gcc.gnu.org/ml/gcc-  |http://gcc.gnu.org/ml/gcc-
   |patches/2009-   |patches/2010-
   |05/msg01609.html|01/msg00029.html
 Status|NEW |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41529

[Bug bootstrap/41529] LTO configuration should detect if the target is ELF

[davek at gcc dot gnu dot org]

--- 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, configure will find it by default and if you are targetting a non elf
> target, LTO will be enabled and all the LTO testsuite will just fail.

ORLY?  :-) Output from "make check-gcc-c RUNTESTFLAGS=lto.exp":


Test Run By DKAdmin on Fri Jan  1 11:11:25 2010
Native configuration is i686-pc-cygwin

=== gcc tests ===

Schedule of variations:
unix

Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for
targe
t.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using /gnu/gcc/gcc/gcc/testsuite/config/default.exp as tool-and-target-specific
interface file.
Running /gnu/gcc/gcc/gcc/testsuite/gcc.dg/lto/lto.exp ...
FAIL: gcc.dg/lto/20081201-2 c_lto_20081201-2_0.o-c_lto_20081201-2_1.o execute
-O
3 -fwhopr
FAIL: gcc.dg/lto/20081222 c_lto_20081222_1.o assemble, -O0 -fwhopr
FAIL: gcc.dg/lto/20081222 c_lto_20081222_1.o assemble, -O2 -fwhopr
FAIL: gcc.dg/lto/20081222 c_lto_20081222_1.o assemble, -O0 -flto
FAIL: gcc.dg/lto/20081222 c_lto_20081222_1.o assemble, -O2 -flto
FAIL: gcc.dg/lto/20090914-2 c_lto_20090914-2_0.o assemble, -O0 -fwhopr
FAIL: gcc.dg/lto/20090914-2 c_lto_20090914-2_0.o assemble, -O2 -fwhopr
FAIL: gcc.dg/lto/20090914-2 c_lto_20090914-2_0.o assemble, -O0 -flto
FAIL: gcc.dg/lto/20090914-2 c_lto_20090914-2_0.o assemble, -O2 -flto

=== gcc Summary ===

# of expected passes445
# of unexpected failures9
# of unresolved testcases   16
# of unsupported tests  2
/gnu/gcc/obj3/gcc/xgcc  version 4.5.0 20091231 (experimental) (GCC)

make[2]: [check-parallel-gcc] Error 1 (ignored)

Do those nine failures really reflect some fundamental breakage on a non-ELF
platform?  The assemble failures all say:

/gnu/gcc/gcc/gcc/testsuite/gcc.dg/lto/20081222_1.c:14:21: error: 'EXT_x'
aliased to undefined symbol 'INT_x'
/gnu/gcc/gcc/gcc/testsuite/gcc.dg/lto/20081222_1.c:14:21: error: 'EXT_x'
aliased to undefined symbol 'INT_x'

which I thought was likely to be a problem either with the lack of symbol
visibility or perhaps a weakness in alias handling on the platform.  But most
of it seems to work.


-- 

davek at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||davek at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41529

[Bug bootstrap/41529] LTO configuration should detect if the target is ELF

[rguenth at gcc dot gnu dot org]

--- 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 you.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41529

[Bug bootstrap/41529] LTO configuration should detect if the target is ELF

[davek at gcc dot gnu dot org]

--- 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 )
> 
> So LTO is not working for you.

  Righto, I'll look at that one first.

  Are you aware of any structural reason why LTO can't possibly work on a
non-ELF platform? 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41529

[Bug bootstrap/41529] LTO configuration should detect if the target is ELF

[rguenther at suse dot de]

--- 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 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 )
> > 
> > So LTO is not working for you.
> 
>   Righto, I'll look at that one first.
> 
>   Are you aware of any structural reason why LTO can't possibly work on a
> non-ELF platform? 

The only part that really relies on native ELF object files is
the mixing of LTO sections with regular object code as produced
by cc1 - lto1 relies on libelf to identify and read the LTO sections,
which probably does not work.

And of course the linker-plugin and symbol resolution stuff done
by it - but the linker-plugin is gold only and ELF only anyway.
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
assemble the LTO sections to a ELF object file).

Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41529

[Bug bootstrap/41529] LTO configuration should detect if the target is ELF

[davek at gcc dot gnu dot org]

--- 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
> assemble the LTO sections to a ELF object file).

  Hmm, that would be an alternative to extending libelf to speak a rudimentary
degree of non-ELF format.  Maybe we could extend collect2 on non-ELF to use
objcopy to extract the elf sections from any input files to temporary
pure-ELF-format objects; does that seem reasonable?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41529

[Bug middle-end/42574] [4.3/4.4/4.5 Regression] Address of global variable is calculated multiple times (missed CSE)

[steven at gcc dot gnu dot org]

--- 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 following code:

test:
push{r4, r5, r6, lr}
ldr r3, .L4
ldr r2, .L4+4
.LPIC0:
add r3, pc
ldr r5, [r3, r2]
mov r4, #200
lsl r4, r4, #1
mov r6, r0
ldr r0, [r5, r4]
bl  func1
ldr r0, [r5, r4]
mov r1, r6
bl  func2
cmp r0, #0
beq .L2
bl  func
.L2:
mov r3, #200
lsl r3, r3, #1
ldr r0, [r5, r3]
bl  func3
@ sp needed for prologue
pop {r4, r5, r6, pc}


The constant load of #400 is not eliminated, because classic GCSE is not value
numbering, so to it, the following expressions in insns 11 and 31 are not
equivalent:

   11 r141:SI=0x190
   12 r142:SI=[r139:SI+r141:SI]
  REG_EQUAL: [const(`glob'+0x190)]

   30 r149:SI=0x190
   31 r150:SI=[r139:SI+r149:SI]

The REG_EQUAL note is probably not exploited because it is a CONST and
want_to_gcse_p rejects it (someone should check if that is indeed the reason).

I have no intention at this point to finish this patch.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42574

[Bug middle-end/42574] [4.3/4.4/4.5 Regression] Address of global variable is calculated multiple times (missed CSE)

[steven at gcc dot gnu dot org]

-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|steven at gcc dot gnu dot   |unassigned at gcc dot gnu
   |org |dot org
 Status|ASSIGNED|NEW


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42574

[Bug middle-end/42574] [4.3/4.4/4.5 Regression] Address of global variable is calculated multiple times (missed CSE)

[steven at gcc dot gnu dot 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

[Bug bootstrap/41529] LTO configuration should detect if the target is ELF

[rguenth at gcc dot gnu dot org]

--- 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
* configure.ac: Include config/elf.m4.  Disable LTO if not
builting for an elf target.
* configure: Regenerate.

config/
* elf.m4: New file.

Added:
trunk/config/elf.m4
Modified:
trunk/ChangeLog
trunk/config/ChangeLog
trunk/configure
trunk/configure.ac


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41529

[Bug bootstrap/41529] LTO configuration should detect if the target is ELF

[rguenth at gcc dot gnu dot org]

--- 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 libelf to parse
that section content.

The implementation difficulty is to use libelf to produce the ELF object file
and then get that included in the assembly for the native wrapper section.

Well - for 4.6 if anyone wants to work on this.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41529

[Bug target/42448] [4.3/4.4/4.5 Regression] Wrong code with _Complex char in structure

[uros at gcc dot gnu dot org]

--- 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 (aligned_memory_operand): Return false
for CQImode.
(unaligned_memory_operand): Return true for CQImode.
* config/alpha/alpha.c (get_aligned_mem): Assert that location
doesn not cross aligned SImode word boundary.

testsuite/ChangeLog:

PR target/42448
* gcc.target/alpha/pr42448-1.c: New test.
* gcc.target/alpha/pr42448-2.c: Ditto.


Added:
trunk/gcc/testsuite/gcc.target/alpha/pr42448-1.c
trunk/gcc/testsuite/gcc.target/alpha/pr42448-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/alpha/alpha.c
trunk/gcc/config/alpha/predicates.md
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42448

[Bug c/42557] gcc no compile for m68k(coff/elf)

[mikpe at it dot uu dot se]

--- 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. gcc-4.4's NEWS file lists m68k-coff as unmaintained and scheduled for
removal

> I'm sure that problem has easy solution, but I'm starting now. What books can
> help in this process?

Your best option is to target m68k-elf instead, as that's still supported.

If you absolutely must use coff, it's probably best to use older versions of
binutils and gcc from the time when it was still supported. binutils-2.16.1 and
gcc-3.4.6 might be a good starting point. You can't expect any upstream support
for these old versions, however.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42557

[Bug lto/41670] FAIL: gcc.c-torture/execute/builtins/memcpy-chk.c compilation, -O2 -fwhopr

[rguenth at gcc dot gnu dot org]

--- 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

 Status|WAITING |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41670

[Bug testsuite/41659] FAIL: gcc.dg/lto/20090914-2 c_lto_20090914-2_0.o assemble, -O0 -fwhopr

[rguenth at gcc dot gnu dot org]

--- 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

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41659

[Bug lto/41664] FAIL: gfortran.dg/lto/pr40725 f_lto_pr40725_0.o-f_lto_pr40725_1.o execute -O2 -fwhopr and -flto

[rguenth at gcc dot gnu dot org]

--- 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

  GCC build triplet|hppa-unknown-linux-gnu  |
   GCC host triplet|hppa-unknown-linux-gnu  |
 GCC target triplet|hppa-unknown-linux-gnu  |
   Keywords||wrong-code


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41664

[Bug target/42448] [4.3/4.4/4.5 Regression] Wrong code with _Complex char in structure

[uros at gcc dot gnu dot org]

--- 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 (aligned_memory_operand): Return false
for CQImode.
(unaligned_memory_operand): Return true for CQImode.
* config/alpha/alpha.c (get_aligned_mem): Assert that location
doesn not cross aligned SImode word boundary.

testsuite/ChangeLog:

PR target/42448
* gcc.target/alpha/pr42448-1.c: New test.
* gcc.target/alpha/pr42448-2.c: Ditto.


Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/alpha/pr42448-1.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/alpha/pr42448-2.c
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/config/alpha/alpha.c
branches/gcc-4_4-branch/gcc/config/alpha/predicates.md
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42448

[Bug target/42536] [4.4/4.5 regression] ICE in spill_failure, at reload1.c:2141

[jakub at gcc dot gnu dot org]

--- 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, which leaves
just %eax, %edx and %ecx for register allocation.  Even if this happens to
compile, the result can't work fast, as almost all insns need to have
temporaries spilled and reread back.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42536

[Bug target/42448] [4.3/4.4/4.5 Regression] Wrong code with _Complex char in structure

[uros at gcc dot gnu dot org]

--- 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 (aligned_memory_operand): Return false
for CQImode.
(unaligned_memory_operand): Return true for CQImode.
* config/alpha/alpha.c (get_aligned_mem): Assert that location
doesn not cross aligned SImode word boundary.

testsuite/ChangeLog:

PR target/42448
* gcc.target/alpha/pr42448-1.c: New test.
* gcc.target/alpha/pr42448-2.c: Ditto.


Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/alpha/pr42448-1.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/alpha/pr42448-2.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/config/alpha/alpha.c
branches/gcc-4_3-branch/gcc/config/alpha/predicates.md


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42448

[Bug lto/41664] FAIL: gfortran.dg/lto/pr40725 f_lto_pr40725_0.o-f_lto_pr40725_1.o execute -O2 -fwhopr and -flto

[rguenth at gcc dot gnu dot org]

--- 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

  BugsThisDependsOn||41227


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41664

[Bug bootstrap/41529] LTO configuration should detect if the target is ELF

[davek at gcc dot gnu dot org]

--- 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

[Bug target/42448] [4.3/4.4/4.5 Regression] Wrong code with _Complex char in structure

[ubizjak at gmail dot com]

--- 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|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42448

[Bug testsuite/41651] g++.dg/lto/20080908-3.C is broken

[rguenth at gcc dot gnu dot org]

--- 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
* g++.dg/lto/20080908-3_0.C: Avoid uninitialized vars.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/lto/20080908-3_0.C


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41651

[Bug testsuite/41651] g++.dg/lto/20080908-3.C is broken

[rguenth at gcc dot gnu dot org]

--- 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|UNCONFIRMED |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41651

[Bug middle-end/42577] array bounds false positive with -O3, goes away with -O2

[rguenth at gcc dot gnu dot org]

--- 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|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-01-02 14:57:22
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42577

[Bug target/41095] 4x bigger object when compiled with -O3 option

[ami_stuff at o2 dot pl]

--- 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_bug.cgi?id=41095

[Bug bootstrap/41529] LTO configuration should detect if the target is ELF

[joseph at codesourcery dot com]

--- 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 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 libelf to parse
> that section content.

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 of the set of interfaces that 
lto-elf.c provides, using hooks (or proper C++ classes) to select which 
implementation is used, or switch the targets to use ELF completely with a 
postlinker converting to executables in another format (like on 
arm-symbianelf).  The former (lto-coff.c, lto-macho.c etc. or lto-bfd.c) 
should be a lot less work (the latter requires an ABI to define how all 
the features of the other object format are represented in ELF).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41529

[Bug debug/42565] [4.5 Regression] Huge compilation time with -O1 -g

[jakub at gcc dot gnu dot org]

--- 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

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42565

[Bug debug/41371] [4.5 Regression] var-tracking is slow and memory hungry

[jakub at gcc dot gnu dot org]

--- 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

 CC||aanisimov at inbox dot ru


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371

[Bug bootstrap/41529] LTO configuration should detect if the target is ELF

[davek at gcc dot gnu dot org]

--- 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 of the set of interfaces that 
> lto-elf.c provides, 

  Thanks Joseph!  That's probably much cleaner.  (Did I mention I didn't study
the code yet?  I only just started testing this stuff for the first time before
christmas.)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41529

[Bug rtl-optimization/41862] [4.5 Regression] -fgcse-sm causes bootstrap comparison failures

[rguenth at gcc dot gnu dot org]

--- 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

[Bug rtl-optimization/42258] [4.5 Regression] redundant register move around mul instruction

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42258

[Bug c++/42336] [4.5 Regression] ICE with pointer-to-member-function argument in template function

[rguenth at gcc dot gnu dot org]

--- 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 |Added

   Priority|P3  |P1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42336

[Bug rtl-optimization/42388] [4.5 Regression] ICE in move_bb_info with sel-sched and modulo-sched for 176.gcc

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42388

[Bug middle-end/42393] [4.5 Regression] [graphite] internal compiler error: in check_loop_closed_ssa_use

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42393

[Bug debug/42395] [4.5 Regression] "error: definition in block 12 does not dominate use in block 19" with -O3 -g

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42395

[Bug debug/42396] [4.5 Regression] ICE: in dwarf2out_frame_debug_adjust_cfa, at dwarf2out.c:1859

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Priority|P3  |P2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42396

[Bug tree-optimization/42398] [4.5 Regression] internal compiler error: in sra_modify_expr, at tree-sra.c:2175

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42398

[Bug target/42427] [4.5 Regression] invalid assembly code for 301.apsi for -fnon-call-exceptions

[rguenth at gcc dot gnu dot org]

--- 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

   Priority|P3  |P1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42427

[Bug target/42431] [4.5 Regression] wrong code for 200.sixtrack with vectorization and -fdata-sections

[rguenth at gcc dot gnu dot org]

--- 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|UNCONFIRMED |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42431

[Bug middle-end/42450] [4.5 Regression] another GCC 4.5 ICE on C++ templated code

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42450

[Bug rtl-optimization/42461] [4.5 Regression] Missed optimisation for pure functions with __builtin_unreachable

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42461

[Bug tree-optimization/42462] [4.5 Regression] wrong-code with computed-goto

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42462

[Bug middle-end/42482] [4.5 Regression] Many graphite test failures

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42482

[Bug driver/42485] [4.4/4.5 Regression] -V switch broken

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42485

[Bug tree-optimization/42508] [4.5 Regression] wrong code with "-O1 -fipa-sra"

[rguenth at gcc dot gnu dot org]

--- 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

   Priority|P3  |P1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42508

[Bug tree-optimization/42521] [4.5 Regression] ICE: in graphite_loop_normal_form, at graphite-sese-to-poly.c:2844

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42521

[Bug tree-optimization/42558] [4.5 Regression] miscompilation related to -floop-block

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|middle-end  |tree-optimization
   Priority|P3  |P1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42558

[Bug middle-end/42574] [4.3/4.4/4.5 Regression] Address of global variable is calculated multiple times (missed CSE)

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42574

[Bug c++/40561] [4.3 Regression] code does not compile -- compiles fine when replacing != with !(==)

[rguenth at gcc dot gnu dot org]

--- 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:

   What|Removed |Added

   Keywords||rejects-valid
  Known to fail|4.3.3   |4.3.0 4.3.4
  Known to work|4.2.1 4.4.1 4.5.0   |4.2.4 4.4.0 4.5.0
   Priority|P3  |P2
   Last reconfirmed|2009-08-26 22:01:37 |2010-01-02 16:23:06
   date||
Summary|[4.3 regression] code does  |[4.3 Regression] code does
   |not compile -- compiles fine|not compile -- compiles fine
   |when replacing != with !(==)|when replacing != with !(==)


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40561

[Bug bootstrap/42424] in-tree GMP/MPFR/MPC bootstrap fails

[ghazi at gcc dot gnu dot org]

--- 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 we need more
info, e.g.

1.  Is this a recent regression or has it always failed?
2.  What versions of the various libraries did you use?
3.  Does it fail with all versions of the libs or just some?
4.  The targets listed include darwin9 and i686-linux, do they both fail for
the same reason?
5.  Do you have other versions of gmp/mpfr installed somewhere that conflict
with the bootstrap?
6.  Is there more info or investigation you can provide?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42424

[Bug c++/41131] [4.3 Regression] non-lvalue in unary `&' wrongly accepted

[rguenth at gcc dot gnu dot org]

--- 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

 Status|NEW |RESOLVED
  Known to fail|4.3.0 4.4.0 |4.3.4 4.4.1
 Resolution||FIXED
   Target Milestone|4.3.5   |4.4.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41131

[Bug middle-end/41623] [4.3 Regression] ICE: emit_move_insn at expr.c 3162 when compiling template code.

[rguenth at gcc dot gnu dot org]

-- 

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://gcc.gnu.org/bugzilla/show_bug.cgi?id=41623

[Bug rtl-optimization/41646] [4.3 Regression] Reload ICE due to combiner extending life time of a hard register

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to fail||4.3.4 4.4.1
  Known to work||4.4.2 4.5.0
   Priority|P3  |P2
   Last reconfirmed|-00-00 00:00:00 |2010-01-02 16:29:44
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41646

[Bug rtl-optimization/41917] [4.3 Regression] Strange athrithmetic result with -O3

[rguenth at gcc dot gnu dot org]

-- 

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://gcc.gnu.org/bugzilla/show_bug.cgi?id=41917

[Bug libffi/42289] [4.3 only] libffi fails to build with binutils-2.20 on ARM

[rguenth at gcc dot gnu dot org]

-- 

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

[Bug middle-end/42577] [4.4/4.5 Regression] array bounds false positive with -O3, goes away with -O2

[rguenth at gcc dot gnu dot org]

--- 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

   Keywords||diagnostic
Summary|array bounds false positive |[4.4/4.5 Regression] array
   |with -O3, goes away with -O2|bounds false positive with -
   ||O3, goes away with -O2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42577

[Bug bootstrap/42424] in-tree GMP/MPFR/MPC bootstrap fails

[developer at sandoe-acoustics dot co dot uk]

--- 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 this a recent regression or has it always failed?
since the introduction of mpc - prior to that I had been using in-tree mpc/mpfr
with no issues.
[however the first version of mpc I've used is 0.8.1].
> 2.  What versions of the various libraries did you use?
gmp-4-3-1, mpfr-2-4-1 source trees.
mpc-0.8.1 source tree
> 3.  Does it fail with all versions of the libs or just some?
I haven't built with mpc prior to 0.8.1 - but these same gmp/mpfr versions
*were* OK prior to the introduction of mpc.
> 4.  The targets listed include darwin9 and i686-linux, do they both fail for
> the same reason?
yes - configure fail for mpc.
> 5.  Do you have other versions of gmp/mpfr installed somewhere that conflict
> with the bootstrap?
no, I don't install any of these libs on darwin.  
I have installed on i686-linux *since*, but the fault occurred on a fresh
ubuntu 9.10 install.

> 6.  Is there more info or investigation you can provide?
make check (mpc part) also fails when the mpc is built in tree - even when the
gm/mpfr libs are supplied using --with-{gmp,mpfr}= ... this perhaps points at
an mpc config change between 0.8 and 0.8.1 - since 0.8 works for you.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42424

[Bug middle-end/42577] [4.4/4.5 Regression] array bounds false positive with -O3, goes away with -O2

[rguenth at gcc dot gnu dot org]

-- 

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

[Bug target/42536] [4.4/4.5 regression] ICE in spill_failure, at reload1.c:2141

[jakub at gcc dot gnu dot org]

--- 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); };
typedef union { int f; void *e; } D;
struct E { struct B *e; };
struct A { struct E *a1; D *a2; D *a3; };

void
foo (long *x, long y)
{
  *(long long *) x = y;
}

extern long fn1 (D);
extern void fn2 (void);

void
_bar (struct A *x)
{
  register int a asm ("esi");
  register D *volatile b asm ("edi");
  register int c asm ("ebx");
  void *d;
  asm volatile ("" : "=r" (a), "=r" (b), "=r" (c) : : "memory");
  if ((d = b[-2].e) != 0 && b [-2].e < d)
{
  foo (&(((long *) d) + 1) [b[0].f], fn1 (b[-1]));
  x->a2 = (D *) c;
  x->a3 = b;
  fn2 ();
}
  x->a1->e->b->baz (x->a1->e, (void *) (long) a, 1);
}

Wonder why RA doesn't try to force the memory address into register, that would
free up one register from the 4 otherwise needed (2 for the address, 2 for
DImode value being stored into the memory). 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42536

[Bug lto/42580] New: Missing command line option file causes ICE

[hjl dot tools at gmail dot com]

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/cc0mkdyt.lto.o -O2 -version 
@/tmp/ccsQ6Ult -o y.s
GNU GIMPLE (GCC) version 4.5.0 20091229 (experimental)
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.5.0 20091229 (experimental), GMP version
4.3.1, MPFR version 2.4.2, MPC version 0.8
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
lto1: internal compiler error: could not parse hex number
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
[...@gnu-34 gcc]$


-- 
   Summary: Missing command line option file causes ICE
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42580

[Bug lto/42580] Missing command line option file causes ICE

[hjl dot tools at gmail dot com]

--- 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

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2010-
   ||01/msg00064.html


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42580

[Bug driver/41564] -fdump-tree-all for lto does not work as expected

[hjl dot tools at gmail dot com]

--- 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

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2010-
   ||01/msg00065.html


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41564

[Bug tree-optimization/42337] [4.4 Regression] GCC ICE in compute_antic, at tree-ssa-pre.c:2534

[rguenth at gcc dot gnu dot org]

--- 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 mainline
2009-12-10  Richard Guenther  

PR tree-optimization/42337
* tree-ssa-pre.c (seen_during_translate): Remove.
(phi_translate_1): Collapse into ...
(phi_translate): ... this.  Remove seen parameter and
adjust recursive calls.

Backport from mainline
2009-12-09  Xinliang David Li  

PR tree-optimization/42337
* g++.dg/tree-ssa/pr42337.C: New test.

Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/tree-ssa/pr42337.C
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
branches/gcc-4_4-branch/gcc/tree-ssa-pre.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42337

[Bug tree-optimization/42337] [4.4 Regression] GCC ICE in compute_antic, at tree-ssa-pre.c:2534

[rguenth at gcc dot gnu dot org]

--- 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|RESOLVED
  Known to fail|4.4.3   |4.4.2
  Known to work|4.3.4 4.5.0 |4.3.4 4.4.3 4.5.0
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42337

[Bug lto/42580] Missing command line option file causes ICE

[hjl at gcc dot gnu dot org]

--- 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  

PR lto/42580
* lto-elf.c (lto_elf_file_open): Stop if the command line
option file is missing.

Modified:
trunk/gcc/lto/ChangeLog
trunk/gcc/lto/lto-elf.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42580

[Bug target/42564] ICE on sparc - unrecognizable insn

[ebotcazou at gcc dot gnu dot org]

--- 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

 AssignedTo|unassigned at gcc dot gnu   |ebotcazou at gcc dot gnu dot
   |dot org |org
 Status|WAITING |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-01-02 17:33:26
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42564

[Bug lto/42580] Missing command line option file causes ICE

[hjl dot tools at gmail dot com]

--- 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|--- |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42580

[Bug lto/42581] New: "gcc -v" doesn't work with lto

[hjl dot tools at gmail dot com]

[...@gnu-6 gcc]$ ./xgcc -B. -o t t1.o t2.o  -fwhopr -O -fdump-tree-optimized -v
Reading specs from ./specs
COLLECT_GCC=./xgcc
COLLECT_LTO_WRAPPER=./lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /export/gnu/import/git/gcc/configure --enable-languages=c,c++
--disable-bootstrap --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' 't' '-fwhopr' '-O' '-fdump-tree-optimized' '-v'
'-mtune=generic'
 ./collect2 -fwhopr --eh-frame-hdr -m elf_x86_64 -dynamic-linker
/lib64/ld-linux-x86-64.so.2 -o t /usr/lib/../lib64/crt1.o
/usr/lib/../lib64/crti.o ./crtbegin.o -L. -L/lib/../lib64 -L/usr/lib/../lib64
t1.o t2.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed
-lgcc_s --no-as-needed ./crtend.o /usr/lib/../lib64/crtn.o
Reading specs from ./specs
COLLECT_GCC=././xgcc
COLLECT_LTO_WRAPPER=./lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /export/gnu/import/git/gcc/configure --enable-languages=c,c++
--disable-bootstrap --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) 
COLLECT_GCC_OPTIONS='-combine' '-c'
'-fltrans-output-list=/tmp/ccFzFDK6.ltrans.out' '-fwpa' '-B.' '-dumpbase' 't'
'-dumpdir' './' '-O' '-fdump-tree-optimized' '-v' '-mtune=generic'
 ./lto1 -quiet -dumpbase t1.o -dumpbase t -dumpdir ./ -mtune=generic -auxbase
t1 -O -version -fltrans-output-list=/tmp/ccFzFDK6.ltrans.out -fwpa
-fdump-tree-optimized @/tmp/cc1mIiH6
GNU GIMPLE (GCC) version 4.5.0 20100102 (experimental)
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.4.2 20091222 (Red Hat 4.4.2-20), GMP
version 4.3.1, MPFR version 2.4.2, MPC version 0.8
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU GIMPLE (GCC) version 4.5.0 20100102 (experimental)
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.4.2 20091222 (Red Hat 4.4.2-20), GMP
version 4.3.1, MPFR version 2.4.2, MPC version 0.8
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Reading specs from ./specs
COLLECT_GCC=././xgcc
COLLECT_LTO_WRAPPER=./lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /export/gnu/import/git/gcc/configure --enable-languages=c,c++
--disable-bootstrap --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) 
COLLECT_GCC_OPTIONS='-combine' '-c' '-B.' '-dumpbase' 't' '-dumpdir' './' '-O'
'-fdump-tree-optimized' '-v' '-mtune=generic' '-fltrans' '-o' 't2.wpa.ltrans.o'
 ./lto1 -quiet -dumpbase t2.wpa.o -dumpbase t -dumpdir ./ -mtune=generic
-auxbase-strip t2.wpa.ltrans.o -O -version -fdump-tree-optimized -fltrans
t2.wpa.o -o /tmp/ccMCxira.s
GNU GIMPLE (GCC) version 4.5.0 20100102 (experimental)
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.4.2 20091222 (Red Hat 4.4.2-20), GMP
version 4.3.1, MPFR version 2.4.2, MPC version 0.8
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU GIMPLE (GCC) version 4.5.0 20100102 (experimental)
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.4.2 20091222 (Red Hat 4.4.2-20), GMP
version 4.3.1, MPFR version 2.4.2, MPC version 0.8
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
COLLECT_GCC_OPTIONS='-combine' '-c' '-B.' '-dumpbase' 't' '-dumpdir' './' '-O'
'-fdump-tree-optimized' '-v' '-mtune=generic' '-fltrans' '-o' 't2.wpa.ltrans.o'
 ./as -V -Qy -o t2.wpa.ltrans.o /tmp/ccMCxira.s
GNU assembler version 2.20.51.0.5 (x86_64-unknown-linux-gnu) using BFD version
(Linux/GNU Binutils) 2.20.51.0.5.20091221
COMPILER_PATH=./:./
LIBRARY_PATH=./:/lib/../lib64/../lib64/:/usr/lib/../lib64/../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/lib/../lib64/:/usr/lib/../lib64/:./:/lib/../lib64/:/usr/lib/../lib64/:/lib/:/usr/lib/:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-combine' '-c' '-B.' '-dumpbase' 't' '-dumpdir' './' '-O'
'-fdump-tree-optimized' '-v' '-mtune=generic' '-fltrans' '-o' 't2.wpa.ltrans.o'
Reading specs from ./specs
COLLECT_GCC=././xgcc
COLLECT_LTO_WRAPPER=./lto-wrapper
Target: x86_64-unknown-linux-gnu
Confi

[Bug middle-end/42577] [4.4/4.5 Regression] array bounds false positive with -O3, goes away with -O2

[rguenth at gcc dot gnu dot org]

--- 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
* tree-vrp.c (check_all_array_refs): Skip non-excutable blocks.
(simplify_switch_using_ranges): Mark to be removed edges
as non-executable.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vrp.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42577

[Bug middle-end/42577] [4.4 Regression] array bounds false positive with -O3, goes away with -O2

[rguenth at gcc dot gnu dot org]

--- 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

 AssignedTo|rguenth at gcc dot gnu dot  |unassigned at gcc dot gnu
   |org |dot org
 Status|ASSIGNED|NEW
  Known to work||4.5.0
Summary|[4.4/4.5 Regression] array  |[4.4 Regression] array
   |bounds false positive with -|bounds false positive with -
   |O3, goes away with -O2  |O3, goes away with -O2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42577

[Bug c/35392] Warning "array subscript is above array bounds" in inline fct

[rguenth at gcc dot gnu dot org]

--- 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|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to fail||4.5.0
   Last reconfirmed|-00-00 00:00:00 |2010-01-02 19:19:14
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35392

[Bug middle-end/35903] false uninitialized warning when passing quoted string to function strcmp(arg,"no");

[rguenth at gcc dot gnu dot org]

--- 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

  BugsThisDependsOn||35392
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-01-02 19:24:39
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35903

[Bug c++/35966] array-subscript-above-bounds warning disappears when unrelated constructor definition is added

[rguenth at gcc dot gnu dot org]

--- 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

 Status|UNCONFIRMED |RESOLVED
   Keywords||diagnostic
 Resolution||FIXED
   Target Milestone|--- |4.3.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35966

[Bug middle-end/37130] warning: array subscript is above array bounds.

[rguenth at gcc dot gnu dot org]

--- 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

 Status|UNCONFIRMED |RESOLVED
  Known to fail||4.3.4
  Known to work||4.4.2 4.5.0
 Resolution||FIXED
   Target Milestone|--- |4.4.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37130

[Bug middle-end/37921] __builtin_constant_p seems to be giving false positives

[rguenth at gcc dot gnu dot org]

--- 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 |Added

  Component|c   |middle-end
   Keywords||diagnostic
  Known to fail||4.5.0
   Last reconfirmed|2008-10-26 22:40:30 |2010-01-02 19:35:34
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37921

[Bug c++/38625] Segmentation fault when dereferencing valid pointer, probably REGRESSION

[rguenth at gcc dot gnu dot org]

--- 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

 Status|NEW |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38625

[Bug middle-end/38808] another warning from system headers.

[rguenth at gcc dot gnu dot org]

--- 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|UNCONFIRMED |RESOLVED
  Known to fail||4.4.2
  Known to work||4.5.0
 Resolution||FIXED
   Target Milestone|--- |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38808

[Bug bootstrap/42424] in-tree GMP/MPFR/MPC bootstrap fails

[fxcoudert at gcc dot gnu dot org]

--- 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=/Users/fx/devel/gcc/irun --enable-languages=c
3. "make" fails with:

checking for __gmpz_init in -lgmp... no
configure: error: libgmp not found or uses a different ABI.
make[2]: *** [configure-stage1-mpc] Error 1
make[1]: *** [stage1-bubble] Error 2
make: *** [all] Error 2


The problem is actually not an ABI one, but that the mpc configure fails with:

configure:10805: checking for __gmpz_init in -lgmp
configure:10830: gcc -o conftest -g -fkeep-inline-functions
-I/Users/fx/devel/gcc/ibin-intree/./gmp -I/Users/fx/devel/gcc/trunk/mpfr   
conftest.c -lgmp   >&5
ld: library not found for -lgmp

The problem is that mpc isn't told where to find the gmp and mpfr libraries. It
is confirmed by the mpc configure command-line (from mpc/config.log):

/Users/fx/devel/gcc/trunk/mpc/configure --cache-file=./config.cache
--prefix=/Users/fx/devel/gcc/irun --enable-languages=c
--program-transform-name=s,y,y, --disable-option-checking
--build=x86_64-apple-darwin10.2.0 --host=x86_64-apple-darwin10.2.0
--target=x86_64-apple-darwin10.2.0 --srcdir=../../trunk/mpc
--disable-intermodule --enable-checking=yes,types --disable-coverage
--enable-languages=c --disable-shared
--with-gmp-include=/Users/fx/devel/gcc/ibin-intree/./gmp
--with-mpfr-include=/Users/fx/devel/gcc/trunk/mpfr


This can be contrasted with mpfr, which is configured with
'--with-gmp-build=/Users/fx/devel/gcc/ibin-intree/./gmp', and thus knows where
to find libgmp. So it seems that the following patch should be applied to
configure.ac:

Index: configure.ac
===
--- configure.ac(revision 155544)
+++ configure.ac(working copy)
@@ -1287,7 +1287,7 @@
 if test "x$with_mpfr$with_mpfr_include$with_mpfr_lib" = x && test -d
${srcdir}/mpfr; then
   gmplibs='-L$$r/$(HOST_SUBDIR)/mpfr/.libs -L$$r/$(HOST_SUBDIR)/mpfr/_libs
'"$gmplibs"
   gmpinc='-I$$r/$(HOST_SUBDIR)/mpfr -I$$s/mpfr '"$gmpinc"
-  extra_mpc_mpfr_configure_flags='--with-mpfr-include=$$s/mpfr'
+  extra_mpc_mpfr_configure_flags='--with-mpfr-include=$$s/mpfr
--with-mpfr-lib=$$r/$(HOST_SUBDIR)/mpfr/.libs'
   # Do not test the mpfr version.  Assume that it is sufficient, since
   # it is in the source tree, and the library has not been built yet
   # but it would be included on the link line in the version check below
@@ -1321,7 +1321,7 @@
   gmplibs='-L$$r/$(HOST_SUBDIR)/gmp/.libs -L$$r/$(HOST_SUBDIR)/gmp/_libs
'"$gmplibs"
   gmpinc='-I$$r/$(HOST_SUBDIR)/gmp -I$$s/gmp '"$gmpinc"
   extra_mpfr_configure_flags='--with-gmp-build=$$r/$(HOST_SUBDIR)/gmp'
-  extra_mpc_gmp_configure_flags='--with-gmp-include=$$r/$(HOST_SUBDIR)/gmp'
+  extra_mpc_gmp_configure_flags='--with-gmp-include=$$r/$(HOST_SUBDIR)/gmp
--with-gmp-lib=$$r/$(HOST_SUBDIR)/gmp/.libs'
   # Do not test the gmp version.  Assume that it is sufficient, since
   # it is in the source tree, and the library has not been built yet
   # but it would be included on the link line in the version check below



Except that on some targets, ".libs" is actually called "_libs". I don't know
how to deal with that.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-01-02 19:53:42
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42424

[Bug c/42582] New: fortify with optimisation above -O0 cause abort in realpath()

[pva at gentoo dot org]

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 *argv[])
{
int ret;
char device_file_or_mount_point[1024];

if (argc < 2 || strlen (argv[1]) == 0) {
fprintf (stderr, "%s: pass relative path.\n", argv[0]);
return 1;
}

realpath(argv[1], device_file_or_mount_point);

return 0;
}
==

produces:

 $ ./a.out /boot/
*** buffer overflow detected ***: ./a.out terminated
=== Backtrace: =
/lib/libc.so.6(__fortify_fail+0x37)[0x7f1adb1c33a7]
/lib/libc.so.6[0x7f1adb1c03d0]
/lib/libc.so.6[0x7f1adb1c0a9b]
./a.out(main+0x55)[0x7f1adb6518c5]
/lib/libc.so.6(__libc_start_main+0xe6)[0x7f1adb1015c6]
./a.out[0x7f1adb651789]
=== Memory map: 
[snip]


I found this bug with umount.hal helper which started to fail here after this
commit:
http://cgit.freedesktop.org/hal/commit/?id=6d8eed9015a6ca648fe1dad575621b6ea959a748

But probably other applications are affected too. At least I found similar
issue with python reported here:
https://bugs.launchpad.net/ubuntu/+source/gcc-defaults/+bug/286334

Also I found that scilab has 6a5321bddceaf0e4761f29a507bfad6e1f3a7b33 commit
(googable) that basically modifies realpath(r,a) call to a=realpath(r,NULL).


Reproduced with gcc-4.4.2 (glibc-2.11) and gcc-4.3.4 (glibc-2.9_p20081201-r2)
 $ LC_ALL=C gcc --version
gcc (Gentoo 4.4.2 p1.0) 4.4.2
 $ uname -a
Linux tablet 2.6.32-gentoo #2 SMP PREEMPT Sat Dec 19 23:36:55 MSK 2009 x86_64
Intel(R) Core(TM)2 Duo CPU L7500 @ 1.60GHz GenuineIntel GNU/Linux


-- 
   Summary: fortify with optimisation above -O0 cause abort in
realpath()
   Product: gcc
   Version: 4.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pva at gentoo dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42582

[Bug bootstrap/42566] Bootstrap fails in stage3 building the libstdc++ PCH

[fxcoudert at gcc dot gnu dot org]

--- 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 command line at the top of
Users/ed/obj/powerpc-apple-darwin7.9.0/libstdc++-v3/config.log (following the
text "Invocation command line was")

I don't see why the just built compiler is not picked up in your configuration,
as it is in mine.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42566

[Bug lto/42581] "gcc -v" doesn't work with lto

[rguenth at gcc dot gnu dot org]

--- 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 collect2, lto-wrapper and lto1.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-01-02 20:26:26
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42581

[Bug c/42582] fortify with optimisation above -O0 cause abort in realpath()

[truedfx at gentoo dot org]

--- 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://gcc.gnu.org/bugzilla/show_bug.cgi?id=42582

[Bug c/42582] fortify with optimisation above -O0 cause abort in realpath()

[rguenth at gcc dot gnu dot org]

--- 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

[Bug bootstrap/42566] Bootstrap fails in stage3 building the libstdc++ PCH

[3dw4rd at verizon dot net]

--- 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.cgi?id=42566

[Bug middle-end/37921] __builtin_constant_p seems to be giving false positives

[manu at gcc dot gnu dot org]

--- 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.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37921

[Bug bootstrap/42566] Bootstrap fails in stage3 building the libstdc++ PCH

[3dw4rd at verizon dot net]

--- 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

[Bug bootstrap/42566] Bootstrap fails in stage3 building the libstdc++ PCH

[3dw4rd at verizon dot net]

--- 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