[Bug bootstrap/38523] New: arm build fails to link cc1-dummy

[laurent at guerby dot net]

At trunk rev 142742 on debian arm-linux-gnueabi bootstrap fails at the end of
stage1 with:

../trunk/configure --prefix=/n/50/guerby/install-trunk --enable-languages=c
--enable-__cxa_atexit --disable-nls --enable-threads=posix
--with-mpfr=/opt/cfarm/mpfr-2.3.2
make bootstrap 
...
gcc  -g -fkeep-inline-functions -DIN_GCC   -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition
-Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H  -o
cc1-dummy c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o
c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o
c-semantics.o c-ppoutput.o c-cppbuiltin.o c-objc-common.o c-dump.o c-pch.o
c-parser.o arm-c.o c-gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o
dummy-checksum.o \
  main.o tree-browser.o libbackend.a ../libcpp/libcpp.a
../libdecnumber/libdecnumber.a ../libcpp/libcpp.a   ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a -L/opt/cfarm/mpfr-2.3.2/lib -lmpfr -lgmp  
attribs.o: In function `init_attributes':
/home/guerby/build/gcc/../../trunk/gcc/attribs.c:182: relocation truncated to
fit: R_ARM_CALL against symbol `htab_create' defined in .text section in
../libiberty/libiberty.a(hashtab.o)
/home/guerby/build/gcc/../../trunk/gcc/attribs.c:191: relocation truncated to
fit: R_ARM_CALL against symbol `htab_find_slot_with_hash' defined in .text
section in ../libiberty/libiberty.a(hashtab.o)
attribs.o: In function `lookup_attribute_spec':
/home/guerby/build/gcc/../../trunk/gcc/attribs.c:210: relocation truncated to
fit: R_ARM_CALL against symbol `htab_find_with_hash' defined in .text section
in ../libiberty/libiberty.a(hashtab.o)
c-lex.o: In function `init_c_lex':
/home/guerby/build/gcc/../../trunk/gcc/c-lex.c:81: relocation truncated to fit:
R_ARM_CALL against symbol `get_run_time' defined in .text section in
../libiberty/libiberty.a(getruntime.o)
/home/guerby/build/gcc/../../trunk/gcc/c-lex.c:85: relocation truncated to fit:
R_ARM_CALL against symbol `cpp_get_callbacks' defined in .text section in
../libcpp/libcpp.a(directives.o)
c-lex.o: In function `get_fileinfo':
/home/guerby/build/gcc/../../trunk/gcc/c-lex.c:110: relocation truncated to
fit: R_ARM_CALL against symbol `splay_tree_new' defined in .text section in
../libiberty/libiberty.a(splay-tree.o)
/home/guerby/build/gcc/../../trunk/gcc/c-lex.c:114: relocation truncated to
fit: R_ARM_CALL against symbol `splay_tree_lookup' defined in .text section in
../libiberty/libiberty.a(splay-tree.o)
/home/guerby/build/gcc/../../trunk/gcc/c-lex.c:118: relocation truncated to
fit: R_ARM_CALL against symbol `xmalloc' defined in .text section in
../libiberty/libiberty.a(xmalloc.o)
/home/guerby/build/gcc/../../trunk/gcc/c-lex.c:122: relocation truncated to
fit: R_ARM_CALL against symbol `splay_tree_insert' defined in .text section in
../libiberty/libiberty.a(splay-tree.o)
c-lex.o: In function `update_header_times':
/home/guerby/build/gcc/../../trunk/gcc/c-lex.c:134: relocation truncated to
fit: R_ARM_CALL against symbol `get_run_time' defined in .text section in
../libiberty/libiberty.a(getruntime.o)
c-lex.o: In function `dump_time_statistics':
/home/guerby/build/gcc/../../trunk/gcc/c-lex.c:154: additional relocation
overflows omitted from the output
collect2: ld returned 1 exit status
make[3]: *** [cc1-dummy] Error 1
make[3]: Leaving directory `/home/guerby/build/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/home/guerby/build'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/guerby/build'
make: *** [bootstrap] Error 2

Any idea on what to try?

Some debian build are successful, eg:

http://gcc.gnu.org/ml/gcc-testresults/2008-12/msg00520.html

But I don't know what configure/patch are critical for building on this
platform.


-- 
   Summary: arm build fails to link cc1-dummy
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: laurent at guerby dot net
 GCC build triplet: arm-linux-gnueabi
  GCC host triplet: arm-linux-gnueabi
GCC target triplet: arm-linux-gnueabi


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

[Bug c/38518] Excessive compile time with -O3

[dcb314 at hotmail dot com]

--- Comment #3 from dcb314 at hotmail dot com  2008-12-14 09:52 ---
(In reply to comment #2)
> On 2.66GHz Cor2 Quad running Fedora 9/x86-64, gcc 4.4 revision 142740 gave:

Thanks for the extra information.

I am concerned that the -O3 takes nine times longer than the -O2.

I'd be interested in finding out where that extra time is 
being spent. I've had a look at "man gcc" but nothing obvious 
is found.


-- 

dcb314 at hotmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|WORKSFORME  |


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

[Bug bootstrap/37349] [4.4 Regression] bootstrap broken on Alpha: undefined reference to _Jv_RegisterClasses

[ubizjak at gmail dot com]

--- Comment #7 from ubizjak at gmail dot com  2008-12-14 10:41 ---
(In reply to comment #6)
> Has this been fixed in the meantime?
> 
> Uros, you wrote in
> http://gcc.gnu.org/ml/gcc/2008-12/msg00228.html that bootstrap works
> on Alpha...

Yes, bootstrap works. I have bootstrapped gcc on gcc30 cfarm machine a couple
of times, last bootstrap from a clean directory was yesterday. Bootstrap
produces working compiler:

u...@sarah:~/gcc-build/gcc$ ./xgcc -v
Using built-in specs.
Target: alphaev56-unknown-linux-gnu
Configured with: ../gcc-svn/trunk/configure --enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.4.0 20081213 (experimental) [ revision ] (GCC) 
u...@sarah:~/gcc-build/gcc$ 

And from (still running) testrun:

--cut here--
LAST_UPDATED: samedi 13 décembre 2008, 16:52:13 (UTC+) (revision )

Native configuration is alphaev56-unknown-linux-gnu

=== gcc tests ===


Running target unix

Compiler version: gcc gcc 
Platform: alphaev56-unknown-linux-gnu
configure flags: --enable-languages=c,c++,fortran
BOOT_CFLAGS=-g -O2
--cut here--


-- 


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

[Bug c++/38524] New: "ICE at cp/typeck.c:2268" on "struct{enum E{};}A;int main(){A.E::foo;}"

[logixoul at gmail dot com]

The following source:
struct{enum E{};}A;int main(){A.E::foo;}
generates:
"internal compiler error: in finish_class_member_access_expr, at
cp/typeck.c:2268"


-- 
   Summary: "ICE at cp/typeck.c:2268" on "struct{enum E{};}A;int
main(){A.E::foo;}"
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: logixoul at gmail dot com
 GCC build triplet: 4.4.0 20080929 (experimental)
  GCC host triplet: 4.4.0 20080929 (experimental)
GCC target triplet: 4.4.0 20080929 (experimental)


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

[Bug c++/38524] "ICE at cp/typeck.c:2268" on "struct{enum E{};}A;int main(){A.E::foo;}"

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2008-12-14 11:59 
---
Can't reproduce the ICE with current (142748) mainline:

38524.C:1: warning: non-local variable ‘ A’ uses anonymous
type
38524.C: In function ‘int main()’:
38524.C:1: error: ‘E’ is not a class or namespace

If you can, please re-open.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME


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

[Bug c/38521] -masm=intel, struct output for __asm__() block causes gcc to ask for bug report.

[ubizjak at gmail dot com]

--- Comment #1 from ubizjak at gmail dot com  2008-12-14 11:18 ---
There were many problems with -masm=intel, that were fixed for gcc-4.3 and
later by [1] and (many) followup patches. The change that you are looking for
is (gcc/config/i386/i386.c):

@@ -9037,8 +9047,9 @@ print_operand (FILE *file, rtx x, int co

   else if (MEM_P (x))
 {
-  /* No `byte ptr' prefix for call instructions.  */
-  if (ASSEMBLER_DIALECT == ASM_INTEL && code != 'X' && code != 'P')
+  /* No `byte ptr' prefix for call instructions or BLKmode operands.  */
+  if (ASSEMBLER_DIALECT == ASM_INTEL && code != 'X' && code != 'P'
+ && GET_MODE (x) != BLKmode)
{
  const char * size;
  switch (GET_MODE_SIZE (GET_MODE (x)))


However, this is just one of many changes to properly support -masm=intel, so
my best advice is to use gcc-4.3.x. This won't be fixed for gcc-4.2.

[1] http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01254.html


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||4.3.0
 Resolution||WONTFIX


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

[Bug middle-end/38520] [graphite] wrong code with -O3 -fgraphite-identity on polyhedron benchmarks

[dominiq at lps dot ens dot fr]

--- Comment #2 from dominiq at lps dot ens dot fr  2008-12-14 14:10 ---
The test protein.f90 fails when compiled with  "-O1 -fstrict-overflow
-fgraphite-identity". It works with "-O3 -fno-strict-overflow
-fgraphite-identity".

The test capacita.f90 fails when compiled with "-O1 -fstrict-aliasing
-fstrict-overflow -fgraphite-identity" and works with "-O3 -fno-strict-aliasing
-fno-strict-overflow -fgraphite-identity".


-- 


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

[Bug c/37865] gfortran build fails in stage 3 bootstrap with --enable-intermodule

[mikael at gcc dot gnu dot org]

--- Comment #3 from mikael at gcc dot gnu dot org  2008-12-14 14:46 ---
(In reply to comment #2)
> I'm not sure what 'now' means.  It's still true for release 4.3.2!
> I'm prepared to test with the live sources, but do you want me to?
Sure!

> Do you believe that the problem has been understood and addressed,
Not by me at least... ;-)
> or are you hoping that it's gone away (not for the first time in
> the history of gcc 4.x.x)?
Yes, I have seen some recent bootstrap fixing patches going in. 
So the bug could be fixed now. 
If it isn't, you will have to find the offending configure option(s) :-(. 


-- 


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

[Bug c/37865] gfortran build fails in stage 3 bootstrap with --enable-intermodule

[aldot at gcc dot gnu dot org]

--- Comment #4 from aldot at gcc dot gnu dot org  2008-12-14 15:30 ---
Sounds a bit like the problem from comment #0 is a duplicate or related to
PR31537 and/or PR35034 ?


-- 


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

[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)

[dominiq at lps dot ens dot fr]

--- Comment #12 from dominiq at lps dot ens dot fr  2008-12-14 15:54 ---
Could you try with the addition of " -fno-strict-aliasing
-fno-strict-overflow"? See pr38520.


-- 


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

[Bug fortran/35937] Wrong type for charlength of function

[pault at gcc dot gnu dot org]

--- Comment #19 from pault at gcc dot gnu dot org  2008-12-14 16:01 ---
Subject: Bug 35937

Author: pault
Date: Sun Dec 14 16:00:25 2008
New Revision: 142750

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142750
Log:
2008-12-14  Paul Thomas  

PR fortran/35937
* trans-expr.c (gfc_finish_interface_mapping): Fold convert the
character length to gfc_charlen_type_node.

2008-12-14  Paul Thomas  

PR fortran/35937
* gfortran.dg/char_length_14.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/char_length_14.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/35937] Wrong type for charlength of function

[pault at gcc dot gnu dot org]

--- Comment #20 from pault at gcc dot gnu dot org  2008-12-14 16:09 ---
Subject: Bug 35937

Author: pault
Date: Sun Dec 14 16:07:46 2008
New Revision: 142751

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142751
Log:
2008-12-14  Paul Thomas  

PR fortran/35937
* trans-expr.c (gfc_finish_interface_mapping): Fold convert the
character length to gfc_charlen_type_node.

2008-12-14  Paul Thomas  

PR fortran/35937
* gfortran.dg/char_length_14.f90: New test.

Added:
branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/char_length_14.f90
Modified:
branches/gcc-4_3-branch/gcc/fortran/ChangeLog
branches/gcc-4_3-branch/gcc/fortran/trans-expr.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/35937] Wrong type for charlength of function

[pault at gcc dot gnu dot org]

--- Comment #21 from pault at gcc dot gnu dot org  2008-12-14 16:11 ---
Fixed on trunk and 4.3.

Thanks for the report.

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/38525] New: sse2(int16) code fails with -O3

[leonid at volnitsky dot com]

When compiling attached unit test with -O3, it fails on sse2 test.  With any
other optimization  level including -O2 plus: 
   -fgcse-after-reload
   -finline-functions 
   -fipa-cp-clone 
   -fpredictive-commoning -ftree-vectorize   
   -funswitch-loops
which should be the same as -O3, it passes unit test succesfully. 

Gentoo x86_64, with  gcc-4.4 and 4.3.2
Project page: http://volnitsky/project/lvvlib
Source: http://github.com/lvv/lvvlib
u-array.ii.gz attached. 

-
g++  u-array.cc -o u-array -Wall
-DID='"081214_183302-��g++-4.4.0-OPTIMIZE-0e541970++M"'   -I ~/p/  -I
/usr/local/include -DNDEBUG  -DGSL_RANGE_CHECK_OFF -DNOCHECK   -pipe
-Wno-reorder -Wno-sign-compare  -O3 -march=native  -fwhole-program --combine 
-fopenmp -fomit-frame-pointer -funsafe-loop-optimizations  -DGCC_BUG -O3 -v  
-Wno-unused-variable -Wno-unused-variable  
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ./configure : (reconfigured) ./configure --disable-bootstrap
--enable-languages=c,c++,fortran --enable-multilib
Thread model: posix
gcc version 4.4.0 20081208 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-o' 'u-array' '-Wall'
'-DID="081214_183302-��g++-4.4.0-OPTIMIZE-0e541970++M"' '-I' '/home/lvv/p/'
'-I' '/usr/local/include' '-DNDEBUG' '-DGSL_RANGE_CHECK_OFF' '-DNOCHECK'
'-pipe' '-Wno-reorder' '-Wno-sign-compare' '-O3'  '-fwhole-program' '-combine'
'-fopenmp' '-fomit-frame-pointer' '-funsafe-loop-optimizations' '-DGCC_BUG'
'-O3' '-v' '-Wno-unused-variable' '-shared-libgcc' '-pthread'
 /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/cc1plus -quiet -v -I
/home/lvv/p/ -I /usr/local/include -D_GNU_SOURCE -D_REENTRANT
-DID="081214_183302-��g++-4.4.0-OPTIMIZE-0e541970++M" -DNDEBUG
-DGSL_RANGE_CHECK_OFF -DNOCHECK -DGCC_BUG u-array.cc -march=core2 -mcx16 -msahf
--param l1-cache-size=32 --param l1-cache-line-size=64 --param
l2-cache-size=4096 -mtune=core2 -quiet -dumpbase u-array.cc -auxbase u-array
-O3 -O3 -Wall -Wno-reorder -Wno-sign-compare -Wno-unused-variable -version
-fwhole-program -fopenmp -fomit-frame-pointer -funsafe-loop-optimizations -o -
|
 as -V -Qy -o /tmp/ccO8IZrX.o -
GNU assembler version 2.18 (x86_64-pc-linux-gnu) using BFD version (GNU
Binutils) 2.18
ignoring nonexistent directory
"/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../x86_64-unknown-linux-gnu/include"
ignoring duplicate directory "/usr/local/include"
  as it is a non-system directory that duplicates a system directory
ignoring duplicate directory "/usr/local/include"
  as it is a non-system directory that duplicates a system directory
#include "..." search starts here:
#include <...> search starts here:
 /home/lvv/p/

/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../include/c++/4.4.0

/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../include/c++/4.4.0/x86_64-unknown-linux-gnu

/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../include/c++/4.4.0/backward
 /usr/local/include
 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/include
 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/include-fixed
 /usr/include
End of search list.
GNU C++ (GCC) version 4.4.0 20081208 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.4.0 20081115 (experimental), GMP version
4.2.4, MPFR version 2.3.2.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: f0165b2e8081c04e24b530c99a2b0b81
COMPILER_PATH=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/:/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/:/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/:/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/:/usr/local/lib/gcc/x86_64-unknown-linux-gnu/
LIBRARY_PATH=/usr/local/lib/../lib64/:/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/:/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:./:/usr/local/lib/:/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../:/lib/:/usr/lib/
Reading specs from /usr/local/lib/../lib64/libgomp.spec
COLLECT_GCC_OPTIONS='-o' 'u-array' '-Wall'
'-DID="081214_183302-��g++-4.4.0-OPTIMIZE-0e541970++M"' '-I' '/home/lvv/p/'
'-I' '/usr/local/include' '-DNDEBUG' '-DGSL_RANGE_CHECK_OFF' '-DNOCHECK'
'-pipe' '-Wno-reorder' '-Wno-sign-compare' '-O3'  '-fwhole-program' '-combine'
'-fopenmp' '-fomit-frame-pointer' '-funsafe-loop-optimizations' '-DGCC_BUG'
'-O3' '-v' '-Wno-unused-variable' '-shared-libgcc' '-pthread'
 /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/collect2 --eh-frame-hdr
-m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o u-array
/usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/crtbegin.o
-L/usr/local/lib/../lib64 -L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0
-L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64 -L. -L/us

[Bug c++/38525] sse2(int16) code fails with -O3

[leonid at volnitsky dot com]

--- Comment #1 from leonid at volnitsky dot com  2008-12-14 16:52 ---
Created an attachment (id=16907)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16907&action=view)
u-array.ii  


-- 


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

[Bug middle-end/38520] [graphite] wrong code with -O3 -fgraphite-identity on polyhedron benchmarks

[dominiq at lps dot ens dot fr]

--- Comment #3 from dominiq at lps dot ens dot fr  2008-12-14 17:32 ---
Compiling mdbx.f90 with "-m64 -O3 -fgraphite-identity -floop-block
-ftree-loop-linear -fno-strict-overflow" gives an ICE:

mdbx.f90: In function 'mstep':
mdbx.f90:822: internal compiler error: Bus error
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

The test compiles and gives a correct excutable if -m64 is removed.


-- 


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

[Bug testsuite/38526] New: WARNING: Could not compile gcc.dg/compat/struct-layout-1 generator

[danglin at gcc dot gnu dot org]

Executing on build: gcc -g -O2 -o
/Users/dave/gnu/gcc/objdir/gcc/testsuite/gcc/g
cc.dg-struct-layout-1_generate.exe -DSKIP_DECIMAL_FLOAT
/Users/dave/gnu/gcc/gcc/
gcc/testsuite/gcc.dg/compat/struct-layout-1_generate.c
/Users/dave/gnu/gcc/gcc/g
cc/testsuite/gcc.dg/compat/generate-random.c
/Users/dave/gnu/gcc/gcc/gcc/testsui
te/gcc.dg/compat/generate-random_r.c(timeout = 300)
gcc: error trying to exec 'cc1': execvp: No such file or directory
gcc: error trying to exec 'cc1': execvp: No such file or directory
gcc: error trying to exec 'cc1': execvp: No such file or directory
WARNING: Could not compile gcc.dg/compat/struct-layout-1 generator
testcase
/Users/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/compat/struct-layout-1.exp
 completed in 0 seconds

This doesn't happen when I use the system's gcc compiler for initial bootstrap.
However, it doesn't support Ada, so I use my own gcc build for bootstrap.

export CC=gcc
export
PATH=/opt/gnu/gcc/gcc-4.3.2/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/
bin:/usr/X11/bin

When GCC_EXEC_PREFIX is not set in the environment, gcc finds the installed
cc1.  However, when GCC_EXEC_PREFIX is set in the environment to the null
string, gcc doesn't find cc1.

We have this code in struct-layout-1.exp:

# Temporarily unset GCC_EXEC_PREFIX from environment, as that might
# confuse the $HOSTCC.
set orig_gcc_exec_prefix_saved 0
if [info exists env(GCC_EXEC_PREFIX)] {
 set orig_gcc_exec_prefix "$env(GCC_EXEC_PREFIX)"
 set orig_gcc_exec_prefix_saved 1
 unsetenv GCC_EXEC_PREFIX
}

For some reason, the dejagnu "unsetenv" command doesn't actually unset
GCC_EXEC_PREFIX on darwin9.


-- 
   Summary: WARNING: Could not compile gcc.dg/compat/struct-layout-1
generator
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: i686-apple-darwin9
  GCC host triplet: i686-apple-darwin9
GCC target triplet: i686-apple-darwin9


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

[Bug c++/38525] sse2(int16) code fails with -O3

[ubizjak at gmail dot com]

--- Comment #2 from ubizjak at gmail dot com  2008-12-14 19:29 ---
I can't compile the attachment:

g++ -O3 -fpreprocessed u-array.ii 
In file included from /home/lvv/p/lvv/sse.h:23,
 from /home/lvv/p/lvv/array.h:35,
 from u-array.cc:10:
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/include/pmmintrin.h: In
function ‘float __vector__ _mm_addsub_ps(float __vector__, float __vector__)’:
[...]

However, since you already found a failing test, please reduce your source to a
short, self contained runtime testcase (in plain C if possible) that fails with
certain compile flags.


-- 


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

[Bug c++/38525] sse2(int16) code fails with -O3

[ubizjak at gmail dot com]

--- Comment #3 from ubizjak at gmail dot com  2008-12-14 19:31 ---
(In reply to comment #2)

> /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/include/pmmintrin.h: In
> function ‘float __vector__ _mm_addsub_ps(float __vector__, float __vector__)’:

g++ -O3 -fpreprocessed u-array.ii 
In file included from /home/lvv/p/lvv/sse.h:23,
 from /home/lvv/p/lvv/array.h:35,
 from u-array.cc:10:
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/include/pmmintrin.h: In
function ‘float __vector__ _mm_addsub_ps(float __vector__, float __vector__)’:
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/include/pmmintrin.h:53:
error: ‘__builtin_ia32_addsubps’ was not declared in this scope
[...]


-- 


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

[Bug c++/38525] sse2(int16) code fails with -O3

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2008-12-14 19:57 ---
(In reply to comment #3)
> (In reply to comment #2)
> 
> > /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/include/pmmintrin.h: In
> > function �float __vector__ _mm_addsub_ps(float __vector__, float 
> > __vector__)�:
> 
> g++ -O3 -fpreprocessed u-array.ii 
> In file included from /home/lvv/p/lvv/sse.h:23,
>  from /home/lvv/p/lvv/array.h:35,
>  from u-array.cc:10:
> /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/include/pmmintrin.h: In
> function �float __vector__ _mm_addsub_ps(float __vector__, float 
> __vector__)�:
> /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/include/pmmintrin.h:53:
> error: �__builtin_ia32_addsubps� was not declared in this scope
> [...]
> 

You need to use -march=core2 to enable SSSE3.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||hjl dot tools at gmail dot
   ||com


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

[Bug c++/38525] sse2(int16) code fails with -O3

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2008-12-14 19:59 ---
(In reply to comment #1)
> Created an attachment (id=16907)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16907&action=view) [edit]
> u-array.ii  
> 

Please extract the failed ones to create a smaller testcase.


-- 


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

[Bug testsuite/38526] WARNING: Could not compile gcc.dg/compat/struct-layout-1 generator

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2008-12-14 20:07 ---
This is really PR 36443.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

  BugsThisDependsOn||36443


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

[Bug c/38527] New: Gcc optimizes code to an endless loop

[gray at gnu dot org dot ua]

When compiling the following program with -O2, gcc optimizes the var_unwind_all
function to an endless loop. Without -O, the program is compiled and runs
correctly. The same error is present with gcc 4.3.0.

The program is (no includes):

struct rlist {
struct rlist *prev;
};

void
_list_remove(struct rlist **last, struct rlist *obj)
{
*last = obj->prev;
}


struct var {
struct var *prev;
};

struct var *var_last;

void
var_unwind_all()
{
while (var_last)
_list_remove((struct rlist**)&var_last,
 (struct rlist*)var_last);
;
}


/* Implementation */
struct var bucket[2];

int
main()
{
int i;
struct var *cur;

/* Create the list */
for (i = 0; i < sizeof(bucket)/sizeof(bucket[0]); i++) {
cur = bucket + i;
cur->prev = var_last;
var_last = cur;
}

/* Deallocate it */
var_unwind_all();

return 0;
}

The generated .s file contains:

.L10:


-- 
   Summary: Gcc optimizes code to an endless loop
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gray at gnu dot org dot ua
 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=38527

[Bug c/38528] New: ICE while building libgfortran (gcc bootstrap)

[bernard at brenda-arkle dot me dot uk]

Apologies if 4.3.3 isn't the right magic version: seen in Revision 142751
(today's live trunk).

While trying to verify Bug 37865 (not connected) on the live tree:
during the building of libgfortran in stage 3 (so supposedly with a
"correct" gcc build) I got

internal compiler error: in change_decl_assembler_name, at cgraph.c:1256

A slightly reduced test-case uses the command-line

/mnt/devel/lfs/lfs-build/gcc-2008-12-14/build-gcc-2008-12-14/./gcc/xgcc
-B/mnt/devel/lfs/lfs-build/gcc-2008-12-14/build-gcc-2008-12-14/./gcc/
-B/usr/i686-pc-linux-gnu/bin/ -B/usr/i686-pc-linux-gnu/lib/ -std=gnu99
-fcx-fortran-rules -march=athlon64 -c error.cpp.c fpu.cpp.c -combine

with the source files attached.   This build was configured as

'../gcc-2008-12-14/configure' '--prefix=/usr' '--libexecdir=/usr/lib'
'--infodir=/usr/share/info' '--mandir=/usr/share/man' '--enable-libada'
'--enable-libssp' '--disable-werror' '--with-mpfr=/usr' '--with-gmp=/usr'
'--with-datarootdir=/usr/share' '--with-docdir=/usr/share/gcc-2008-12-14/doc'
'--with-pdfdir=/usr/share/gcc-2008-12-14/doc'
'--with-htmldir=/usr/share/gcc-2008-12-14/doc/html' '--disable-coverage'
'--enable-nls' '--enable-__cxa_atexit' '--enable-decimal-float'
'--disable-fixed-point' '--enable-threads=posix' '--enable-clocale=gnu'
'--enable-shared' '--enable-intermodule'
'--enable-languages=ada,c++,fortran,java,objc,obj-c++,c'
'--with-local-prefix=/usr' '--with-gnu-ld' '--with-demangler-in-ld'
'--with-gnu-as' '--with-system-libunwind' '--with-system-zlib'
'--enable-bootstrap'

The CPU is an Athlon64 X2.


-- 
   Summary: ICE while building libgfortran (gcc bootstrap)
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bernard at brenda-arkle dot me dot uk
  GCC host triplet: i686-pc-linux-gnu


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

[Bug c/38527] Gcc optimizes code to an endless loop

[gray at gnu dot org dot ua]

--- Comment #1 from gray at gnu dot org dot ua  2008-12-14 20:15 ---
My apologies for the inclomplete last line of the posting.  It should read:
The generated .s code contains:

.L10:
jmp .L10


-- 


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

[Bug c/38528] ICE while building libgfortran (gcc bootstrap)

[bernard at brenda-arkle dot me dot uk]

--- Comment #1 from bernard at brenda-arkle dot me dot uk  2008-12-14 20:15 
---
Created an attachment (id=16908)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16908&action=view)
First source file in test-case


-- 


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

[Bug c/38528] ICE while building libgfortran (gcc bootstrap)

[bernard at brenda-arkle dot me dot uk]

--- Comment #2 from bernard at brenda-arkle dot me dot uk  2008-12-14 20:16 
---
Created an attachment (id=16909)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16909&action=view)
Second source-file of test case (2/2)


-- 


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

[Bug c/37865] gfortran build fails in stage 3 bootstrap with --enable-intermodule

[bernard at brenda-arkle dot me dot uk]

--- Comment #5 from bernard at brenda-arkle dot me dot uk  2008-12-14 20:30 
---
Responding to comment #3: *Ahem*.  I tried with today's live sources
(revision 142751).  I got as far as building libgfortran in stage 3, and
*bang*.  Bug 35828, which see.  It's not obviously related to the
problem here (though presumably there are some options which don't
produce it, of which --enable-intermodule may perhaps be one).


-- 


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

[Bug c/38527] Gcc optimizes code to an endless loop

[schwab at suse dot de]

--- Comment #2 from schwab at suse dot de  2008-12-14 20:36 ---
_list_remove((struct rlist**)&var_last,
 (struct rlist*)var_last);

This violates the C aliasing rules.

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


-- 

schwab at suse dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c/21920] aliasing violations

[schwab at suse dot de]

--- Comment #135 from schwab at suse dot de  2008-12-14 20:36 ---
*** Bug 38527 has been marked as a duplicate of this bug. ***


-- 

schwab at suse dot de changed:

   What|Removed |Added

 CC||gray at gnu dot org dot ua


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

[Bug c++/38525] sse2(int16) code fails with -O3

[leonid at volnitsky dot com]

--- Comment #6 from leonid at volnitsky dot com  2008-12-14 21:00 ---
Created an attachment (id=16910)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16910&action=view)
Trimmed unit test.  Only one,  relevant to bug test


-- 

leonid at volnitsky dot com changed:

   What|Removed |Added

  Attachment #16907|0   |1
is obsolete||


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

[Bug testsuite/38526] WARNING: Could not compile gcc.dg/compat/struct-layout-1 generator

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca  2008-12-14 
22:25 ---
Subject: Re:  WARNING: Could not compile gcc.dg/compat/struct-layout-1
generator

> This is really PR 36443.

Aside from darwin specific issues with the environment, the problem looks
the same.  Did anybody try Mark's suggestion (i.e., setting HOSTCC to
"unset GCC_EXEC_PREFIX && gcc")?

Dave


-- 


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

[Bug target/38062] FAIL: gfortran.dg/include_2.f90 -O (test for excess errors): error: stray '#' in program

[danglin at gcc dot gnu dot org]

--- Comment #7 from danglin at gcc dot gnu dot org  2008-12-14 22:31 ---
Subject: Bug 38062

Author: danglin
Date: Sun Dec 14 22:30:32 2008
New Revision: 142755

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142755
Log:
PR target/38062
Backport from mainline:
2008-04-08  John David Anglin  

* collect2.c (write_c_file): Don't wrap in "#ifdef __cplusplus".


Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/collect2.c


-- 


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

[Bug c++/38525] sse2(int16) code fails with -O3

[leonid at volnitsky dot com]

--- Comment #7 from leonid at volnitsky dot com  2008-12-14 22:32 ---
(In reply to comment #2)
> ... please reduce your source to a
> short, self contained runtime testcase (in plain C if possible) that fails 
> with
> certain compile flags.

I've tried to do that (see below).  But unfortunately it does not exhibit same
behavior. It will fail on any optimized compile with warning about aliasing.
Which is fixable by adding -fno-strict-aliasing. Don't know if this is related
on not. 

-
#include 
#include 

int main(int argc, char *argv[]) {

int16_t  volatile A[2000];
for (int i=0; i<(2000-2); i+=2) { A[i]=1;  A[i+1]=2; };  A[333] = 3; 

 #define mk_m128i(x) *(__m128i*)&(x)
__m128i m1 = mk_m128i(A[0]);
__m128i m2 = mk_m128i(A[8]);

for (int i= 16;  i < 2000-16; i+=16) {  // SSE
 m1 = _mm_max_epi16(m1, mk_m128i(A[i]) ); 
 m2 = _mm_max_epi16(m2, mk_m128i(A[i+8]) ); 
}  

m1 = _mm_max_epi16(m1, m2);

int16_t* ip  = (int16_t*)&m1;  
printf("%hi %hi %hi %hi  %hi %hi %hi %hi \n", *ip++, *ip++, *ip++,
*ip++, *ip++, *ip++, *ip++, *ip);   

return 0;   
 }




-- 


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

[Bug target/38062] FAIL: gfortran.dg/include_2.f90 -O (test for excess errors): error: stray '#' in program

[danglin at gcc dot gnu dot org]

--- Comment #8 from danglin at gcc dot gnu dot org  2008-12-14 22:32 ---
Fixed.


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug c/37865] gfortran build fails in stage 3 bootstrap with --enable-intermodule

[mikael at gcc dot gnu dot org]

--- Comment #6 from mikael at gcc dot gnu dot org  2008-12-15 00:14 ---
(In reply to comment #4)
> Sounds a bit like the problem from comment #0 is a duplicate or related to
> PR31537 and/or PR35034 ?
> 
31537 seems definitely related. 
Is there a specific option/configuration to reproduce/bypass it?

(In reply to comment #5)
> Responding to comment #3: *Ahem*.  I tried with today's live sources
> (revision 142751).  I got as far as building libgfortran in stage 3, and
> *bang*.  Bug 35828, which see.  It's not obviously related to the
> problem here (though presumably there are some options which don't
> produce it, of which --enable-intermodule may perhaps be one).
> 
s/Bug 35828/Bug 38528/
It seems some configure options are not much tested. :-(
Something has just come to my mind. 
Since you are on i686-pc-linux-gnu, I'm not sure it is legal to specify
-march=athlon64-sse3 as it will use the 64 bits extensions.
>From the gcc manual:
_k8, opteron, athlon64, athlon-fx_
  AMD K8 core based CPUs with x86-64 instruction set support.
  (This supersets MMX, SSE, SSE2, 3dNOW!, enhanced 3dNOW! and
  64-bit instruction set extensions.)

_k8-sse3, opteron-sse3, athlon64-sse3_
  Improved versions of k8, opteron and athlon64 with SSE3
  instruction set support.


-- 


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

[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI

[joseph at codesourcery dot com]

--- Comment #12 from joseph at codesourcery dot com  2008-12-15 00:21 
---
Subject: Re:  Gcc misaligns arrays when stack is forced
 follow the x8632 ABI

On Fri, 12 Dec 2008, whaley at cs dot utsa dot edu wrote:

> >LSB may be a starting point for plausible hypotheses about the ABIs, but 
> >you need to evaluate it critically to see whether each statement is 
> >actually an accurate description of fact.
> 
> I.e., you are saying "we don't adhere to any standards: whatever we do is the
> standard".  Again, I wonder how you feel about that attitude when microsoft

No; "The nice thing about standards is that there are so many to choose 
from" is a well-known saying.  GCC chooses certain standards and documents 
those choices in the manuals.  For the >99.% of standards not 
documented as being used by GCC, you should not assume they have been 
chosen, or that they are of any more relevance to GCC than the standard 
for making a cup of tea.  Not choosing to implement a standard is not a 
bug - GCC does not make tea - though you might have a feature request to 
implement a new feature where a particular standard is followed.  You are 
free to procure software on the basis of which of many standards it 
chooses to implement and how accurately it does so; if producers of 
compilers that do not make tea find that compilers making tea are more 
widely used because they make tea, this may cause the tea-making feature 
to be added to more compilers.

Anyone can write a document that says anything and put any title on it.  
Anyone else can write a contradictory document with the same title and 
claim that document instead is the true standard.  That someone has 
written such a document gives it no special status for GCC whatever.  
There is nothing magical about being a "standard"; it's just another 
document describing something that may or may not be useful, may or may 
not describe something a particular piece of software aims to implement, 
and may or may not describe what a particular piece of software does 
implement.  If multiple implementations choose to try to implement the 
same document, or if it has been prepared to match what implementations 
do, it may then be of use in describing how to interoperate with those 
implementations.  If it was written to describe how someone wishes things 
would work but they don't work that way, any influence they have to change 
how things work will have to come from a source other than that they have 
written down their wishes and put the word "standard" wishfully on them.

> says it?  Would you like to argue that ODF is useless, since MSOffice binary
> formats are more accurate description of fact?  I don't like it when MS

ODF is useless for interoperating with MS Office if MS Office does not 
choose to use that standard for interoperation.  That's obviously a choice 
for the MS Office maintainers.  Anyone can invent a document format, write 
a description and call that description a standard, but writing the 
description doesn't make it any more or less appropriate for MS Office to 
implement the format.

Where OOXML differs from the formats in fact used by MS Office, this may 
very well be a bug in the specification, whose only use is likely to be 
interoperating with MS Office.  If all implementations of ODF do the same 
thing which contradicts the literal text of ODF, that is likely to be a 
bug in the specification as well, since the text is not serving the 
purpose of interoperation.

> kind of boggles my mind.  If a standard is out of date, you write a new
> standard, or admit you are violating it in certain respects, not make the
> absurd claim that whatever you happen to like doing this week is the standard.

GCC's manuals "violate" the ODF specification you mentioned above by being 
in Texinfo.  This is not a bug; it's simply there are millions of 
"standards" and almost all are more or less completely irrelevant to GCC.  
GCC no longer supports SCO Unix, so even if the document you like was an 
accurate description of how to interoperate with SCO Unix versions from 
1996 that does not make it relevant to GCC.

Anyone with the person-years to spend is free to write their own "new 
standard" describing what they think a particular ABI should be.  There is 
no particular reason for anyone else to care about that document unless it 
reflects reality or there is a genuine commitment from multiple involved 
parties to implement the document where it describes something different 
from reality.  That might apply, for example, if direction comes from the 
CPU vendor with agreement of multiple involved parties (c.f. the ARM EABI, 
or the Power.org effort I mentioned); maybe those producing x86 processors 
would like to coordinate the person-years of effort needed either to write 
a specification accurately describing the present ABI or develop a new and 
incompatible better ABI.  (The SCO copyrights prevent just patching the 
existing document, even if mu

[Bug c++/38377] __builtin_constant_p(t) ? t : 1 is not considered a constant integer expression

[joseph at codesourcery dot com]

--- Comment #8 from joseph at codesourcery dot com  2008-12-15 00:31 ---
Subject: Re:  __builtin_constant_p(t) ? t : 1 is not considered
 a constant integer expression

I also added more __builtin_constant_p tests (gcc.dg/bconstp-[34].c) to 
c-4_5-branch, following this discussion, to verify more of the model for 
how __builtin_constant_p works in constant expressions.  In general the 
constant expressions tests there (both those added there, and the 
previously existing constant expressions / overflow diagnostics tests, 
most of which have had XFAILs removed on the branch) reflect my 
interpretation for the GNU C language of both the standard constant 
expressions rules where unclear and of how the rules should be applied to 
new language features in GNU C that aren't in ISO C.


-- 


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

[Bug tree-optimization/38401] TreeSSA-PRE load after store misoptimization

[sergeid at il dot ibm dot com]

--- Comment #14 from sergeid at il dot ibm dot com  2008-12-15 07:17 ---
Ok, since this case is the only one where RTL PRE (gcse-las) improves
performance and it can be dealt with at the TreeSSA level, it should be ok to
remove gcse-las from mainline and keep this PR open? 


-- 


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

[Bug tree-optimization/38529] New: [4.3/4.4 regression] ICE with nested loops

[reichelt at gcc dot gnu dot org]

The following valid code snippet triggers an ICE since GCC 4.3.0 when
compiled with "-O3 -march=pentium4" or "-O -ftree-vectorize -march=pentium4":

==
float a[4];

void foo()
{
  int i, j;

  for (i = 0; i < 4; ++i)
for (j = 0; j < 17; ++j)
  a[i] = 0;
}
==

bug.c: In function 'foo':
bug.c:3: internal compiler error: in vect_get_vec_def_for_operand, at
tree-vect-transform.c:2000
Please submit a full bug report, [etc.]


-- 
   Summary: [4.3/4.4 regression] ICE with nested loops
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, monitored
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug tree-optimization/38529] [4.3/4.4 regression] ICE with nested loops

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.3.3


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