[Bug libfortran/32456] IO error message should show Unit/Filename
--- Comment #7 from patchapp at dberlin dot org 2007-06-29 06:15 --- Subject: Bug number PR32456 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-06/msg02095.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32456
[Bug fortran/32483] edit descriptor checking: Compile-time check for zero width for reading
--- Comment #4 from burnus at gcc dot gnu dot org 2007-06-29 06:04 --- > What was status on this? I think the patch was OK. I somehow expected that you would send also an email to the list besides the "OK" in the IRC channel. FIXED in GCC 4.3.x -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32483
[Bug fortran/32483] edit descriptor checking: Compile-time check for zero width for reading
--- Comment #3 from burnus at gcc dot gnu dot org 2007-06-29 06:03 --- Subject: Bug 32483 Author: burnus Date: Fri Jun 29 06:03:05 2007 New Revision: 126107 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126107 Log: 2007-06-29 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/32483 * io.c (format_lex): Fix FMT_ZERO. (check_format,check_format_string,gfc_match_format, check_io_constraints) Additional checking for READ. 2007-06-29 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/32483 * gfortran.dg/fmt_read_2.f90: New. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32483
[Bug c/32542] New: When -msdata is set, gcc sent -memb to gas.
I have a question about the behavior of gcc for powerpc. I think the arguments -msdata and -msdata=default have same effect to gcc. But gcc sent different argument to gas. When -msdata is set, gcc sent -memb to gas. When -msdata=default is set, gcc doesn't send -memb to gas. I think `specs' has an error. Is it correct? Environment: gcc version 4.1.1 Configured with: ../gcc-4.1.1/configure --prefix=/work/te/tool/Linux-i686 --target=powerpc-unknown-linux --with-gnu-as --with-gnu-ld --disable-threads --enable-languages=c --enable-version-specific-runtime-libs --disable-libstdcxx-pch --disable-shared GNU assembler version 2.17 (powerpc-unknown-linux) using BFD version 2.17 host: i686-pc-linux-gnu Example $ /work/te/tool/Linux-i686/bin/powerpc-unknown-linux-gcc -save-temps -v -msdata -c -o main.o main.c . . /work/te/tool/Linux-i686/powerpc-unknown-linux/bin/as -mppc -many -V -Qy -memb -o main.o main.s $ /work/te/tool/Linux-i686/bin/powerpc-unknown-linux-gcc -save-temps -v -msdata=default -c -o main.o main.c . . /work/te/tool/Linux-i686/powerpc-unknown-linux/bin/as -mppc -many -V -Qy -o main.o main.s Regards. -- Summary: When -msdata is set, gcc sent -memb to gas. Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tanaka at personal-media dot co dot jp GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: powerpc-unknown-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32542
[Bug fortran/32483] edit descriptor checking: Compile-time check for zero width for reading
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-06-29 03:28 --- What was status on this? I think the patch was OK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32483
[Bug tree-optimization/32527] [4.3 Regression] ICE in build2_stat, at tree.c:3074
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-29 03:23 --- Testing a patch for this right now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32527
[Bug tree-optimization/32120] missed PRE/FRE of a*2+4 and (a+2)*2
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-29 03:05 ---
Note we should also optimize:
int f(int a, int b)
{
int c = a+4;
int d = c*2;
int e = a*2;
int f = e+4;
return f+d;
}
into "a*2 + 12;" (or "(a+6)*2" ) so that only one mutliplication is there.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32120
[Bug libstdc++/32509] [4.2 4.3 regression] unable to explicitely configure with a given locale model
--- Comment #10 from pcarlini at suse dot de 2007-06-28 23:04 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Target Milestone|--- |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32509
[Bug libstdc++/32509] [4.2 4.3 regression] unable to explicitely configure with a given locale model
--- Comment #9 from paolo at gcc dot gnu dot org 2007-06-28 23:02 --- Subject: Bug 32509 Author: paolo Date: Thu Jun 28 23:02:05 2007 New Revision: 126098 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126098 Log: 2007-06-28 Paolo Carlini <[EMAIL PROTECTED]> PR libstdc++/32509 * acinclude.m4 (GLIBCXX_ENABLE_CLOCALE): Carry out the checks involving the de_DE locale only if an auto locale config is used for a target suitable for the gnu locale model. * docs/html/install.html: Update. * configure: Regenerated. Modified: branches/gcc-4_2-branch/libstdc++-v3/acinclude.m4 branches/gcc-4_2-branch/libstdc++-v3/configure branches/gcc-4_2-branch/libstdc++-v3/docs/html/install.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32509
[Bug fortran/30940] Fortran 2003: Scalar CHARACTER supplied to array dummy
--- Comment #3 from burnus at gcc dot gnu dot org 2007-06-28 23:01 --- Created an attachment (id=13802) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13802&action=view) tests, early draft of a patch Attached is some tests plus some minimal patch. Using the patch most valid cases should work. However, some invalid cases are allowed (no range check). The tests have been verified using NAG f95, except for the fourth case in char_argument_3.f90 for which f95 does not give an error. One should re-read the standard and check whether I miss some invalid/valid cases, which should be covered. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30940
[Bug libstdc++/32509] [4.2 4.3 regression] unable to explicitely configure with a given locale model
--- Comment #8 from paolo at gcc dot gnu dot org 2007-06-28 22:59 --- Subject: Bug 32509 Author: paolo Date: Thu Jun 28 22:59:00 2007 New Revision: 126097 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126097 Log: 2007-06-28 Paolo Carlini <[EMAIL PROTECTED]> PR libstdc++/32509 * acinclude.m4 (GLIBCXX_ENABLE_CLOCALE): Carry out the checks involving the de_DE locale only if an auto locale config is used for a target suitable for the gnu locale model. * docs/html/install.html: Update. * configure: Regenerated. Modified: branches/gcc-4_2-branch/libstdc++-v3/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32509
[Bug libstdc++/32509] [4.2 4.3 regression] unable to explicitely configure with a given locale model
--- Comment #7 from paolo at gcc dot gnu dot org 2007-06-28 22:58 --- Subject: Bug 32509 Author: paolo Date: Thu Jun 28 22:58:32 2007 New Revision: 126096 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126096 Log: 2007-06-28 Paolo Carlini <[EMAIL PROTECTED]> PR libstdc++/32509 * acinclude.m4 (GLIBCXX_ENABLE_CLOCALE): Carry out the checks involving the de_DE locale only if an auto locale config is used for a target suitable for the gnu locale model. * docs/html/install.html: Update. * configure: Regenerated. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/configure trunk/libstdc++-v3/docs/html/install.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32509
[Bug tree-optimization/32540] [4.3 Regression] Exponential time behavior in PRE
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-06-28 20:25 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-28 20:25:29 date|| Summary|Exponential time behavior in|[4.3 Regression] Exponential |PRE |time behavior in PRE Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32540
[Bug tree-optimization/32540] Exponential time behavior in PRE
--- Comment #1 from falk at debian dot org 2007-06-28 20:15 --- Created an attachment (id=13801) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13801&action=view) Original test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32540
[Bug tree-optimization/32540] New: Exponential time behavior in PRE
int f(void);
void acceptloop_th(int *t) {
int options = 0;
if (f()) options |= 0x1 << 0;
if (f()) options |= 0x1 << 1;
if (f()) options |= 0x1 << 2;
if (f()) options |= 0x1 << 3;
if (f()) options |= 0x1 << 4;
if (f()) options |= 0x1 << 5;
if (f()) options |= 0x1 << 6;
if (f()) options |= 0x1 << 7;
if (f()) options |= 0x1 << 8;
if (f()) options |= 0x1 << 9;
if (f()) options |= 0x1 << 10;
if (f()) options |= 0x1 << 11;
if (f()) options |= 0x1 << 12;
if (f()) options |= 0x1 << 13;
if (f()) options |= 0x1 << 14;
if (f()) options |= 0x1 << 15;
if (f()) options |= 0x1 << 16;
if (f()) options |= 0x1 << 17;
if (f()) options |= 0x1 << 18;
if (f()) options |= 0x1 << 19;
if (f()) options |= 0x1 << 20;
if (f()) options |= 0x1 << 21;
if (f()) options |= 0x1 << 22;
if (f()) options |= 0x1 << 23;
if (f()) options |= 0x1 << 24;
if (f()) options |= 0x1 << 25;
if (f()) options |= 0x1 << 26;
*t = options;
}
takes many minutes to compile with 4.3. No problem with 4.2. Timing report
shows PRE, and -fno-tree-pre makes it go really fast.
Some timings, where the first number is the number of "if"-lines:
10 gcc -c -O3 mini2.c -DN=$n 0.17s user 0.01s system 97% cpu 0.184 total
11 gcc -c -O3 mini2.c -DN=$n 0.20s user 0.02s system 97% cpu 0.221 total
12 gcc -c -O3 mini2.c -DN=$n 0.28s user 0.01s system 95% cpu 0.306 total
13 gcc -c -O3 mini2.c -DN=$n 0.42s user 0.03s system 97% cpu 0.463 total
14 gcc -c -O3 mini2.c -DN=$n 0.76s user 0.02s system 97% cpu 0.805 total
15 gcc -c -O3 mini2.c -DN=$n 1.52s user 0.03s system 97% cpu 1.604 total
16 gcc -c -O3 mini2.c -DN=$n 3.24s user 0.07s system 97% cpu 3.396 total
17 gcc -c -O3 mini2.c -DN=$n 7.00s user 0.12s system 97% cpu 7.314 total
18 gcc -c -O3 mini2.c -DN=$n 15.01s user 0.21s system 96% cpu 15.748 total
19 gcc -c -O3 mini2.c -DN=$n 33.21s user 0.49s system 94% cpu 35.600 total
20 gcc -c -O3 mini2.c -DN=$n 76.29s user 0.87s system 96% cpu 1:19.94 total
I'll also attach the original source this test case was extracted from.
--
Summary: Exponential time behavior in PRE
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: compile-time-hog
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: falk at debian dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32540
[Bug libgcj/30999] support for GCC4.0's fvisibility option in JNIEXPORT macro
--- Comment #4 from tromey at gcc dot gnu dot org 2007-06-28 19:59 --- Fix checked in. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30999
[Bug target/30417] Section .data cannot be moved with -mmcu=atmega88
--- Comment #4 from eweddington at cso dot atmel dot com 2007-06-28 19:48 --- Closing bug as WORKSFORME. -- eweddington at cso dot atmel dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30417
[Bug libgcj/30999] support for GCC4.0's fvisibility option in JNIEXPORT macro
--- Comment #3 from tromey at gcc dot gnu dot org 2007-06-28 19:35 --- Subject: Bug 30999 Author: tromey Date: Thu Jun 28 19:35:25 2007 New Revision: 126090 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126090 Log: 2007-06-28 Jan Nijtmans <[EMAIL PROTECTED]> PR libgcj/30999: * jni_md.h: Add the possibility to compile jni code with. -fvisibility=hidden. This causes all symbols to be hidden except the JNI functions which need to be exported. Modified: trunk/libjava/ChangeLog trunk/libjava/include/jni_md.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30999
[Bug target/30417] Section .data cannot be moved with -mmcu=atmega88
--- Comment #3 from e9fritte at etek dot chalmers dot se 2007-06-28 19:29 --- At that time I was probably using binutils 2.16 (Ubunty Edgy). It seems Feisty still has that version. It's great if this has been resolved in 4.2, although my workaround does its job for now. Thanks to whoever fixed it! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30417
[Bug middle-end/32417] [4.3 Regression] 416.gamess ICEs (in aff_combination_add_elt, tree-affine.c)
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-06-28 19:06 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32417
[Bug c/32494] gcc-4.3.x _32-bit_ becoming irrelevant to kernel
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-06-28 19:06 --- Again please read What I wrote about what the C99 standard requires. It requires long long support for a freestanding compiler. So that is provided with libgcc. If the Linux kernel team decides that they don't want to use libgcc, how can this be a GCC bug then? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32494
[Bug middle-end/32417] [4.3 Regression] 416.gamess ICEs (in aff_combination_add_elt, tree-affine.c)
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-06-28 19:04 --- Subject: Bug 32417 Author: pinskia Date: Thu Jun 28 19:03:49 2007 New Revision: 126082 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126082 Log: 2007-06-28 Andrew Pinski <[EMAIL PROTECTED]> PR tree-opt/32417 * tree-affine.c (aff_combination_add_elt): Handle pointer addition specially. 2007-06-28 Andrew Pinski <[EMAIL PROTECTED]> PR tree-opt/32417 * gfortran.fortran-torture/compile/pr32417.f90: New test. Added: trunk/gcc/testsuite/gfortran.fortran-torture/compile/pr32417.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-affine.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32417
[Bug c/32448] abs / printf bug
--- Comment #23 from pinskia at gcc dot gnu dot org 2007-06-28 18:51 --- There is a -Wformat for a reason, use it. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|Security - abs / printf bug |abs / printf bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32448
[Bug c/32529] [4.1 only] ICE, typedef of function taking VLA
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-06-28 18:49 --- No, this is a dup as the bug there still has not been fixed for 4.1.x. *** This bug has been marked as a duplicate of 28504 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32529
[Bug c/28504] [4.0/4.1 regression] ICE with variable sized array
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-06-28 18:49 --- *** Bug 32529 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28504
[Bug c/32448] Security - abs / printf bug
--- Comment #22 from rob1weld at aol dot com 2007-06-28 18:32 --- Why is it a bad idea to leave this flaw in GCC ? Format String Bugs and Exploits http://www.geocities.com/ravecoolr/fmt.doc or if you like: http://www.enderunix.org/docs/formatstr.txt Allowing GCC to stay as-is and permit someone to use a user supplied format string to print an integer opens a whole field of exploits that could be closed by fixing this. -- rob1weld at aol dot com changed: What|Removed |Added Summary|abs / printf bug|Security - abs / printf bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32448
[Bug c/32529] [4.1 only] ICE, typedef of function taking VLA
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-28 18:01 --- This works for me in both 4.2.0 and the trunk. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.0.4 Known to work||4.2.0 4.3.0 Summary|ICE, typedef of function|[4.1 only] ICE, typedef of |taking VLA |function taking VLA Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32529
[Bug libgomp/32538] New: All libgomp tests fail to link on IRIX 6: copysignl undefined
All libgomp tests fail to link on IRIX 6: Executing on host: /vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/gcc/xgcc -B/vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/gcc/ /vol/gcc/src/gcc-dist/libgomp/testsuite/libgomp.fortran/appendix-a/a.16.1.f90 -B/vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/mips-sgi-irix6.5/./libgomp/ -I/vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/mips-sgi-irix6.5/./libgomp -I/vol/gcc/src/gcc-dist/libgomp/testsuite/.. -fmessage-length=0 -fopenmp -O0 -L/vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/mips-sgi-irix6.5/./libgomp/.libs -lgomp -L/vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/mips-sgi-irix6.5/./libgomp/../libgfortran/.libs -lgfortranbegin -lgfortran -lm -o ./a.16.1.exe(timeout = 300) ld32: ERROR 33 : Unresolved data symbol "copysignl" -- 1st referenced by /vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/gcc/libgcc.a(_divtc3.o). Use linker option -v to see when and which objects, archives and dsos are loaded. ld32: INFO152: Output file removed because of error. collect2: ld returned 2 exit status compiler exited with status 1 This happens because libgcc contains an undefined reference to copysignl. This function is present in libm, but libm is before libgcc on the linker command line, as can be seen with -v: /vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/gcc/collect2 -call_shared -no_unresolved -init __gcc_init -fini __gcc_fini -_SYSTYPE_SVR4 -woff 131 -n32 -o ./a.16.1.exe /usr/lib32/mips3/crt1.o /vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/gcc/irix-crti.o /vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/gcc/crtbegin.o -L/vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/mips-sgi-irix6.5/./libgomp/.libs -L/vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/mips-sgi-irix6.5/./libgomp/../libgfortran/.libs -L/vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/gcc -L/vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/mips-sgi-irix6.5/./libgomp -L/lib/../lib32 -L/usr/lib/../lib32 /var/tmp//ccCchLrr.o -lgomp -lgfortranbegin -lgfortran -lm -lgomp -dont_warn_unused -lgcc -lgcc_eh -warn_unused -L/usr/lib32/mips3 -L/usr/lib32 -dont_warn_unused -lpthread -lc -warn_unused -dont_warn_unused -lgcc -lgcc_eh -warn_unused /vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/gcc/crtend.o /vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/gcc/irix-crtn.o /usr/lib32/mips3/crtn.o The 4.2 branch is affected as well. Environment: System: IRIX64 columba 6.5 07010238 IP27 host: mips-sgi-irix6.5 build: mips-sgi-irix6.5 target: mips-sgi-irix6.5 configured with: /vol/gcc/src/gcc-dist/configure --prefix=/vol/gcc --with-local-prefix=/vol/gcc --disable-nls --with-gnu-as --with-as=/vol/gcc/lib/gas-2.17 --enable-libgcj --with-gmp=/vol/gcc --with-mpfr=/vol/gcc --disable-libmudflap --enable-languages=c,ada,c++,fortran,objc --no-create --no-recursion How-To-Repeat: Bootstrap and test as described above. --- Comment #1 from ro at techfak dot uni-bielefeld dot de 2007-06-28 17:35 --- Fix: There are two possible solutions: * add -lgcc -lm to the link_gomp spec (this is obviously a hack) * add -lm to the libgcc spec (this seems to be the proper solution) Comments? -- Summary: All libgomp tests fail to link on IRIX 6: copysignl undefined Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at techfak dot uni-bielefeld dot de GCC build triplet: mips-sgi-irix6.5 GCC host triplet: mips-sgi-irix6.5 GCC target triplet: mips-sgi-irix6.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32538
[Bug c/11751] wrong evaluation order of an expression
--- Comment #77 from schwab at suse dot de 2007-06-28 16:54 --- *** Bug 32536 has been marked as a duplicate of this bug. *** -- schwab at suse dot de changed: What|Removed |Added CC||astier at lpnp204 dot in2p3 ||dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11751
[Bug c/32536] wrong generated code on complex statement;
--- Comment #1 from schwab at suse dot de 2007-06-28 16:54 --- You are modifying the same object twice between two sequence points. *** This bug has been marked as a duplicate of 11751 *** -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32536
[Bug bootstrap/32537] New: Boostrap failure: ICE when compiling gengtype-lex.c
When configured and made with
[descartes:gcc/objdirs/objdir-mainline] gcc-test% cat
../../mainline/build-and-check-gcc
#!/bin/tcsh
/bin/rm -rf *; env CC=/pkgs/gcc-4.2.0-64/bin/gcc ../../mainline/configure
--build=powerpc64-apple-darwin8.9.0 --host=powerpc64-apple-darwin8.9.0
--target=powerpc64-apple-darwin8.9.0 --with-gmp=/pkgs/gmp-4.2.1-64/
--with-mpfr=/pkgs/gmp-4.2.1-64/ --prefix=/pkgs/gcc-4.3.0-64; make -j 2
bootstrap BOOT_LDFLAGS='-Wl,-search_paths_first' >& build.log && (make install)
&& (make -k -j 4 check RUNTESTFLAGS="--target_board 'unix{-mcpu=970/-m64}'" >&
check.log ; make mail-report.log)
bootstrap fails with
/Users/gcc-test/programs/gcc/objdirs/objdir-mainline/./prev-gcc/xgcc
-B/Users/gcc-test/programs/gcc/objdirs/objdir-mainline/./prev-gcc/
-B/pkgs/gcc-4.3.0-64/powerpc64-apple-darwin8.9.0/bin/ -c -g -O2 -DIN_GCC -W
-Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings
-Werror -fno-common -Wno-error -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild
-I../../../mainline/gcc -I../../../mainline/gcc/build
-I../../../mainline/gcc/../include -I./../intl
-I../../../mainline/gcc/../libcpp/include -I/pkgs/gmp-4.2.1-64//include
-I/pkgs/gmp-4.2.1-64//include -I../../../mainline/gcc/../libdecnumber
-I../../../mainline/gcc/../libdecnumber/dpd -I../libdecnumber-o
build/gengtype-lex.o gengtype-lex.c
gengtype-lex.c: In function 'yy_get_next_buffer':
gengtype-lex.c:1614: warning: old-style function definition
gengtype-lex.c: In function 'yy_get_previous_state':
gengtype-lex.c:1746: warning: old-style function definition
gengtype-lex.c: In function 'input':
gengtype-lex.c:1859: warning: old-style function definition
gengtype-lex.c: In function 'yylex':
gengtype-lex.c:1602: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
make[3]: *** [build/gengtype-lex.o] Error 1
make[2]: *** [all-stage3-gcc] Error 2
make[1]: *** [stage3-bubble] Error 2
make: *** [all] Error 2
with this version of gcc
[descartes:~/programs/gcc/mainline] gcc-test% cat LAST_UPDATED
Tue Jun 26 16:03:55 EDT 2007
Tue Jun 26 20:03:55 UTC 2007 (revision 126036M)
--
Summary: Boostrap failure: ICE when compiling gengtype-lex.c
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lucier at math dot purdue dot edu
GCC build triplet: powerpc64-apple-darwin8.9.0
GCC host triplet: powerpc64-apple-darwin8.9.0
GCC target triplet: powerpc64-apple-darwin8.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32537
[Bug c/32536] New: wrong generated code on complex statement;
sample code:
#include
int main()
{
char cp[2];
cp[0] = 'A';
cp[1] = 'B';
printf("%x %x\n",cp[0],cp[1]);
cp[0] ^= (cp[1]^=(cp[0]^=cp[1]));
printf("%x %x\n",cp[0],cp[1]);
return 0;
}
The complex byte swapping instruction is far fetched but seems legal.
It actually swaps bytes if compiled with "gcc -O3". Without optimization,
one of the bytes receives a '\0'.
This instruction seemed to work properly with versions 3.
Environment:
System: Linux lpnp204 2.4.21-47.0.1.EL.cernsmp #1 SMP Thu Oct 19 16:35:52 CEST
2006 i686 i686 i386 GNU/Linux
Architecture: i686
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ./configure
How-To-Repeat:
Compile the code above with various degrees of optimization.
--
Summary: wrong generated code on complex statement;
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: astier at lpnp204 dot in2p3 dot fr
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=32536
[Bug target/32523] disastrous scheduling for POWER5
--- Comment #8 from whaley at cs dot utsa dot edu 2007-06-28 14:18 --- I've been doing further testing on the g5 (the only machine where I have local and root access), and this problem does not occur with stock gcc 4.1.1 either. Therefore, whatever problem is avoided by throwing -fno-schedule-insns was not in 4.1.1. BTW, as on the Power5, the best kernel does not get all it's performance back by throwing this flag, even though the simplified example does. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32523
[Bug rtl-optimization/32084] gfortran 4.3 13%-18% slower for induct.f90 than gcc 4.0-based competitor
--- Comment #14 from ubizjak at gmail dot com 2007-06-28 12:59 --- (In reply to comment #13) > core2 AMD > 0m45.215s 0m4.312s (no vectorize) Ehm, the first is full induct.f90 run on _nocona_, whereas AMD is the result of running the attached test. The table with comparable results is then: (gfortran -march=nocona -msse3 -O3 -ffast-math -mfpmath=sse -funroll-loops) nocona(32) AMD(64) 0m4.176s 0m4.312s (no vectorize) 0m8.169s 0m4.668s -ftree-vectorize 0m4.108s 0m4.300s -ftree-vectorize -fvect-cost-model -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32084
[Bug tree-optimization/32230] [4.3 Regression] Segfault in set_bb_for_stmt with -O -ftree-vectorize
--- Comment #10 from irar at il dot ibm dot com 2007-06-28 12:38 --- (In reply to comment #9) >> I suppose all INTEGER_CST bases should be rejected. > Richard. Right. The value actually doesn't matter since the constant part is split to the init part in (tree-data-ref.c:656): split_constant_offset (base_iv.base, &base_iv.base, &dinit); I only don't know where it is better to fail - in dr analysis on in the vectorizer. Thanks, Ira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32230
[Bug tree-optimization/32230] [4.3 Regression] Segfault in set_bb_for_stmt with -O -ftree-vectorize
--- Comment #9 from rguenther at suse dot de 2007-06-28 12:30 --- Subject: Re: [4.3 Regression] Segfault in set_bb_for_stmt with -O -ftree-vectorize On Thu, 28 Jun 2007, irar at il dot ibm dot com wrote: > > > --- Comment #8 from irar at il dot ibm dot com 2007-06-28 12:29 --- > (In reply to comment #7) > > I suppose rejecting NULL bases should work here? > > Yes, only it's not NULL it's zero (0B). > We can reject it in the vectorizer or not create a dr for it... I suppose all INTEGER_CST bases should be rejected. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32230
[Bug tree-optimization/32230] [4.3 Regression] Segfault in set_bb_for_stmt with -O -ftree-vectorize
--- Comment #8 from irar at il dot ibm dot com 2007-06-28 12:29 --- (In reply to comment #7) > I suppose rejecting NULL bases should work here? Yes, only it's not NULL it's zero (0B). We can reject it in the vectorizer or not create a dr for it... Ira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32230
[Bug tree-optimization/32230] [4.3 Regression] Segfault in set_bb_for_stmt with -O -ftree-vectorize
--- Comment #7 from rguenther at suse dot de 2007-06-28 12:20 --- Subject: Re: [4.3 Regression] Segfault in set_bb_for_stmt with -O -ftree-vectorize On Thu, 28 Jun 2007, irar at il dot ibm dot com wrote: > > > --- Comment #6 from irar at il dot ibm dot com 2007-06-28 11:41 --- > ((float*) (&((sbuf_header_t *) ((buf) == &(buf)->buf[0]))->buf[0]))[i] = val; > > is (after ommiting the casts) > > *(1B + (i * 4)) = val; > > Is that legal? "Legal" as far as that you are not allowed to reject it at compile-time. Of course runtime behavior looks completely undefined ;) > Vectorizer assumes that every data-ref has base_address. In the above case we > get the following data-ref structure: > base_address: 0B > offset from base address: 0 > constant offset from base address: 1 > step: 4 > aligned to: 128 > base_object: *0B > symbol tag: SMT.5 > > therefore, creating an empty stmt for the first access of the data-ref in the > loop. > > Before Zdenek's rewrite of data-refs analysis, it failed to create a dr here, > and thus no segfault occurred. I suppose rejecting NULL bases should work here? Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32230
[Bug fortran/32535] New: namelist with private items contained in sub-sub-procedure of a module rejected
Janus, how about submitting a patch for this bug including a testcase? As Janus Weil found out: http://gcc.gnu.org/ml/fortran/2007-06/msg00488.html If a namelist in a procedure contained in a module procedure contains a private item as element, a bogus error message is printed: Error: PRIVATE symbol 'r' cannot be member of PUBLIC namelist at (1) This fails if the symbol is not in the parent, but in the parent->parent namespace. One solution would be to add && !(sym->ns->parent->parent == nl->sym->ns) module mod real, private :: r contains subroutine x contains subroutine y namelist /n/ r end subroutine y end subroutine x end module mod end -- Summary: namelist with private items contained in sub-sub- procedure of a module rejected Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: rejects-valid 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=32535
[Bug rtl-optimization/32084] gfortran 4.3 13%-18% slower for induct.f90 than gcc 4.0-based competitor
--- Comment #13 from burnus at gcc dot gnu dot org 2007-06-28 12:03 --- core2 AMD 0m45.215s 0m4.312s (no vectorize) 1m34.046s 0m4.668s -ftree-vectorize 0m45.447s 0m4.300s -ftree-vectorize -fvect-cost-model i.e. "-ftree-vectorize -fvect-cost-model" is marginally faster than without -ftree-vectorize on AMD but slower on Intel; and on Intel "-ftree-vectorize" alone has a huge impact (80% slower) whereas on AMD only it is only 8% slower. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32084
[Bug middle-end/31150] [4.1/4.2/4.3 Regression] Not promoting an whole array to be static const
--- Comment #5 from eres at il dot ibm dot com 2007-06-28 11:55 ---
(Form off-line discussion with Richard Guenther)
For-
char str[2][16] = {"thisis16charslo","thisis16charslo"};
On ppc64 we will get -
static char C.0[2][16] = {"thisis16charslo", "thisis16charslo"};
while on x86_64 -
str[0] = "thisis16charslo";
str[1] = "thisis16charslo";
and this patch makes this output much worse (although it should be
applied only on sparse data)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31150
[Bug tree-optimization/32230] [4.3 Regression] Segfault in set_bb_for_stmt with -O -ftree-vectorize
--- Comment #6 from irar at il dot ibm dot com 2007-06-28 11:41 --- ((float*) (&((sbuf_header_t *) ((buf) == &(buf)->buf[0]))->buf[0]))[i] = val; is (after ommiting the casts) *(1B + (i * 4)) = val; Is that legal? Vectorizer assumes that every data-ref has base_address. In the above case we get the following data-ref structure: base_address: 0B offset from base address: 0 constant offset from base address: 1 step: 4 aligned to: 128 base_object: *0B symbol tag: SMT.5 therefore, creating an empty stmt for the first access of the data-ref in the loop. Before Zdenek's rewrite of data-refs analysis, it failed to create a dr here, and thus no segfault occurred. Ira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32230
[Bug rtl-optimization/32084] gfortran 4.3 13%-18% slower for induct.f90 than gcc 4.0-based competitor
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-06-28 11:40 --- I suspect the vectorizer leaves us with too much dead statements that confuse the complete unrollers size cost metric. Running dce after vectorization might fix this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32084
[Bug rtl-optimization/32084] gfortran 4.3 13%-18% slower for induct.f90 than gcc 4.0-based competitor
--- Comment #11 from ubizjak at gmail dot com 2007-06-28 11:39 --- (In reply to comment #10) > ;; Not peeling loop completely, rolls too much (8 iterations > 8 [maximum > peelings]) This is meant that original + 8 unroll iterations > 8. So, loop has 46 insns, and 9 copies of loops is more than PARAM_MAX_COMPLETELY_PEELED_INSNS (currently 400) and unroll is rejeceted. However, even with unrolled vectorized loop, we are still 50% slower. It looks that tight sequences of subsd/subpd and mulsd/mulpd kill performance in -ftree-vectorize: movapd %xmm6, %xmm0 movsd %xmm1, -200(%ebp) subsd %xmm5, %xmm0 subpd (%ebx), %xmm3 mulsd %xmm0, %xmm0 mulpd %xmm3, %xmm3 haddpd %xmm3, %xmm3 movapd %xmm3, %xmm2 movsd w2gauss.1408+8, %xmm3 addsd %xmm2, %xmm0 mulsd w1gauss.1411-8(,%eax,8), %xmm3 sqrtsd %xmm0, %xmm1 It looks that there is no other help but -fvect-cost-model. The results for induct.f90 (gfortran -march=nocona -msse3 -O3 -ffast-math -mfpmath=sse -funroll-loops) are: induct.f90, -ftree-vectorize without -fvect-cost-model: user1m34.046s induct.f90, -ftree-vectorize with -fvect-cost-model: user0m45.447s induct.f90 without -ftree-vectorize: user0m45.215s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32084
[Bug c++/32534] New: gcc fails to initialize template's static data members before their use in some cases
the following programm
---
#include
struct A
{
A() : value(0) {}
int value;
};
template
struct B
{
static A a;
};
template A B::a;
//template<> A B::a;
template
struct C
{
C() { B::a.value = 1; }
};
C c;
main()
{
std::cout << B::a.value << std::endl;
}
-
prints 0 instead of expected 1.
It is important that C is template. Otherwise (if C is ordinary class) the
output is 1.
If I use "template<> A B::a;" instead of "template A B::a;" I
got linker error: undefined reference to 'B::a'.
I can't use "template<> A B::a = something;" form (which would help)
because I have only empty ctor (like in the case of map).
--
Summary: gcc fails to initialize template's static data members
before their use in some cases
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vlbel at mail dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32534
[Bug libstdc++/32509] [4.2 4.3 regression] unable to explicitely configure with a given locale model
--- Comment #6 from pcarlini at suse dot de 2007-06-28 10:22 --- Ok, I'm implementing the idea. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-28 10:22:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32509
[Bug rtl-optimization/32084] gfortran 4.3 13%-18% slower for induct.f90 than gcc 4.0-based competitor
--- Comment #10 from ubizjak at gmail dot com 2007-06-28 09:20 --- Well, well - what can be found in _.146r.loop_unroll: Loop 10 is simple: simple exit 40 -> 42 number of iterations: (const_int 8 [0x8]) upper bound: 8 ;; Unable to prove that the loop rolls exactly once ;; Considering peeling completely ;; Not peeling loop completely, rolls too much (8 iterations > 8 [maximum peelings]) Really funny... Since when is "8 more than 8"? ;( However, gcc has no problems when unrolling without --ftree-vectorize: Loop 8 is simple: simple exit 28 -> 30 number of iterations: (const_int 8 [0x8]) upper bound: 8 ;; Unable to prove that the loop rolls exactly once ;; Considering peeling completely ;; Decided to peel loop completely Investigating... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32084
[Bug other/31400] enable static linking of support libraries through -static-libXY
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu |org |dot org URL|http://gcc.gnu.org/ml/gcc- | |patches/2007- | |06/msg00956.html| Status|REOPENED|NEW Keywords|patch | Target Milestone|4.3.0 |--- Version|unknown |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31400
[Bug tree-optimization/32230] [4.3 Regression] Segfault in set_bb_for_stmt with -O -ftree-vectorize
--- Comment #5 from irar at il dot ibm dot com 2007-06-28 09:02 --- I think it is better to check that the statement is not NULL before calling bsi_insert_on_edge_immediate. I am going to prepare a patch for this. Ira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32230
[Bug c/32496] fno-builtin-* not working
--- Comment #3 from schwab at suse dot de 2007-06-28 08:42 --- A freestanding implementation is required to provide long long support. -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32496
[Bug tree-optimization/32533] [4.2 regression] miscompilation at -O3 -ffast-math -ftree-vectorize -march=native
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Known to fail|4.0.2 |4.2.0 Target Milestone|--- |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32533
[Bug rtl-optimization/32084] gfortran 4.3 13%-18% slower for induct.f90 than gcc 4.0-based competitor
--- Comment #9 from ubizjak at gmail dot com 2007-06-28 08:36 --- (In reply to comment #7) > This is what I get without -ftree-vectorize, with -ftree-vectorize (default > cost model off) and with -ftree-vectorize -fvect-cost-model respectively on an > AMD x86-64 (with trunk plus the patch posted by Dorit at > http://gcc.gnu.org/ml/gcc-patches/2007-06/txt00156.txt ) > > Case 1: (no vectorization) > gfortran -static -march=opteron -msse3 -O3 -ffast-math -funroll-loops > pr32084.f90 -o 4.3.novect.out > time ./4.3.novect.out > real0m4.414s > user0m4.312s > sys 0m0.000s > > Case 2: (vectorization without cost model) > gfortran -static -ftree-vectorize -march=opteron -msse3 -O3 -ffast-math > -funroll-loops -fdump-tree-vect-details -fno-show-column pr32084.f90 -o > 4.3.nocost.out > time ./4.3.nocost.out > real0m4.776s > user0m4.668s > sys 0m0.004s > > In short, the 8% advantage that the scalar version has over the vector version > disappears with the cost model. > > Unless I am missing something, the inner loops at lines 207 and 319 (do k = 1, > 9) dont get vectorized (irrespective of the cost model). No, it is OK (but for core2 and nocona -ftree-vectorize has 50% disadvantage compared to scalar versions). The problem is that vectorized loop is not unrolled anymore in the RTL unroller. My speculation is, that by unrolling the vectorized loop, the runtimes of vectorized version will be _faster_ than scalar versions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32084
[Bug c/32529] ICE, typedef of function taking VLA
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Last reconfirmed|-00-00 00:00:00 |2007-06-28 08:34:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32529
[Bug tree-optimization/32533] [4.2 regression] miscompilation at -O3 -ffast-math -ftree-vectorize -march=native
--- Comment #2 from ubizjak at gmail dot com 2007-06-28 08:14 --- (In reply to comment #1) > This bug could be hidden in 4.3.0 as we use MIN_EXPR and MAX_EXPR here. To clear the typo - we use MIN_EXPR and MAX_EXPR in 4.3.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32533
[Bug tree-optimization/32533] [4.2 regression] miscompilation at -O3 -ffast-math -ftree-vectorize -march=native
--- Comment #1 from ubizjak at gmail dot com 2007-06-28 08:13 --- Looks like problems in tree ifcvt pass. Before ifcvt, we have: M.2_16 = (int4) D.1257_15; if (M.2_16 > 1) goto ; else goto ; :; if (M.2_16 > 20) goto ; else goto ; # M.2_64 = PHI ; :; pretmp.118_78 = (real8) M.2_64; # prephitmp.119_79 = PHI <2.0e+1(6), pretmp.118_78(7)>; # M.2_4 = PHI <20(6), M.2_64(7)>; :; But ifcvt creates: D.1446_84 = M.2_16 > 1; D.1447_85 = M.2_16 > 20; _ifc_.127_86 = D.1446_84 && D.1447_85; D.1449_87 = M.2_16 > 1; D.1450_88 = M.2_16 <= 20; _ifc_.128_89 = D.1449_87 && D.1450_88; M.2_64 = M.2_16 > 1 ? M.2_16 : 1; pretmp.118_78 = (real8) M.2_64; prephitmp.119_79 = M.2_16 > 1 ? 2.0e+1 : pretmp.118_78; M.2_4 = M.2_16 > 1 ? 20 : M.2_64; Note the last two lines, where we compare "M.2_16 > 1" instead of "M.2_16 > 20". This bug could be hidden in 4.3.0 as we use MIN_EXPR and MAX_EXPR here. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|middle-end |tree-optimization Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-28 08:13:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32533
[Bug fortran/31205] aliased operator assignment produces wrong result
--- Comment #5 from pault at gcc dot gnu dot org 2007-06-28 08:04 --- (In reply to comment #4) > (In reply to comment #2) > > This is related to PR 14771, most likely the parentheses are being ignored. > The parentheses are being ignored - in fact they disappear completely; I > presume that gfc_simplify_expr is the culprit. Not so - it is matchexp.c, where there is an incorrect interpretation of the standard, such that parentheses are not applied to non-numeric expressions. All expressions in parentheses are data entities. Applying this (modifying gfc_get_parentheses to resolve the expression before doing anything with it.) causes one or two regressions because character lengths need to be carried over (I think!). The second test in this PR now works. > In addition, a temporary needs to be made for intent(out), derived types with > a > default initializer and the initialization applied to that, when the variable > is aliassed. > I note that other compilers apply the initialization in the callee, whereas > gfortran leaves that duty to the caller. I think that the former is "cleaner" Applying gfc_get_parentheses for this case, in resolve_code at the point where module operator assignments are detected, fixes the 1st test in thi PR, as long as the initialization is shifted to the callee. This latter was effected by writing a helper function to write an lvalue expression from a symbol; this has at least one other existing client and does not apparently cause any regressions. > in some sense and that we should make the change. > Thus, this little beauty comprises at least two bugs and should probably be > three PRs:-) I propose that, for the sake of tractability, it should be left > as it is. > Paul I am down to 5 regressions for the overall patch, so I had better assign myself the PR! Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-03-17 07:26:16 |2007-06-28 08:04:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31205
[Bug other/31400] enable static linking of support libraries through -static-libXY
--- Comment #8 from dfranke at gcc dot gnu dot org 2007-06-28 07:00 --- FX, thanks for your patch :) As libgfortran is one of many, at least -static-libgomp would be nice to have as well (others?). Reopening, so the request is not lost. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31400
