[Bug fortran/40612] internal compiler error: in gfc_add_modify, at fortran/trans.c
--- Comment #9 from burnus at gcc dot gnu dot org 2009-07-03 06:40 --- (In reply to comment #8) Please try with a newer version of gfortran. Literally, hundreds of bugs and changes have occurred since version 4.3.0 was released. I believe this bug is a duplicate of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34026 If it is PR 34026, using the 4.3.0 release (instead of a 4.3.0 developer version) is enough. For a recent 4.5 build, see e.g. http://gcc.gnu.org/wiki/GFortranBinaries#MacOS1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40612
[Bug c/40627] not following right-then-left rule when compiling function pointers
--- Comment #1 from raeburn at raeburn dot org 2009-07-03 06:45 --- (In reply to comment #0) , but it does not seem to recognize that the following is also a valid prototype: int count * ( demo_counter * self, int count_amt ); It isn't. Following the traditional right-then-left rule, BOTH of these should be parsed as: count is a pointer to a function which accepts a demo_counter pointer and an int and returns an int.. But the second one results in a compilation error with gcc. After more than 20 years working with C (and with the C language specification), I've never seen this supposed traditional construct. My experience on Windows is weak; maybe it's some strange Microsoft extension? It's not part of the C language specification. If you believe otherwise, please find a reference for it... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40627
[Bug fortran/40628] New: Assignment using = trim(string): Optimize trim away
In assignments, such as string = trim(string) string(n1:n2) = trim(string) the trim has no effect and can be optimized away. (Note: With Fortran 2003 and allocatable strings with len=:, the first version cannot be optimized as on length mismatch the LHS is reallocated.) Such code can easily be present in real-world code and causes unnecessarily a large overhead, cf. e.g. http://www.tddft.org/trac/octopus/changeset/5672 -- Summary: Assignment using = trim(string): Optimize trim away Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: missed-optimization 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=40628
[Bug fortran/40629] New: Host association problem
The following code (inspired from host_assoc_function_1.f90) breaks f951: MODULE m REAL :: x CONTAINS SUBROUTINE s CONTAINS SUBROUTINE inner y = x(1, 1) END SUBROUTINE FUNCTION x(n, m) END FUNCTION END SUBROUTINE END MODULE I have an internal compiler error with f951; I have checked out and built the latest version of fortran this morning. Note that host_assoc_function_1.f90 compiles OK. -- Summary: Host association problem Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: philippe dot marguinaud at meteo dot fr GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40629
[Bug fortran/40629] Host association problem
--- Comment #1 from dominiq at lps dot ens dot fr 2009-07-03 08:18 --- Confirmed on i686-apple-darwin9. More precisely, I get: pr40629.f90:12.10: END MODULE 1 Error: Symbol 'x' at (1) has already been host associated f951: internal compiler error: Bus error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40629
[Bug target/34163] [4.3/4.4/4.5 Regression] 10% performance regression since Nov 1 on Polyhedron's NF on AMD64
--- Comment #17 from ubizjak at gmail dot com 2009-07-03 08:46 --- (In reply to comment #16) One of the cases SCEV is confused about pointer-plus offsets being sizetype: Do we have a solution for this problem...? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34163
[Bug c++/40341] [4.4/4.5 Regression] invalid use of member in static member function not diagnosed
--- Comment #2 from jakub at gcc dot gnu dot org 2009-07-03 09:00 --- Jason, am I correct that this is now valid rather than invalid? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40341
[Bug target/34163] [4.3/4.4/4.5 Regression] 10% performance regression since Nov 1 on Polyhedron's NF on AMD64
--- Comment #18 from rguenther at suse dot de 2009-07-03 09:08 --- Subject: Re: [4.3/4.4/4.5 Regression] 10% performance regression since Nov 1 on Polyhedron's NF on AMD64 On Fri, 3 Jul 2009, ubizjak at gmail dot com wrote: --- Comment #17 from ubizjak at gmail dot com 2009-07-03 08:46 --- (In reply to comment #16) One of the cases SCEV is confused about pointer-plus offsets being sizetype: Do we have a solution for this problem...? My hope is that no-undefined-overflow will somehow magically solve these problems ... otherwise no, there is unfortunately no way out here. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34163
[Bug c/40627] not following right-then-left rule when compiling function pointers
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-03 09:57 --- int count * ( demo_counter * self, int count_amt ); is not a valid prototype. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40627
[Bug bootstrap/40617] [4.5 Regression] Revision 149170 breaks bootstrap
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-07-03 09:57 --- Fixed I suppose. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40617
[Bug fortran/31067] MINLOC should sometimes be inlined (gas_dyn is sooooo sloooow)
--- Comment #22 from rguenth at gcc dot gnu dot org 2009-07-03 10:00 --- One issue is that ISET = MINLOC (DTEMP) will cause GCC to assume that DTEMP is clobbered. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31067
[Bug fortran/40612] internal compiler error: in gfc_add_modify, at fortran/trans.c
--- Comment #10 from rogermc at iinet dot net dot au 2009-07-03 10:01 --- I updated gfortran as suggested and now abavrml.F compiles OK. Bug seems resolved. Thanks for advice. gfortran -v now responds with: Using built-in specs. Target: i386-apple-darwin8.10.1 Configured with: /tmp/gfortran-20090604/ibin/../gcc/configure --prefix=/usr/local/gfortran --enable-languages=c,fortran --with-gmp=/tmp/gfortran-20090604/gfortran_libs --enable-bootstrap Thread model: posix gcc version 4.5.0 20090604 (experimental) [trunk revision 148180] (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40612
[Bug fortran/40629] Host association problem
--- Comment #2 from burnus at gcc dot gnu dot org 2009-07-03 10:13 --- Confirmed. One first gets the error message from gfc_get_sym_tree (already been host associated), followed by the segfault, which happens at ==12785== Use of uninitialised value of size 8 ==12785==at 0x500F17: gfc_resolve_expr (resolve.c:4459) which is 4457/* Give the symbol a symtree in the right place! */ 4458gfc_get_sym_tree (sym-name, gfc_current_ns, st, false); 4459st-n.sym = sym; Thus one should add a check for st == NULL (e.g via gcc_assert) and fix gfc_get_sym_tree. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||pault at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|x86_64-unknown-linux-gnu| GCC host triplet|x86_64-unknown-linux-gnu| GCC target triplet|x86_64-unknown-linux-gnu| Keywords||rejects-valid Known to fail||4.1.3 4.2.1 4.3.3 4.4.1 ||4.5.0 Last reconfirmed|-00-00 00:00:00 |2009-07-03 10:13:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40629
[Bug ada/40631] New: [4.5 Regression] bootstrap with Ada fails on __gnat_backtrace warning on mips-linux
/n/51/guerby/build/./prev-gcc/xgcc -B/n/51/guerby/build/./prev-gcc/
-B/mnt/lemote/home/loongson/install-trunk-149181/mips64el-unknown-linux-gnu/bin/
-B/mnt/lemote/home/loongson/install-trunk-149181/mips64el\
-unknown-linux-gnu/bin/
-B/mnt/lemote/home/loongson/install-trunk-149181/mips64el-unknown-linux-gnu/lib/
-isystem
/mnt/lemote/home/loongson/install-trunk-149181/mips64el-unknown-linux-gnu/include
-isystem /\
mnt/lemote/home/loongson/install-trunk-149181/mips64el-unknown-linux-gnu/sys-include
-c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-\
attribute -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror
-Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -I. -Iada
-I../../trunk/gcc -I../../trunk/gcc/ada -I../../trun\
k/gcc/../include -I../../trunk/gcc/../libcpp/include
-I/opt/cfarm/gmp-4.2.4-n32/include -I/opt/cfarm/mpfr-2.3.2-n32/include
-I../../trunk/gcc/../libdecnumber -I../../trunk/gcc/../libdecnumber/dpd
-I../libde\
cnumber\
-I. -Iada -I../../trunk/gcc -I../../trunk/gcc/ada
-I../../trunk/gcc/../include -I../../trunk/gcc/../libcpp/include
-I/opt/cfarm/gmp-4.2.4-n32/include -I/opt/cfarm/mpfr-2.3.2-n32/include -I../.\
./trunk/gcc/../libdecnumber -I../../trunk/gcc/../libdecnumber/dpd
-I../libdecnumber -fno-omit-frame-pointer ../../trunk/gcc/ada/tracebak.c -o
ada/tracebak.o
cc1: warnings being treated as errors
../../trunk/gcc/ada/tracebak.c: In function '__gnat_backtrace':
../../trunk/gcc/ada/tracebak.c:497:1: error: old-style function definition
make[3]: *** [ada/tracebak.o] Error 1
make[3]: Leaving directory `/home/guerby/build/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory `/home/guerby/build'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/home/guerby/build'
make: *** [bootstrap] Error 2
I'm testing the patch below, will commit as obvious if it works
Index: gcc/ada/tracebak.c
===
--- gcc/ada/tracebak.c (revision 149204)
+++ gcc/ada/tracebak.c (working copy)
@@ -494,12 +494,11 @@
*--*/
int
-__gnat_backtrace (array, size, exclude_min, exclude_max, skip_frames)
- void **array ATTRIBUTE_UNUSED;
- int size ATTRIBUTE_UNUSED;
- void *exclude_min ATTRIBUTE_UNUSED;
- void *exclude_max ATTRIBUTE_UNUSED;
- int skip_frames ATTRIBUTE_UNUSED;
+__gnat_backtrace (void **array ATTRIBUTE_UNUSED,
+ int size ATTRIBUTE_UNUSED,
+ void *exclude_min ATTRIBUTE_UNUSED,
+ void *exclude_max ATTRIBUTE_UNUSED,
+ int skip_frames ATTRIBUTE_UNUSED)
{
return 0;
}
--
Summary: [4.5 Regression] bootstrap with Ada fails on
__gnat_backtrace warning on mips-linux
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: build
Severity: normal
Priority: P3
Component: ada
AssignedTo: laurent at guerby dot net
ReportedBy: laurent at guerby dot net
GCC build triplet: mips-linux
GCC host triplet: mips-linux
GCC target triplet: mips-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40631
[Bug c++/24985] caret diagnostics
--- Comment #8 from dave at treblig dot org 2009-07-03 11:03 --- Note there are two slightly different things being asked for here: 1) Showing the horizontal position in the line 2) show the preprocessed line rather than the raw line (which was my 40228 that just got marked as a dupe) - obviously this would be an option rather than the default. I'm not entirely sure they are actually dupes. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
[Bug target/34163] [4.3/4.4/4.5 Regression] 10% performance regression since Nov 1 on Polyhedron's NF on AMD64
--- Comment #19 from rguenth at gcc dot gnu dot org 2009-07-03 11:05 --- In fact, in this case we have the C equivalent int i; long j = (long)(i - 1); vs. long j = (long)i - 1; which I believe are equivalent if overflow is undefined (or i - 1 does not wrap). It is just that fold obviously considers (long)i - 1 to be more expensive than (long)(i - 1) and thus does not transform the latter into the former (and it can't transform (long)i - 1 to (long)(i - 1) as if (long)i - 1 does not overflow there is no guarantee that i - 1 does not). We should be able to do the former transformation during SCEV analysis though. I have a patch which results in (-O3 -ffast-math -funroll-loops) .L6: mulss (%rcx), %xmm0 movss (%rdx), %xmm5 movss 4(%rdx), %xmm4 addl$4, %ebp subss %xmm0, %xmm5 movss 8(%rdx), %xmm0 mulss (%rsi), %xmm5 movss %xmm5, (%rdx) mulss 4(%rcx), %xmm5 subss %xmm5, %xmm4 mulss 4(%rsi), %xmm4 movss %xmm4, 4(%rdx) movss 8(%rcx), %xmm3 mulss %xmm4, %xmm3 subss %xmm3, %xmm0 mulss 8(%rsi), %xmm0 movss %xmm0, 8(%rdx) movss 12(%rcx), %xmm2 addq$16, %rcx mulss %xmm0, %xmm2 movss 12(%rdx), %xmm0 subss %xmm2, %xmm0 mulss 12(%rsi), %xmm0 addq$16, %rsi movss %xmm0, 12(%rdx) addq$16, %rdx cmpl%r8d, %ebp jne .L6 -- 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|NEW |ASSIGNED Last reconfirmed|2008-04-21 07:11:35 |2009-07-03 11:05:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34163
[Bug target/34163] [4.3/4.4/4.5 Regression] 10% performance regression since Nov 1 on Polyhedron's NF on AMD64
--- Comment #20 from rguenth at gcc dot gnu dot org 2009-07-03 11:14 --- Before: Time for setup 0.139 Time per iteration 0.271 Total Time 6.649 Time for setup 0.136 Time per iteration 0.265 Total Time 10.210 Time for setup 0.134 Time per iteration 0.265 Total Time 7.276 Time for setup 0.134 Time per iteration 0.260 Total Time 11.572 After: Time for setup 0.114 Time per iteration 0.238 Total Time 5.834 Time for setup 0.111 Time per iteration 0.233 Total Time 8.948 Time for setup 0.110 Time per iteration 0.237 Total Time 6.504 Time for setup 0.112 Time per iteration 0.235 Total Time 10.454 which seems to exactly recover this regression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34163
[Bug target/34163] [4.3/4.4/4.5 Regression] 10% performance regression since Nov 1 on Polyhedron's NF on AMD64
--- Comment #21 from rguenth at gcc dot gnu dot org 2009-07-03 11:22 --- Created an attachment (id=18133) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18133action=view) patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34163
[Bug fortran/40632] New: Support F2008's contiguous attribute
On one hand it needs a new attribute, which needs some checking that the contiguity is not violated. It also needs the contiguous flag of the reworked descriptor. One place where it can be used is: a) In functions calls b) In assignments of the type (cf. PR 40551) array = function() c) In compile-time value for the strides, cf. PR 32131 -- Summary: Support F2008's contiguous attribute Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: missed-optimization 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=40632
[Bug fortran/32131] knowing that stride==1 when using allocated arrays and escaping allocatable arrays
--- Comment #12 from burnus at gcc dot gnu dot org 2009-07-03 11:33 --- Michael Matz fixed that for allocatable arrays, but the patch needs to be extended to nonallocatable arrays, cf. http://gcc.gnu.org/ml/fortran/2009-07/msg4.html Actually, there it already works. Left is only to do the same optimization for CONTIGUOUS arrays, but this F2008 feature does not exist, yet. Thus I am closing this PR. For the contiguous attribute, see PR 40632. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32131
[Bug c++/40633] New: ICE with scoped enum inside a template
The following code produces an internal compiler error:
template typename T
struct wrap {
enum class E { val };
};
Note that there is no problem supplying a fixed-base for a 'classic' enum, this
is purely an issue with the enum class keyword combination.
Tested under MinGW 4.4.0
--
Summary: ICE with scoped enum inside a template
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: public at alisdairm dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40633
[Bug c/40634] New: 2 small problems when building cross compiler
On Debian (and probably other), if I execute: tar xf ../update/gcc-4.4.0.tar.bz2 cd gcc-4.4.0/ tar xf ../../update/mpfr-2.4.1.tar.bz2 tar xf ../../update/gmp-4.3.1.tar.bz2 tar xf ../../update/binutils-2.19.1.tar.bz2 mv gmp-4.3.1 gmp mv mpfr-2.4.1 mpfr mv binutils-2.19.1 binutils mkdir -v ../gcc-build cd ../gcc-build mkdir /home/etienne/cross-tools /home/etienne/tools ../gcc-4.4.0/configure --prefix=/home/etienne/cross-tools \ --host=$(echo $MACHTYPE) --target=powerpc-unknown-linux-gnu \ --disable-multilib --with-local-prefix=/home/etienne/tools \ --disable-nls --disable-shared --disable-threads --enable-languages=c make all-gcc (echo $MACHTYPE gives: i486-pc-linux-gnu) First error: if [ x != x ]; then \ gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gcc-4.4.0/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic ../../gcc-4.4.0/libiberty/strncmp.c -o pic/strncmp.o; \ else true; fi gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gcc-4.4.0/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic ../../gcc-4.4.0/libiberty/strncmp.c -o strncmp.o rm -f ./libiberty.a pic/./libiberty.a i486-pc-linux-gnu-ar rc ./libiberty.a \ ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./sha1.o ./alloca.o ./argv.o ./choose-temp.o ./concat.o ./cp-demint.o ./dyn-string.o ./fdmatch.o ./fibheap.o ./filename_cmp.o ./floatformat.o ./fnmatch.o ./fopen_unlocked.o ./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o ./hashtab.o ./hex.o ./lbasename.o ./lrealpath.o ./make-relative-prefix.o ./make-temp-file.o ./objalloc.o ./obstack.o ./partition.o ./pexecute.o ./physmem.o ./pex-common.o ./pex-one.o ./pex-unix.o ./safe-ctype.o ./sort.o ./spaces.o ./splay-tree.o ./strerror.o ./strsignal.o ./unlink-if-ordinary.o ./xatexit.o ./xexit.o ./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror.o ./xstrndup.o ./mkstemps.o ./strncmp.o make[1]: i486-pc-linux-gnu-ar: Command not found make[1]: *** [libiberty.a] Error 127 make[1]: Leaving directory `/home/etienne/gcc-build/gcc-build/libiberty' make: *** [all-libiberty] Error 2 etie...@eqng:~/gcc-build/gcc-build$ If I create i486-pc-linux-gnu-ar pointing to ar in /usr/bin: # ln -vs /usr/bin/ar /usr/bin/i486-pc-linux-gnu-ar `/usr/bin/i486-pc-linux-gnu-ar' - `/usr/bin/ar' and rerun the same script: gcc -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -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 -DHAVE_CONFIG_H -o xgcc gcc.o opts-common.o gcc-options.o gccspec.o \ intl.o prefix.o version.o ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a cp xgcc gcc-cross gcc -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -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 -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.4.0/gcc -I../../gcc-4.4.0/gcc/. -I../../gcc-4.4.0/gcc/../include -I../../gcc-4.4.0/gcc/../libcpp/include -I/home/etienne/tmp/gcc-build/./gmp -I/home/etienne/tmp/gcc-4.4.0/gmp -I/home/etienne/tmp/gcc-build/./mpfr -I/home/etienne/tmp/gcc-4.4.0/mpfr -I../../gcc-4.4.0/gcc/../libdecnumber -I../../gcc-4.4.0/gcc/../libdecnumber/dpd -I../libdecnumber ../../gcc-4.4.0/gcc/cppspec.c -o cppspec.o gcc -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -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 -DHAVE_CONFIG_H -o cpp gcc.o opts-common.o gcc-options.o cppspec.o \ intl.o prefix.o version.o ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a powerpc-unknown-linux-gnu-gcc -dumpspecs tmp-specs /bin/sh: powerpc-unknown-linux-gnu-gcc: command not found make[1]: *** [specs] Error 127 make[1]: Leaving directory `/home/etienne/tmp/gcc-build/gcc' make: *** [all-gcc] Error 2 etie...@eqng:~/tmp/gcc-build$ I just need todo: cd /home/etienne/tmp/gcc-build/gcc gcc-cross -dumpspecs tmp-specs make cd .. make all-gcc make install-gcc install-binutils and I get a working compiler. Exactly the same 2 problems on gcc-4.3.3. Regards, Etienne. -- Summary: 2 small problems when building cross compiler Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: etienne_lorrain at yahoo dot fr GCC build triplet: i486-pc-linux-gnu GCC host triplet: i486-pc-linux-gnu GCC target triplet: powerpc-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40634
[Bug c/40635] New: bogus name and location in 'may be used uninitialized' warning
The following test case produces a 'may be used uninitialized' warning that
refers to a variable that isn't in scope at the point of the warning:
cat nntpinit.c
struct hostent {
char **h_addr_list;
};
struct hostent *gethostbyname(const char*);
int socket(void);
int close(int);
int connect(int, const char*);
void foo(void);
static int get_tcp_socket(const char *machine)
{
struct hostent *hp;
int s42, x;
char **addr;
hp = gethostbyname(machine);
x = 0;
for (addr = hp-h_addr_list; *addr; addr++) {
s42 = socket();
if (s42 0)
return -1;
x = connect(s42, *addr);
if (x == 0)
break;
close(s42);
}
if (x 0)
return -1;
return s42;
}
int server_init(const char *machine)
{
int sockt_rd;
sockt_rd = get_tcp_socket(machine);
foo();
if (sockt_rd 0)
return -1;
return 0;
}
gcc -O2 -Wall -c nntpinit.c
nntpinit.c: In function 'server_init':
nntpinit.c:38: warning: 's42' may be used uninitialized in this function
There is indeed a 'may be used uninitialized' issue in this code, but it's
actually in get_tcp_socket(), not in server_init() because there every use is
trivially preceeded by a def.
I guess that automatic inlining is messing up name and context information.
The test case is distilled down from some ancient nntp client code I'm tidying
up, and the bogus data in the warning did cause some headscratching before the
warning could be analysed and fixed (set x = -1 in get_tcp_socket()).
--
Summary: bogus name and location in 'may be used uninitialized'
warning
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikpe at it dot uu dot se
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40635
[Bug fortran/31067] MINLOC should sometimes be inlined (gas_dyn is sooooo sloooow)
--- Comment #23 from rguenth at gcc dot gnu dot org 2009-07-03 12:19 --- We are not able to vectorize the loop in program main implicit none integer, volatile, dimension(1) :: n real, allocatable :: a(:) integer :: i real :: t1, t2 allocate (a(100)) call random_number(a) ! negligible time !call cpu_time(t1) do i=1, 1000 n = minloc(a, dim=1) end do !call cpu_time(t2) print *, n !, t2-t1 end program main because there are two reductions in that loop which I think the vectorizer cannot handle: bb 7: # pos.0_31 = PHI pos.0_3(10), 0(6) # limit.2_8 = PHI limit.2_5(10), 3.4028234663852885981170418348451692544e+38(6) # S.3_74 = PHI S.3_33(10), pretmp.22_79(6) D.1593_21 = S.3_74 + pretmp.22_77; limit.2_22 = (*D.1568_14)[D.1593_21]; D.1595_23 = limit.2_22 limit.2_8; D.1596_24 = pos.0_31 == 0; D.1597_27 = limit.2_8 == limit.2_22; D.1598_28 = D.1597_27 D.1596_24; D.1599_29 = D.1595_23 | D.1598_28; pos.0_32 = S.3_74 + pretmp.28_90; pos.0_3 = [cond_expr] D.1599_29 ? pos.0_32 : pos.0_31; limit.2_5 = [cond_expr] D.1599_29 ? limit.2_22 : limit.2_8; S.3_33 = S.3_74 + 1; if (S.3_33 pretmp.22_81) goto bb 11; else goto bb 10; bb 10: goto bb 7; we reduce over limit.2_5 and pos.0_3. The intel compiler vectorizes the function just fine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||irar at il dot ibm dot com, ||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31067
[Bug target/40636] New: Build failed with --enable-build-with-cxx (mingw32 target)
GCC 4.5.0 20090702 Build failed because the static const structures in config/i386/msformat-c.c (mingw_format_attribute_overrides and mingw_format_attributes) were optimized out. Also solaris target can be affected (solaris_format_types). -- Summary: Build failed with --enable-build-with-cxx (mingw32 target) Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: d dot g dot gorbachev at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40636
[Bug target/40587] [4.4/4.5 Regression] Revision 139590 caused ICE in emit_swap_insn at reg-stack.c:827
--- Comment #7 from vmakarov at redhat dot com 2009-07-03 12:38 --- Thanks for reporting this. I started to work on the PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40587
[Bug fortran/31067] MINLOC should sometimes be inlined (gas_dyn is sooooo sloooow)
--- Comment #24 from burnus at gcc dot gnu dot org 2009-07-03 12:40 --- One issue is that ISET = MINLOC (DTEMP) will cause GCC to assume that DTEMP is clobbered. The problem is that while MINLOC is pure, we cannot use DECL_PURE_P as the result is passed by reference: (void) minloc(isset, DTEMP) ^^--- result -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31067
[Bug fortran/31067] MINLOC should sometimes be inlined (gas_dyn is sooooo sloooow)
--- Comment #25 from rguenth at gcc dot gnu dot org 2009-07-03 12:57
---
Btw, the inlined minloc
D.1570 = a.dim[0].lbound;
D.1571 = a.dim[0].ubound;
pos.0 = 0;
{
integer(kind=8) S.3;
({ S.3 = D.1570;
while (1)
{
({ if (S.3 D.1571) goto L.3;
offset.1 = 1 - D.1570;
if ((*D.1568)[S.3 + D.1569] limit.2 || pos.0 == 0
(*D.1568)[S.3 + D.1569] == limit.2)
{
({ limit.2 = (*D.1568)[S.3 + D.1569];
pos.0 = S.3 + offset.1; }) void
}
S.3 = S.3 + 1; }) void
}
L.3:; }) void
has a superfluous check || (pos.0 == 0 (*D.1568)[S.3 + D.1569] == limit.2)
at least for flag_finite_math_only. If the array cannot contain Inf or NaN
then it either has all elements == FLT_MAX, so pos will stay zero, or at
least one is less than FLT_MAX in which case pos will be adjusted anyway.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31067
[Bug fortran/31067] MINLOC should sometimes be inlined (gas_dyn is sooooo sloooow)
--- Comment #26 from burnus at gcc dot gnu dot org 2009-07-03 13:07 --- has a superfluous check || (pos.0 == 0 (*D.1568)[S.3 + D.1569] == limit.2) at least for flag_finite_math_only. If the array cannot contain Inf or NaN then it either has all elements == FLT_MAX, so pos will stay zero, or at least one is less than FLT_MAX in which case pos will be adjusted anyway. I have not checked whether algorithm requires the check; NaN/Inf are possible, but maybe the check is still not needed. And if it is, one could enclose it in a if(!flag_finite_math_only) condition. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31067
[Bug ada/40637] New: Ada bootstrap ICE on stage3 s-bitops.o
On trunk revision 149204: /home/guerby/build/./prev-gcc/xgcc -B/home/guerby/build/./prev-gcc/ -B/n/40/guerby/install-trunk/powerpc64-unknown-linux-gnu/bin/ -B/n/40/guerby/install-trunk/powerpc64-unknown-linux-gnu/bin/ -B/n/40/guerby/install-trunk/powerpc64-unknown-linux-gnu/lib/ -isystem /n/40/guerby/install-trunk/powerpc64-unknown-linux-gnu/include -isystem /n/40/guerby/install-trunk/powerpc64-unknown-linux-gnu/sys-include-c -g -O2 -gnatpg -gnata -nostdinc -I- -I. -Iada -I../../trunk/gcc/ada -I../../trunk/gcc/ada/gcc-interface ../../trunk/gcc/ada/s-bitops.adb -o ada/s-bitops.o raised STORAGE_ERROR : stack overflow (or erroneous memory access) make[3]: *** [ada/s-bitops.o] Error 1 make[3]: Leaving directory `/home/guerby/build/gcc' make[2]: *** [all-stage3-gcc] Error 2 make[2]: Leaving directory `/home/guerby/build' make[1]: *** [stage3-bubble] Error 2 make[1]: Leaving directory `/home/guerby/build' make: *** [bootstrap] Error 2 Under the debugger: (gdb) r -I- -I. -Iada -I../../trunk/gcc/ada -I../../trunk/gcc/ada/gcc-interface -quiet -nostdinc -dumpbase s-bitops.adb -auxbase-strip ada/s-bitops.o -O2 -g -gnatpg -gnata -gnatO ada/s-bitops.o ../../trunk/gcc/ada/s-bitops.adb -o /tmp/ccz0AGDK.s Starting program: /home/guerby/build/prev-gcc/gnat1 -I- -I. -Iada -I../../trunk/gcc/ada -I../../trunk/gcc/ada/gcc-interface -quiet -nostdinc -dumpbase s-bitops.adb -auxbase-strip ada/s-bitops.o -O2 -g -gnatpg -gnata -gnatO ada/s-bitops.o ../../trunk/gcc/ada/s-bitops.adb -o /tmp/ccz0AGDK.s warning: no loadable sections found in added symbol-file system-supplied DSO at 0x10 Program received signal SIGSEGV, Segmentation fault. 0x1030d95c in osint___elabs () at ../../trunk/gcc/ada/osint.ads:601 601 new File_Name_Array (1 .. Int (Argument_Count) + 2); Current language: auto; currently ada (gdb) bt #0 0x1030d95c in osint___elabs () at ../../trunk/gcc/ada/osint.ads:601 #1 0x1011e644 in adainit () at ada/b_gnat1.c:368 Backtrace stopped: frame did not save the PC (gdb) b main Breakpoint 3 at 0x104ae94c: file ../../trunk/gcc/main.c, line 35. (gdb) r The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /home/guerby/build/prev-gcc/gnat1 -I- -I. -Iada -I../../trunk/gcc/ada -I../../trunk/gcc/ada/gcc-interface -quiet -nostdinc -dumpbase s-bitops.adb -auxbase-strip ada/s-bitops.o -O2 -g -gnatpg -gnata -gnatO ada/s-bitops.o ../../trunk/gcc/ada/s-bitops.adb -o /tmp/ccz0AGDK.s warning: no loadable sections found in added symbol-file system-supplied DSO at 0x10 Breakpoint 3, main (argc=21, argv=0x7d8) at ../../trunk/gcc/main.c:35 35return toplev_main (argc, argv); Current language: auto; currently c (gdb) bt #0 main (argc=21, argv=0x7d8) at ../../trunk/gcc/main.c:35 (gdb) s Program received signal SIGSEGV, Segmentation fault. 0x1030d95c in osint___elabs () at ../../trunk/gcc/ada/osint.ads:601 601 new File_Name_Array (1 .. Int (Argument_Count) + 2); Current language: auto; currently ada (gdb) bt #0 0x1030d95c in osint___elabs () at ../../trunk/gcc/ada/osint.ads:601 #1 0x1011e644 in adainit () at ada/b_gnat1.c:368 Backtrace stopped: frame did not save the PC This is the first Ada file compiled during stage3, likely stage2 compiler is miscompiled. -- Summary: Ada bootstrap ICE on stage3 s-bitops.o Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, build Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: laurent at guerby dot net GCC build triplet: powerpc64-unknown-linux-gnu GCC host triplet: powerpc64-unknown-linux-gnu GCC target triplet: powerpc64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40637
[Bug ada/40637] Ada bootstrap ICE on stage3 s-bitops.o
--- Comment #1 from laurent at guerby dot net 2009-07-03 13:26 --- powerpc 32 bits Ada bootstraps and testresults are fine: http://gcc.gnu.org/ml/gcc-testresults/2009-07/msg00181.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40637
[Bug fortran/40638] New: RTE: Unit number in I/O statement too large -- falls with any low value
I find this hard to believe but a g77 code that has been in use for years crashed at the first OPEN statement when compiled with gfortran 4.3.1. Attached 15 line test program reproduces the effect, stops at line 8 with the error message: At line 8 of file testlun.f Fortran runtime error: Unit number in I/O statement too large but the unit number was set to 12. Investigation shows it can be set to any value, even 1. I am guessing this is hardware-related. It is a new system--ASUS MB with Intel Core I7 CPU. Identical code runs fine with same gfortran installed on a system equipped with an earlier Intel chip. -- Summary: RTE: Unit number in I/O statement too large -- falls with any low value Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dtprice at shaw dot ca GCC build triplet: gfortran -Wall testfile.f GCC host triplet: Intel Core I7; SuSE 11; http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40638
[Bug target/34163] [4.3/4.4/4.5 Regression] 10% performance regression since Nov 1 on Polyhedron's NF on AMD64
--- Comment #22 from rguenth at gcc dot gnu dot org 2009-07-03 14:11 --- Subject: Bug 34163 Author: rguenth Date: Fri Jul 3 14:11:14 2009 New Revision: 149207 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149207 Log: 2009-07-03 Richard Guenther rguent...@suse.de PR middle-end/34163 * tree-chrec.c (chrec_convert_1): Fold (T2)(t +- x) to (T2)t +- (T2)x if t +- x is known to not overflow and the conversion widens the operation. * Makefile.in (tree-chrec.o): Add $(FLAGS_H) dependency. * gfortran.dg/pr34163.f90: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/pr34163.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-chrec.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34163
[Bug middle-end/34163] [4.3/4.4 Regression] 10% performance regression since Nov 1 on Polyhedron's NF on AMD64
--- Comment #23 from rguenth at gcc dot gnu dot org 2009-07-03 14:11 --- Fixed on the trunk. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|rguenth at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW Component|target |middle-end Known to work||4.5.0 Summary|[4.3/4.4/4.5 Regression] 10%|[4.3/4.4 Regression] 10% |performance regression since|performance regression since |Nov 1 on Polyhedron's NF |Nov 1 on Polyhedron's NF |on AMD64|on AMD64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34163
[Bug c++/40639] New: Cannot parse dependant type for enum-base in C++0x
In C++0x mode, enums are allowed to specify an integral type for the base
representation. If the enum is inside a class template, it may be a
type-dependant expression that should not evaluate and potentially error until
instantiation time.
Example code:
//
template typename T
struct wrap {
enum E : T { val };
};
template typename T
struct dependant {
enum E : typename T::type { val };
};
templatetypename T
struct identity {
typedef T type;
};
wrapint x;
dependantidentityint y;
//
--
Summary: Cannot parse dependant type for enum-base in C++0x
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: public at alisdairm dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40639
[Bug fortran/40612] internal compiler error: in gfc_add_modify, at fortran/trans.c
--- Comment #11 from kargl at gcc dot gnu dot org 2009-07-03 14:15 --- Closing. Bug is fixed in newer versions of gfortran. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40612
[Bug c++/40341] [4.4/4.5 Regression] invalid use of member in static member function not diagnosed
--- Comment #3 from jason at gcc dot gnu dot org 2009-07-03 14:18 --- Yes. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40341
[Bug fortran/40638] RTE: Unit number in I/O statement too large -- falls with any low value
--- Comment #1 from burnus at gcc dot gnu dot org 2009-07-03 14:19 --- gfortran 4.3.1. Attached 15 line test program reproduces the effect Can you attach the program? I assume you compiled it with gfortran -Wall testfile.f and no further option such a -malign-double or similar? Can you also show the output of: gfortran -v? You are not by chance mixing the library of an older gfortran with a binary of a newer gfortran or vice versa? (Not a issue for your single-file test, but combining files compiled with 4.2.x with 4.3.x/4.4.x compiled files, might also cause problems. 4.3 and 4.4 should be compatible.) stops at line 8 with the error message: At line 8 of file testlun.f Fortran runtime error: Unit number in I/O statement too large I am guessing this is hardware-related. It is a new system--ASUS MB with Intel Core I7 CPU. Identical code runs fine with same gfortran installed on a system equipped with an earlier Intel chip. As GCC/gfortran is continuously tested one a wide range of systems (x86, x86-64, ia64, sparc, s930, ...), I think it is unlikely that it is a Core i7 problem; I rather think that somehow the installation was messed up or some strange option was used. After we solved the problem, we will know ... -- burnus at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal GCC build triplet|gfortran -Wall testfile.f | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40638
[Bug fortran/40638] RTE: Unit number in I/O statement too large -- falls with any low value
--- Comment #2 from dtprice at shaw dot ca 2009-07-03 14:20 --- Created an attachment (id=18134) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18134action=view) Contains simple demo program and input file. Input file is not really needed because program never opens it! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40638
[Bug fortran/40638] RTE: Unit number in I/O statement too large -- falls with any low value
--- Comment #3 from kargl at gcc dot gnu dot org 2009-07-03 14:40 --- Upgrade your compiler. The bug appears to fixed in at least trunk while the bug is present in 4.3.3. I can't test 4.4.0 at the moment. troutmask:sgk[203] gfc4x -o z testlun.f troutmask:sgk[204] ./z troutmask:sgk[205] gfc43 -o z testlun.f troutmask:sgk[206] ./z At line 8 of file testlun.f Fortran runtime error: Unit number in I/O statement too large PS: Your code would work fine with 4.3.x if you use a default integer kind for the lun instead of an INTEGER(KIND=2) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40638
[Bug c/40627] not following right-then-left rule when compiling function pointers
--- Comment #3 from dj2con at gmail dot com 2009-07-03 14:42 --- (In reply to comment #1) (In reply to comment #0) , but it does not seem to recognize that the following is also a valid prototype: int count * ( demo_counter * self, int count_amt ); It isn't. Following the traditional right-then-left rule, BOTH of these should be parsed as: count is a pointer to a function which accepts a demo_counter pointer and an int and returns an int.. But the second one results in a compilation error with gcc. After more than 20 years working with C (and with the C language specification), I've never seen this supposed traditional construct. My experience on Windows is weak; maybe it's some strange Microsoft extension? It's not part of the C language specification. If you believe otherwise, please find a reference for it... I don't know where you've been hiding for these past twenty years, Ken. But the right left rule has been around longer than you've been working (and longer than Microsoft has been in business!). I would take the time to explain it to you, but you can google the terms right left rule C as easily as I can. My experience on Windows is also weak. But I don't see what that has to do with the problem at hand. In another comment Richard Guenther also claimed it is not a valid prototype. Richard typically knows what he's talking about, so I'll take his word for it and assume that the right left rule does not apply for some reason in this particular case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40627
[Bug c++/40639] Cannot parse dependent type for enum-base in C++0x
--- Comment #1 from paolo dot carlini at oracle dot com 2009-07-03 14:49 --- Adding Jason in CC for this one too. -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40639
[Bug fortran/40638] RTE: Unit number in I/O statement too large -- fails with any low value
--- Comment #4 from dtprice at shaw dot ca 2009-07-03 14:54 --- Sorry. In the middle of uploading the attachment I had a power cut! To respond to your queries: Program and input file are now uploaded. Yes it was compiled with gfortran -Wall testfile.f and no further options. I have found it necessary to use -static on some installations but all of these compiles run fine. gfortran -v produces: Using built-in specs. Target: i586-suse-linux Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.2.1 --enable-ssp --disable-libssp --disable-libgcj --with-slibdir=/lib --with-system-zlib --enable-shared --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --program-suffix=-4.2 --enable-version-specific-runtime-libs --without-system-libunwind --with-cpu=generic --host=i586-suse-linux Thread model: posix gcc version 4.2.1 (SUSE Linux) mika:/~%lo Connection to mika.nofc.cfs.nrcan.gc.ca closed. locatelli:/~/ibis/prog/source%gfortran -v Using built-in specs. Target: x86_64-suse-linux Configured with: ../configure --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3 --enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --program-suffix=-4.3 --enable-version-specific-runtime-libs --enable-linux-futex --without-system-libunwind --with-cpu=generic --build=x86_64-suse-linux Thread model: posix gcc version 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036] (SUSE Linux) I should not be mixing libraries... this is a brand new installation on a new machine (bought two weeks ago!). The gcc-4.3 collection were installed as part of the initial SuSE installation. I only tried building gcc-4.4 after this problem manifested. My build of gcc-4.4 was installed into /usr/local/ and the only test I did was to substitute the gfortran executable (using a temporary symlink) to compile the test program. Thanks David gfortran 4.3.1. Attached 15 line test program reproduces the effect Can you attach the program? I assume you compiled it with gfortran -Wall testfile.f and no further option such a -malign-double or similar? Can you also show the output of: gfortran -v? You are not by chance mixing the library of an older gfortran with a binary of a newer gfortran or vice versa? (Not a issue for your single-file test, but combining files compiled with 4.2.x with 4.3.x/4.4.x compiled files, might also cause problems. 4.3 and 4.4 should be compatible.) stops at line 8 with the error message: At line 8 of file testlun.f Fortran runtime error: Unit number in I/O statement too large I am guessing this is hardware-related. It is a new system--ASUS MB with Intel Core I7 CPU. Identical code runs fine with same gfortran installed on a system equipped with an earlier Intel chip. As GCC/gfortran is continuously tested one a wide range of systems (x86, x86-64, ia64, sparc, s930, ...), I think it is unlikely that it is a Core i7 problem; I rather think that somehow the installation was messed up or some strange option was used. After we solved the problem, we will know ... -- dtprice at shaw dot ca changed: What|Removed |Added GCC build triplet||version 4.3.1 20080507 ||(prerelease) [gcc-4_3-branch ||revision 135 GCC target triplet||x86_64_sise-linux_ Keywords||diagnostic Summary|RTE: Unit number in I/O|RTE: Unit number in I/O |statement too large -- |statement too large -- |falls with any low value|fails with any low value http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40638
[Bug fortran/40638] RTE: Unit number in I/O statement too large -- fails with any low value
--- Comment #5 from dtprice at shaw dot ca 2009-07-03 15:06 --- I stated earlier Identical code runs fine with same gfortran installed on a system equipped with an earlier Intel chip Turns out this was wrong. The version on that system is 4.2.0 Interesting that using default integer format (integer*4) does not cause the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40638
[Bug c/40627] not following right-then-left rule when compiling function pointers
--- Comment #4 from ubizjak at gmail dot com 2009-07-03 15:19 --- For the interested reader: see [1]. [1]: http://ieng9.ucsd.edu/~cs30x/rt_lt.rule.html Unfortunately: --quote-- First, symbols. Read * as pointer to - always on the left side [] as array of - always on the right side () as function returning - always on the right side as you encounter them in the declaration. --/quote-- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40627
[Bug fortran/40638] RTE: Unit number in I/O statement too large -- fails with any low value
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2009-07-03 15:20 --- I will add that I suspect that the bug may be latent in 4.5 since I did change the error code when I added NEWUNIT to 4.5. After we get to the bottom of it, we need to consider backporting a fix to 4.4 since this is a regression relative to g77 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40638
[Bug c/40640] New: ICE in set_value_range, at tree-vrp.c:383 [regression]
gcc (GCC) 4.5.0 20090702 (experimental) [trunk revision 149195] building gdb head as of today. preprocessed file and coming in next update gcc -c -g -O2 -DDEFAULT_INLINE=PSIM_INLINE_LOCALS -DWITH_HOST_BYTE_ORDER=LITTLE_ENDIAN -DWITH_SMP=5-DWITH_TRACE=1 -DHAVE_TERMIOS_STRUCTURE -DHAVE_TERMIOS_CLINE -DHAVE_DEVZERO -I. -I/home/joel/test-gcc/gdb-cvs/src/sim/ppc -I/home/joel/test-gcc/gdb-cvs/src/sim/ppc/../../include -I../../bfd -I/home/joel/test-gcc/gdb-cvs/src/sim/ppc/../../bfd -I../../gdb -I/home/joel/test-gcc/gdb-cvs/src/sim/ppc/../../gdb -I/home/joel/test-gcc/gdb-cvs/src/sim/ppc/../../gdb/config -DHAVE_COMMON_FPU -I../common -I/home/joel/test-gcc/gdb-cvs/src/sim/ppc/../common targ-map.c gcc -c -g -O2 -DDEFAULT_INLINE=PSIM_INLINE_LOCALS -DWITH_HOST_BYTE_ORDER=LITTLE_ENDIAN -DWITH_SMP=5-DWITH_TRACE=1 -DHAVE_TERMIOS_STRUCTURE -DHAVE_TERMIOS_CLINE -DHAVE_DEVZERO -I. -I/home/joel/test-gcc/gdb-cvs/src/sim/ppc -I/home/joel/test-gcc/gdb-cvs/src/sim/ppc/../../include -I../../bfd -I/home/joel/test-gcc/gdb-cvs/src/sim/ppc/../../bfd -I../../gdb -I/home/joel/test-gcc/gdb-cvs/src/sim/ppc/../../gdb -I/home/joel/test-gcc/gdb-cvs/src/sim/ppc/../../gdb/config -DHAVE_COMMON_FPU -I../common -I/home/joel/test-gcc/gdb-cvs/src/sim/ppc/../common /home/joel/test-gcc/gdb-cvs/src/sim/ppc/main.c /home/joel/test-gcc/gdb-cvs/src/sim/ppc/hw_opic.c: In function ‘hw_opic_io_read_buffer’: /home/joel/test-gcc/gdb-cvs/src/sim/ppc/hw_opic.c:1613:1: internal compiler error: in set_value_range, at tree-vrp.c:383 -- Summary: ICE in set_value_range, at tree-vrp.c:383 [regression] Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: joel at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40640
[Bug c/40640] ICE in set_value_range, at tree-vrp.c:383 [regression]
--- Comment #1 from joel at gcc dot gnu dot org 2009-07-03 15:24 --- Created an attachment (id=18135) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18135action=view) preprocessed test case (hw_opic.c preprocessed version of gdb/sim/ppc/hw_opic.c FAILS: gcc -O2 -c t.c PASSES: gcc -O1 -c t.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40640
[Bug c/40627] not following right-then-left rule when compiling function pointers
--- Comment #5 from dj2con at gmail dot com 2009-07-03 15:29 --- I was still curious, so I re-read section 6.7.5.3 of the standard. And having re-read it, I would like to apologize for troubling everyone -- upon re-reading 6.7.5.3, it now seems obvious that I was mis-applying the right left rule. For anyone else who might pop across this exchange in the future, here is the explanation: A regular function prototype, for a function named D, *must* be of the format: T D( parmlist ); If we replace the name D with a dereferenced function pointer d, the prototype *must* still be of the same format; otherwise it will no longer be recognized as a function by the compiler. And if the prototype is no longer recognized as a function, it is not going to be parsed properly no matter how compliant it is with any other rules. Hence, T (*d)( parmlist ); is valid, but T d * ( parmlist ) is not because the compiler should not recognize that d * is a function. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40627
[Bug fortran/40638] RTE: Unit number in I/O statement too large -- fails with any low value
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2009-07-03 15:16 --- I can reproduce the problem on 4.3 and 4.4. I would like to investigate further, especially regarding 4.4 and what did we change between 4.4 and 4.5 to fix this. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-07-03 15:16:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40638
[Bug c/40641] New: gcc-4.4.0 does not honor the alway_inline attribute when using -Os
This is a bug report from an OpenWrt user that I have also noticed myself. uClibc requires its syscalls to be inlined and therefore the attribute always_inline was added to ensure inlining. When gcc is called with -Os the always_inline attribute is not honored, resulting in a non working uClibc ldso. Please find the environmnet below. This is probably related to the regression closed here: System type: Debian testing compiling OpenWrt trunk 16656 GCC configuration: Using built-in specs. Target: mips-openwrt-linux-uclibc Configured with: /home/florian/dev/openwrt/trunk/build_dir/toolchain-mips_gcc-4.4.0_uClibc-0.9.30.1/gcc-4.4.0/configure --prefix=/home/florian/dev/openwrt/trunk/staging_dir/toolchain-mips_gcc-4.4.0_uClibc-0.9.30.1/usr --build=i486-linux-gnu --host=i486-linux-gnu --target=mips-openwrt-linux-uclibc --with-gnu-ld --enable-target-optspace --disable-libgomp --disable-libmudflap --disable-multilib --disable-nls --with-float=soft --with-gmp=/home/florian/dev/openwrt/trunk/staging_dir/host --with-mpfr=/home/florian/dev/openwrt/trunk/staging_dir/host --disable-decimal-float --disable-libssp --disable-__cxa_atexit --enable-languages=c --enable-shared --enable-threads --disable-tls --with-slibdir=/home/florian/dev/openwrt/trunk/staging_dir/toolchain-mips_gcc-4.4.0_uClibc-0.9.30.1/lib Thread model: posix gcc version 4.4.0 (GCC) Compiler output: mips-openwrt-linux-uclibc-gcc -c ldso/ldso/ldso.c -o ldso/ldso/ldso.oS -include ./include/libc-symbols.h -Wall -Wstrict-prototypes -fno-strict-aliasing -Os -march=octeon -pipe -funit-at-a-time -fhonour-copts -msoft-float -fno-stack-protector -fno-builtin -nostdinc -I./include -I. -I./libc/sysdeps/linux/mips -fno-asm -msoft-float -DUCLIBC_INTERNAL -std=gnu99 -Os -funit-at-a-time -fno-tree-loop-optimize -fno-tree-dominator-opts -fno-strength-reduce -mno-split-addresses -I./libpthread/linuxthreads.old/sysdeps/unix/sysv/linux/mips -I./libpthread/linuxthreads.old/sysdeps/mips -I./libpthread/linuxthreads.old/sysdeps/unix/sysv/linux -I./libpthread/linuxthreads.old/sysdeps/pthread -I./libpthread/linuxthreads.old -I./libpthread -I/home/florian/dev/openwrt/trunk/build_dir/toolchain-mips_gcc-4.4.0_uClibc-0.9.30.1/linux-dev/usr/include/ -I/home/florian/dev/openwrt/trunk/staging_dir/toolchain-mips_gcc-4.4.0_uClibc-0.9.30.1/usr/lib/gcc/mips-openwrt-linux-uclibc/4.4.0//include-fixed -I/home/florian/dev/openwrt/trunk/staging_dir/toolchain-mips_gcc-4.4.0_uClibc-0.9.30.1/usr/lib/gcc/mips-openwrt-linux-uclibc/4.4.0/include -DNDEBUG -mno-split-addresses -fPIC -DSHARED -DNOT_IN_libc -DIS_IN_rtld -fno-stack-protector -E -fno-omit-frame-pointer -I./ldso/ldso/mips -I./ldso/include -I./ldso/ldso -DUCLIBC_RUNTIME_PREFIX=/ -DUCLIBC_LDSO=ld-uClibc.so.0 -DLDSO_ELFINTERP=mips/elfinterp.c -DNOT_IN_libc -DIS_IN_rtld -fno-stack-protector -E -fno-omit-frame-pointer -I./ldso/ldso/mips -I./ldso/include -I./ldso/ldso -DUCLIBC_RUNTIME_PREFIX=/ -DUCLIBC_LDSO=ld-uClibc.so.0 -MT ldso/ldso/ldso.oS -MD -MP -MF ldso/ldso/.ldso.oS.dep mips-openwrt-linux-uclibc-gcc -c ldso/ldso/mips/resolve.S -o ldso/ldso/mips/resolve.oS -include ./include/libc-symbols.h -Wall -Wstrict-prototypes -fno-strict-aliasing -Os -march=octeon -pipe -funit-at-a-time -fhonour-copts -msoft-float -fno-stack-protector -fno-builtin -nostdinc -I./include -I. -I./libc/sysdeps/linux/mips -fno-asm -msoft-float -DUCLIBC_INTERNAL -Os -funit-at-a-time -fno-tree-loop-optimize -fno-tree-dominator-opts -fno-strength-reduce -mno-split-addresses -I./libpthread/linuxthreads.old/sysdeps/unix/sysv/linux/mips -I./libpthread/linuxthreads.old/sysdeps/mips -I./libpthread/linuxthreads.old/sysdeps/unix/sysv/linux -I./libpthread/linuxthreads.old/sysdeps/pthread -I./libpthread/linuxthreads.old -I./libpthread -I/home/florian/dev/openwrt/trunk/build_dir/toolchain-mips_gcc-4.4.0_uClibc-0.9.30.1/linux-dev/usr/include/ -I/home/florian/dev/openwrt/trunk/staging_dir/toolchain-mips_gcc-4.4.0_uClibc-0.9.30.1/usr/lib/gcc/mips-openwrt-linux-uclibc/4.4.0//include-fixed -I/home/florian/dev/openwrt/trunk/staging_dir/toolchain-mips_gcc-4.4.0_uClibc-0.9.30.1/usr/lib/gcc/mips-openwrt-linux-uclibc/4.4.0/include -DNDEBUG -mno-split-addresses -fPIC -DSHARED -DNOT_IN_libc -DIS_IN_rtld -fno-stack-protector -E -fno-omit-frame-pointer -I./ldso/ldso/mips -I./ldso/include -I./ldso/ldso -DUCLIBC_RUNTIME_PREFIX=/ -DUCLIBC_LDSO=ld-uClibc.so.0 -MT ldso/ldso/mips/resolve.oS -MD -MP -MF ldso/ldso/mips/.resolve.oS.dep -D__ASSEMBLER__ -Wa,--noexecstack -- Summary: gcc-4.4.0 does not honor the alway_inline attribute when using -Os Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: florian at openwrt dot org GCC build triplet: i486-linux-gnu- GCC host triplet: i486-linux-gnu- GCC target triplet: mips-openwrt-linux-uclibc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40641
[Bug c/40641] gcc-4.4.0 does not honor the alway_inline attribute when using -Os
--- Comment #1 from florian at openwrt dot org 2009-07-03 16:16 --- Created an attachment (id=18136) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18136action=view) ldso.Os.i preprocessed file This file is the preprocessed file which causes problems. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40641
[Bug tree-optimization/40642] New: [4.5 regression] ICE with -fprofile-generate
This is a regression in at least current mainline over 4.2. I can't check
4.3 and 4.4 for the moment. I found this working on a successor to the
447.dealII benchmark to be included in the next SPEC testsuite. It triggers
about half a dozen times on that code base.
Either way, here it is:
---
#include vector
void foo ()
{
std::vectorstd::vectorstd::vectorint v(3);
for (unsigned int d=0; d3; ++d)
v[d].resize (13);
}
---
c++ -O3 -fprofile-generate -c x.cc
x.cc: In function 'void foo()':
x.cc:8:1: error: EH edge 11-18 is missing
x.cc:8:1: error: unnecessary EH edge 11-23
x.cc:8:1: error: EH edge 16-18 is missing
x.cc:8:1: error: unnecessary EH edge 16-23
x.cc:8:1: internal compiler error: verify_flow_info failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
c++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../mainline/configure --enable-languages=c,c++
--enable-checking --with-mpfr=/home/bangerth/bin/x86
--with-gmp=/home/bangerth/bin/x86 --prefix=/home/bangerth/bin/x86/gcc-mainline
Thread model: posix
gcc version 4.5.0 20090703 (experimental) [trunk revision 149208] (GCC)
--
Summary: [4.5 regression] ICE with -fprofile-generate
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40642
[Bug tree-optimization/40642] [4.5 regression] ICE with -fprofile-generate
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40642
[Bug c/40641] gcc-4.4.0 does not honor the alway_inline attribute when using -Os
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-03 17:24 --- Does -fno-ipa-cp fix it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40641
[Bug c/40641] gcc-4.4.0 does not honor the alway_inline attribute when using -Os
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-07-03 17:32 --- Btw, with a cross I cannot seem to reproduce the problem. How do non-inlined calls look like with mips? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40641
[Bug fortran/40638] RTE: Unit number in I/O statement too large -- fails with any low value
--- Comment #8 from kargl at gcc dot gnu dot org 2009-07-03 17:44 ---
(In reply to comment #7)
I will add that I suspect that the bug may be latent in 4.5 since I did change
the error code when I added NEWUNIT to 4.5. After we get to the bottom of it,
we need to consider backporting a fix to 4.4 since this is a regression
relative to g77
The -fdump-tree-original code is
D.536 = lun;
if ((logical(kind=4)) __builtin_expect (D.536 0, 0))
{
_gfortran_generate_error (open_parm.1, 5005, Negative unit number in
I/O statement[1]{lb: 1 sz: 1});
}
if ((logical(kind=4)) __builtin_expect (D.536 -1, 0))
{
_gfortran_generate_error (open_parm.1, 5005, Unit number in I/O
statement too large[1]{lb: 1 sz: 1});
}
open_parm.1.common.unit = (integer(kind=4)) D.536;
_gfortran_st_open (open_parm.1);
Clearly, the second if() is bogus. The dump with 4.5.0 does
not contain either if() block.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40638
[Bug fortran/40643] New: maxloc/minloc: Wrong result for NaN at position 1
Per IEEE 754:2008, one has max(x,NaN) == max(NaN,x) == x. Gfortran's inline version of maxloc, maxval and max (ditto for min*) follows this. However, the libgfortran version does not: real :: r(4), z z = 0.0 r = (/ z/z, -1., -42., 849. /) print *,r print *, minloc(r), minval(r) print *, maxloc(r), maxval(r) end Produces: NaN -1.000 -42.00 849.0 1 -42.00 1 849.0 Correct is - as ifort has -: NaN -1.00 -42.0 849. 3 -42.0 4 849. -- Summary: maxloc/minloc: Wrong result for NaN at position 1 Product: gcc Version: 4.5.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=40643
[Bug target/40644] New: Optimizing for pentium-m gives worse code than optimizing for i486
Try compiling the attached program with the following options (they differ only in -march specification) 1. gcc -std=c99 -march=i486 -funroll-loops -fprefetch-loop-arrays -ftree-vectorize -O3 -o gen_weyl_group gen_weyl_group.c 2. gcc -std=c99 -march=i686 -funroll-loops -fprefetch-loop-arrays -ftree-vectorize -O3 -o gen_weyl_group gen_weyl_group.c 3. gcc -std=c99 -march=pentium-m -funroll-loops -fprefetch-loop-arrays -ftree-vectorize -O3 -o gen_weyl_group gen_weyl_group.c With my notebook (CPU core is Dothan) I get the following execution times: i486 37.510 i686 37.534 p-m 53.959 Results for i486 and i686 are roughly the same, but compiling for pentium-m results in a seriously degraded performance. I first noted this behaviour with gcc 4.3.3 that is my system's stock compiler; the abovementioned times were measured for 4.5.0-svn149207, so, probably, all versions from 4.3 to 4.5 are affected by this bug. GCC 4.5.0, used to compile the tests, was configured with the following options: --prefix=/home/artem/testing/gcc45 --enable-shared --enable-bootstrap --enable-languages=c --enable-threads=posix --enable-checking=release --with-system-zlib --with-gnu-ld --verbose --with-arch=i686 -- Summary: Optimizing for pentium-m gives worse code than optimizing for i486 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aanisimov at inbox dot ru GCC build triplet: i486-slackware-linux GCC host triplet: i486-slackware-linux GCC target triplet: i486-slackware-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40644
[Bug target/40644] Optimizing for pentium-m gives worse code than optimizing for i486
--- Comment #1 from aanisimov at inbox dot ru 2009-07-03 18:28 --- Created an attachment (id=18137) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18137action=view) Sample program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40644
[Bug target/40644] Optimizing for pentium-m gives worse code than optimizing for i486
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-03 18:55 --- Try -march=pentium-m -mtune=generic. Pentium-M never received any special tuning (it is the same as for pentium-pro). So is -march=i686 btw, but i686 does not have SSE, so it is likely vectorization and/or prefetching that slows your case 3. down. Try disabling prefetching. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40644
[Bug target/40644] Optimizing for pentium-m gives worse code than optimizing for i486
--- Comment #3 from aanisimov at inbox dot ru 2009-07-03 19:12 --- Try disabling prefetching. Indeed, removing -fprefetch-loop-arrays made the program run in 37.534 seconds, exactly like one compiled for i686. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40644
[Bug tree-optimization/40640] ICE in set_value_range, at tree-vrp.c:383 [regression]
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-03 19:26 --- Reducing. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|c |tree-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40640
[Bug fortran/40643] maxloc/minloc: Wrong result for NaN at position 1
--- Comment #1 from jakub at gcc dot gnu dot org 2009-07-03 19:30 --- Even the inline version is wrong I think. real :: r(4), z z = 0.0 r = (/ z/z, z/z, z/z, z/z /) print *,r print *, minloc(r,dim=1), minval(r,dim=1) print *, maxloc(r,dim=1), maxval(r,dim=1) end Not sure what minval/maxval should be in this case, but minloc/maxloc 0 looks wrong (given that for non-empty arrays it is supposed to be 1 .. arrayextent). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40643
[Bug tree-optimization/40640] [4.5 Regression] ICE in set_value_range, at tree-vrp.c:383
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-07-03 19:42 ---
Confirmed.
enum { gcr0_8259_bit = 0x2000, gcr0_reset_bit = 0x8000 };
void decode_opic_address(int *);
void hw_opic_io_read_buffer(int index)
{
unsigned reg = 0;
decode_opic_address(index);
switch (index)
{
case 0:
reg |= gcr0_8259_bit;
}
sim_io_printf_filtered2 (index, reg);
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||ice-on-valid-code
Known to work||4.4.0
Last reconfirmed|-00-00 00:00:00 |2009-07-03 19:42:25
date||
Summary|ICE in set_value_range, at |[4.5 Regression] ICE in
|tree-vrp.c:383 [regression] |set_value_range, at tree-
||vrp.c:383
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40640
[Bug tree-optimization/40640] [4.5 Regression] ICE in set_value_range, at tree-vrp.c:383
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-07-03 19:49 --- switch-conversion triggers this, but it looks like a VRP issue after all. Mine. -- 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|NEW |ASSIGNED Last reconfirmed|2009-07-03 19:42:25 |2009-07-03 19:49:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40640
[Bug tree-optimization/40640] [4.5 Regression] ICE in set_value_range, at tree-vrp.c:383
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-07-03 20:04 --- (gdb) call debug_tree (limit) integer_cst 0xb7d5ac40 type integer_type 0xb7d2aee0 constant 0 (gdb) call vrp_val_is_max (limit) $6 = 1 '\001' (gdb) call vrp_val_is_min (limit) $7 = 1 '\001' err ... (gdb) call debug_tree (0xb7d2aee0) integer_type 0xb7d2aee0 type integer_type 0xb7ccd000 unsigned int public unsigned sizetype SI size integer_cst 0xb7cbe4b4 constant 32 unit size integer_cst 0xb7cbe2a0 constant 4 align 32 symtab 0 alias set -1 canonical type 0xb7ccd000 precision 32 min integer_cst 0xb7cbe4d0 0 max integer_cst 0xb7cbea64 -1 public SI size integer_cst 0xb7cbe4b4 32 unit size integer_cst 0xb7cbe2a0 4 align 32 symtab 0 alias set -1 canonical type 0xb7d2aee0 precision 32 min integer_cst 0xb7cbe2bc 0 max integer_cst 0xb7cbe2bc 0 hmm - single-valued integer subtypes. I have a patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40640
[Bug c/40627] not following right-then-left rule when compiling function pointers
--- Comment #6 from raeburn at raeburn dot org 2009-07-03 20:06 --- Subject: Re: not following right-then-left rule when compiling function pointers On Jul 3, 2009, at 10:42, dj2con at gmail dot com wrote: I don't know where you've been hiding for these past twenty years, Ken. But the right left rule has been around longer than you've been working (and longer than Microsoft has been in business!). I would take the time to explain it to you, but you can google the terms right left rule C as easily as I can. I've seen it. What I haven't seen is the declaration you were trying to use, and that you were claiming was valid. My experience on Windows is also weak. But I don't see what that has to do with the problem at hand. From your phrasing, I assumed that you had used the construct before, but it would've had to have been in an environment where extensions were added to the language and where I wouldn't have been familiar with them. Looking back, you described the rule as traditional and in long use, not the specific construct; my mistake. And, you appeared to be using cygwin in your preprocessed example; hence my (wrong) guess about Windows experience. In another comment Richard Guenther also claimed it is not a valid prototype. Richard typically knows what he's talking about, so I'll take his word for it and assume that the right left rule does not apply for some reason in this particular case. I'd say the right then left rule is a guide to reading valid C declarations, more than constructing them. The standard tells you how you can construct valid C declarations. Ken -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40627
[Bug target/40587] [4.4/4.5 Regression] Revision 139590 caused ICE in emit_swap_insn at reg-stack.c:827
--- Comment #8 from vmakarov at redhat dot com 2009-07-03 21:30 --- The problem was in usage of df_get_live_out in ira.c::build_insn_chain instead of DF_LR_OUT. Later contains r58 (assigned to st0 register) and it creates restore insn for st0 after the call and prevents reg-stack crashing. The original IRA patch used DF_LR_OUT. After removing the old RA, accidentally IRA started to use df_get_live_out used by the old RA. I'll send a patch solving the problem soon. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40587
[Bug tree-optimization/40640] [4.5 Regression] ICE in set_value_range, at tree-vrp.c:383
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-07-03 22:09 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40640
[Bug tree-optimization/40640] [4.5 Regression] ICE in set_value_range, at tree-vrp.c:383
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-07-03 22:09 --- Subject: Bug 40640 Author: rguenth Date: Fri Jul 3 22:09:12 2009 New Revision: 149211 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149211 Log: 2009-07-03 Richard Guenther rguent...@suse.de PR tree-optimization/40640 * tree-switch-conversion.c (build_arrays): Perform arithmetic in original type. * gcc.c-torture/compile/pr40640.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr40640.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-switch-conversion.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40640
[Bug target/40587] [4.4/4.5 Regression] Revision 139590 caused ICE in emit_swap_insn at reg-stack.c:827
--- Comment #9 from vmakarov at gcc dot gnu dot org 2009-07-03 22:36 --- Subject: Bug 40587 Author: vmakarov Date: Fri Jul 3 22:36:31 2009 New Revision: 149212 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149212 Log: 2009-07-03 Vladimir Makarov vmaka...@redhat.com PR target/40587 * ira.c (build_insn_chain): Use DF_LR_OUT instead of df_get_live_out. * testsuite/gfortran.dg/pr40587.f: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr40587.f Modified: trunk/gcc/ChangeLog trunk/gcc/ira.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40587
[Bug target/40587] [4.4/4.5 Regression] Revision 139590 caused ICE in emit_swap_insn at reg-stack.c:827
--- Comment #10 from vmakarov at gcc dot gnu dot org 2009-07-03 22:46 --- Subject: Bug 40587 Author: vmakarov Date: Fri Jul 3 22:46:30 2009 New Revision: 149213 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149213 Log: 2009-07-03 Vladimir Makarov vmaka...@redhat.com PR target/40587 * ira.c (build_insn_chain): Use DF_LR_OUT instead of df_get_live_out. * testsuite/gfortran.dg/pr40587.f: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/pr40587.f Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/ira.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40587
[Bug fortran/40638] RTE: Unit number in I/O statement too large -- fails with any low value
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2009-07-03 23:24
---
Yes, I have the patch already. Its a one liner.
Index: trans-io.c
===
--- trans-io.c (revision 149123)
+++ trans-io.c (working copy)
@@ -471,7 +471,7 @@ set_parameter_value (stmtblock_t *block,
gfc_conv_expr_val (se, e);
/* If we're storing a UNIT number, we need to check it first. */
- if (type == IOPARM_common_unit e-ts.kind != 4)
+ if (type == IOPARM_common_unit e-ts.kind 4)
{
tree cond, max;
int i;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40638
[Bug c/40645] New: Bus error caused by ldd/std instructions in struct copy.
$ gcc -v
Using built-in specs.
Target: sparc-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --with-cpu=v8 --with-long-double-128
--enable-checking=release --build=sparc-linux-gnu --host=sparc-linux-gnu
--target=sparc-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1.1)
To trigger the bug :-
$ gcc align_bug.c
$ ./a.out
Bus error
$
Here is align_bug.c :-
-
#include stdio.h
struct b_one {
int i;
double d;
};
struct b_two {
int i1;
int i2;
};
union myblock {
struct b_one one;
struct b_two two;
};
void myfunc(union myblock *dp1, union myblock *dp2)
{
dp2-two = dp1-two;
}
int main()
{
int w;
struct b_two a = {1,2};
struct b_two b;
myfunc((union myblock *)a, (union myblock *)b);
printf(%d %d\n, b.i1, b.i2);
return 0;
}
--
The problem seems to happen in myfunc when the compiled code tries
to copy the 8-byte structure dp2-two to dp1-two, using a ldd/std
instruction pair. The problem seems to be that dp1 and dp2 (ie a and
b in main) aren't strictly enough aligned for that. If you take out
the redundant int w in main then a and b happen to be aligned okay
and the bus error doesn't happen.
I think the compiler is assuming union myblock has the same
alignment as struct b_one, which is more strictly aligned than
struct b_two because of its double member.
I realise that casting a to (union myblock*) in main may technically
invoke undefined behaviour... but I think the cast is reasonable given
that union myblock contains the type of a.
One other thing, there is a flag -mno-faster-structs which this page
suggests would prevent this sort of ldd/std use
(http://gcc.gnu.org/onlinedocs/gcc/SPARC-Options.html). Unfortunately
this flag doesn't seem to make any difference to this case.
--
Summary: Bus error caused by ldd/std instructions in struct copy.
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dentongosnell at yahoo dot com
GCC build triplet: sparc-linux-gnu
GCC host triplet: sparc-linux-gnu
GCC target triplet: sparc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40645
Re: [Bug c/40645] New: Bus error caused by ldd/std instructions in struct copy.
This code is undefined because of alignment requirments differences
for the structs and the union.
Sent from my iPhone
On Jul 3, 2009, at 6:33 PM, dentongosnell at yahoo dot com gcc-bugzi...@gcc.gnu.org
wrote:
$ gcc -v
Using built-in specs.
Target: sparc-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1
'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-
shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/
include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --with-cpu=v8 --with-long-double-128
--enable-checking=release --build=sparc-linux-gnu --host=sparc-linux-
gnu
--target=sparc-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1.1)
To trigger the bug :-
$ gcc align_bug.c
$ ./a.out
Bus error
$
Here is align_bug.c :-
-
#include stdio.h
struct b_one {
int i;
double d;
};
struct b_two {
int i1;
int i2;
};
union myblock {
struct b_one one;
struct b_two two;
};
void myfunc(union myblock *dp1, union myblock *dp2)
{
dp2-two = dp1-two;
}
int main()
{
int w;
struct b_two a = {1,2};
struct b_two b;
myfunc((union myblock *)a, (union myblock *)b);
printf(%d %d\n, b.i1, b.i2);
return 0;
}
--
The problem seems to happen in myfunc when the compiled code tries
to copy the 8-byte structure dp2-two to dp1-two, using a ldd/std
instruction pair. The problem seems to be that dp1 and dp2 (ie a and
b in main) aren't strictly enough aligned for that. If you take out
the redundant int w in main then a and b happen to be aligned okay
and the bus error doesn't happen.
I think the compiler is assuming union myblock has the same
alignment as struct b_one, which is more strictly aligned than
struct b_two because of its double member.
I realise that casting a to (union myblock*) in main may technically
invoke undefined behaviour... but I think the cast is reasonable given
that union myblock contains the type of a.
One other thing, there is a flag -mno-faster-structs which this page
suggests would prevent this sort of ldd/std use
(http://gcc.gnu.org/onlinedocs/gcc/SPARC-Options.html). Unfortunately
this flag doesn't seem to make any difference to this case.
--
Summary: Bus error caused by ldd/std instructions in
struct copy.
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dentongosnell at yahoo dot com
GCC build triplet: sparc-linux-gnu
GCC host triplet: sparc-linux-gnu
GCC target triplet: sparc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40645
[Bug c/40645] Bus error caused by ldd/std instructions in struct copy.
--- Comment #1 from pinskia at gmail dot com 2009-07-04 01:38 ---
Subject: Re: New: Bus error caused by ldd/std instructions in struct copy.
This code is undefined because of alignment requirments differences
for the structs and the union.
Sent from my iPhone
On Jul 3, 2009, at 6:33 PM, dentongosnell at yahoo dot com
gcc-bugzi...@gcc.gnu.org
wrote:
$ gcc -v
Using built-in specs.
Target: sparc-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1
'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-
shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/
include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --with-cpu=v8 --with-long-double-128
--enable-checking=release --build=sparc-linux-gnu --host=sparc-linux-
gnu
--target=sparc-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1.1)
To trigger the bug :-
$ gcc align_bug.c
$ ./a.out
Bus error
$
Here is align_bug.c :-
-
#include stdio.h
struct b_one {
int i;
double d;
};
struct b_two {
int i1;
int i2;
};
union myblock {
struct b_one one;
struct b_two two;
};
void myfunc(union myblock *dp1, union myblock *dp2)
{
dp2-two = dp1-two;
}
int main()
{
int w;
struct b_two a = {1,2};
struct b_two b;
myfunc((union myblock *)a, (union myblock *)b);
printf(%d %d\n, b.i1, b.i2);
return 0;
}
--
The problem seems to happen in myfunc when the compiled code tries
to copy the 8-byte structure dp2-two to dp1-two, using a ldd/std
instruction pair. The problem seems to be that dp1 and dp2 (ie a and
b in main) aren't strictly enough aligned for that. If you take out
the redundant int w in main then a and b happen to be aligned okay
and the bus error doesn't happen.
I think the compiler is assuming union myblock has the same
alignment as struct b_one, which is more strictly aligned than
struct b_two because of its double member.
I realise that casting a to (union myblock*) in main may technically
invoke undefined behaviour... but I think the cast is reasonable given
that union myblock contains the type of a.
One other thing, there is a flag -mno-faster-structs which this page
suggests would prevent this sort of ldd/std use
(http://gcc.gnu.org/onlinedocs/gcc/SPARC-Options.html). Unfortunately
this flag doesn't seem to make any difference to this case.
--
Summary: Bus error caused by ldd/std instructions in
struct copy.
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dentongosnell at yahoo dot com
GCC build triplet: sparc-linux-gnu
GCC host triplet: sparc-linux-gnu
GCC target triplet: sparc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40645
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40645
[Bug fortran/40638] RTE: Unit number in I/O statement too large -- fails with any low value
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2009-07-04 03:07 --- Subject: Bug 40638 Author: jvdelisle Date: Sat Jul 4 03:07:12 2009 New Revision: 149218 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149218 Log: 2009-07-03 Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/40638 * trans-io.c (set_parameter_value): Don't build un-necessary run-time checks for units of KIND less than 4. Modified: branches/gcc-4_4-branch/gcc/fortran/ChangeLog branches/gcc-4_4-branch/gcc/fortran/trans-io.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40638
[Bug fortran/40638] RTE: Unit number in I/O statement too large -- fails with any low value
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2009-07-04 04:05 --- Subject: Bug 40638 Author: jvdelisle Date: Sat Jul 4 04:05:19 2009 New Revision: 149219 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149219 Log: 2009-07-03 Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/40638 * gfortran.dg/unit_1.f90: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/unit_1.f90 Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40638
[Bug fortran/40638] RTE: Unit number in I/O statement too large -- fails with any low value
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2009-07-04 04:17 --- Subject: Bug 40638 Author: jvdelisle Date: Sat Jul 4 04:16:59 2009 New Revision: 149220 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149220 Log: 2009-07-03 Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/40638 * trans-io.c (set_parameter_value): Don't build un-necessary run-time checks for units of KIND less than 4. Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/trans-io.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40638
[Bug fortran/40638] RTE: Unit number in I/O statement too large -- fails with any low value
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2009-07-04 04:20 --- Subject: Bug 40638 Author: jvdelisle Date: Sat Jul 4 04:20:24 2009 New Revision: 149221 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149221 Log: 2009-07-03 Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/40638 * gfortran.dg/unit_1.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/unit_1.f90 Modified: branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40638
[Bug fortran/40638] RTE: Unit number in I/O statement too large -- fails with any low value
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2009-07-04 04:25 --- Subject: Bug 40638 Author: jvdelisle Date: Sat Jul 4 04:25:20 2009 New Revision: 149222 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149222 Log: 2009-07-03 Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/40638 * gfortran.dg/unit_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/unit_1.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40638
[Bug fortran/40638] RTE: Unit number in I/O statement too large -- fails with any low value
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2009-07-04 04:28 --- Fixed on 4.3 and 4.4. Added new test case to 4.5 as well as 4.3 and 4.4 -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40638
[Bug c++/40619] [c++0x] ICE on repeated decltype expression in auto functions
--- Comment #2 from jason at gcc dot gnu dot org 2009-07-04 04:34 --- Subject: Bug 40619 Author: jason Date: Sat Jul 4 04:34:03 2009 New Revision: 149223 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149223 Log: PR c++/40619 * cp-tree.h (struct lang_decl_parm): New. (struct lang_decl): Add it. (LANG_DECL_PARM_CHECK): New. (DECL_PARM_INDEX): New. * decl2.c (parm_index): Remove. * lex.c (retrofit_lang_decl): Handle parms. (cxx_dup_lang_specific_decl): Likewise. * mangle.c (write_expression): Adjust. * tree.c (cp_tree_equal): Adjust. (decl_linkage): Only check DECL_COMDAT for functions and variables. * parser.c (cp_parser_parameter_declaration_list): Set DECL_PARM_INDEX. * pt.c (iterative_hash_template_arg): Hash it. Added: trunk/gcc/testsuite/g++.dg/cpp0x/auto16.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl2.c trunk/gcc/cp/lex.c trunk/gcc/cp/mangle.c trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40619
