[Bug target/36064] could not split insn with -O1 -march=nocona -m32

[ubizjak at gmail dot com]

--- Comment #2 from ubizjak at gmail dot com  2008-04-28 05:34 ---
Mine.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ubizjak at gmail dot com
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-04-28 05:34:45
   date||


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

[Bug tree-optimization/35639] [4.3/4.4 Regression] -fprofile-generate + PRE = big compile-time

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug libstdc++/35637] [4.3 Regression] tr1::function fails with const member function pointer

[mmitchel at gcc dot gnu dot org]

--- Comment #11 from mmitchel at gcc dot gnu dot org  2008-04-28 04:40 
---
Manuel --

Would you please open a new bug for the diagnostic.c issue and close this one
now that the library problem has been resolved?

Thanks,

-- Mark


-- 


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

[Bug c++/35985] [4.1/4.2/4.3/4.4 regression] ICE with pointer to member function as base

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug debug/36060] [4.3/4.4 Regression] Too big stack requirements of cc1plus during GC

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug c++/35987] [4.1/4.2/4.3/4.4 regression] ICE with invalid if-condition

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P4


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

[Bug middle-end/36013] [4.1/4.3/4.4 Regression] Wrong code involving restricted pointers to non-restricted pointers

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


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

[Bug c++/35813] [4.3 regression] ICE with partial specialization of variadic templates

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug middle-end/35509] [4.3/4.4 Regression] builtin isinf() mismatch to compile-time substitution

[mmitchel at gcc dot gnu dot org]

--- Comment #12 from mmitchel at gcc dot gnu dot org  2008-04-28 04:37 
---
I don't see that this is a bug, given that the compiler's optimization is
within the bounds set by the C standard.  I agree with Kaveh's comment that it
is desirable that C libraries be able to implement external functions in terms
of the builtin, if they choose.

If you disagree with that conclusion, please raise the issue on
[EMAIL PROTECTED]  If there is consensus that QoI dictates that we should do
something different, then we can reopen this issue.


-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID


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

[Bug c++/36023] [4.1/4.3/4.4 regression] ICE with cast to variable-sized object

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug c++/35986] [4.1/4.2/4.3/4.4 regression] ICE with ambiguous template functions

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug target/35659] [4.3/4.4 Regression] Miscompiled code with -O2 (but not with -O2 -funroll-loops) on ia64

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P5


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

[Bug target/35658] [4.3/4.4 regression] Bad interaction on ia64 between -funroll-loops -fno-automatic -O2 and common block variable

[mmitchel at gcc dot gnu dot org]

--- Comment #1 from mmitchel at gcc dot gnu dot org  2008-04-28 04:28 
---
Fortran is not a primary language.


-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P5


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

[Bug target/35399] [4.3 regression] bootstrap error, ICE in free_list, at lists.c:52

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


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

[Bug target/35090] [4.3/4.4 regression] libjava testsuite failures on hppa-linux

[mmitchel at gcc dot gnu dot org]

--- Comment #4 from mmitchel at gcc dot gnu dot org  2008-04-28 04:27 
---
Not a primary platform.


-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P5


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

[Bug target/32871] [avr] Bad optimisation - gcc is pushing too many registers

[hutchinsonandy at aim dot com]

--- Comment #7 from hutchinsonandy at aim dot com  2008-04-28 00:59 ---
Attached is INCOMPLETE attempt to fix this issue.

Register saves appear to be ok. But same function is required for Argument
pointer elimination offset. It would appear DF chain info is not maintained,
when global.c  uses this. So offset used to access arguments on stack does not
reflect final value required and will fail.


-- 


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

[Bug target/32871] [avr] Bad optimisation - gcc is pushing too many registers

[hutchinsonandy at aim dot com]

--- Comment #6 from hutchinsonandy at aim dot com  2008-04-28 00:58 ---
Created an attachment (id=15540)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15540&action=view)
Partial solution using DF defs.


-- 

hutchinsonandy at aim dot com changed:

   What|Removed |Added

  Attachment #15254|0   |1
is obsolete||


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

[Bug testsuite/36068] New: gcc.dg/vect/vect-118.c doesn't work on Linux/ia32

[hjl dot tools at gmail dot com]

I got

Executing on host: /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/
/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.dg/vect/vect-118.c   -O3
-fdump-tree-vect-details -fno-show-column  -lm   -m32 -o ./vect-118.exe   
(timeout = 300)
PASS: gcc.dg/vect/vect-118.c (test for excess errors)
Setting LD_LIBRARY_PATH to
:/export/build/gnu/gcc/build-x86_64-linux/gcc:/export/build/gnu/gcc/build-x86_64-linux/gcc/32::/export/build/gnu/gcc/build-x86_64-linux/gcc:/export/build/gnu/gcc/build-x86_64-linux/gcc/32:/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/libstdc++-v3/.libs:/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/libmudflap/.libs:/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/libssp/.libs:/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/libgomp/.libs:/export/build/gnu/gcc/build-x86_64-linux/./gcc:/export/build/gnu/gcc/build-x86_64-linux/./prev-gcc
PASS: gcc.dg/vect/vect-118.c execution test
FAIL: gcc.dg/vect/vect-118.c scan-tree-dump-times vect "vectorized 1 loops" 1


-- 
   Summary: gcc.dg/vect/vect-118.c doesn't  work on Linux/ia32
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
GCC target triplet: i686-pc-linux-gnu


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

[Bug testsuite/36067] New: gcc.dg/tls/section-2.c doesn't work

[hjl dot tools at gmail dot com]

On Linux/ia32 and Linux/Intel64, I got

Executing on host: /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/
/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.dg/tls/section-2.c-ansi
-pedantic-errors -fno-show-column -S  -m32 -o section-2.s(timeout = 300)
FAIL: gcc.dg/tls/section-2.c  (test for errors, line 7)


-- 
   Summary: gcc.dg/tls/section-2.c doesn't work
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
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=36067

[Bug tree-optimization/36066] [4.4 Regression] ICE with -O1 -finline-small-functions -ftree-vrp -funsafe-loop-optimizations

[martin dot drab at fjfi dot cvut dot cz]

--- Comment #5 from martin dot drab at fjfi dot cvut dot cz  2008-04-27 
22:54 ---
And the test cases also fail with

   -O1 -finline-small-functions -ftree-vrp -m32

so if you compile it for 32-bit target, naither the -funsafe-loop-optimizations
nor the -fprefetch-loop-arrays needs to be specified. Haven't tested it on a
native 32-bit host, so, hard to say whether it would ICE there as well, just
like this. However, natively on a 64-bit host with just "-O1
-finline-small-functions -ftree-vrp" it works without an ICE.


-- 


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

[Bug c/36050] Ternary operator warning on assignment used as truth value

[manu at gcc dot gnu dot org]

--- Comment #1 from manu at gcc dot gnu dot org  2008-04-27 22:13 ---


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


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c/25733] missed diagnostic about assignment used as truth value.

[manu at gcc dot gnu dot org]

--- Comment #2 from manu at gcc dot gnu dot org  2008-04-27 22:13 ---
*** Bug 36050 has been marked as a duplicate of this bug. ***


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ianw at vmware dot com


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

[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.

[gnu_andrew at member dot fsf dot org]

--- Comment #16 from gnu_andrew at member dot fsf dot org  2008-04-27 22:01 
---
Created an attachment (id=15539)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15539&action=view)
Fix substring bug


-- 


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

[Bug tree-optimization/36066] [4.4 Regression] ICE with -O1 -finline-small-functions -ftree-vrp -funsafe-loop-optimizations

[martin dot drab at fjfi dot cvut dot cz]

--- Comment #4 from martin dot drab at fjfi dot cvut dot cz  2008-04-27 
21:43 ---
The test cases also fail with

   -O1 -finline-small-functions -ftree-vrp -fprefetch-loop-arrays


-- 


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

[Bug tree-optimization/36066] [4.4 Regression] ICE with -O1 -finline-small-functions -ftree-vrp -funsafe-loop-optimizations

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
Summary|ICE with -O1 -finline-small-|[4.4 Regression] ICE with -
   |functions -ftree-vrp -  |O1 -finline-small-functions
   |funsafe-loop-optimizations  |-ftree-vrp -funsafe-loop-
   ||optimizations
   Target Milestone|--- |4.4.0


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

[Bug tree-optimization/36066] ICE with -O1 -finline-small-functions -ftree-vrp -funsafe-loop-optimizations

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-04-27 21:31 ---
Created an attachment (id=15538)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15538&action=view)
somehwat reduced testcase


-- 


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

[Bug tree-optimization/36066] ICE with -O1 -finline-small-functions -ftree-vrp -funsafe-loop-optimizations

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-04-27 21:11 ---
Confirmed.

Program received signal SIGSEGV, Segmentation fault.
0x0829ba29 in operand_equal_p (arg0=0xb7b248f0, arg1=0xb7c6fd68, flags=0)
at /home/richard/src/trunk/gcc/fold-const.c:3037
3037  if (TYPE_UNSIGNED (TREE_TYPE (arg0)) != TYPE_UNSIGNED (TREE_TYPE
(arg1)))
(gdb) print arg0->common.type
$2 = (tree) 0x0

#0  0x0829ba29 in operand_equal_p (arg0=0xb7b248f0, arg1=0xb7c6fd68, flags=0)
at /home/richard/src/trunk/gcc/fold-const.c:3037
#1  0x08623ccf in simplify_replace_tree (expr=0xb7b248f0, old=0xb7c6fd68, 
new_tree=0xb7c4ec64)
at /home/richard/src/trunk/gcc/tree-ssa-loop-niter.c:1347
#2  0x08623e50 in simplify_replace_tree (expr=0xb7774318, old=0xb7c6fd68, 
new_tree=0xb7c4ec64)
at /home/richard/src/trunk/gcc/tree-ssa-loop-niter.c:1358
#3  0x0862ba0e in substitute_in_loop_info (loop=0xb78bb898, name=0xb7c6fd68, 
val=0xb7c4ec64) at /home/richard/src/trunk/gcc/tree-ssa-loop-niter.c:3070
#4  0x084abab2 in replace_uses_by (name=0xb7c6fd68, val=0xb7c4ec64)
at /home/richard/src/trunk/gcc/tree-cfg.c:1273
#5  0x084ad00a in tree_merge_blocks (a=0xb7b3d30c, b=0xb7b3d744)
at /home/richard/src/trunk/gcc/tree-cfg.c:1337
#6  0x0819f781 in merge_blocks (a=0xb7b3d30c, b=0xb7b3d744)
at /home/richard/src/trunk/gcc/cfghooks.c:660
#7  0x084cfbbe in cleanup_tree_cfg_bb (bb=0xb7b3d30c)
at /home/richard/src/trunk/gcc/tree-cfgcleanup.c:568
#8  0x084cfc76 in cleanup_tree_cfg_1 ()
at /home/richard/src/trunk/gcc/tree-cfgcleanup.c:601
#9  0x084cfdf8 in cleanup_tree_cfg_noloop ()
at /home/richard/src/trunk/gcc/tree-cfgcleanup.c:657
#10 0x084cff49 in cleanup_tree_cfg ()
#11 0x0870f68f in execute_vrp () at /home/richard/src/trunk/gcc/tree-vrp.c:6758
#12 0x083ec77e in execute_one_pass (pass=0x8c6b538)
at /home/richard/src/trunk/gcc/passes.c:1133


-- 

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-27 21:11:09
   date||


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

[Bug tree-optimization/36066] ICE with -O1 -finline-small-functions -ftree-vrp -funsafe-loop-optimizations

[martin dot drab at fjfi dot cvut dot cz]

--- Comment #1 from martin dot drab at fjfi dot cvut dot cz  2008-04-27 
20:58 ---
Created an attachment (id=15537)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15537&action=view)
Example that triggers the bug.


-- 


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

[Bug tree-optimization/36066] New: ICE with -O1 -finline-small-functions -ftree-vrp -funsafe-loop-optimizations

[martin dot drab at fjfi dot cvut dot cz]

The attached example, when compiled with
   gcc version 4.4.0 20080426 (experimental) (GCC)
using
-
   gcc -O1 -finline-small-functions -ftree-vrp -funsafe-loop-optimizations -c
stream_encoder.c.c -o stream_encoder.o
-
produces the following ICE.

-
stream_encoder.c: In function 'process_frame_':
stream_encoder.c:1844: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
-

When any of the CFLAGS are removed, it passes. Tested on x86_64.


-- 
   Summary: ICE with -O1 -finline-small-functions -ftree-vrp -
funsafe-loop-optimizations
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: martin dot drab at fjfi dot cvut dot cz
 GCC build triplet: x86_64-pc-linux-gnu
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


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

[Bug other/36062] -mpc32,-mpc64, and -mpc80 are not documented properly

[kargl at gcc dot gnu dot org]

--- Comment #2 from kargl at gcc dot gnu dot org  2008-04-27 20:39 ---
(In reply to comment #1)
> No, these options are also working well on darwin. Other OSes need to update
> their ENDFILE_SPEC entry and their config.gcc entry.
> 

Then document the platforms on which these options work.  Or, mark these
options as experimental and supported on a limited number of platforms.
I've already fielded one query about the failure of these options to
work on mingw64. 

http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/e9add97708681397#


-- 


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

[Bug java/36065] New: gcj 4.3.1 fails to compile if system libtool is version 2.x

[bero at arklinux dot org]

# libtool --version |head -n1
ltmain.sh (GNU libtool) 2.2.2

# make
[...]
make[5]: Entering directory
`/build-gcc-i586/BUILD/gcc-4.3.1/build/i586-ark-linux/libjava/classpath/native/fdlibm'
if /bin/sh ../../libtool --tag=CC --mode=compile
/build-gcc-i586/BUILD/gcc-4.3.1/build/./gcc/xgcc
-B/build-gcc-i586/BUILD/gcc-4.3.1/build/./gcc/ -B/usr/i586-ark-linux/bin/
-B/usr/i586-ark-linux/lib/ -isystem /usr/i586-ark-linux/include -isystem
/usr/i586-ark-linux/sys-include -DHAVE_CONFIG_H -I.
-I../../../../../../libjava/classpath/native/fdlibm -I../../include -O2 -g
-O2 -march=i586 -mtune=i686  -fweb -frename-registers -fno-strict-aliasing  
-MT dtoa.lo -MD -MP -MF ".deps/dtoa.Tpo" -c -o dtoa.lo
../../../../../../libjava/classpath/native/fdlibm/dtoa.c; \
then mv -f ".deps/dtoa.Tpo" ".deps/dtoa.Plo"; else rm -f
".deps/dtoa.Tpo"; exit 1; fi
../../libtool: line 154: CDPATH: command not found
libtool: Version mismatch error.  This is libtool 2.1a, but the
libtool: definition of this LT_INIT comes from an older release.
libtool: You should recreate aclocal.m4 with macros from libtool 2.1a
libtool: and run autoconf again.
make[5]: *** [dtoa.lo] Error 1
make[5]: Leaving directory
`/build-gcc-i586/BUILD/gcc-4.3.1/build/i586-ark-linux/libjava/classpath/native/fdlibm'
make[4]: *** [all-recursive] Error 1


The configure script should probably detect this and fix aclocal.m4...


-- 
   Summary: gcj 4.3.1 fails to compile if system libtool is version
2.x
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bero at arklinux dot org
 GCC build triplet: i586-pc-linux-gnu
  GCC host triplet: i586-pc-linux-gnu
GCC target triplet: i586-pc-linux-gnu


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

[Bug rtl-optimization/36064] could not split insn with -O1 -march=nocona -m32

[drab at kepler dot fjfi dot cvut dot cz]

--- Comment #1 from drab at kepler dot fjfi dot cvut dot cz  2008-04-27 
18:55 ---
Created an attachment (id=15536)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15536&action=view)
Example that triggers the bug.


-- 


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

[Bug rtl-optimization/36064] New: could not split insn with -O1 -march=nocona -m32

[drab at kepler dot fjfi dot cvut dot cz]

When the attached example is compiled by the
   gcc version 4.4.0 20080426 (experimental) (GCC)
using

   gcc -O1 -march=nocona -m32 -c vorbisfile.c.c -o vorbisfile.o

it produces the following error:


vorbisfile.c: In function 'ov_time_seek_page':
vorbisfile.c:1622: error: could not split insn
(insn 108 66 156 vorbisfile.c:1620 (parallel [
(set (reg:DF 8 st)
(float:DF (mem/c:DI (plus:SI (reg/f:SI 6 bp)
(const_int -40 [0xffd8])) [0
pcm_total+0 S8 A8])))
(clobber (scratch:V4SI))
(clobber (scratch:V4SI))
(clobber (mem/c:DI (plus:SI (reg/f:SI 6 bp)
(const_int -24 [0xffe8])) [0 S8 A8]))
]) 235 {floatdidf2_i387_with_xmm} (nil))
vorbisfile.c:1622: internal compiler error: in final_scan_insn, at final.c:2597
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


The same error is produced with -march=core2, -march=prescott or
-march=pentium4. This error is not present when -m64 is used instead of -m32,
or when any of the AMD architectures are used, like -march=athlon64 and so on.


-- 
   Summary: could not split insn with -O1 -march=nocona -m32
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drab at kepler dot fjfi dot cvut dot cz
 GCC build triplet: x86_64-pc-linux-gnu
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


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

[Bug fortran/36063] [win64] Wrong results for RRSPACING, SCALE, SET_EXPONENT and SPACING

[fxcoudert at gcc dot gnu dot org]

--- Comment #1 from fxcoudert at gcc dot gnu dot org  2008-04-27 18:48 
---
I'll start giving it a look, to see whether it's a Fortran front-end issue or a
more generic win64 issue.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |fxcoudert at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-04-27 18:48:06
   date||


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

[Bug fortran/36063] New: [win64] Wrong results for RRSPACING, SCALE, SET_EXPONENT and SPACING

[fxcoudert at gcc dot gnu dot org]

The following code:

program spacing_bug
   implicit none
   real, parameter :: x1 = 3.14159265358979
   integer, parameter :: ulps1 = 2
   real, parameter :: y1 = ulps1*spacing(x1) ! Only f03
   real, parameter :: y2 = rrspacing(x1) ! Only f03
   real, parameter :: y3 = scale(x1,ulps1) ! Only f03
   real, parameter :: y4 = set_exponent(x1,ulps1) ! Only f03
   real x
   integer ulps

   write(*,*) 'ulps1*spacing(x1) = ', y1
   write(*,*) 'rrspacing(x1) = ', y2
   write(*,*) 'scale(x1,ulps1) = ', y3
   write(*,*) 'set_exponent(x1,ulps1) = ', y4
   x = x1
   ulps = ulps1
   call sub(x,ulps)
end program spacing_bug

subroutine sub(x,ulps)
   implicit none
   real x
   integer ulps
   integer j1(int(ulps*spacing(x)))
   integer j2(int(rrspacing(x))/10)
   integer j3(int(scale(x,ulps)))
   integer j4(int(set_exponent(x,ulps)))
   write(*,*) 'ulps*spacing(x) = ', ulps*spacing(x)
   write(*,*) 'rrspacing(x) = ', rrspacing(x)
   write(*,*) 'scale(x,ulps) = ', scale(x,ulps)
   write(*,*) 'set_exponent(x,ulps) = ', set_exponent(x,ulps)
   write(*,*) 'size(j1) = ', size(j1)
   write(*,*) 'size(j2) = ', size(j2)
   write(*,*) 'size(j3) = ', size(j3)
   write(*,*) 'size(j4) = ', size(j4)
end subroutine sub

gives, on x86_64-pc-mingw32, the output:

 ulps1*spacing(x1) =   4.76837158E-07
 rrspacing(x1) =13176795.
 scale(x1,ulps1) =12.566371
 set_exponent(x1,ulps1) =3.1415927
 ulps*spacing(x) =2.000
 rrspacing(x) =3.1415927
 scale(x,ulps) =3.1415927
 set_exponent(x,ulps) =   0.78539819
 size(j1) =2
 size(j2) =0
 size(j3) =3
 size(j4) =0

while it should give something like (here on i686-apple-darwin):

 ulps1*spacing(x1) =   4.76837158E-07
 rrspacing(x1) =13176795.
 scale(x1,ulps1) =12.566371
 set_exponent(x1,ulps1) =3.1415927
 ulps*spacing(x) =   4.76837158E-07
 rrspacing(x) =13176795.
 scale(x,ulps) =12.566371
 set_exponent(x,ulps) =3.1415927
 size(j1) =0
 size(j2) =  131
 size(j3) =   12
 size(j4) =3

(reported by James Van Buskirk in comp.lang.fortran:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/e9add97708681397)


-- 
   Summary: [win64] Wrong results for RRSPACING, SCALE, SET_EXPONENT
and SPACING
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
 GCC build triplet: x86_64-pc-mingw32
  GCC host triplet: x86_64-pc-mingw32
GCC target triplet: x86_64-pc-mingw32


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

[Bug libfortran/36044] user-requested backtrace

[fxcoudert at gcc dot gnu dot org]

--- Comment #1 from fxcoudert at gcc dot gnu dot org  2008-04-27 18:43 
---
I think compiling with -fbacktrace and calling the STOP intrinsic should emit a
backtrace. Maybe not enough, but still useful.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org


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

[Bug other/36062] -mpc32,-mpc64, and -mpc80 are not documented properly

[ubizjak at gmail dot com]

--- Comment #1 from ubizjak at gmail dot com  2008-04-27 18:05 ---
No, these options are also working well on darwin. Other OSes need to update
their ENDFILE_SPEC entry and their config.gcc entry.

Sorry, I'm not able to test this on other systems than x86-*-linux, so it is up
to  OS maintainers to enable -mpc*. It is a couple of lines only.


-- 


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

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

[danglin at gcc dot gnu dot org]

--- Comment #5 from danglin at gcc dot gnu dot org  2008-04-27 18:01 ---
I first saw this in 133010.


-- 


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

[Bug tree-optimization/9895] GCC unable to retain array values in registers

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2008-04-27 17:21 ---
Which is also the reason for early unrolling not helping.  But at -O3 the
tree loop optimizer unrolls the loop after LIM/PRE "fixed" the size estimate.

But it's too late to clean up at this point (no strong memory optimizers left).


-- 


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

[Bug rtl-optimization/35729] const volatile variable access incorrectly hoisted out of loop

[danglin at gcc dot gnu dot org]

--- Comment #5 from danglin at gcc dot gnu dot org  2008-04-27 17:17 ---
The test pr35729.c also fails on hppa-unknown-linux-gnu.


-- 

danglin 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=35729

[Bug tree-optimization/18754] unrolling happens too late/SRA does not happen late enough

[rguenth at gcc dot gnu dot org]

--- Comment #21 from rguenth at gcc dot gnu dot org  2008-04-27 17:16 
---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug tree-optimization/34223] missed optimization - complete unrolling pass before the vectorizer

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2008-04-27 17:16 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug tree-optimization/18754] unrolling happens too late/SRA does not happen late enough

[rguenth at gcc dot gnu dot org]

--- Comment #20 from rguenth at gcc dot gnu dot org  2008-04-27 16:27 
---
Subject: Bug 18754

Author: rguenth
Date: Sun Apr 27 16:27:08 2008
New Revision: 134730

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134730
Log:
2008-04-27  Richard Guenther  <[EMAIL PROTECTED]>

PR tree-optimization/18754
PR tree-optimization/34223
* tree-pass.h (pass_complete_unrolli): Declare.
* tree-ssa-loop-ivcanon.c (try_unroll_loop_completely): Print
loop size before and after unconditionally of UL_NO_GROWTH in effect.
Rewrite loop into loop closed SSA form if it is not already.
(tree_unroll_loops_completely): Re-structure to iterate over
innermost loops with intermediate CFG cleanups.
Unroll outermost loops only if requested or the code does not grow
doing so.
* tree-ssa-loop.c (gate_tree_vectorize): Don't shortcut if no
loops are available.
(tree_vectorize): Instead do so here.
(tree_complete_unroll): Also unroll outermost loops.
(tree_complete_unroll_inner): New function.
(gate_tree_complete_unroll_inner): Likewise.
(pass_complete_unrolli): New pass.
* tree-ssa-loop-manip.c (find_uses_to_rename_use): Only record
uses outside of the loop.
(tree_duplicate_loop_to_header_edge): Only verify loop-closed SSA
form if it is available.  
* tree-flow.h (tree_unroll_loops_completely): Add extra parameter.
* passes.c (init_optimization_passes): Schedule complete inner
loop unrolling pass before the first CCP pass after final inlining.

* gcc.dg/tree-ssa/loop-36.c: New testcase.
* gcc.dg/tree-ssa/loop-37.c: Likewise.
* gcc.dg/vect/vect-118.c: Likewise.
* gcc.dg/Wunreachable-8.c: XFAIL bogus warning.
* gcc.dg/vect/vect-66.c: Increase loop trip count.
* gcc.dg/vect/no-section-anchors-vect-66.c: Likewise.
* gcc.dg/vect/no-section-anchors-vect-69.c: Likewise.
* gcc.dg/vect/vect-76.c: Likewise.
* gcc.dg/vect/vect-outer-6.c: Likewise.
* gcc.dg/vect/vect-outer-1.c: Likewise.
* gcc.dg/vect/vect-outer-1a.c: Likewise.
* gcc.dg/vect/vect-11a.c: Likewise.
* gcc.dg/vect/vect-shift-1.c: Likewise.
* gcc.target/i386/vectorize1.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-36.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-37.c
trunk/gcc/testsuite/gcc.dg/vect/vect-118.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/passes.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/Wunreachable-8.c
trunk/gcc/testsuite/gcc.dg/vect/no-section-anchors-vect-66.c
trunk/gcc/testsuite/gcc.dg/vect/no-section-anchors-vect-69.c
trunk/gcc/testsuite/gcc.dg/vect/vect-11a.c
trunk/gcc/testsuite/gcc.dg/vect/vect-66.c
trunk/gcc/testsuite/gcc.dg/vect/vect-76.c
trunk/gcc/testsuite/gcc.dg/vect/vect-outer-1.c
trunk/gcc/testsuite/gcc.dg/vect/vect-outer-1a.c
trunk/gcc/testsuite/gcc.dg/vect/vect-outer-6.c
trunk/gcc/testsuite/gcc.dg/vect/vect-shift-1.c
trunk/gcc/testsuite/gcc.target/i386/vectorize1.c
trunk/gcc/tree-flow.h
trunk/gcc/tree-pass.h
trunk/gcc/tree-ssa-loop-ivcanon.c
trunk/gcc/tree-ssa-loop-manip.c
trunk/gcc/tree-ssa-loop.c


-- 


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

[Bug tree-optimization/34223] missed optimization - complete unrolling pass before the vectorizer

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-04-27 16:27 ---
Subject: Bug 34223

Author: rguenth
Date: Sun Apr 27 16:27:08 2008
New Revision: 134730

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134730
Log:
2008-04-27  Richard Guenther  <[EMAIL PROTECTED]>

PR tree-optimization/18754
PR tree-optimization/34223
* tree-pass.h (pass_complete_unrolli): Declare.
* tree-ssa-loop-ivcanon.c (try_unroll_loop_completely): Print
loop size before and after unconditionally of UL_NO_GROWTH in effect.
Rewrite loop into loop closed SSA form if it is not already.
(tree_unroll_loops_completely): Re-structure to iterate over
innermost loops with intermediate CFG cleanups.
Unroll outermost loops only if requested or the code does not grow
doing so.
* tree-ssa-loop.c (gate_tree_vectorize): Don't shortcut if no
loops are available.
(tree_vectorize): Instead do so here.
(tree_complete_unroll): Also unroll outermost loops.
(tree_complete_unroll_inner): New function.
(gate_tree_complete_unroll_inner): Likewise.
(pass_complete_unrolli): New pass.
* tree-ssa-loop-manip.c (find_uses_to_rename_use): Only record
uses outside of the loop.
(tree_duplicate_loop_to_header_edge): Only verify loop-closed SSA
form if it is available.  
* tree-flow.h (tree_unroll_loops_completely): Add extra parameter.
* passes.c (init_optimization_passes): Schedule complete inner
loop unrolling pass before the first CCP pass after final inlining.

* gcc.dg/tree-ssa/loop-36.c: New testcase.
* gcc.dg/tree-ssa/loop-37.c: Likewise.
* gcc.dg/vect/vect-118.c: Likewise.
* gcc.dg/Wunreachable-8.c: XFAIL bogus warning.
* gcc.dg/vect/vect-66.c: Increase loop trip count.
* gcc.dg/vect/no-section-anchors-vect-66.c: Likewise.
* gcc.dg/vect/no-section-anchors-vect-69.c: Likewise.
* gcc.dg/vect/vect-76.c: Likewise.
* gcc.dg/vect/vect-outer-6.c: Likewise.
* gcc.dg/vect/vect-outer-1.c: Likewise.
* gcc.dg/vect/vect-outer-1a.c: Likewise.
* gcc.dg/vect/vect-11a.c: Likewise.
* gcc.dg/vect/vect-shift-1.c: Likewise.
* gcc.target/i386/vectorize1.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-36.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-37.c
trunk/gcc/testsuite/gcc.dg/vect/vect-118.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/passes.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/Wunreachable-8.c
trunk/gcc/testsuite/gcc.dg/vect/no-section-anchors-vect-66.c
trunk/gcc/testsuite/gcc.dg/vect/no-section-anchors-vect-69.c
trunk/gcc/testsuite/gcc.dg/vect/vect-11a.c
trunk/gcc/testsuite/gcc.dg/vect/vect-66.c
trunk/gcc/testsuite/gcc.dg/vect/vect-76.c
trunk/gcc/testsuite/gcc.dg/vect/vect-outer-1.c
trunk/gcc/testsuite/gcc.dg/vect/vect-outer-1a.c
trunk/gcc/testsuite/gcc.dg/vect/vect-outer-6.c
trunk/gcc/testsuite/gcc.dg/vect/vect-shift-1.c
trunk/gcc/testsuite/gcc.target/i386/vectorize1.c
trunk/gcc/tree-flow.h
trunk/gcc/tree-pass.h
trunk/gcc/tree-ssa-loop-ivcanon.c
trunk/gcc/tree-ssa-loop-manip.c
trunk/gcc/tree-ssa-loop.c


-- 


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

[Bug other/36062] New: -mpc32,-mpc64, and -mpc80 are not documented properly

[kargl at gcc dot gnu dot org]

The recently added options -mpc32, -mpc64, and -mpc80 are not documented
properly.
These are claimed to be i386 and amd64 only option.  In fact, these options are
i386, amd64, and *linux only* options.  These options do not work on any other
target.


-- 
   Summary: -mpc32,-mpc64, and -mpc80 are not documented properly
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kargl at gcc dot gnu dot org


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

[Bug fortran/36058] Not allowing pointers to derived types in COMMON

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2008-04-27 15:30 ---
See also:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/773de8d5b57f8e20

(In reply to comment #2)
> I am only concerned with the POINTER case.  I am not placing a
> derived type object in the COMMON block.  I am only storing a
> pointer to it.

But still you want (at least potentially) to access the pointer target at
different scopes. And then the type declaration needs to be the same (storage
wise), which is only guaranteed for SEQUENCE.

Additionally and more formally, the storage unit for a pointer is different if
the type is different (16.4.3.1 Storage sequence, item (8)) and without
SEQUENCE they describe different types [see 4.5.1.3 Determination of derived
types].

Thus I maintain that this is invalid. I'm however less sure about using a
derived type with default initializer and a pointer in a common.

Let's see what will be the reply in comp.lang.fortran.


-- 


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

[Bug c++/36061] Severe internal compiler error when building Battle for Wesnoth 1.4.1 on a Linux from Scratch 6.0 box

[gabrielcvdj at yahoo dot com]

--- Comment #4 from gabrielcvdj at yahoo dot com  2008-04-27 14:43 ---
I inially thought this problem was solved earlier in the 3.4.x series. I've
seen this bug mentioned several times for the 3.4.x series.


-- 


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

[Bug debug/36060] [4.3/4.4 Regression] Too big stack requirements of cc1plus during GC

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2008-04-27 13:33 ---
You can't always do that, sometimes the stack limit is a hard limit.
Additionally, often on Linux setrlimit RLIMIT_STACK after exec is already
too late (as in topdown memory layout things are often mapped already close to
the stack bottom limit) and doing RLIMIT_STACK RLIM_INFINITY in the driver
would result in less desirable VM layout.  So, perhaps the driver could try to
silently up the soft limit to say 256MB or so, but relying on that in gcc is
still risky.


-- 


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

[Bug fortran/36058] Not allowing pointers to derived types in COMMON

[w6ws at earthlink dot net]

--- Comment #2 from w6ws at earthlink dot net  2008-04-27 13:24 ---
Subject: Re:  Not allowing pointers to derived types in
 COMMON

burnus at gcc dot gnu dot org wrote:
> --- Comment #1 from burnus at gcc dot gnu dot org  2008-04-27 08:01 
> ---
> gfortran's rejection is in line with g95, NAG f95, ifort, openf95, sunf95 and
> ifort.

On the other side are PGI and Salford/Silverfrost - who allow the pointer
to reside in the COMMON block.

> Additionally, I think the following also applies to pointers. ("my_wwsptr" is
> of a derived type [albeit with pointer attribute].)
> 
> "C589 (R558) If a common-block-object is of a derived type, it shall be a
> sequence type (4.5.1) or a type with the BIND attribute and it shall have no
> default initialization."

I am only concerned with the POINTER case.  I am not placing a
derived type object in the COMMON block.  I am only storing a
pointer to it.

W.


-- 


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

[Bug debug/36060] [4.3/4.4 Regression] Too big stack requirements of cc1plus during GC

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-04-27 13:08 ---
Similar to PR35204 shouldn't we simply lift soft stack limits at the start of
gcc?


-- 


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

[Bug c++/36061] Severe internal compiler error when building Battle for Wesnoth 1.4.1 on a Linux from Scratch 6.0 box

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-04-27 13:06 ---
3.4.6 works for me.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|critical|normal
 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |3.4.6


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

[Bug ada/36007] [4.4 regression] verify_gimple failed

[ebotcazou at gcc dot gnu dot org]

--- Comment #1 from ebotcazou at gcc dot gnu dot org  2008-04-27 12:32 
---
Fixing.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC|ebotcazou at gcc dot gnu dot|
   |org |
 AssignedTo|unassigned at gcc dot gnu   |ebotcazou at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-04-27 12:32:48
   date||


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

[Bug c++/36061] Severe internal compiler error when building Battle for Wesnoth 1.4.1 on a Linux from Scratch 6.0 box

[gabrielcvdj at yahoo dot com]

--- Comment #2 from gabrielcvdj at yahoo dot com  2008-04-27 11:21 ---
This bug seems to be similar to:
GCC Bugzilla Bug 14452


-- 


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

[Bug c++/36061] Severe internal compiler error when building Battle for Wesnoth 1.4.1 on a Linux from Scratch 6.0 box

[gabrielcvdj at yahoo dot com]

--- Comment #1 from gabrielcvdj at yahoo dot com  2008-04-27 11:08 ---
Created an attachment (id=15535)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15535&action=view)
The preprocessed file that triggers the bug, generated by adding -save-temps

I didn't considered necessary to add the other *.ii files also. Please let me
know if I should provide these as well.


-- 


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

[Bug debug/36060] [4.3/4.4 Regression] Too big stack requirements of cc1plus during GC

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2008-04-27 11:06 ---
As most of the nested calls are due to following die_sib, out of the first
almost 46000 frames I've uped, there were:
20273  gt_ggc_m_10die_struct ((*x).die_sib);
 8878  gt_ggc_m_19VEC_dw_attr_node_gc ((*x).die_attr);
 8877  gt_ggc_m_10die_struct ((*x).base.vec[i0].dw_attr_val.v.val_die_ref.die);
 7220  gt_ggc_m_10die_struct ((*x).die_child);
the best fix is IMHO to mark die_sib as chain_next.  Unfortunately, the DIEs
are linked circularly through the die_sib field, so chain_next doesn't work
properly for that.  I'll post a patch which introduces chain_circular
alternative to chain_next.  With this patch, cc1plus with this testcase on
ppc64-linux native
compiles even with ulimit -s 500, which is 28 times lower stack usage than
before.


-- 


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

[Bug debug/36060] [4.3/4.4 Regression] Too big stack requirements of cc1plus during GC

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2008-04-27 11:00 ---
Created an attachment (id=15534)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15534&action=view)
1.ii.bz2

Preprocessed file from openvrml.


-- 


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

[Bug debug/36060] [4.3/4.4 Regression] Too big stack requirements of cc1plus during GC

[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|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-04-27 10:59:40
   date||
   Target Milestone|--- |4.3.1


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

[Bug c++/36061] New: Severe internal compiler error when building Battle for Wesnoth 1.4.1 on a Linux from Scratch 6.0 box

[gabrielcvdj at yahoo dot com]

Environment:
System: Linux darksky.homeunix.net 2.6.22.9-THUNDERBIRD_31-Shadowfax #3 Tue Oct
2 00:48:34 EEST 2007 i686 athlon-4 i386 GNU/Linux
Architecture: i686


host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ../gcc-3.4.3/configure --prefix=/usr --libexecdir=/usr/lib
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-languages=c,c++,objc,f77,ada,java
Description:
I am using a Linux from Scratch 6.0 GNU/Linux distribution built by
myself. It also features Beyond Linux from Scratch. For two and a half years I
have been using GCC 3.4.3 (both C
and C++ compilers) successfully without even the smallest error,
although I have been using this compiler quite intensively. The
compilation of the compiler itself has was entirely done as
indicated by the LFS book (version 6.0). 
I was trying to build a game, Battle for Wesnoth 1.4.1 (stable
branch) and the C++ compiler crashed during the build process. 
Result of gcc -v:
# gcc -v
Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/specs
Configured with: ../gcc-3.4.3/configure --prefix=/usr
--libexecdir=/usr/lib --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu
--enable-languages=c,c++,objc,f77,ada,java
Thread model: posix
gcc version 3.4.3

I was using the following settings while compiling:
# echo ${CXXFLAGS}
-O3 -msse -mmmx -m3dnow -mfpmath=sse -march=athlon-xp
# echo ${CFLAGS}
-O3 -msse -mmmx -m3dnow -mfpmath=sse -march=athlon-xp

The complete error message can be found below:
Making all in src
make[2]: Entering directory
`/root/battle-for-wesnoth/wesnoth/wesnoth-1.4.1/src'depbase=`echo
actions.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
g++ -DHAVE_CONFIG_H -I. -I..   -I/usr/X11R6/include
-I/usr/include/freetype2 -I ./sdl_ttf -I../intl -I../intl
-I/usr/include/SDL -D_REENTRANT
-DWESNOTH_PATH=\"/usr/share/wesnoth\"
-DLOCALEDIR=\"translations\" -DHAS_RELATIVE_LOCALEDIR=1
-DFIFODIR=\"/usr/var/run/wesnothd\" -DHAVE_PYTHON
-I/usr/include/python2.4 -DHAVE_FRIBIDI -I/usr/include -O2 -W
-Wall -ansi -O3 -msse -mmmx -m3dnow -mfpmath=sse
-march=athlon-xp -DHAVE_BUILTIN_EXPECT  -D_X11
-I/usr/X11R6/include -DWESNOTH_BOOST_TEST_MAIN
-I/usr/include/boost-1_35/ -MT actions.o -MD -MP -MF
$depbase.Tpo -c -o actions.o actions.cpp &&\
mv -f $depbase.Tpo $depbase.Po
actions.cpp: In constructor `attack::attack(game_display&,
const gamemap&, std::vector >&, gamemap::location,
gamemap::location, int, int, unit_map&, const
gamestatus&, const game_data&, bool)':
actions.cpp:1439: internal compiler error: in
stabilize_call, at cp/tree.c:2465
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
make[2]: *** [actions.o] Error 1
make[2]: Leaving directory
`/root/battle-for-wesnoth/wesnoth/wesnoth-1.4.1/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/root/battle-for-wesnoth/wesnoth/wesnoth-1.4.1'
make: *** [all] Error 2

The error seems to be caused by the line:
THROW_END_LEVEL(delayed_exception); 
in src/actions.cpp

At first I thought that the crash could be caused by the lack of swap
space (my machine has 1 GB of RAM, single-processor, AMD Athlon-XP
Barton 2600+). I added 512 MB of swap space (swap file) but the swap
usage was limited. The same result appeared even after adding the swap
space. I also tried to eliminate the CFLAGS and CXXFLAGS and then
reconfiguring and rebuilding the package. The same result was
obtained.


>How-To-Repeat:
I was also using Boost libraries (1.35) and Boost Jam. Unfortunately I
don't know the intricacies of the build process for Wesnoth 1.4.1 so I
cannot exactly say what is the impact of these libraries on the build
process.
When I started building the Battle for Wesnoth 1.4.1 source package I
used the following commands:

# ./configure --prefix=/usr --enable-server --enable-campain-server
--with-server-uid=8000 --with-server-gid=8000 --enable-editor
--enable-tools --with-boost=/usr/include/boost-1_35/

# make

Other packages that were installed in my system at that time:
# automake --version
automake (GNU automake) 1.9.5
Written by Tom Tromey <[EMAIL PROTECTED]>.

Copyright 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There
is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.


# autoconf --version
autoconf (GNU Autoconf) 2.59
Written by David J. MacKenzie and Akim Demaille.

Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There
is NO
warranty; not even for MERCHANTABILITY or FITNES

[Bug debug/36060] New: [4.3/4.4 Regression] Too big stack requirements of cc1plus during GC

[jakub at gcc dot gnu dot org]

On the attached testcase on powerpc64-linux (native, 64-bit cc1plus)
compiling with -O2 -g -w -m64 -mminimal-toc -fPIC results in ICE during garbage
collection.  I've tracked that to excessively deep backtrace when marking
dwarf2 debug info, above 94000 calls in the backtrace, out of this
80462 calls to gt_ggc_mx_die_struct and 14232 gt_ggc_mx_VEC_dw_attr_node_gc
calls.  If I bump the ulimit -s to 14000 it already compiles, with 13500 it
still ICEs.  On ppc64 it is perhaps more visible as each frame takes
128 bytes, so e.g. I don't get ICE with the default ulimit -s 10240 with
x86_64-linux -> powerpc64-linux cross, still the stack usage is massive.


-- 
   Summary: [4.3/4.4 Regression] Too big stack requirements of
cc1plus during GC
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: powerpc64-linux


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

[Bug driver/35956] gcc/g++ print different trunk revision #

[dimhen at gmail dot com]

--- Comment #3 from dimhen at gmail dot com  2008-04-27 10:26 ---
trunk rev.#134722 has no bug


-- 

dimhen at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug fortran/36059] New: -frepack-arrays: symbols w/ TARGET should not be repacked

[burnus at gcc dot gnu dot org]

See thread at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/e9add97708681397

Full example, reported by James Van Buskirk, see
http://groups.google.com/group/comp.lang.fortran/msg/9c42edc4620a1cff

Using -frepack-arrays, the dummy array "x" is repacked in the function. This
repacking should not happen if the TARGET attribute is present as this can lead
to wrong code. (The result symbol "point" points to the repacked array and not
to the original array.)

   function point(x)
 real, intent(in), target :: x(:)
 type(C_PTR) point
 real, pointer :: p

 p => x(2)
 point = C_LOC(p)
  end function point


-- 
   Summary: -frepack-arrays: symbols w/ TARGET should not be
repacked
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug fortran/36058] Not allowing pointers to derived types in COMMON

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2008-04-27 08:01 ---
gfortran's rejection is in line with g95, NAG f95, ifort, openf95, sunf95 and
ifort.

I think gfortran is right and the sequence (or bind(C)) attribute is needed.

The reason is the same as for the following program:

  type my_t
integer :: x, y, z
  end type my_t
  type(my_t) :: tt
  call foo(tt)
contains
subroutine foo(t)
  type foo_t
integer :: x, y, z
  end type foo_t
  type(foo_t) :: t
end subroutine
end

foo_t and my_t are different, incompatible types without SEQUENCE. From that
point of view, it makes sense to reject your example.

Additionally, I think the following also applies to pointers. ("my_wwsptr" is
of a derived type [albeit with pointer attribute].)

"C589 (R558) If a common-block-object is of a derived type, it shall be a
sequence type (4.5.1) or a type with the BIND attribute and it shall have no
default initialization."

 * * *

If one now adds "SEQUENCE", gfortran rejects it as there is a default
initialization; in principle this it can be allowed as the default
initialization does not happen for pointers to derived types (only for its
targets). However, I believe that C589 also applies in this case.

The such modified program is rejected by NAG f95, sunf95, openf95, g95 and
gfortran, but ifort accepts the program.

 * * *

In conclustion, I think both error messages of gfortran are correct.


-- 


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

[Bug target/36049] m68k assembly comment causes assembler error

[kendallc at vxitech dot com]

--- Comment #3 from kendallc at vxitech dot com  2008-04-27 07:32 ---
The issue was the uClibc makefiles having "-Wa,--bitwise-or" as a default
config option. This causes binutils to not treat "|" as a comment.


-- 


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