[Bug rtl-optimization/35785] gcc.c-torture/compile/pr11832.c doesn't work for Linux/ia64

[wilson at gcc dot gnu dot org]

--- Comment #3 from wilson at gcc dot gnu dot org  2008-04-03 06:29 ---
Created an attachment (id=15419)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15419&action=view)
rtl-factoring.c patch to allocate second reg for IA-64

This allocates a second register if REGNO_OK_FOR_INDIRECT_JUMP_P is defined,
and then adjusts the code appropriately to use the second reg.  This obviously
needs some cleanup, I didn't give it much thought.  It seems to be working for
the simple testcase though.


-- 


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

[Bug rtl-optimization/35785] gcc.c-torture/compile/pr11832.c doesn't work for Linux/ia64

[wilson at gcc dot gnu dot org]

--- Comment #2 from wilson at gcc dot gnu dot org  2008-04-03 06:27 ---
Created an attachment (id=15418)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15418&action=view)
ia64.h patch to define REGNO_OK_FOR_INDIRECT_JUMP_P

Obvious definition of the REGNO_OK_FOR_INDIRECT_JUMP_P macro.


-- 


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

[Bug rtl-optimization/35785] gcc.c-torture/compile/pr11832.c doesn't work for Linux/ia64

[wilson at tuliptree dot org]

--- Comment #1 from wilson at tuliptree dot org  2008-04-03 06:26 ---
Subject: Re:   New: gcc.c-torture/compile/pr11832.c
 doesn't work for Linux/ia64

hjl dot tools at gmail dot com wrote:
> (set (pc)^M
> (reg:DI 2 loc79)) 329 {indirect_jump} (nil))^M

This is a problem with the seqabstr pass, which is confusingly in the 
rtl-factoring.c file.  It is allocating a hard register, but not 
checking that the register is OK for a jump instruction.  On IA-64, we 
can't use a general reg here, we need one of the branch registers.

I see a REGNO_OK_FOR_INDIRECT_JUMP_P macro which we could define in the 
ia64.h file to fix the problem.  This macro is of course undocumented. 
Someone should file a PR for that and assign it to the author of this code.

I tried adding the obvious definition to ia64.h and now it fails in a 
different place.  rtl-factoring.c aka seqabstr is doing
>   /* Emit an insn saving the return address to the link register before the   
>   
>  sequence.  */
>   saveinsn = emit_insn_after (gen_move_insn (pattern_seqs->link_reg,
>   gen_symbol_ref_rtx_for_label
>   (retlabel)), BB_END (bb));
It is trying to load a label_ref directly into a branch register which 
is certainly not going to work on an IA-64.  Since this is after reload, 
there is nothing the ia64.md backend can do to fix this.  This requires 
a rtl-factoring.c aka seqabstr fix.  It needs to allocate two registers 
for a machine like IA-64, a general reg to load the label into, and a 
branch reg to move the label value to for the branch.

I tried writing a quick patch, taking advantage of the fact that 
REGNO_OK_FOR_INDIRECT_JUMP_P is undocumented and unused, hence I can 
redfine it anyway I need in order to make the IA-64 port work.  I didn't 
give this much thought; this can clearly be improved.

I'll attach the two patches I have.  I'm not sure if this will actually 
work, but at least the compiler doesn't crash anymore, and I don't see 
anything obviously wrong with the code.

Jim


-- 


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

[Bug target/35795] [4.4 Regression] Revision 133787 breaks ia64

[hubicka at ucw dot cz]

--- Comment #7 from hubicka at ucw dot cz  2008-04-03 06:12 ---
Subject: Re:  [4.4 Regression] Revision 133787 breaks ia64

> The patch is OK.
> 
> But won't all targets that have similar code need the same fix?  If I cd 
> to the config dir, and try "grep final_end_function */*" it looks like 
> alpha, ia64, m68k, mips, rs6000, score (both score3 and score7), sh, and 
> sparc all have the same problem.  The rs6000 port has already been fixed 
> via PR 35801.  We have an ia64 patch here.  We also need patches for the 
> rest.

Thanks,
I've just noticed that too and send patch for all the backends.  Looks
like we was leaking memory here for ages, probably not that big deal
since thunks are pretty small functions, but still keeping all the RTL
register tables around seems bit expensive.

Honza
> 
> Jim
> 
> 
> -- 
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35795
> 
> --- You are receiving this mail because: ---
> You are on the CC list for the bug, or are watching someone who is.


-- 


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

[Bug rtl-optimization/35281] [4.3 Regression] multiply with 0 generated for 64*32->64

[bonzini at gcc dot gnu dot org]

--- Comment #16 from bonzini at gnu dot org  2008-04-03 05:37 ---
Subject: Bug 35281

Author: bonzini
Date: Thu Apr  3 05:36:26 2008
New Revision: 133859

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133859
Log:
2008-04-03  Paolo Bonzini  <[EMAIL PROTECTED]>

PR rtl-optimization/35281
* gcc.target/i386/pr35281.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr35281.c
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug target/35795] [4.4 Regression] Revision 133787 breaks ia64

[wilson at tuliptree dot org]

--- Comment #6 from wilson at tuliptree dot org  2008-04-03 05:16 ---
Subject: Re:  [4.4 Regression] Revision 133787
 breaks ia64

hubicka at ucw dot cz wrote:
> *** ia64_output_mi_thunk (FILE *file, tree t
> final_end_function ();
> +   free_after_compilation (cfun);

The patch is OK.

But won't all targets that have similar code need the same fix?  If I cd 
to the config dir, and try "grep final_end_function */*" it looks like 
alpha, ia64, m68k, mips, rs6000, score (both score3 and score7), sh, and 
sparc all have the same problem.  The rs6000 port has already been fixed 
via PR 35801.  We have an ia64 patch here.  We also need patches for the 
rest.

Jim


-- 


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

[Bug ada/35284] Branch to 0x0 from Ada run-time

[laurent at guerby dot net]

--- Comment #34 from laurent at guerby dot net  2008-04-03 03:47 ---
May be other platform aligned the record 8 byte hence hiding the issue, and x86
only 4 bytes hence showing it.


-- 


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

[Bug ada/35284] Branch to 0x0 from Ada run-time

[laurent at guerby dot net]

--- Comment #33 from laurent at guerby dot net  2008-04-03 03:46 ---
Great news!


-- 


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

[Bug bootstrap/35804] Bootstrap of combined gcc + binutils, with --enable-shared, with sysroot fails

[oblivian at users dot sourceforge dot net]

--- Comment #6 from oblivian at users dot sourceforge dot net  2008-04-03 
03:24 ---
(In reply to comment #5)
Ok, so this is a sysroot bug in binutils that they marked as invalid
http://sourceware.org/bugzilla/show_bug.cgi?id=4966

I guess I would argue that it's not invalid anymore since this behavior is now
required with the removal of the spec search paths that allowed a minimal
"tools" toolchain to be installed before chrooting and compiling a new full
target toolchain without overwriting binaries.

I applied the change from that bug and now it continues on to stage 2.

This bug is now invalid and it will have to be straightened out with binutils.
My vote is of course this should be supported by sysroot, and not limited to a
root directory chrooted toolchain.


-- 


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

[Bug c++/16635] g++ instantiates templates at the wrong place

[pinskia at gcc dot gnu dot org]

--- Comment #11 from pinskia at gcc dot gnu dot org  2008-04-03 02:51 
---
*** Bug 35799 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||peter at empeg dot com


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

[Bug c++/35799] GCC uses inheritance information it doesn't yet know

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-04-03 02:51 ---
It is a delayed instantiation issue, we are instantiating
Fnord::Fnord at the wrong spot, 

*** This bug has been marked as a duplicate of 16635 ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug tree-optimization/35809] New: default case label for casesi should be spliced off from last element

[hp at gcc dot gnu dot org]

The fix for PR middle-end/35800 was to find a "new" default label as one is
required by the casesi pattern, but value-range-propagation had determined that
a switch statement can't fall through or reach the default label, so "it was
NULL".  The fix was to arbitrarily use the first label of the case-table.  An
improvement would be to slice off the last element, shrinking the table and its
range.
This naturally only affects targets with casesi patterns.


-- 
   Summary: default case label for casesi should be spliced off from
last element
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
GCC target triplet: cris-*-*


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

[Bug middle-end/35800] [4.4 Regression]: Revision 133835 failed to compile binutils

[hp at gcc dot gnu dot org]

--- Comment #19 from hp at gcc dot gnu dot org  2008-04-03 02:20 ---
s/13 and 13/13 and 14/ in comment #18


-- 


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

[Bug middle-end/35800] [4.4 Regression]: Revision 133835 failed to compile binutils

[hp at gcc dot gnu dot org]

--- Comment #18 from hp at gcc dot gnu dot org  2008-04-03 02:18 ---
I presume we can close this one as
 (comment #13 and
comment #13) has been committed.


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/35800] [4.4 Regression]: Revision 133835 failed to compile binutils

[hp at gcc dot gnu dot org]

--- Comment #17 from hp at gcc dot gnu dot org  2008-04-03 02:10 ---
Subject: Bug 35800

Author: hp
Date: Thu Apr  3 02:09:20 2008
New Revision: 133857

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133857
Log:
PR middle-end/35800
* expr.h (try_casesi): Adjust prototype.
* expr.c (try_casesi): Take fallback label as extra parameter.
Use that for gen_casesi if default_label is NULL.
* stmt.c (expand_case): Pass fallback label to try_casesi,
make sure to fill gaps with a fallback label if default_label
is not present.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/expr.c
trunk/gcc/expr.h
trunk/gcc/stmt.c


-- 


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

[Bug middle-end/35800] [4.4 Regression]: Revision 133835 failed to compile binutils

[hp at gcc dot gnu dot org]

--- Comment #16 from hp at gcc dot gnu dot org  2008-04-03 02:09 ---
Subject: Bug 35800

Author: hp
Date: Thu Apr  3 02:08:13 2008
New Revision: 133856

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133856
Log:
PR middle-end/35800
* gcc.c-torture/execute/pr35800.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr35800.c
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug bootstrap/35804] Bootstrap of combined gcc + binutils, with --enable-shared, with sysroot fails

[oblivian at users dot sourceforge dot net]

--- Comment #5 from oblivian at users dot sourceforge dot net  2008-04-03 
01:40 ---
Is this something special in the compiler specs for libc?

I created this test file conftest.c

#include 

int testing_lib()
{
printf("hello world!\n");
return 0;
}


And ran a scaled down libgcc command with the stage 1 compiler:

/media/disk/build/scripts/tools/toolchain-pass-1/build/./gcc/xgcc
-B/media/disk/build/scripts/tools/toolchain-pass-1/build/./gcc/
-B/tools/usr/i686-pc-linux-gnu/bin/ -B/tools/usr/i686-pc-linux-gnu/lib/
-isystem /tools/usr/i686-pc-linux-gnu/include -isystem
/tools/usr/i686-pc-linux-gnu/sys-include
-L/media/disk/build/scripts/tools/toolchain-pass-1/build/./ld -O2  -O2 -g -g
-O2   -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include  -fPIC -g
-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -shared
-nodefaultlibs -Wl,--soname=libgcc_s.so.1 -o ./conftest.so.1.tmp conftest.c -lm
-lc

--
conftest.c:4: warning: function declaration isn't a prototype
conftest.c: In function 'testing_lib':
conftest.c:4: warning: old-style function definition
/media/disk/build/scripts/tools/toolchain-pass-1/build/gcc/../ld/ld-new: cannot
find /tools/lib/libc.so.6 inside /tools
collect2: ld returned 1 exit status
--

Now running the same command without -lc

--
/media/disk/build/scripts/tools/toolchain-pass-1/build/./gcc/xgcc
-B/media/disk/build/scripts/tools/toolchain-pass-1/build/./gcc/
-B/tools/usr/i686-pc-linux-gnu/bin/ -B/tools/usr/i686-pc-linux-gnu/lib/
-isystem /tools/usr/i686-pc-linux-gnu/include -isystem
/tools/usr/i686-pc-linux-gnu/sys-include
-L/media/disk/build/scripts/tools/toolchain-pass-1/build/./ld -O2  -O2 -g -g
-O2   -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include  -fPIC -g
-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -shared
-nodefaultlibs -Wl,--soname=libgcc_s.so.1 -o ./conftest.so.1.tmp conftest.c -lm 
conftest.c:4: warning: function declaration isn't a prototype
conftest.c: In function 'testing_lib':
conftest.c:4: warning: old-style function definition
---
Despite the warnings it creates the shared library file

and running 

ldd conftest.so.1.tmp 
linux-gate.so.1 =>  (0xb7eec000)
libm.so.6 => /tools/lib/libm.so.6 (0xb7ebf000)
/tools/lib/ld-linux.so.2 (0xb7eed000)
libc.so.6 => /tools/lib/libc.so.6 (0xb7d94000)

The new file not only is linked with the correct libm, but also libc

Where is this special handling of -lc?


-- 


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

[Bug tree-optimization/28029] [4.1 Regression] wrong optimization with -ftree-vectorize

[pinskia at gcc dot gnu dot org]

--- Comment #11 from pinskia at gcc dot gnu dot org  2008-04-03 01:08 
---
I ran into this even without the vectorizer :).


-- 


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

[Bug tree-optimization/32353] [4.1/4.2 Regression] Miscompilation with RESULT_DECL

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.1.3


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

[Bug target/35801] [4.4 Regression]: At revision 133817, bootstrap fails at libstdc++-v3/src/strstream.cc on powerpc-apple-darwin9

[dje at gcc dot gnu dot org]

--- Comment #5 from dje at gcc dot gnu dot org  2008-04-03 00:34 ---
Patch in comment #3 applied.  Fixed.


-- 

dje at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dje at gcc dot gnu dot org
 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug target/35801] [4.4 Regression]: At revision 133817, bootstrap fails at libstdc++-v3/src/strstream.cc on powerpc-apple-darwin9

[dje at gcc dot gnu dot org]

--- Comment #4 from dje at gcc dot gnu dot org  2008-04-03 00:33 ---
Subject: Bug 35801

Author: dje
Date: Thu Apr  3 00:33:05 2008
New Revision: 133855

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133855
Log:
2008-04-03  Dominique d'Humieres <[EMAIL PROTECTED]>

PR target/35801
* config/rs6000/rs6000.c (rs6000_output_mi_thunk): Free cfun.

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


-- 


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

[Bug ada/35284] Branch to 0x0 from Ada run-time

[joel at gcc dot gnu dot org]

--- Comment #32 from joel at gcc dot gnu dot org  2008-04-03 00:14 ---
Created an attachment (id=15417)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15417&action=view)
Correct structure bindings

pthread_condattr_t was missing a field.

sched_param had an incorrect type.


-- 


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

[Bug bootstrap/35804] Bootstrap of combined gcc + binutils, with --enable-shared, with sysroot fails

[oblivian at users dot sourceforge dot net]

--- Comment #4 from oblivian at users dot sourceforge dot net  2008-04-03 
00:12 ---
(In reply to comment #1)
> Sounds like you should be using --build-sysroot= and not set 
> LDFLAGS_FOR_TARGET
> and CPPFLAGS_FOR_TARGET .
> 

I pulled the compiler command that failed, and ran it with -v. I took that
command and  ran it with the current stage ld.
Here is what GCC tries to run when linking libgcc_s.so.1.tmp
--
/media/disk/build/scripts/tools/toolchain-pass-1/build/./ld/ld-new
--sysroot=/tools --eh-frame-hdr -m elf_i386 -shared -o ./libgcc_s.so.1.tmp
/tools/usr/lib/crti.o
/media/disk/build/scripts/tools/toolchain-pass-1/build/./gcc/crtbeginS.o
-L/media/disk/build/scripts/tools/toolchain-pass-1/build/./ld
-L/media/disk/build/scripts/tools/toolchain-pass-1/build/./gcc -L. -L/tools/lib
-L/tools/usr/lib --soname=libgcc_s.so.1 --version-script=libgcc.map _muldi3_s.o
_negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o
_clear_cache_s.o _enable_execute_stack_s.o _trampoline_s.o __main_s.o
_absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o
_mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o
_ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o
_popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o
_paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o
_muldc3_s.o _mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o
_divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o
_fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixtfdi_s.o
_fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _fixunstfdi_s.o _floatdisf_s.o
_floatdidf_s.o _floatdixf_s.o _floatditf_s.o _floatundisf_s.o _floatundidf_s.o
_floatundixf_s.o _floatunditf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o
_umoddi3_s.o _udiv_w_sdiv_s.o _udivmoddi4_s.o unwind-dw2_s.o
unwind-dw2-fde-glibc_s.o unwind-sjlj_s.o gthr-gnat_s.o unwind-c_s.o emutls_s.o
-lc /media/disk/build/scripts/tools/toolchain-pass-1/build/./gcc/crtendS.o
/tools/usr/lib/crtn.o
---
The error is...
---
/media/disk/build/scripts/tools/toolchain-pass-1/build/gcc/../ld/ld-new: cannot
find /tools/lib/libc.so.6 inside /tools

Now if I run the same command and take the /tools prefix off of the -L flags
for -L/tools/lib and -L/tools/usr/lib the library will link and running:

ldd libgcc_s.so.1.tmp 
linux-gate.so.1 =>  (0xb7fce000)
libc.so.6 => /tools/lib/libc.so.6 (0xb7e9)
/tools/lib/ld-linux.so.2 (0xb7fcf000)

So it seems that gcc should strip sysroot from the library paths if it is
calling a sysrooted ld, but should not if ld does not support sysroot.  Even
though the ld gets search directories without the sysroot prefix it is linking
against the correct target libraries.  For example, I can remove the --sysroot
from the first command above and run it with my host ld which doesn't support
sysroot (it's version 2.17 compiled the old way), and it will link the library
correctly and produce a ldd output the same as above pointing to the correct
locations.

Not sure where to go from here.

Also ran across a potential problem in binutils with elf32.em which does not
take into account sysroot correctly for the ld.so.conf path.  The use_sysroot
flag is passed to the script, but it needs to use TARGET_SYSTEM_ROOT not prefix
to point to the correct sysroot /etc/ld.so.conf.  For example my prefix for ld
configuration is /tools/usr whereas the sysroot is /tools.  elf32.em will look
for it in /tools/usr/etc/ld.so.conf even though glibc installed it in
/tools/etc.


-- 


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

[Bug ada/35284] Branch to 0x0 from Ada run-time

[joel at gcc dot gnu dot org]

--- Comment #31 from joel at gcc dot gnu dot org  2008-04-03 00:10 ---

(In reply to comment #30)
> Did you look at what happens in Initialize_TCB to the variable Success ?

After waiting and waiting at the hospital today, I had plenty of time
to think.  My guess was that the saved copy of %ebx on the stack was
getting corrupted.  About an hour of playing on my laptop, I found the
culprit!!  

The pthread_condattr_t structure in s-opsinte-rtems.ads was one 4 byte 
integer field too short!!! 

I also noticed a typo in the pthread_attr_t structure.  I have no
idea how this worked on powerpc, sparc, and mips so well and only
failed on i386.  Must just be lucky on the alignment or something
and missed stuff on the stack that mattered.  

Here is the much improved ACATS with this change on i386.  Many appear to
be floating point issues. The last run I sent to the mailing list had
307 failures.

=== acats Summary ===
# of expected passes2286
# of unexpected failures26
# of unsupported tests  3
*** FAILURES: c34014h c52103q c52104k c64005c c64005d c953002 cd1009w cd5011e
cxg2002 cxg2003 cxg2004 cxg2006 cxg2007 cxg2010 cxg2011 cxg2012 cxg2013 cxg2014
cxg2015 cxg2016 cxg2017 cxg2018 cxg2019 cxg2020 cxg2021 la14012

I will run overnight and file more test results on the mailing list. 
Patch will be attached in a minute.  


-- 


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

[Bug middle-end/35800] [4.4 Regression]: Revision 133835 failed to compile binutils

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||build, ice-on-valid-code
   Target Milestone|--- |4.4.0


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

[Bug middle-end/35808] In function 'inflateBack': ../../gcc/zlib/infback.c:612: internal compiler error: Segmentation fault

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-04-02 23:41 ---


*** This bug has been marked as a duplicate of 35800 ***

*** This bug has been marked as a duplicate of 35800 ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug middle-end/35800] [4.4 Regression]: Revision 133835 failed to compile binutils

[pinskia at gcc dot gnu dot org]

--- Comment #15 from pinskia at gcc dot gnu dot org  2008-04-02 23:41 
---
*** Bug 35808 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu dot
   ||org


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

[Bug middle-end/35808] In function 'inflateBack': ../../gcc/zlib/infback.c:612: internal compiler error: Segmentation fault

[danglin at gcc dot gnu dot org]

--- Comment #1 from danglin at gcc dot gnu dot org  2008-04-02 23:41 ---
[EMAIL PROTECTED]:~/gnu/gcc/objdir/prev-gcc$ ./xgcc -B./ -v
Reading specs from ./specs
Target: hppa-linux
Configured with: ../gcc/configure --with-gnu-as --with-gnu-ld --enable-shared
--prefix=/home/dave/opt/gnu/gcc/gcc-4.4.0
--with-local-prefix=/home/dave/opt/gnu --enable-threads=posix
--enable-__cxa_atexit --build=hppa-linux --enable-clocale=gnu
--enable-java-gc=boehm --enable-java-awt=xlib
--enable-languages=c,c++,objc,fortran,obj-c++,java
Thread model: posix
gcc version 4.4.0 20080402 (experimental) [trunk revision 133848] (GCC) 

This didn't happen with revision 133813 on hppa2.0w-hp-hpux11.11.


-- 


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

[Bug middle-end/35808] New: In function 'inflateBack': ../../gcc/zlib/infback.c:612: internal compiler error: Segmentation fault

[danglin at gcc dot gnu dot org]

/home/dave/gnu/gcc/objdir/./prev-gcc/xgcc
-B/home/dave/gnu/gcc/objdir/./prev-gcc
/ -B/home/dave/opt/gnu/gcc/gcc-4.4.0/hppa-linux/bin/ -DPACKAGE_NAME=\"\"
-DPACKA
GE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\"
-DPACKAGE_BUGREPORT
=\"\" -DPACKAGE=\"zlib\" -DVERSION=\"1.1.4\" -DSTDC_HEADERS=1
-DHAVE_SYS_TYPES_H
=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1
-DH
AVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1
-DHAVE_D
LFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_STDLIB_H=1 -DHAVE_UNISTD_H=1
-DHAVE_GETPA
GESIZE=1 -DHAVE_MMAP=1 -DHAVE_MEMCPY=1 -DHAVE_STRERROR=1 -DHAVE_UNISTD_H=1  -I. 
-I../../gcc/zlib -g -O2 -c -o libz_a-infback.o `test -f 'infback.c' || echo 
'../../gcc/zlib/'`infback.c
../../gcc/zlib/infback.c: In function 'inflateBack':
../../gcc/zlib/infback.c:612: internal compiler error: Segmentation fault

(gdb) r
Starting program: /home/dave/gnu/gcc-4.4/objdir/prev-gcc/cc1 -I.
-I../../gcc/zlib -iprefix
/home/dave/gnu/gcc-4.4/objdir/prev-gcc/../lib/gcc/hppa-linux/4.4.0/ -isystem
/home/dave/gnu/gcc-4.4/objdir/./prev-gcc/include -isystem
/home/dave/gnu/gcc-4.4/objdir/./prev-gcc/include-fixed -DPACKAGE_NAME=""
-DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" -DPACKAGE_STRING=""
-DPACKAGE_BUGREPORT="" -DPACKAGE="zlib" -DVERSION="1.1.4" -DSTDC_HEADERS=1
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
-DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1
-DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=".libs/" -DHAVE_STDLIB_H=1
-DHAVE_UNISTD_H=1 -DHAVE_GETPAGESIZE=1 -DHAVE_MMAP=1 -DHAVE_MEMCPY=1
-DHAVE_STRERROR=1 -DHAVE_UNISTD_H=1 ../../gcc/zlib/infback.c -dumpbase
infback.c -auxbase-strip libz_a-infback.o -g -O2 -version -o xxx.s
GNU C (GCC) version 4.4.0 20080402 (experimental) [trunk revision 133849]
(hppa-linux)
compiled by GNU C version 4.1.1, GMP version 4.2.2, MPFR version 2.3.1.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
options passed:  -I. -I../../gcc/zlib -iprefix
 /home/dave/gnu/gcc-4.4/objdir/prev-gcc/../lib/gcc/hppa-linux/4.4.0/
 -isystem /home/dave/gnu/gcc-4.4/objdir/./prev-gcc/include -isystem
 /home/dave/gnu/gcc-4.4/objdir/./prev-gcc/include-fixed -DPACKAGE_NAME=
 -DPACKAGE_TARNAME= -DPACKAGE_VERSION= -DPACKAGE_STRING=
 -DPACKAGE_BUGREPORT= -DPACKAGE=zlib -DVERSION=1.1.4 -DSTDC_HEADERS=1
 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=.libs/
 -DHAVE_STDLIB_H=1 -DHAVE_UNISTD_H=1 -DHAVE_GETPAGESIZE=1 -DHAVE_MMAP=1
 -DHAVE_MEMCPY=1 -DHAVE_STRERROR=1 -DHAVE_UNISTD_H=1
 ../../gcc/zlib/infback.c -auxbase-strip libz_a-infback.o -g -O2
options enabled:  -falign-functions -falign-jumps -falign-labels
 -fargument-alias -fauto-inc-dec -fbranch-count-reg -fcaller-saves -fcommon
 -fcprop-registers -fcrossjumping -fcse-follow-jumps -fdefer-pop
 -fdelayed-branch -fdelete-null-pointer-checks -fearly-inlining
 -feliminate-unused-debug-types -fexpensive-optimizations
 -fforward-propagate -ffunction-cse -fgcse -fgcse-lm
 -fguess-branch-probability -fident -fif-conversion -fif-conversion2
 -finline-functions-called-once -finline-small-functions -fipa-pure-const
 -fipa-reference -fivopts -fkeep-static-consts -fleading-underscore
 -fmath-errno -fmerge-constants -fmerge-debug-strings
 -fmove-loop-invariants -fomit-frame-pointer -foptimize-register-move
 -foptimize-sibling-calls -fpeephole -fpeephole2 -freg-struct-return
 -fregmove -freorder-blocks -freorder-functions -frerun-cse-after-loop
 -fsched-interblock -fsched-spec -fsched-stalled-insns-dep -fschedule-insns
 -fschedule-insns2 -fsigned-zeros -fsplit-ivs-in-unroller
 -fsplit-wide-types -fstrict-aliasing -fstrict-overflow -fthread-jumps
 -ftoplevel-reorder -ftrapping-math -ftree-ccp -ftree-ch -ftree-copy-prop
 -ftree-copyrename -ftree-cselim -ftree-dce -ftree-dominator-opts
 -ftree-dse -ftree-fre -ftree-loop-im -ftree-loop-ivcanon
 -ftree-loop-optimize -ftree-parallelize-loops= -ftree-pre -ftree-reassoc
 -ftree-salias -ftree-scev-cprop -ftree-sink -ftree-sra -ftree-store-ccp
 -ftree-ter -ftree-vect-loop-version -ftree-vrp -funit-at-a-time
 -fvar-tracking -fzero-initialized-in-bss -mbig-switch -mgas -mglibc
 -mno-space-regs
Compiler executable checksum: 3c5287d1a0783206676a1bdc69e55e6b
 __strcspn_c1 __strcspn_c2 __strcspn_c3 __strspn_c1 __strspn_c2 __strspn_c3
__strpbrk_c2 __strpbrk_c3 __strtok_r_1c __strsep_1c __strsep_2c __strsep_3c
atof atoi atol atoll gnu_dev_major gnu_dev_minor gnu_dev_makedev
inflateBackInit_ fixedtables inflateBack inflateBackEnd
Analyzing compilation unit
Performing interprocedural optimizations

Assembling functions:
 inflateBackInit_ inflateBackEnd in

[Bug target/35807] Compiler makes use of [std Y+1, rX] instruction without initializing r28,r29

[ruud at betaresearch dot nl]

--- Comment #3 from ruud at betaresearch dot nl  2008-04-02 22:57 ---
(In reply to comment #2)
> From  Andy H <[EMAIL PROTECTED]>
> [avr-gcc-list] Incorrect code by gcc?
> 
> Not a bug

OK, I changed the status to INVALID.

Ruud


-- 


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

[Bug target/35807] Compiler makes use of [std Y+1, rX] instruction without initializing r28,r29

[ruud at betaresearch dot nl]

--- Comment #2 from ruud at betaresearch dot nl  2008-04-02 22:39 ---
>From  Andy H <[EMAIL PROTECTED]>
[avr-gcc-list] Incorrect code by gcc?

Not a bug

According to the sources you posted,

privQueuRequestBody

void privQueuRequestBody(uint8_t uiSlot, int8_t siFreeFilling, uint16_t
uiTicksToWait) __attribute__ ( ( naked ) );

The relevant part being "naked"

That means gcc will omit prolog - which is where stack and frame pointer are
setup.
R28/29 is the frame pointer. What you see in assembler is gcc saving the
register around a call. Depending on optimization, it may choose to do this
rather than use a register (as the register would need to be saved on the
stack).

If you use naked, you must replace all of prolog/epilog by hand. (its normal
use is for assembler only functions)


Andy


-- 

ruud at betaresearch dot nl changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug target/35807] Compiler makes use of [std Y+1, rX] instruction without initializing r28,r29

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|major   |normal


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

[Bug target/35807] Compiler makes use of [std Y+1, rX] instruction without initializing r28,r29

[ruud at betaresearch dot nl]

--- Comment #1 from ruud at betaresearch dot nl  2008-04-02 22:28 ---
Other versions of gcc (like 4.2.1 or 4.3.0) display the
same behavior, but not on the same testcase. A separate
testcase can be made for each version if needed.

Since i cannot attach a zip file, and i don't know how otherwise to attach the
information needed to reproduce (you need all .i files and must link in order
to see the effect). please use link to download the example.


-- 

ruud at betaresearch dot nl changed:

   What|Removed |Added

  Known to fail||4.2.1 4.3.0


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

[Bug target/35807] New: Compiler makes use of [std Y+1, rX] instruction without initializing r28,r29

[ruud at betaresearch dot nl]

When developing an OS for the smallest Atmels (ATtiny861/461/21)
i observed a strange effect. Sometimes, depending on the optimization
choosen by gcc, the compiler generates code which cannot be correct
(in my  view). Most of the time the code is not functional too.

The problem is that use of the instructions "std Y+1,rX" and
"ldd rX,Y+1" is made, but that de corresponding registers are
never properly initialized. The result is that the value is
stored somewhere in RAM or is retrieved from that (random?)
place. That may or may not hurt, but it seems wrong anyhow.

Below you can see an piece of code generated by GCC (v4.2.3)
 78c:   99 83   std Y+1, r25; 0x01
 78e:   46 de   rcall   .-884   ; 0x41c 
 790:   99 81   ldd r25, Y+1; 0x01
(From the methode below)
The point is nowhere in that method the registers r28 and r29 are used
neither are they set in the called methods. (see below)

In practice this effect indeed results in non functional code
which can most of the time be easily circumvented by inlining
some methods or hooking some variables up to fixed registers.
GCC is then forced to alter the output somewhat and often
the error disappears.

BTW, it seems that the compiler actually meant to do something
like this:
 78c:   79 2e   mov r7, r25 ; 0x01
 78e:   46 de   rcall   .-884   ; 0x41c 
 790:   97 2d   mov r25, r7 ; 0x01
where r7 can be any free register, since if you substitute
that (in the raw hex file for example) the code turns fully
functional.

I have observed the effect also at GCC 4.2.1 and GCC 4.3.0,
although beit not with exactly the same code. The effect is
reproducible, but depends critically on the choose optimizations
and structure of the code. These are my compiler options

avr-gcc -c -save-temps -mmcu=attiny861 -mint8 -Wall -Wno-main \
  -Winline -Wundef -gdwarf-2 -Os -funsigned-char -fomit-frame-pointer \
  -fpack-struct -fshort-enums 

OK, it would take to much space to include enough details here
for you to be able to reproduce the problem. I made a zip which
can be downloaded from:
  http://www.femtoos.org/gcc_effect.zip
which should make this possible. (includes source code, and a
compiler script, you need avr-gcc 4.2.3 on your system, other
versions will no reproduce the error in this particular example)

regards,
Ruud

074e :
 74e:   08 2fmov r16, r24
 750:   c6 2emov r12, r22
 752:   7a 01movwr14, r20
 754:   0d dercall   .-998  ; 0x370 
 756:   fb ddrcall   .-1034 ; 0x34e 
 758:   5c 01movwr10, r24
 75a:   6c 2dmov r22, r12
 75c:   80 2fmov r24, r16
 75e:   09 ddrcall   .-1518 ; 0x172 
 760:   98 2fmov r25, r24
 762:   1c 14cp  r1, r12
 764:   24 f4brge.+8; 0x76e 
 766:   8c 15cp  r24, r12
 768:   08 f4brcc.+2; 0x76c 
 76a:   57 c0rjmp.+174  ; 0x81a 
 76c:   07 c0rjmp.+14   ; 0x77c 
 76e:   cc 20and r12, r12
 770:   29 f0breq.+10 ; 0x77c 
 772:   8c 2dmov r24, r12
 774:   81 95neg r24
 776:   98 17cp  r25, r24
 778:   08 f4brcc.+2; 0x77c 
 77a:   4f c0rjmp.+158  ; 0x81a 
 77c:   90 e0ldi r25, 0x00  ; 0
 77e:   10 2fmov r17, r16
 780:   1f 70andir17, 0x0F  ; 15
 782:   f0 e8ldi r31, 0x80  ; 128
 784:   df 2emov r13, r31
 786:   d1 2aor  r13, r17
 788:   6d 2dmov r22, r13
 78a:   89 2fmov r24, r25
 78c:   99 83std Y+1, r25   ; 0x01
 78e:   46 dercall   .-884  ; 0x41c 
 790:   99 81ldd r25, Y+1   ; 0x01
 792:   88 23and r24, r24
 794:   31 f0breq.+12   ; 0x7a2 
 796:   07 ffsbrsr16, 7
 798:   40 c0rjmp.+128  ; 0x81a 
 79a:   60 2fmov r22, r16
 79c:   89 2fmov r24, r25
 79e:   26 dercall   .-948  ; 0x3ec 
 7a0:   3c c0rjmp.+120  ; 0x81a 
 7a2:   9f 5fsubir25, 0xFF  ; 255
 7a4:   93 30cpi r25, 0x03  ; 3
 7a6:   09 f4brne.+2; 0x7aa 
 7a8:   77 c0rjmp.+238  ; 0x898 
 7aa:   ee cfrjmp.-36   ; 0x788 
 7ac:   f6 01movwr30, r12
 7ae:   81 81ldd r24, Z+1   ; 0x01
 7b0:   8f 7dandir24, 0xDF  ; 223
 7b2:   81 83std Z+1, r24   ; 0x01
 7b4:   e1 14cp  r14, r1
 7b6:   f1 04cpc r15, r1
 7b8:   49 f1breq.+82   ; 0x80c 
 7ba:   bd ddrcall   .-1158 ; 0x336 
 7bc:   c8 ddrcall   .-1136 ; 0x34e 
 7be:   8c 01movwr16, r24
 7c0:   f0 e0ldi r31, 0x00  ; 0
 7c2:   ef 16cp  r14, r31
 7c4:   ff efldi r31, 0xFF  ; 255
 7c6:   

[Bug rtl-optimization/33642] unrecognizable insn for -frtl-abstract-sequences

[janis at gcc dot gnu dot org]

--- Comment #17 from janis at gcc dot gnu dot org  2008-04-02 22:11 ---
I tried the patch referenced in comment #16 on powerpc64-linux.  It allows
tests pr11832.c and pr33009 to pass, but adding -frtl-abstract-sequences to all
tests causes several tests to timeout on compilation, and gcc.dg/pr32912-1.c
fails at execution for -m32.  I built the C tests from SPEC CPU2000 with "-O2
-frtl-abstract-sequences" using the patched compiler and ran them with the
short test input.  A couple took a very long time to compile (try, for example,
the file toke.c in test perlbmk) and four failed at execution time: vpr and
crafty for -m32, gcc and gap for -m64.


-- 


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

[Bug middle-end/35800] [4.4 Regression]: Revision 133835 failed to compile binutils

[rguenth at gcc dot gnu dot org]

--- Comment #14 from rguenth at gcc dot gnu dot org  2008-04-02 22:10 
---
The fallback_label parm of try_casesi needs ATTRIBUTE_UNUSED for ! HAVE_casesi
targets.


-- 


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

[Bug middle-end/35800] [4.4 Regression]: Revision 133835 failed to compile binutils

[rguenth at gcc dot gnu dot org]

--- Comment #13 from rguenth at gcc dot gnu dot org  2008-04-02 22:07 
---
Created an attachment (id=15416)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15416&action=view)
patch

Patch in comment #10 passed bootstrap & regtest on x86_64-unknown-linux-gnu,
the
attached patch should also fix comment #7, testing is in progess.  If anyone
beats me on it the patch is ok for trunk.


-- 


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

[Bug driver/35532] Native GCC no longer searches $prefix/lib for startfiles when run from $objdir

[carlos at codesourcery dot com]

--- Comment #14 from carlos at codesourcery dot com  2008-04-02 21:52 
---
Using the sysroot flags is the solution for Greg's scenario. In fact I would
say it makes his job easier.

I'm looking for a test case that doesn't mangle GCC's configure files, and is
broken with no easy alternative.

Do we have one?


-- 


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

[Bug middle-end/35800] [4.4 Regression]: Revision 133835 failed to compile binutils

[hp at gcc dot gnu dot org]

--- Comment #12 from hp at gcc dot gnu dot org  2008-04-02 21:43 ---
In reply to comment #10)
> relies on the created hole be filled by the default_label - but that is
> NULL here.  So, the following looks like the right fix here:
> 
> Index: stmt.c

That's too late; it's not enough for casesi targets for the reason I outline in
comment #7.


-- 


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

[Bug target/35806] Object code is bigger at -Os than at -O2

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-04-02 21:18 ---
This is because we don't run PRE at -Os, as PRE usually increases code-size.


-- 


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

[Bug middle-end/35800] [4.4 Regression]: Revision 133835 failed to compile binutils

[rguenth at gcc dot gnu dot org]

--- Comment #11 from rguenth at gcc dot gnu dot org  2008-04-02 20:56 
---
For now I have a compile-time testcase - I'll try to transform it into a
runtime one.


-- 


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

[Bug middle-end/35800] [4.4 Regression]: Revision 133835 failed to compile binutils

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2008-04-02 20:50 
---
Ah, the following

  /* Index jumptables from zero for suitable values of
 minval to avoid a subtraction.  */
  if (! optimize_size
  && compare_tree_int (minval, 0) > 0
  && compare_tree_int (minval, 3) < 0)
{
  minval = build_int_cst (index_type, 0);
  range = maxval;
}

relies on the created hole be filled by the default_label - but that is
NULL here.  So, the following looks like the right fix here:

Index: stmt.c
===
--- stmt.c  (revision 133848)
+++ stmt.c  (working copy)
@@ -2566,11 +2566,15 @@ expand_case (tree exp)
  = gen_rtx_LABEL_REF (Pmode, label_rtx (n->code_label));
}

- /* Fill in the gaps with the default.  */
- if (default_label)
-   for (i = 0; i < ncases; i++)
- if (labelvec[i] == 0)
-   labelvec[i] = gen_rtx_LABEL_REF (Pmode, default_label);
+ /* Fill in the gaps with the default.  We may have gaps at
+the beginning if we tried to avoid the minval subtraction,
+so substitute some label even if the default label was
+deemed unreachable.  */
+ if (!default_label)
+   default_label = label_rtx (case_list->code_label);
+ for (i = 0; i < ncases; i++)
+   if (labelvec[i] == 0)
+ labelvec[i] = gen_rtx_LABEL_REF (Pmode, default_label);

  /* Output the table.  */
  emit_label (table_label);


-- 


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

[Bug driver/35532] Native GCC no longer searches $prefix/lib for startfiles when run from $objdir

[bonzini at gnu dot org]

--- Comment #13 from bonzini at gnu dot org  2008-04-02 20:27 ---
Subject: Re:  Native GCC no longer searches $prefix/lib for startfiles when run
from $objdir

>  What's the test-case?

I'm talking of Greg's setting.


-- 


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

[Bug middle-end/35800] [4.4 Regression]: Revision 133835 failed to compile binutils

[hjl dot tools at gmail dot com]

--- Comment #9 from hjl dot tools at gmail dot com  2008-04-02 20:23 ---
(In reply to comment #8)
> Hm, yeah.  The trick of course is to not emit the jump to the default label. 
> For
> the tablejump case it may be easiest to just use any other label.  I'll see if
> that works.
> 

Can we add a run-time testcase to make sure that the result is correct?


-- 


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

[Bug middle-end/35800] [4.4 Regression]: Revision 133835 failed to compile binutils

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2008-04-02 20:17 ---
Hm, yeah.  The trick of course is to not emit the jump to the default label. 
For
the tablejump case it may be easiest to just use any other label.  I'll see if
that works.


-- 


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

[Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |blocker


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

[Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2008-04-02 20:01 ---
spu-elf also fails the same way.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  GCC build triplet|hppa2.0w-hp-hpux11.11   |
   GCC host triplet|hppa2.0w-hp-hpux11.11   |
 GCC target triplet|hppa2.0w-hp-hpux11.11   |hppa2.0w-hp-hpux11.11, spu-
   ||elf


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

[Bug middle-end/35800] [4.4 Regression]: Revision 133835 failed to compile binutils

[hp at gcc dot gnu dot org]

--- Comment #7 from hp at gcc dot gnu dot org  2008-04-02 19:56 ---
It's not just about creating a properly filled (or handling the NULLs in the)
addr_vec after generating the tablejump or casesi: for machines with casesi,
passing a NULL default_label (operand[4]; fifth operand) is...unexpected. 
While this could be pushed from the middle-end to the target domain by defining
the NULL default label as a valid case that the target casesi pattern must
handle (hard to do without casesi being a define_expand), I think it'd be
better to just pass any label as default_label any at the try_casesi call.

Here's a related minor optimization opportunity for casesi: if default_label is
set to the last case label, the max index / the range and the table size, can
be shrunk by one.


-- 


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

[Bug driver/35532] Native GCC no longer searches $prefix/lib for startfiles when run from $objdir

[carlos at codesourcery dot com]

--- Comment #12 from carlos at codesourcery dot com  2008-04-02 19:20 
---
Paolo,

What's the test-case?


-- 


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

[Bug c++/35741] [4.2/4.3/4.4 regression] ICE with offsetof and references

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-03-30 20:54:22 |2008-04-02 19:03:11
   date||


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

[Bug c++/33878] Pure virtual method body omitted from template

[bangerth at math dot tamu dot edu]

--- Comment #18 from bangerth at math dot tamu dot edu  2008-04-02 18:34 
---
Subject: Re:  Pure virtual method body omitted from template


> You are absolutely right as long as there is no multithreading and no
> dangling pointer. Sure. The thing is: If it's called, something bad has
> occured

I see your point, but in a case like this you are working outside what the 
standard says (it would call the program erroneous and its 
actions 'undefined'). The compiler's job being to translate what the standard 
describes, you can't rely on any such behavior.


> * For templates the method is not generated, and we've discussed why. It's
> due to the template function emission rules: Not called, not emitted. But
> there is also the shortcut rule when deriving: Cannot be called, not
> emitted. That is what you explained. Thus here you have no choice.

You can instantiate explicitly if you want this.

By the way, there is also a rule somewhere in the standard that says that only 
those templates must be instantiated that are actually needed; in other 
words, the compiler cannot instantiate more functions just because someone 
may want it to be there -- the functions must actually be *needed* for the 
program to work correctly.

W.

-
Wolfgang Bangerthemail:[EMAIL PROTECTED]
 www: http://www.math.tamu.edu/~bangerth/


-- 


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

[Bug tree-optimization/35805] [ira] error in start_allocno_priorities, at ira-color.c:1806

[vmakarov at redhat dot com]

--- Comment #1 from vmakarov at redhat dot com  2008-04-02 18:34 ---
I've just fixed it on ira branch.  The problem was in an assert requiring
nonzero number of references for an allocno.  I permitted to have zero number
of references.

I've just realized that such situations are possible in a region but something
is wrong with this particular case.  The pseudo-register 69 lives at the
start/end of each basic block there is no such pseduo-register in RTL.  It is
removed in ce2.  Either the live info was not updated or something wrong with
the updating itself.

Therefore I am not closing IRA and I am adding Ken to the list.  I think the
problem can be reproduced on the mainline because I've merged the trunk into
the branch recently.


-- 

vmakarov at redhat dot com changed:

   What|Removed |Added

 CC||Kenneth dot Zadeck at
   ||NaturalBridge dot com


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

[Bug target/35801] [4.4 Regression]: At revision 133817, bootstrap fails at libstdc++-v3/src/strstream.cc on powerpc-apple-darwin9

[dominiq at lps dot ens dot fr]

--- Comment #3 from dominiq at lps dot ens dot fr  2008-04-02 18:32 ---
Borrowed from pr35795, the following patch seems to work:

--- ../_gcc_clean/gcc/config/rs6000/rs6000.c2008-03-29 23:59:15.0
+0100
+++ ../gcc-4.4-work/gcc/config/rs6000/rs6000.c  2008-04-02 20:03:18.0
+0200
@@ -17124,6 +17124,7 @@
   final_start_function (insn, file, 1);
   final (insn, file, 1);
   final_end_function ();
+  free_after_compilation (cfun);

   reload_completed = 0;
   epilogue_completed = 0;

(now building libgfortran).


-- 


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

[Bug c++/33878] Pure virtual method body omitted from template

[bangerth at math dot tamu dot edu]

--- Comment #17 from bangerth at math dot tamu dot edu  2008-04-02 18:31 
---
Subject: Re:  Pure virtual method body omitted from template


On Wednesday 02 April 2008 12:15:53 yuriry at gmail dot com wrote:
> My question is slightly off topic but I am really interested in the purpose
> of defining a template class where a template parameter is not used.  Why
> would you need this?

The class in this example is a stripped-down version for the purpose of 
exposition. In practice, of course, most of the time one would use the 
template argument somehow.

W.

-
Wolfgang Bangerthemail:[EMAIL PROTECTED]
 www: http://www.math.tamu.edu/~bangerth/


-- 


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

[Bug middle-end/35800] [4.4 Regression]: Revision 133835 failed to compile binutils

[hp at gcc dot gnu dot org]

--- Comment #6 from hp at gcc dot gnu dot org  2008-04-02 18:06 ---
Created an attachment (id=15415)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15415&action=view)
another reduced testcase, -O2

I see attachment #2 there, but as long as I did a reduction too, here's
another, a wee bit smaller and no extra warnings at -W -Wall -Wextra. This
fails at -O2 both for native x86_64 as well as cris-elf, just like the original
stabs.i testcase.  FWIW, the same bug causes failure to build
newlib/libc/stdlib/dtoa.c for cris-elf, but that .i doesn't trig the bug for
x86_64.


-- 


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

[Bug c++/33878] Pure virtual method body omitted from template

[yuriry at gmail dot com]

--- Comment #16 from yuriry at gmail dot com  2008-04-02 17:58 ---
Thanks for the reply, David!  But now I have more questions than I had before
:-)

I'm not sure if this thread is the right place to go into details on this
topic.  If you know any other place to move this discussion, please let me
know.

What do you mean by "different flavors that are incompatible with each other"?
Could you tell a little more about "accidental cross-contamination"?

Giving a short example for each question would help a lot :-)

Thanks in advance,
Yuri


-- 


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

[Bug target/35795] [4.4 Regression] Revision 133787 breaks ia64

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|tree-optimization   |target
   Target Milestone|--- |4.4.0


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

[Bug bootstrap/35804] Bootstrap of combined gcc + binutils, with --enable-shared, with sysroot fails

[joseph at codesourcery dot com]

--- Comment #3 from joseph at codesourcery dot com  2008-04-02 17:52 ---
Subject: Re:  Bootstrap of combined gcc + binutils, with
 --enable-shared, with sysroot fails

On Wed, 2 Apr 2008, pinskia at gcc dot gnu dot org wrote:

> Sounds like you should be using --build-sysroot= and not set 
> LDFLAGS_FOR_TARGET
> and CPPFLAGS_FOR_TARGET .

My experience is that you do need to set LDFLAGS_FOR_TARGET and 
CPPFLAGS_FOR_TARGET to include the --sysroot option if you're configuring 
with a build sysroot.  (This is a bug: --with-build-sysroot should cause 
the right --sysroot option to be used automatically when compiling and 
linking runtime libraries.)


-- 


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

[Bug tree-optimization/35806] New: Object code is bigger at -Os than at -O2

[mstein dot lists at googlemail dot com]

Hi,
the code below compiles to 60 byte when using -Os
and 4 byte when using -O2.

This is just one example of many from the test suite: 

extern void f(char *const *);
void g (char **o)
{
  static const char *const multilib_exclusions_raw[] = { 0 };
  const char *const *q = multilib_exclusions_raw;

  f (o);
  while (*q++)
f (o);
}


-- 
   Summary: Object code is bigger at -Os than at -O2
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mstein dot lists at googlemail dot com
GCC target triplet: arm-elf


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

[Bug bootstrap/35216] Out of memory building java

[pogma at gcc dot gnu dot org]

--- Comment #3 from pogma at gcc dot gnu dot org  2008-04-02 17:44 ---
Fixed in r133842


-- 

pogma at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug c++/33878] Pure virtual method body omitted from template

[fang at csl dot cornell dot edu]

--- Comment #15 from fang at csl dot cornell dot edu  2008-04-02 17:38 
---
Unused template parameters can be used when you want to intentionally subtype a
base type with different flavors that are incompatible with each other, using
compile-time checking to prevent accidental cross-contamination, for instance.  


-- 


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

[Bug bootstrap/35216] Out of memory building java

[pogma at gcc dot gnu dot org]

--- Comment #2 from pogma at gcc dot gnu dot org  2008-04-02 17:37 ---
Subject: Bug 35216

Author: pogma
Date: Wed Apr  2 17:36:41 2008
New Revision: 133842

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133842
Log:
PR bootstrap/35216
* scripts/makemake.tcl: Replace org/omg build with build of all its
subpackages.
* sources.am: Regenerate.
* Makefile.in: Regenerate.


Modified:
trunk/libjava/ChangeLog
trunk/libjava/Makefile.in
trunk/libjava/scripts/makemake.tcl
trunk/libjava/sources.am


-- 


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

[Bug c++/35741] [4.2/4.3/4.4 regression] ICE with offsetof and references

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2008-04-02 17:17 ---
IMNSHO this is invalid.
[lib.support.types]/5 says the first argument must be a POD structure or POD
union, but struct A isn't POD structure because of the reference in it.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |ice-on-invalid-code


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

[Bug c++/33878] Pure virtual method body omitted from template

[yuriry at gmail dot com]

--- Comment #14 from yuriry at gmail dot com  2008-04-02 17:15 ---
Hi Björn

My question is slightly off topic but I am really interested in the purpose of
defining a template class where a template parameter is not used.  Why would
you need this?

Regards,
Yuri

template
class TBase
{
public:
~TBase();
virtual void pvMethod() = 0;
};


-- 


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

[Bug target/35735] error in default_secondary_reload, at targhooks.c:649

[mstein dot lists at googlemail dot com]

--- Comment #2 from mstein dot lists at googlemail dot com  2008-04-02 
17:02 ---
Seems to work again in rev 133774


-- 

mstein dot lists at googlemail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME


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

[Bug target/35664] unable to find a register to spill in class 'FP_REGS' (sparc-linux)

[mstein dot lists at googlemail dot com]

--- Comment #2 from mstein dot lists at googlemail dot com  2008-04-02 
16:55 ---
Fails in trunk (133803) too


-- 

mstein dot lists at googlemail dot com changed:

   What|Removed |Added

 CC||davem at redhat dot com,
   ||jakub at redhat dot com


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

[Bug tree-optimization/35805] New: [ira] error in start_allocno_priorities, at ira-color.c:1806

[mstein dot lists at googlemail dot com]

Hi,
gcc  930523-1.c -c -fira -O1 -m32
fails with
930523-1.c: In function 'f':
930523-1.c:54: internal compiler error: in start_allocno_priorities, at
ira-color.c:1806
Please submit a full bug report,

rev: 133765


-- 
   Summary: [ira] error in start_allocno_priorities, at ira-
color.c:1806
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mstein dot lists at googlemail dot com
GCC target triplet: i386


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

[Bug ada/35284] Branch to 0x0 from Ada run-time

[laurent at guerby dot net]

--- Comment #30 from laurent at guerby dot net  2008-04-02 16:44 ---
Did you look at what happens in Initialize_TCB to the variable Success ?


-- 


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

[Bug tree-optimization/35795] [4.4 Regression] Revision 133787 breaks ia64

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2008-04-02 16:42 ---
(In reply to comment #3)
> Subject: Re:   New: [4.4 Regression] Revision 133787 breaks ia64
> 
> Hi,
> I've added the assert to check that we don't initialize RTL world twice
> without freeing it first (and thus that we don't leak memory).  This
> seems to be the case.  Naively, something like this should fix it.
> I am building a cross and will try to reproduce it.
> 
> Index: config/ia64/ia64.c
> ===
> *** config/ia64/ia64.c  (revision 133785)
> --- config/ia64/ia64.c  (working copy)
> *** ia64_output_mi_thunk (FILE *file, tree t
> *** 9694,9699 
> --- 9694,9700 
> final_start_function (insn, file, 1);
> final (insn, file, 1);
> final_end_function ();
> +   free_after_compilation (cfun);
> 
> reload_completed = 0;
> epilogue_completed = 0;
> 

This patch works.


-- 


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

[Bug bootstrap/35804] Bootstrap of combined gcc + binutils, with --enable-shared, with sysroot fails

[oblivian at users dot sourceforge dot net]

--- Comment #2 from oblivian at users dot sourceforge dot net  2008-04-02 
16:26 ---
(In reply to comment #1)
> Sounds like you should be using --build-sysroot= and not set 
> LDFLAGS_FOR_TARGET
> and CPPFLAGS_FOR_TARGET .
> 
You mean configure with just --with-build-sysroot and not --with-sysroot and
remove LD/CPP FLAGS_FOR_TARGET from make?


-- 


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

[Bug bootstrap/35804] Bootstrap of combined gcc + binutils, with --enable-shared, with sysroot fails

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-04-02 16:23 ---
Sounds like you should be using --build-sysroot= and not set LDFLAGS_FOR_TARGET
and CPPFLAGS_FOR_TARGET .


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|critical|normal


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

[Bug c/35739] [4.3/4.4 regression] ICE with _Decimal128 and va_list

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2008-04-02 16:20 ---
Heh, I was testing with -m32 and -m64 on 4.3 branch (but that was
--enable-checking=release default) and on the trunk just -m64.  Can reproduce
now.

This seems to be NRV that is creating non-GIMPLE by replacing GIMPLE regs with
 which needs to live in memory.

The following patch cures this, though I'm not sure if it can actually
pessimize code:

--- tree-nrv.c.jj   2008-03-19 14:18:00.0 +0100
+++ tree-nrv.c  2008-04-02 18:11:14.0 +0200
@@ -1,5 +1,5 @@
 /* Language independent return value optimizations
-   Copyright (C) 2004, 2005, 2007 Free Software Foundation, Inc.
+   Copyright (C) 2004, 2005, 2007, 2008 Free Software Foundation, Inc.

 This file is part of GCC.

@@ -115,6 +115,11 @@ tree_nrv (void)
   if (!aggregate_value_p (result, current_function_decl))
 return 0;

+  /* If a GIMPLE type is returned in memory, finalize_nrv_r might create
+ non-GIMPLE.  */
+  if (is_gimple_reg_type (result_type))
+return 0;
+
   /* Look through each block for assignments to the RESULT_DECL.  */
   FOR_EACH_BB (bb)
 {

The idea is that if found var isn't really an aggregate, but gimple reg, then
1) nvr might create non-GIMPLE as say x = x + 32; can be valid, while 
=  + 32; where  is aggregate_value_p and thus
needs_to_live_in_memory is true for it is invalid GIMPLE (without -fmudflap
just no pass verified that) 2) the replacement might tie hands of the RTL
passes - without the nrv replacement it works with pseudos, but with the nrv
replacement
it suddenly needs to be MEM in all the operations on it.


-- 


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

[Bug bootstrap/35804] New: Bootstrap of combined gcc + binutils, with --enable-shared, with sysroot fails

[oblivian at users dot sourceforge dot net]

Hello,

This bug is a continuation from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752 and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35532. It appears that native
retargeting of the compiler is not supported in the 4.3/4.4 series in favor of
the sysroot option.  When trying to build a pass 1 compiler with combined gcc
and binutils in a single directory, sysroot seems to be appending an extra
sysroot prefix in the linker during libgcc linking.

The current build setup I'm trying is to install in order to the sysroot
directory of /tools:

Linux headers
glibc-pass-1 full compile with native toolchain so that crt files exist.
bootstrap gcc+binutils toolchain against new glibc.

I have tried configuring the gcc+binutils toolchain with the following three
sets of options and it still has the same problem:

configue --prefix=/tools/usr \
 --with-sysroot=/tools \
 --with-pic \
 --disable-nls \
 --disable-libmudflap \
 --disable-libssp \
 --enable-languages=c \
 --enable-checking=release \
 --disable-werror \
 --enable-bootstrap

configue --prefix=/tools/usr \
 --with-sysroot=/tools \
 --with-build-sysroot=/tools \
 --with-pic \
 --disable-nls \
 --disable-libmudflap \
 --disable-libssp \
 --enable-languages=c \
 --enable-checking=release \
 --disable-werror \
 --enable-bootstrap

configue --prefix=/usr \
 --with-sysroot=/tools \
 --with-build-sysroot=/tools \
 --with-pic \
 --disable-nls \
 --disable-libmudflap \
 --disable-libssp \
 --enable-languages=c \
 --enable-checking=release \
 --disable-werror \
 --enable-bootstrap

And building with:
LDFLAGS_FOR_TARGET="--sysroot=/tools" CPPFLAGS_FOR_TARGET="--sysroot=/tools"
make

Everything compiles up to stage 1 libgcc which errors out on the final link
command with the linker error of:
/media/disk-3/build/tools/toolchain-pass-1/build/gcc/../ld/ld-new: cannot find
/tools/lib/libc.so.6 inside /tools

Unfortunately, /tools/lib/libc.so.6 exists and if I create a link to /tools
inside of the tools directory (recursive symlink) the link will complete and
continue to stage 2

I'm pretty sure I shouldn't have to create a link to . for this to work
properly .


-- 
   Summary: Bootstrap of combined gcc + binutils, with --enable-
shared, with sysroot fails
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: oblivian at users dot sourceforge dot net
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug c++/33878] Pure virtual method body omitted from template

[herwig at gdsys dot de]

--- Comment #13 from herwig at gdsys dot de  2008-04-02 16:07 ---
(In reply to comment #12)
> The point I meant to make but failed is: a pure virtual method can *only* 
> *ever* be called explicitly. It can't be called through the vtable because 
> there can be no objects of the type of this pure class, only of derived 
> classes, and in the vtables of this derived class the slot for this 
> virtual function is filled by another function (because the derived class, 
> to be instantiated, must have overwritten the pure function).

You are absolutely right as long as there is no multithreading and no dangling
pointer. Sure. The thing is: If it's called, something bad has occured and I
want to catch it let's say for a backtrace at this point. Or I take it
deliberately into account and let it perform a no-op.

When searching for an example, I came across this link:

http://www.artima.com/forums/flat.jsp?forum=226&thread=196881#270009

This post is the exact description of the problem I initially ran into. Even to
proposed solution is part of what I've done to prevent the call.

> So, yes, I'm not surprised that the object file you produce from your 
> testcase doesn't contain pvMethod. But that's not a problem because in it 
> nobody ever calls this function. What I want to see is a testcase in which 
> this function *should* be there because it is, somehow, called or 
> otherwise required.

Okay, here it is, the faulty code: ;)

#include 
#include 

using namespace std;

template
class TBase
{
public:
~TBase();
virtual void pvMethod() = 0;
};

template
TBase::~TBase()
{
sleep(2);
}

template
void TBase::pvMethod()
{
cerr << "Error" << endl;
}

class TDerived :
public TBase
{
public:
void pvMethod();
};

void TDerived::pvMethod()
{
cout << "OK" << endl;
}

int startThread(pthread_t* handle, void* (*entry)(void*), void* arg)
{
pthread_attr_t attr;
pthread_attr_init(&attr);
pthread_attr_setdetachstate(&attr, true);

int res = pthread_create(handle, &attr, entry, arg);

pthread_attr_destroy(&attr);

return res;
}

void* thread(void* arg)
{
TDerived** typed_arg = (TDerived**)arg;
TDerived* obj = *typed_arg;
sleep(1);
delete obj;
*typed_arg = 0;
return 0;
}

int main(int argc, char** argv)
{
TDerived* obj = new TDerived;
pthread_t thread_handle;
startThread(&thread_handle, &thread, &obj);

for (int i = 0; i < 5; ++i) {
if (!obj) {
break;
}
obj->pvMethod();
sleep(1);
}

return 0;
}

[EMAIL PROTECTED]:~/Programming$ g++ -O0 -Wall -lpthread test.cpp -o test && 
./test
OK
OK
pure virtual method called
terminate called without an active exception
Abgebrochen

> Does this make sense?

The standard says "A pure virtual function need be defined only if explicitly
called with the qualified-id syntax (5.1)." in 10.4.2, so it's perfectly legal
to omit the pvMethod(). But there is a discrepancy between templates and normal
classes:

* For normal classes the method is generated, even if not used. GCC developers
decided to do more than the standard requires, and they must have reasons to do
so. Here you have a choice.

* For templates the method is not generated, and we've discussed why. It's due
to the template function emission rules: Not called, not emitted. But there is
also the shortcut rule when deriving: Cannot be called, not emitted. That is
what you explained. Thus here you have no choice.

Honestly, wouldn't you also like to have the choice?

Best,
Björn!

--
Dipl.-Ing. Björn A. Herwig
Guntermann & Drunck GmbH Systementwicklung 
Dortmunder Str. 4a 
D-57234 Wilnsdorf - Germany 
Tel: +49 (0) 27 39 / 89 01 - 100  Fax: +49 (0) 27 39 / 89 01 - 120 
E-Mail: mailto:[EMAIL PROTECTED] Web: www.gdsys.de
--
Geschäftsführer:
Udo Guntermann - Martin Drunck - Reiner Ruelmann - Klaus Tocke
HRB 2884, Amtsgericht Siegen
USt.-Id.-Nr. DE 126575222 - Steuer-Nr. 342 / 5835 / 1041


-- 


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

[Bug middle-end/35800] [4.4 Regression]: Revision 133835 failed to compile binutils

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-04-02 15:53 ---
So we have

(addr_vec:DI [
(nil)
(label_ref:DI 26)
(label_ref:DI 26)
(label_ref:DI 26)
(label_ref:DI 26)
...


-- 


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

[Bug middle-end/35800] [4.4 Regression]: Revision 133835 failed to compile binutils

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-04-02 15:49 ---
Created an attachment (id=15414)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15414&action=view)
reduced testcase

Reduced testcase, fails with -O -ftree-vrp -fno-inline.

Program received signal SIGSEGV, Segmentation fault.
0x0075e3e4 in mark_jump_label_1 (x=0x0, insn=0x0, in_mem=0 '\0', 
is_target=1 '\001') at /space/rguenther/src/svn/trunk/gcc/jump.c:989
989   RTX_CODE code = GET_CODE (x);

#0  0x0075e3e4 in mark_jump_label_1 (x=0x0, insn=0x0, in_mem=0 '\0', 
is_target=1 '\001') at /space/rguenther/src/svn/trunk/gcc/jump.c:989
#1  0x0075e7f7 in mark_jump_label_1 (x=0x2b658e3e1f10, 
insn=0x2b658eccd960, in_mem=0 '\0', is_target=1 '\001')
at /space/rguenther/src/svn/trunk/gcc/jump.c:1087
#2  0x0075e3c5 in mark_jump_label (x=0x2b658e3e1f10, 
insn=0x2b658eccd960, in_mem=0)
at /space/rguenther/src/svn/trunk/gcc/jump.c:976
#3  0x0075cf52 in mark_all_labels (f=0x2b658ecd6600)
at /space/rguenther/src/svn/trunk/gcc/jump.c:196
#4  0x0075ccf3 in rebuild_jump_labels (f=0x2b658ecd6600)
at /space/rguenther/src/svn/trunk/gcc/jump.c:86
#5  0x00de7232 in tree_expand_cfg ()

(I have to run now.)


-- 


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

[Bug rtl-optimization/35542] [4.3 Regression] fwprop only propagates one operand

[hutchinsonandy at aim dot com]

--- Comment #6 from hutchinsonandy at aim dot com  2008-04-02 15:44 ---
Subject: Re:  [4.3 Regression] fwprop only propagates
 one operand

Eric,

it's difficult to give you a specfic example as the propagation is very 
sensitive to generated code. I found this looking at other AVR bugs and 
discovered it was not working. (I'll  look up that example latter for 
you).

It not an obvious thing as other (good) changes due to DF merge, 
re-arrange code enough to obscure the omission. But the result is an 
extra move or redundant instruction here and there.

(its also not at all specfic to AVR)

Andy





-Original Message-
From: eric dot weddington at atmel dot com <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Sent: Wed, 2 Apr 2008 10:21 am
Subject: [Bug rtl-optimization/35542] [4.3 Regression] fwprop only 
propagates one operand




--- Comment #4 from eric dot weddington at atmel dot com  
2008-04-02 15:21
---
(In reply to comment #3)
> committed to trunk, will backport to 4.3 in due time (causes 
regressions for
> AVR)
>

Could you list what fails?
Thanks!


--


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

--- You are receiving this mail because: ---
You reported the bug, or are watching the reporter.


-- 


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

[Bug middle-end/35803] New: still can't get rid of phony compare patterns - cbranch* / cstore* patterns miss their goal

[amylaar at gcc dot gnu dot org]

Gcc has traditionally used the concept of a compare operation that stores
a comparison result in CC0 or a register, and then can be used with arbitrary
comparison operators to compare it against zero to make a decision for
a branch, store flag, or conditional move instruction.
Since often the actual comparison instructions work differently, a number of
ports need to stash away the comparison operands when they pretend to emit
a comparison, and then emit the actual comparison later when its result is
used.
cbranch* / cstore* patterns had the promise to get rid of this bogosity,
however, they are still don;t deliver.
The only way to have a conditional move is to first perform a comparison, and
then have the the actual move depende on the comparison result.  Thus, if
the architecture has conditional move, a comparison patterns are needed, even
if the targets compare operations are ill-matched, compare patterns have to be
defined, thus disabling cbranch* / cstore* patterns.


-- 
   Summary: still can't get rid of phony compare patterns - cbranch*
/ cstore* patterns miss their goal
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org


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

[Bug rtl-optimization/35542] [4.3 Regression] fwprop only propagates one operand

[bonzini at gnu dot org]

--- Comment #5 from bonzini at gnu dot org  2008-04-02 15:25 ---
I meant that this is a patch that is scheduled for backporting to 4.3, because
it fixes regressions on AVR.

The text between parentheses should have been "bug causes regressions for AVR".
 Sorry.


-- 


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

[Bug rtl-optimization/35542] [4.3 Regression] fwprop only propagates one operand

[eric dot weddington at atmel dot com]

--- Comment #4 from eric dot weddington at atmel dot com  2008-04-02 15:21 
---
(In reply to comment #3)
> committed to trunk, will backport to 4.3 in due time (causes regressions for
> AVR)
> 

Could you list what fails?
Thanks!


-- 


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

[Bug ada/35284] Branch to 0x0 from Ada run-time

[joel at gcc dot gnu dot org]

--- Comment #29 from joel at gcc dot gnu dot org  2008-04-02 15:08 ---
I have spent the morning debugging at the assembly level and I am nearly 100%
positive %ebx is getting corrupted.  It is correct before the call to   

STPO.Initialize_TCB (T, Success);

at s-taskin.adb and 0x0 upon return. There are ~2000 lines in the qemu.log 
between the two points so I have some reduction. 

I grep'ed the RTEMS source for references to ebx and I didn't see any which
were not in ISR or context switch code.  I did a run with no IO or interrupts
and got the same result.  At this point, I am looking for some subroutine that
isn't preserving ebx properly.


(In reply to comment #28)
> I did not notice that s-taprop for rtems was the posix version
> 
>procedure Initialize_TCB (Self_ID : Task_Id; Succeeded : out Boolean) is
>   Mutex_Attr : aliased pthread_mutexattr_t;
>   Result : Interfaces.C.int;
>   Cond_Attr  : aliased pthread_condattr_t;
> 
>begin
> ...
> 
>  if Result /= 0 then
> Succeeded := False;
> return;
>  end if;
> ...
>   if Result = 0 then
>  Succeeded := True;
>   else
>  if not Single_Lock then
> Result := pthread_mutex_destroy (Self_ID.Common.LL.L'Access);
> pragma Assert (Result = 0);
>  end if;
> 
>  Succeeded := False;
>   end if;
> ...
> 
> So it's now just a matter of finding which posix call in there fails.
> 


-- 


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

[Bug libstdc++/20451] Missing po files in multilib systems

[ghazi at gcc dot gnu dot org]

--- Comment #4 from ghazi at gcc dot gnu dot org  2008-04-02 14:59 ---
Problem still occurs on 4.1 branch:
http://gcc.gnu.org/ml/gcc-testresults/2008-04/msg00083.html

I'll try backporting the patch from 4.2.x and see if it still works.


-- 

ghazi at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ghazi at gcc dot gnu dot org


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

[Bug target/35801] [4.4 Regression]: At revision 133817, bootstrap fails at libstdc++-v3/src/strstream.cc on powerpc-apple-darwin9

[dominiq at lps dot ens dot fr]

--- Comment #2 from dominiq at lps dot ens dot fr  2008-04-02 14:34 ---
I think it is another manifestation of PR35795.


-- 


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

[Bug tree-optimization/35795] [4.4 Regression] Revision 133787 breaks ia64

[dominiq at lps dot ens dot fr]

--- Comment #4 from dominiq at lps dot ens dot fr  2008-04-02 14:31 ---
I think PR35801 is the same problem on powerpc-apple-darwin9.


-- 


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

[Bug target/35801] [4.4 Regression]: At revision 133817, bootstrap fails at libstdc++-v3/src/strstream.cc on powerpc-apple-darwin9

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-04-02 14:25 ---
This is thunk related, most likely forgot a free function.


-- 


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

[Bug target/35801] [4.4 Regression]: At revision 133817, bootstrap fails at libstdc++-v3/src/strstream.cc on powerpc-apple-darwin9

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
  Component|bootstrap   |target
   Target Milestone|--- |4.4.0


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

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[oblivian at users dot sourceforge dot net]

--- Comment #39 from oblivian at users dot sourceforge dot net  2008-04-02 
14:19 ---
Created an attachment (id=15413)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15413&action=view)
Optional way to fix ld relink problems

Just for completeness, here is the fix the Ralf was suggesting.  I tried this
out and it seems to work as well.


-- 


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

[Bug libstdc++/31413] FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test

[ghazi at gcc dot gnu dot org]

--- Comment #17 from ghazi at gcc dot gnu dot org  2008-04-02 14:18 ---
I see the same issue on x86_64 debian linux-gnu:
http://gcc.gnu.org/ml/gcc-testresults/2008-04/msg00085.html

Removing hppa tags since it's debian-specific, not hppa.


-- 

ghazi at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ghazi at gcc dot gnu dot org
  GCC build triplet|hppa-unknown-linux-gnu  |
   GCC host triplet|hppa-unknown-linux-gnu  |
 GCC target triplet|hppa-unknown-linux-gnu  |


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

[Bug c/35802] MIPS64: Unable to find a register to spill in class ‘V1_REG’

[aurelien at aurel32 dot net]

--- Comment #3 from aurelien at aurel32 dot net  2008-04-02 14:15 ---
Also please note that the same problem exists on mips
(mips64-unknown-linux-gnu).


-- 

aurelien at aurel32 dot net changed:

   What|Removed |Added

  Known to fail||4.3.0
  Known to work||4.2.3


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

[Bug c/35802] MIPS64: Unable to find a register to spill in class ‘V1_REG’

[aurelien at aurel32 dot net]

--- Comment #2 from aurelien at aurel32 dot net  2008-04-02 14:13 ---
Created an attachment (id=15412)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15412&action=view)
reduced testcase


-- 


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

[Bug c/35802] MIPS64: Unable to find a register to spill in class ‘V1_REG’

[aurelien at aurel32 dot net]

--- Comment #1 from aurelien at aurel32 dot net  2008-04-02 14:13 ---
Created an attachment (id=15411)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15411&action=view)
unreduced testcase


-- 


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

[Bug c/35802] New: MIPS64: Unable to find a register to spill in class ‘V1_REG’

[aurelien at aurel32 dot net]

I am getting a very strange ICE on a mips system when building with -mabi=n32
or -mabi=64:

testcase.i: In function ‘_IO_vfscanf_internal’:
testcase.i:2857: error: unable to find a register to spill in class
‘V1_REG’
testcase.i:2857: error: this is the insn:
(insn 1286 1241 1243 106 testcase.i:577 (set (reg:SI 19 $19 [3464])
(unspec:SI [
(const_int 0 [0x0])
] 28)) 460 {tls_get_tp_si} (expr_list:REG_EQUIV (unspec:SI [
(const_int 0 [0x0])
] 28)
(nil)))
testcase.i:2857: confused by earlier errors, bailing out

This is when trying to build glibc 2.7, file vfscanf.c. The strange part appear
when trying to reduce the testcase. I noticed that removing struct declarations
that are not use elsewhere in the file make the problem disappear. That's why
the reduced testcase is still big.

I'll attach two testcase, one unreduced, and one reduced.

With the unreduced testcase, it is possible to trigger the bug with -mabi=n32
or -mabi=64 with -O2 or -O3.

On reduce testcase, the bug is triggered exclusively with -mabi=n32 and -O2.

This is the command I used to build the file:
/usr/bin/gcc-4.3 -c -O2 -fgnu89-inline -std=gnu99 -mabi=n32 testcase-min.i


-- 
   Summary: MIPS64: Unable to find a register to spill in class
‘V1_REG’
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aurelien at aurel32 dot net
 GCC build triplet: mips64el-unknown-linux-gnu
  GCC host triplet: mips64el-unknown-linux-gnu
GCC target triplet: mips64el-unknown-linux-gnu


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

[Bug driver/35532] Native GCC no longer searches $prefix/lib for startfiles when run from $objdir

[bonzini at gnu dot org]

--- Comment #11 from bonzini at gnu dot org  2008-04-02 14:08 ---
Carlos, I think Greg has a point here:

> the problem is that xgcc thinks it is a relocated compiler when it 
> runs from $objdir eg: when building libgcc* and other target libs, when in
> actual fact, it is not really a true relocated compiler at all.

Looking at http://gcc.gnu.org/ml/gcc/2006-10/msg00280.html it seems to me that
setenv GCC_EXEC_PREFIX "$GCC_EXEC_PREFIX" is always needed when we run in the
build directory.  This is easier said than done -- for example adding a
--exec-prefix option to the driver is not possible because gcc_exec_prefix is
set much earlier than at option-processing time.


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 CC||bonzini at gnu dot org


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

[Bug middle-end/35800] [4.4 Regression]: Revision 133835 failed to compile binutils

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2008-04-02 14:00 ---
(In reply to comment #2)
> This is likely caused by http://gcc.gnu.org/ml/gcc-cvs/2008-04/msg00059.html.
> 
> Reducing.
> 

http://gcc.gnu.org/ml/gcc-cvs/2008-04/msg00059.html

is revision 133835. Revision 133834 passed the failed point.


-- 


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

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[bonzini at gnu dot org]

--- Comment #38 from bonzini at gnu dot org  2008-04-02 13:59 ---
Subject: Re:  [4.3/4.4 Regression]: Combined gcc + binutils
 source tree doesn't bootstrap with --enable-shared


> I'll be opening a new bug on the sysroot problems I'm having with 4.3 since it
> appears no one has tried a combined gcc + binutils bootstrap with sysroot (or
> at least I can't find a bug on it in gcc bugzilla).

Ok, CC me on that bug.


-- 


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

[Bug bootstrap/35801] New: [4.4 Regression]: At revision 133817, bootstrap fails at libstdc++-v3/src/strstream.cc on powerpc-apple-darwin9

[dominiq at lps dot ens dot fr]

At revision 133817, bootstrap fails at libstdc++-v3/src/strstream.cc on
powerpc-apple-darwin9:

...
libtool: compile:  /opt/gcc/darwin_buildw/./gcc/xgcc -shared-libgcc
-B/opt/gcc/darwin_buildw/./gcc -nostdinc++
-L/opt/gcc/darwin_buildw/powerpc-apple-darwin9/libstdc++-v3/src
-L/opt/gcc/darwin_buildw/powerpc-apple-darwin9/libstdc++-v3/src/.libs
-B/opt/gcc/gcc4.4w/powerpc-apple-darwin9/bin/
-B/opt/gcc/gcc4.4w/powerpc-apple-darwin9/lib/ -isystem
/opt/gcc/gcc4.4w/powerpc-apple-darwin9/include -isystem
/opt/gcc/gcc4.4w/powerpc-apple-darwin9/sys-include
-I/opt/gcc/darwin_buildw/powerpc-apple-darwin9/libstdc++-v3/include/powerpc-apple-darwin9
-I/opt/gcc/darwin_buildw/powerpc-apple-darwin9/libstdc++-v3/include
-I/opt/gcc/gcc-4.4-work/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall
-Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once
-ffunction-sections -fdata-sections -g -O2 -c
../../../../gcc-4.4-work/libstdc++-v3/src/stdexcept.cc  -fno-common -DPIC -o
.libs/stdexcept.o
libtool: compile:  /opt/gcc/darwin_buildw/./gcc/xgcc -shared-libgcc
-B/opt/gcc/darwin_buildw/./gcc -nostdinc++
-L/opt/gcc/darwin_buildw/powerpc-apple-darwin9/libstdc++-v3/src
-L/opt/gcc/darwin_buildw/powerpc-apple-darwin9/libstdc++-v3/src/.libs
-B/opt/gcc/gcc4.4w/powerpc-apple-darwin9/bin/
-B/opt/gcc/gcc4.4w/powerpc-apple-darwin9/lib/ -isystem
/opt/gcc/gcc4.4w/powerpc-apple-darwin9/include -isystem
/opt/gcc/gcc4.4w/powerpc-apple-darwin9/sys-include
-I/opt/gcc/darwin_buildw/powerpc-apple-darwin9/libstdc++-v3/include/powerpc-apple-darwin9
-I/opt/gcc/darwin_buildw/powerpc-apple-darwin9/libstdc++-v3/include
-I/opt/gcc/gcc-4.4-work/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall
-Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once
-ffunction-sections -fdata-sections -g -O2 -c
../../../../gcc-4.4-work/libstdc++-v3/src/stdexcept.cc -o stdexcept.o
>/dev/null 2>&1
/bin/sh ../libtool --tag CXX --mode=compile /opt/gcc/darwin_buildw/./gcc/xgcc
-shared-libgcc -B/opt/gcc/darwin_buildw/./gcc -nostdinc++
-L/opt/gcc/darwin_buildw/powerpc-apple-darwin9/libstdc++-v3/src
-L/opt/gcc/darwin_buildw/powerpc-apple-darwin9/libstdc++-v3/src/.libs
-B/opt/gcc/gcc4.4w/powerpc-apple-darwin9/bin/
-B/opt/gcc/gcc4.4w/powerpc-apple-darwin9/lib/ -isystem
/opt/gcc/gcc4.4w/powerpc-apple-darwin9/include -isystem
/opt/gcc/gcc4.4w/powerpc-apple-darwin9/sys-include 
-I/opt/gcc/darwin_buildw/powerpc-apple-darwin9/libstdc++-v3/include/powerpc-apple-darwin9
-I/opt/gcc/darwin_buildw/powerpc-apple-darwin9/libstdc++-v3/include
-I/opt/gcc/gcc-4.4-work/libstdc++-v3/libsupc++  -fno-implicit-templates -Wall
-Wextra -Wwrite-strings -Wcast-qual  -fdiagnostics-show-location=once 
-ffunction-sections -fdata-sections  -g -O2   
-I/opt/gcc/darwin_buildw/powerpc-apple-darwin9/libstdc++-v3/include/backward
-Wno-deprecated -c ../../../../gcc-4.4-work/libstdc++-v3/src/strstream.cc
libtool: compile:  /opt/gcc/darwin_buildw/./gcc/xgcc -shared-libgcc
-B/opt/gcc/darwin_buildw/./gcc -nostdinc++
-L/opt/gcc/darwin_buildw/powerpc-apple-darwin9/libstdc++-v3/src
-L/opt/gcc/darwin_buildw/powerpc-apple-darwin9/libstdc++-v3/src/.libs
-B/opt/gcc/gcc4.4w/powerpc-apple-darwin9/bin/
-B/opt/gcc/gcc4.4w/powerpc-apple-darwin9/lib/ -isystem
/opt/gcc/gcc4.4w/powerpc-apple-darwin9/include -isystem
/opt/gcc/gcc4.4w/powerpc-apple-darwin9/sys-include
-I/opt/gcc/darwin_buildw/powerpc-apple-darwin9/libstdc++-v3/include/powerpc-apple-darwin9
-I/opt/gcc/darwin_buildw/powerpc-apple-darwin9/libstdc++-v3/include
-I/opt/gcc/gcc-4.4-work/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall
-Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once
-ffunction-sections -fdata-sections -g -O2
-I/opt/gcc/darwin_buildw/powerpc-apple-darwin9/libstdc++-v3/include/backward
-Wno-deprecated -c ../../../../gcc-4.4-work/libstdc++-v3/src/strstream.cc 
-fno-common -DPIC -o .libs/strstream.o
../../../../gcc-4.4-work/libstdc++-v3/src/strstream.cc: In destructor 'virtual
std::ostrstream::~ostrstream()':
../../../../gcc-4.4-work/libstdc++-v3/src/strstream.cc:374: internal compiler
error: in prepare_function_start, at function.c:3940
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[4]: *** [strstream.lo] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-target-libstdc++-v3] Error 2
make: *** [all] Error 2

Still fails at revision 133833.


-- 
   Summary: [4.4 Regression]: At revision 133817, bootstrap fails at
libstdc++-v3/src/strstream.cc on powerpc-apple-darwin9
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
 GCC build triplet: powerpc-apple-darwin9
  GCC host triplet: powerpc-apple-darwin9
GCC target triplet: powerpc-apple-darwin9


http://gcc.

[Bug middle-end/35800] [4.4 Regression]: Revision 133835 failed to compile binutils

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-04-02 13:50 ---
This is likely caused by http://gcc.gnu.org/ml/gcc-cvs/2008-04/msg00059.html.

Reducing.


-- 

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 |2008-04-02 13:50:06
   date||


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

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[oblivian at users dot sourceforge dot net]

--- Comment #37 from oblivian at users dot sourceforge dot net  2008-04-02 
13:47 ---
(In reply to comment #35)
> the infinite loop is fixed, don't know if the second bug remains.
> 
Yes and no, It fixes the compilation so that ld no longer gets into a loop, but
the installed compiler is still not working due to the missing search paths.

This bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35532
explored the issue of using sysroot for native builds and it appears the
consensus is not to support retargeted compilers anymore for native builds, and
that the sysroot framework should be used even though some people are still
stating that it is for cross compiling only.

I'll be opening a new bug on the sysroot problems I'm having with 4.3 since it
appears no one has tried a combined gcc + binutils bootstrap with sysroot (or
at least I can't find a bug on it in gcc bugzilla).

Thanks for all the help.


-- 


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

[Bug middle-end/35800] [4.4 Regression]: Revision 133835 failed to compile binutils

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2008-04-02 13:46 ---
Created an attachment (id=15410)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15410&action=view)
A testcase

[EMAIL PROTECTED] binutils]$ 
/export/build/gnu/tools/build-x86_64-linux/./prev-gcc/xgcc
-B/export/build/gnu/tools/build-x86_64-linux/./prev-gcc/ -O2 -S stabs.i 
/export/gnu/src/tools/tools/binutils/stabs.c: In function ‘stab_find_type’:
/export/gnu/src/tools/tools/binutils/stabs.c:3318: internal compiler error:
Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
[EMAIL PROTECTED] binutils]$ 


-- 


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

[Bug middle-end/35800] New: [4.4 Regression]: Revision 133835 failed to compile binutils

[hjl dot tools at gmail dot com]

Stage 1 compiler from revision 133835 failed to compile binutils:

[EMAIL PROTECTED] binutils]$ 
/export/build/gnu/tools/build-x86_64-linux/./prev-gcc/xgcc
-B/export/build/gnu/tools/build-x86_64-linux/./prev-gcc/
-B/usr/gcc-4.4/x86_64-unknown-linux-gnu/bin/ -DHAVE_CONFIG_H -I.
-I/export/gnu/src/tools/tools/binutils -I. -I.
-I/export/gnu/src/tools/tools/binutils -I../bfd
-I/export/gnu/src/tools/tools/binutils/../bfd
-I/export/gnu/src/tools/tools/binutils/../include
-DLOCALEDIR="\"/usr/gcc-4.4/share/locale\""
-Dbin_dummy_emulation=bin_vanilla_emulation   -W -Wall -Wstrict-prototypes
-Wmissing-prototypes -Werror -g -O2 -c
/export/gnu/src/tools/tools/binutils/stabs.c
/export/gnu/src/tools/tools/binutils/stabs.c: In function ‘stab_find_type’:
/export/gnu/src/tools/tools/binutils/stabs.c:3318: internal compiler error:
Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Program received signal SIGSEGV, Segmentation fault.
0x005c3b09 in mark_jump_label_1 (x=0x0, insn=0x0, in_mem=0 '\0', 
is_target=1 '\001') at /export/gnu/src/tools/tools/gcc/jump.c:989
989   RTX_CODE code = GET_CODE (x);
Missing separate debuginfos, use: debuginfo-install glibc.x86_64
(gdb) bt
#0  0x005c3b09 in mark_jump_label_1 (x=0x0, insn=0x0, in_mem=0 '\0', 
is_target=1 '\001') at /export/gnu/src/tools/tools/gcc/jump.c:989
#1  0x005c3db0 in mark_jump_label_1 (x=0x2b86d6b0, 
insn=0x2b8a1cd0, in_mem=0 '\0', is_target=1 '\001')
at /export/gnu/src/tools/tools/gcc/jump.c:1087
#2  0x005c3aea in mark_jump_label (x=0x2b86d6b0, 
insn=0x2b8a1cd0, in_mem=0)
at /export/gnu/src/tools/tools/gcc/jump.c:976
#3  0x005c27a3 in mark_all_labels (f=0x2b4330c0)
at /export/gnu/src/tools/tools/gcc/jump.c:196
#4  0x005c2587 in rebuild_jump_labels (f=0x2b4330c0)
at /export/gnu/src/tools/tools/gcc/jump.c:86
#5  0x00a65513 in tree_expand_cfg ()
at /export/gnu/src/tools/tools/gcc/cfgexpand.c:1923
#6  0x006060f1 in execute_one_pass (pass=0x102a260)
at /export/gnu/src/tools/tools/gcc/passes.c:1127
#7  0x00606249 in execute_pass_list (pass=0x102a260)
at /export/gnu/src/tools/tools/gcc/passes.c:1180
#8  0x006fcbd8 in tree_rest_of_compilation (fndecl=0x2af87820)
at /export/gnu/src/tools/tools/gcc/tree-optimize.c:420
#9  0x0085c758 in cgraph_expand_function (node=0x2b0d3d00)
at /export/gnu/src/tools/tools/gcc/cgraphunit.c:1157
#10 0x0085c908 in cgraph_expand_all_functions ()
---Type  to continue, or q  to quit--- q
 at /export/gnu/src/toolQuit

Revision 133718 is OK.


-- 
   Summary: [4.4 Regression]: Revision 133835 failed to compile
binutils
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
GCC target triplet: x86_64-unknown-linux-gnu


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