[Bug fortran/43228] NAMELIST I/O: Reading at 2 dimensions (rank) array values.
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2010-03-04 05:37 --- Patch in the works. Stay tuned. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43228
[Bug fortran/43228] NAMELIST I/O: Reading at 2 dimensions (rank) array values.
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2010-03-04 05:32 --- Try compiling the test program with -std=f95 and then run it. ;) Oh Bother. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43228
[Bug fortran/43217] Output of Hollerith constants which are not a multiple of 4 bytes
--- Comment #6 from kargl at gcc dot gnu dot org 2010-03-04 03:15 --- (In reply to comment #5) > Tobias, > > If you have a fix in mind, you are welcome to take this. I am going to work > the namelist bug first. > Just close the report. Using Hollerith in 2010 is a less than smart idea. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43217
[Bug fortran/43217] Output of Hollerith constants which are not a multiple of 4 bytes
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2010-03-04 03:08 --- Tobias, If you have a fix in mind, you are welcome to take this. I am going to work the namelist bug first. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43217
[Bug fortran/43244] Invalid statement misinterpreted as FINAL declaration
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2010-03-04 02:34 --- Without looking at the code yet, the matcher must see a space or double colon after the word FINAL before matching it. If it sees anything else, its a MATCH_NO not a MATCH_ERROR. If this is being done then the syntax error in the array qualifiers may/should kick in. Syntax for FINAL is : FINAL [ :: ] final-subroutine-name-list So I think your patch is OK for MATCH_NO but a MATCH_YES must see :: as well. Free or Fixed form is irrelevant. Fixed form may allow things like F I N AL but it still must have :: (or : whitespace :) to match. (Also, the invalid looking array qualifier in that code needs to be caught as well.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43244
[Bug c++/12909] ambiguity in mangling vector types
--- Comment #14 from howarth at nitro dot med dot uc dot edu 2010-03-04 02:32 --- Created an attachment (id=20017) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20017&action=view) g++.dg/abi/mangle41.C assembly file from x86_64-apple-darwin10 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12909
[Bug c++/12909] ambiguity in mangling vector types
--- Comment #13 from howarth at nitro dot med dot uc dot edu 2010-03-04 02:30 --- /sw/src/fink.build/gcc45-4.4.999-20100303/darwin_objdir/gcc/testsuite/g++/../../g++ -B/sw/src/fink.build/gcc45-4.4.999-20100303/darwin_objdir/gcc/testsuite/g++/../../ /sw/src/fink.build/gcc45-4.4.999-20100303/gcc-4.5-20100303/gcc/testsuite/g++.dg/abi/mangle40.C -nostdinc++ -I/sw/src/fink.build/gcc45-4.4.999-20100303/darwin_objdir/x86_64-apple-darwin10.3.0/libstdc++-v3/include/x86_64-apple-darwin10.3.0 -I/sw/src/fink.build/gcc45-4.4.999-20100303/darwin_objdir/x86_64-apple-darwin10.3.0/libstdc++-v3/include -I/sw/src/fink.build/gcc45-4.4.999-20100303/gcc-4.5-20100303/libstdc++-v3/libsupc++ -I/sw/src/fink.build/gcc45-4.4.999-20100303/gcc-4.5-20100303/libstdc++-v3/include/backward -I/sw/src/fink.build/gcc45-4.4.999-20100303/gcc-4.5-20100303/libstdc++-v3/testsuite/util -fmessage-length=0 -mavx -Wabi -fabi-version=2 -S -o mangle40.s /sw/src/fink.build/gcc45-4.4.999-20100303/gcc-4.5-20100303/gcc/testsuite/g++.dg/abi/mangle40.C: In instantiation of void f(T) [with T = float __vector[4]]: /sw/src/fink.build/gcc45-4.4.999-20100303/gcc-4.5-20100303/gcc/testsuite/g++.dg/abi/mangle40.C:25:18: instantiated from here /sw/src/fink.build/gcc45-4.4.999-20100303/gcc-4.5-20100303/gcc/testsuite/g++.dg/abi/mangle40.C:21:6: warning: the mangled name of void f(T) [with T = float __vector[4]] will change in a future version of GCC /sw/src/fink.build/gcc45-4.4.999-20100303/gcc-4.5-20100303/gcc/testsuite/g++.dg/abi/mangle40.C: In instantiation of float __vector[4] A::t: /sw/src/fink.build/gcc45-4.4.999-20100303/gcc-4.5-20100303/gcc/testsuite/g++.dg/abi/mangle40.C:26:1: instantiated from here /sw/src/fink.build/gcc45-4.4.999-20100303/gcc-4.5-20100303/gcc/testsuite/g++.dg/abi/mangle40.C:18:9: warning: the mangled name of A::t will change in a future version of GCC -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12909
[Bug c++/12909] ambiguity in mangling vector types
--- Comment #12 from howarth at nitro dot med dot uc dot edu 2010-03-04 02:28 --- FAIL: g++.dg/abi/mangle40.C scan-assembler weak[^\n]*_Z1fIDv4_fEvT_ FAIL: g++.dg/abi/mangle40.C scan-assembler weak[^\n]*_ZN1AIDv4_fE1tE FAIL: g++.dg/abi/mangle41.C (test for errors, line 6) FAIL: g++.dg/abi/mangle41.C (test for warnings, line 7) are failing on x86_64-apple-darwin10. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12909
[Bug middle-end/42450] [4.5 Regression] another GCC 4.5 ICE on C++ templated code
--- Comment #11 from zsojka at seznam dot cz 2010-03-04 01:28 --- Created an attachment (id=20016) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20016&action=view) different reduced testcase Testcases from comment #0 and comment #10 don't fail for me (x86_64, r157161). However, attached testcase does (further reduced from comment #8). Compiler flags: -O3 ; -O2 ; -O1 -fipa-cp -fipa-sra -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42450
[Bug middle-end/43251] [4.4 Regression] Erroneous code with -ftree-vectorize
--- Comment #11 from kargl at gcc dot gnu dot org 2010-03-04 00:18 --- (In reply to comment #9) > (In reply to comment #8) > > It is a dup of PR 24581. Backporting the gcc/tree-complex.c change > > in revision 147281: > > > > http://gcc.gnu.org/viewcvs?view=revision&revision=147281 > > > > to 4.4 fixes this. > > > If that is the case, then this code is invalid as there are no signed zeros in > Fortran :). Actually, there are signed zeros in Fortran. One needs to read the Standard to see when the sign is ignored (e.g., with a comparison operator) or behavior near a branch cut (i.e., the ever popular processor dependent behavior). > Let's reopen it until further notice because I think there is something else > going on. I think after that patch we just don't vectorizing the code which > is > what you are seeing. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43251
[Bug c++/39751] ICE in cp_lexer_new_from_tokens, at cp/parser.c:342
--- Comment #6 from zsojka at seznam dot cz 2010-03-03 23:45 --- It could be regression from 3.3.6. 3.4.6, 4.1.2, 4.2.4, 4.3.4, 4.4.3 built without checking all bail out, while 3.3.6 ends with: $ g++-3.3.6 xxx.cc xxx.cc:6: error: ISO C++ forbids declaration of `f' with no type xxx.cc:6: error: end of file read inside definition xxx.cc:6: error: syntax error at end of input -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39751
[Bug tree-optimization/42286] October 23rd change to tree-ssa-pre.c breaks calculix on powerpc with -ffast-math
--- Comment #12 from meissner at gcc dot gnu dot org 2010-03-03 23:01 --- As I said in the last bug entry, I have convinced myself that the compiler is correct, and that the bug is caused by using -ffast-math when compiling, but the atan2 library function supporting full IEEE semantics, including -0.0. -- meissner at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42286
[Bug middle-end/43251] [4.4 Regression] Erroneous code with -ftree-vectorize
--- Comment #10 from pinskia at gcc dot gnu dot org 2010-03-03 22:57 --- Or rather vectorizers differently. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43251
[Bug middle-end/43251] [4.4 Regression] Erroneous code with -ftree-vectorize
--- Comment #9 from pinskia at gcc dot gnu dot org 2010-03-03 22:53 --- (In reply to comment #8) > It is a dup of PR 24581. Backporting the gcc/tree-complex.c change > in revision 147281: > > http://gcc.gnu.org/viewcvs?view=revision&revision=147281 > > to 4.4 fixes this. If that is the case, then this code is invalid as there are no signed zeros in Fortran :). Let's reopen it until further notice because I think there is something else going on. I think after that patch we just don't vectorizing the code which is what you are seeing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43251
[Bug c/24581] Complex arithmetic on special cases is incorrect.
--- Comment #9 from hjl dot tools at gmail dot com 2010-03-03 22:49 --- *** Bug 43251 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24581
[Bug middle-end/43251] [4.4 Regression] Erroneous code with -ftree-vectorize
--- Comment #8 from hjl dot tools at gmail dot com 2010-03-03 22:49 --- It is a dup of PR 24581. Backporting the gcc/tree-complex.c change in revision 147281: http://gcc.gnu.org/viewcvs?view=revision&revision=147281 to 4.4 fixes this. *** This bug has been marked as a duplicate of 24581 *** -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43251
[Bug middle-end/43252] New: ICE: verify_stmts failed / not match field size of BIT_FIELD_REF (logical_dot_product.f90)
The Fortran testcase gfortran.dg/logical_dot_product.f90 fails with the
following middle-end message on SPU. As far as I can see, the generated tree by
the front end is OK and I also do not see any bit field which presumably comes
about due to the optimization. The code is:
logical :: l1(4) = (/.TRUE.,.FALSE.,.TRUE.,.FALSE./)
logical :: l2(4) = (/.FALSE.,.TRUE.,.FALSE.,.TRUE./)
if (dot_product (l1, l2)) call abort ()
l2 = .TRUE.
if (.not.dot_product (l1, l2)) call abort ()
end
and the dump shows that the same "int"-wide (4 byte) logical data type is used
for both
static logical(kind=4) l1[4] = {1, 0, 1, 0};
static logical(kind=4) l2[4] = {0, 1, 0, 1};
The error message is:
/home/kwerner/dailybuild/spu-tc-2010-03-01/gcc-build/gcc/testsuite/gfortran2/../../gfortran
-B/home/kwerner/dailybuild/spu-tc-2010-03-01/gcc-build/gcc/testsuite/gfortran2/../../
/home/kwerner/dailybuild/spu-tc-2010-03-01/gcc-head/src/gcc/testsuite/gfortran.dg/logical_dot_product.f90
-O3 -fomit-frame-pointer -pedantic-errors -Wl,--gc-sections
-B/home/kwerner/dailybuild/spu-tc-2010-03-01/gcc-build/spu/./libgfortran/.libs
-L/home/kwerner/dailybuild/spu-tc-2010-03-01/gcc-build/spu/./libgfortran/.libs
-L/home/kwerner/dailybuild/spu-tc-2010-03-01/gcc-build/spu/./libiberty
-Wl,--auto-overlay -Wl,--reserved-space=131072 -lm -o
./logical_dot_product.exe
/home/kwerner/dailybuild/spu-tc-2010-03-01/gcc-head/src/gcc/testsuite/gfortran.dg/logical_dot_product.f90:
In function 'main':
/home/kwerner/dailybuild/spu-tc-2010-03-01/gcc-head/src/gcc/testsuite/gfortran.dg/logical_dot_product.f90:11:0:
error: integral result type precision does not match field size of
BIT_FIELD_REF
BIT_FIELD_REF
f951: note: in statement
stmp_var_.53_106 = BIT_FIELD_REF ;
/home/kwerner/dailybuild/spu-tc-2010-03-01/gcc-head/src/gcc/testsuite/gfortran.dg/logical_dot_product.f90:11:0:
error: integral result type precision does not match field size of
BIT_FIELD_REF
BIT_FIELD_REF
f951: note: in statement
stmp_var_.53_107 = BIT_FIELD_REF ;
/home/kwerner/dailybuild/spu-tc-2010-03-01/gcc-head/src/gcc/testsuite/gfortran.dg/logical_dot_product.f90:11:0:
error: integral result type precision does not match field size of
BIT_FIELD_REF
BIT_FIELD_REF
f951: note: in statement
stmp_var_.53_109 = BIT_FIELD_REF ;
/home/kwerner/dailybuild/spu-tc-2010-03-01/gcc-head/src/gcc/testsuite/gfortran.dg/logical_dot_product.f90:11:0:
error: integral result type precision does not match field size of
BIT_FIELD_REF
BIT_FIELD_REF
f951: note: in statement
stmp_var_.53_111 = BIT_FIELD_REF ;
/home/kwerner/dailybuild/spu-tc-2010-03-01/gcc-head/src/gcc/testsuite/gfortran.dg/logical_dot_product.f90:11:0:
error: integral result type precision does not match field size of
BIT_FIELD_REF
BIT_FIELD_REF
f951: note: in statement
stmp_var_.32_74 = BIT_FIELD_REF ;
/home/kwerner/dailybuild/spu-tc-2010-03-01/gcc-head/src/gcc/testsuite/gfortran.dg/logical_dot_product.f90:11:0:
error: integral result type precision does not match field size of
BIT_FIELD_REF
BIT_FIELD_REF
f951: note: in statement
stmp_var_.32_75 = BIT_FIELD_REF ;
/home/kwerner/dailybuild/spu-tc-2010-03-01/gcc-head/src/gcc/testsuite/gfortran.dg/logical_dot_product.f90:11:0:
error: integral result type precision does not match field size of
BIT_FIELD_REF
BIT_FIELD_REF
f951: note: in statement
stmp_var_.32_77 = BIT_FIELD_REF ;
/home/kwerner/dailybuild/spu-tc-2010-03-01/gcc-head/src/gcc/testsuite/gfortran.dg/logical_dot_product.f90:11:0:
error: integral result type precision does not match field size of
BIT_FIELD_REF
BIT_FIELD_REF
f951: note: in statement
stmp_var_.32_79 = BIT_FIELD_REF ;
/home/kwerner/dailybuild/spu-tc-2010-03-01/gcc-head/src/gcc/testsuite/gfortran.dg/logical_dot_product.f90:11:0:
internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
--
Summary: ICE: verify_stmts failed / not match field size of
BIT_FIELD_REF (logical_dot_product.f90)
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
GCC target triplet: spu-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43252
[Bug middle-end/43251] [4.4 Regression] Erroneous code with -ftree-vectorize
--- Comment #7 from pinskia at gcc dot gnu dot org 2010-03-03 22:33 --- (In reply to comment #6) > -ftree-vectorize never worked correctly on this testcase > until PR 24581 is fixed. Oh no. This is not related to that bug at all since the vectorized code is in Fortran. And the difference is related to aliasing and not the vectorizer. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43251
[Bug c/24581] Complex arithmetic on special cases is incorrect.
--- Comment #8 from hjl dot tools at gmail dot com 2010-03-03 22:30 --- *** Bug 43251 has been marked as a duplicate of this bug. *** -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||a dot kumar at alumni dot ||iitm dot ac dot in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24581
[Bug middle-end/43251] [4.4 Regression] Erroneous code with -ftree-vectorize
--- Comment #6 from hjl dot tools at gmail dot com 2010-03-03 22:30 --- -ftree-vectorize never worked correctly on this testcase until PR 24581 is fixed. *** This bug has been marked as a duplicate of 24581 *** -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43251
[Bug middle-end/42450] [4.5 Regression] another GCC 4.5 ICE on C++ templated code
--- Comment #10 from manu at gcc dot gnu dot org 2010-03-03 22:11 --- Created an attachment (id=20015) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20015&action=view) further reduced testcase This testcase is somehow smaller. I won't try to reduce it further. -- manu at gcc dot gnu dot org changed: What|Removed |Added Attachment #19938|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42450
[Bug middle-end/32693] [H8] : ICE: in gen_rtx_SUBREG, at emit-rtl.c:693
--- Comment #6 from law at gcc dot gnu dot org 2010-03-03 22:10 --- Subject: Bug 32693 Author: law Date: Wed Mar 3 22:10:17 2010 New Revision: 157207 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157207 Log: * PR middle-end/32693 * expmed.c (store_bit_field_1): Use gen_lowpart_SUBREG rather than gen_rtx_SUBREG. (extract_bit_field_1): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/expmed.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32693
[Bug middle-end/32693] [H8] : ICE: in gen_rtx_SUBREG, at emit-rtl.c:693
--- Comment #5 from law at redhat dot com 2010-03-03 22:10 --- Fixed for gcc-4.5 -- law at redhat dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32693
[Bug c++/40145] structure inside a static function is exported, producing warning
--- Comment #3 from manu at gcc dot gnu dot org 2010-03-03 21:43 --- (In reply to comment #2) > 4.4.2 also warns, 4.5.0 doesn't Jonathan, could you add a testcase for GCC 4.5 so we avoid regressing? -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40145
[Bug middle-end/43251] [4.4 Regression] Erroneous code with -ftree-vectorize
--- Comment #5 from a dot kumar at alumni dot iitm dot ac dot in 2010-03-03 20:49 --- My gfortran details: Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.3-3' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.4.3 (Debian 4.4.3-3) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43251
[Bug middle-end/43251] [4.4 Regression] Erroneous code with -ftree-vectorize
--- Comment #4 from a dot kumar at alumni dot iitm dot ac dot in 2010-03-03 20:42 --- Created an attachment (id=20014) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20014&action=view) C program which uses zdrot. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43251
[Bug middle-end/43251] [4.4 Regression] Erroneous code with -ftree-vectorize
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code Known to fail||4.4.3 Known to work||4.5.0 Summary|Erroneous code with -ftree- |[4.4 Regression] Erroneous |vectorize |code with -ftree-vectorize Target Milestone|--- |4.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43251
[Bug middle-end/43251] Erroneous code with -ftree-vectorize
--- Comment #3 from a dot kumar at alumni dot iitm dot ac dot in 2010-03-03 20:41 --- Created an attachment (id=20013) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20013&action=view) The zdrot function from Blas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43251
[Bug middle-end/43251] Erroneous code with -ftree-vectorize
--- Comment #2 from a dot kumar at alumni dot iitm dot ac dot in 2010-03-03 20:41 --- Created an attachment (id=20012) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20012&action=view) The Makefile used for this build. The Makefile used for this build. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43251
[Bug fortran/43251] Erroneous code with -ftree-vectorize
--- Comment #1 from a dot kumar at alumni dot iitm dot ac dot in 2010-03-03 20:40 --- Created an attachment (id=20011) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20011&action=view) Preprocessed file, built with -O2 -ftree-vectorize This is the preprocessed file, built as: gfortran -c -O2 -ftree-vectorize -save-temps zdrot.f -o zdrot.o -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43251
[Bug fortran/43251] New: Erroneous code with -ftree-vectorize
Hi! While compiling zdrot.f from Blas with -ftree-vectorize (which seems to be on with -O3), I get incorrect results. I have attached a .s file, but I also attach the original (self-contained) source files with an explanation available here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=571572#174 Please let me know anything else I can do to help. Thanks! -- Summary: Erroneous code with -ftree-vectorize Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: a dot kumar at alumni dot iitm dot ac dot in GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43251
[Bug tree-optimization/39612] [4.3/4.4/4.5 Regression] LIM inserts loads from uninitialized local memory
--- Comment #10 from pinskia at gcc dot gnu dot org 2010-03-03 20:21 --- I have noticed this with some code with graphite enabled too, graphite uses arrays for some reason. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|ppc64-redhat-linux | GCC host triplet|ppc64-redhat-linux | GCC target triplet|ppc64-redhat-linux | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39612
[Bug libstdc++/43241] std::tr1::regex is not fully implemented yet
--- Comment #7 from pinskia at gcc dot gnu dot org 2010-03-03 20:13 --- I should mention why I filed this bug, someone asked (on IRC) how to fix up a link error when using std::tr1::regex. Of course I looked inside bugzilla first and did not see any so I did not look into further than that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43241
[Bug libstdc++/43241] std::tr1::regex is not fully implemented yet
--- Comment #6 from paolo dot carlini at oracle dot com 2010-03-03 20:10 --- Bah, frankly WONTFIX doesn't seem correct either: we are not taking about a *bug* which we are not going to fix. We are talking about a largely *unimplemented* part of the future C++1x standard. Now, in my opinion, almost completely *unimplemented* features do not really belong to Bugzilla, it's way to too early for it. Unless we want to limit the span of this PR to the TR1 version: in that case, WONTFIX could be slightly more correct in the sense that we may well never implement the TR1 version of regex, but frankly it's not sure, it depends on whether it turns out to be feasible with a decent amount of macros and such. But I don't care much either way. I wanted only to clarify that the real issue is known, and we (the library maintainers) we don't consider it a bug, but a big chunk of work awaiting for somebody volunteering to do it ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43241
[Bug c++/20397] g++ rejects valid code with 'is inaccessible' error
--- Comment #8 from bangerth at gmail dot com 2010-03-03 19:40 --- (In reply to comment #7) > The use of a base class ( class B : A ) is not a declaration of A. > Thus the base class ( class A ) is visible and not private. > > Reopen the bug and fix it. Andrew was right: the name 'A' is injected into the class 'A' upon declaration of the class 'A', into 'B' upon deriving from it, and from 'B' into 'C'. This amounts to a 'using' declaration. As such, 'A' exists in 'C' as a name, but it is private and consequently inaccessible. Since you cite chapter and verse, take a look at 3.4/3 and 9.1/2. As stated before, if you don't want the locally injected name, use ::A instead. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20397
[Bug libstdc++/43241] std::tr1::regex is not fully implemented yet
--- Comment #5 from bangerth at gmail dot com 2010-03-03 19:31 --- ...is WONTFIX. -- bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43241
[Bug libstdc++/43241] std::tr1::regex is not fully implemented yet
--- Comment #4 from bangerth at gmail dot com 2010-03-03 19:30 --- I think INVALID is the wrong resolution of this PR. This clearly is a bug (if we offer a class we should make sure it can be used), but we may choose to say that we won't work on this bug. The right resolution therefore... -- bangerth at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43241
[Bug c++/20397] g++ rejects valid code with 'is inaccessible' error
--- Comment #7 from s dot franke at bebbosoft dot de 2010-03-03 19:26 --- The C++ Standard says: 3.4 Name lookup The name lookup rules apply uniformly to all names (including typedef-names (7.1.3), namespace-names (7.3) and class-names (9.1)) wherever the grammar allows such names in the context discussed by a particular rule. Name lookup associates the use of a name with a declaration (3.1) of that name. Name lookup shall find an unambiguous declaration for the name (see 10.2). ..." The use of a base class ( class B : A ) is not a declaration of A. Thus the base class ( class A ) is visible and not private. Reopen the bug and fix it. Thanks SF -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20397
[Bug c/43082] ICE in tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-03-03 19:21 --- I have a patch to c_common_truthvalue_conversion which fixes this issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43082
[Bug c/43250] New: Warning for missing break in switch statement
I think will be good idea to have warning (and command line option to turn it on/off) to report missing break in switch statement. Sure syntax is valid, but I think missed breaks are occurring more often then intentionally skipped ones. Same goes for C++ and other languages where similar problem could exist. -- Summary: Warning for missing break in switch statement Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: eugene dot zelenko at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43250
[Bug target/43249] New: unsigned int arg with no prototype gets full 64-bit reg
For a function with no prototype that defines an argument as unsigned
int, GCC for powerpc64-linux with -m64 and optimization uses the
entire 64-bit argument register rather than masking off the lower
32 bits. This problem was discoverd with 176.gcc using options
"-m64 -O2 -ftree-vectorize -maltivec -fdata-sections", which changed
the order of 32-element arrays so that accessing element 63 instead of
element 31 started getting garbage that no longer happened to work.
Here's a simple testcase that works with -O0 and fails with -O1.
It's useful to compare this with a a version whose argument is
unsigned short. For the GCC testsuite, just remove references to
printf.
---
extern int printf (const char *, ...);
int
__attribute__((noinline))
floor_log2_wide (x)
unsigned int x;
{
int log = -1;
while (x != 0)
log++,
x >>= 1;
return log;
}
int
main ()
{
int m;
unsigned int n = 4294967259U;
m = floor_log2_wide ((int)n);
printf ("n = %u, m = %d\n", n, m);
if (m != 31)
__builtin_abort ();
return 0;
}
---
elm3c105% /home/janis/tools/gcc-trunk-anonsvn/bin/gcc -m64 -O0 bug.c && ./a.out
n = 4294967259, m = 31
elm3c105% /home/janis/tools/gcc-trunk-anonsvn/bin/gcc -m64 -O1 bug.c && ./a.out
n = 4294967259, m = 63
Aborted
I've tried compilers back to GCC 4.1 and they all have the same problem;
it's probably not a regression.
--
Summary: unsigned int arg with no prototype gets full 64-bit reg
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org
GCC target triplet: powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43249
[Bug c++/12909] ambiguity in mangling vector types
--- Comment #11 from jason at gcc dot gnu dot org 2010-03-03 19:05 --- As fixed as it reasonably can be until we switch to -fabi-version=4. We now have a new mangling enabled with that flag, an error in the compiler for this situation, a warning with -Wabi about the old mangling, and forward-compatibility aliases so that code built with ABI v4 can link against definitions compiled with ABI v2. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12909
[Bug c/43082] ICE in tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-03-03 19:02 --- I get: t1.c:4:7: internal compiler error: tree check: expected class type, have exceptional (error_mark) in get_narrower, at tree.c:7654 Now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43082
[Bug c++/12909] ambiguity in mangling vector types
--- Comment #10 from jason at gcc dot gnu dot org 2010-03-03 19:02 --- Subject: Bug 12909 Author: jason Date: Wed Mar 3 19:02:08 2010 New Revision: 157204 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157204 Log: PR c++/12909 * lto-streamer.h (LTO_tags): Add LTO_var_decl_alias. * lto-streamer-in.c (lto_input_tree): Read it. * lto-streamer-out.c (output_unreferenced_globals): Write it. Added: trunk/gcc/testsuite/g++.dg/lto/20100302.h trunk/gcc/testsuite/g++.dg/lto/20100302_0.C trunk/gcc/testsuite/g++.dg/lto/20100302_1.C Modified: trunk/gcc/ChangeLog trunk/gcc/lto-streamer-in.c trunk/gcc/lto-streamer-out.c trunk/gcc/lto-streamer.h trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12909
[Bug c++/12909] ambiguity in mangling vector types
--- Comment #9 from jason at gcc dot gnu dot org 2010-03-03 19:02 --- Subject: Bug 12909 Author: jason Date: Wed Mar 3 19:01:58 2010 New Revision: 157203 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157203 Log: PR c++/12909 * cgraph.h (varpool_node): Add extra_name field. * varpool.c (varpool_extra_name_alias): New. (varpool_assemble_decl): Emit extra name aliases. (varpool_mark_needed_node): Look past an extra name alias. cp/ * mangle.c (mangle_decl): Handle VAR_DECL, too. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraph.h trunk/gcc/cp/mangle.c trunk/gcc/testsuite/g++.dg/abi/mangle40.C trunk/gcc/varpool.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12909
[Bug c++/12909] ambiguity in mangling vector types
--- Comment #8 from jason at gcc dot gnu dot org 2010-03-03 19:02 --- Subject: Bug 12909 Author: jason Date: Wed Mar 3 19:01:46 2010 New Revision: 157202 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157202 Log: PR c++/12909 * method.c (make_alias_for): Handle VAR_DECL, too. * decl2.c (vague_linkage_p): Rename from vague_linkage_fn_p. * tree.c (no_linkage_check): Adjust. * decl.c (maybe_commonize_var): Adjust. * mangle.c (mangle_decl): Adjust. * cp-tree.h: Adjust. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/decl2.c trunk/gcc/cp/mangle.c trunk/gcc/cp/method.c trunk/gcc/cp/tree.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12909
[Bug c++/12909] ambiguity in mangling vector types
--- Comment #7 from jason at gcc dot gnu dot org 2010-03-03 19:02 --- Subject: Bug 12909 Author: jason Date: Wed Mar 3 19:01:36 2010 New Revision: 157201 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157201 Log: PR c++/12909 * mangle.c: Include cgraph.h. (mangle_decl): If the mangled name will change in a later ABI version, make the later mangled name an alias. * method.c (make_alias_for): Copy DECL_ARGUMENTS. * Make-lang.in (mangle.o): Depend on cgraph.h. Added: trunk/gcc/testsuite/g++.dg/abi/mangle40.C trunk/gcc/testsuite/g++.dg/abi/mangle41.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/Make-lang.in trunk/gcc/cp/mangle.c trunk/gcc/cp/method.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12909
[Bug c/43082] ICE in tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-03-03 19:00 ---
Reduced testcase:
int main(void)
{
int gpf;
if(gpf ? (void) (0) : f ()) ;
}
--- CUT ---
Looking into it.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2010-02-16 10:21:57 |2010-03-03 19:00:50
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43082
[Bug c/43248] [4.4/4.5 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at tree-ssa.c:1233
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-03-03 18:09 --- I have a simple patch to build_compound_literal which fixes this. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-03-03 18:09:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43248
[Bug fortran/43243] [4.5 Regression] Wrong-code due to missing array temp for DT with pointer component
--- Comment #7 from pault at gcc dot gnu dot org 2010-03-03 17:53 --- Fixed on trunk and yes, thanks for the report! Cheers Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43243
[Bug fortran/43243] [4.5 Regression] Wrong-code due to missing array temp for DT with pointer component
--- Comment #6 from pault at gcc dot gnu dot org 2010-03-03 17:50 --- Subject: Bug 43243 Author: pault Date: Wed Mar 3 17:49:53 2010 New Revision: 157199 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157199 Log: 2010-03-03 Paul Thomas PR fortran/43243 * trans-array.c (gfc_conv_array_parameter): Contiguous refs to allocatable ultimate components do not need temporaries, whilst ultimate pointer components do. 2010-03-03 Paul Thomas PR fortran/43243 * gfortran.dg/internal_pack_12.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/internal_pack_12.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43243
[Bug c/43248] [4.4/4.5 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at tree-ssa.c:1233
--- Comment #1 from hjl dot tools at gmail dot com 2010-03-03 17:06 --- It is caused by tuples merge. We must have missed something. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43248
[Bug fortran/43243] [4.5 Regression] Wrong-code due to missing array temp for DT with pointer component
--- Comment #5 from burnus at net-b dot de 2010-03-03 16:59 --- Subject: Re: [4.5 Regression] Missing array temp for DT with pointer component On 03/03/2010 04:53 PM, Paul Richard Thomas wrote: > Yet another in the series :-) I hope that it is the last... > So do I - especially with regards to regressions. Regarding temporaries: I was compiling some programs with the patched gfortran and the number of created temporaries is quite low - and I think no low-lying fruits are left. There are some cases of assignments for which middle-end array support were helpful (hint, hint) and some other cases with MATMUL and assignments which could be solved in the front end. (And two of the programs here could gain some performance, if they would move to TR 15581; without the compiler has unnecessarily to assume aliasing. But as both do not dare to drop support for F95-only compilers, yet, ...) By the way, for RESHAPE gfortran generates temporaries what could be avoided if RESHAPE wouldn't deallocate - that's another candidate to fix after the new array descriptor gained a "bool allocated" component ... cf. PR 32512. > This bootstraps and regtests on RHEL5.2/x86_64 - OK for trunk? > OK. Thanks a lot for the patch! Tobias > 2010-03-03 Paul Thomas > > PR fortran/43243 > * trans-array.c (gfc_conv_array_parameter): Contiguous refs to > allocatable ultimate components do not need temporaries, whilst > ultimate pointer components do. > > 2010-03-03 Paul Thomas > > PR fortran/43243 > * gfortran.dg/internal_pack_12.f90: New test. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43243
[Bug target/42313] FAIL: gcc.target/i386/builtin-unreachable.c scan-assembler-not %e[bs]p on i686 darwin
--- Comment #7 from mikestump at comcast dot net 2010-03-03 16:56 ---
I fixed the test case to not expect the unimplemented optimization in r157197,
however, it would be nice to ensure the async signal handlers can handle
unaligned stacks and to perform this optimization. I'm fairly certain the
signal handers have to cope as code gen can do:
_h:
subl$12, %esp
movl$1, %eax
addl$12, %esp
ret
for int h () { return 1; } and certainly we can take a signal at _h+0, where
esp isn't aligned. Given that, we can omit sp alignments for leaf functions
(and no tail calls either), even on machines where otherwise an alignment is
required, as long as any variables on the stack are correctly aligned.
When this optimization is added, we can undo the r157197 change.
--
mikestump at comcast dot net changed:
What|Removed |Added
CC||mikestump at comcast dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42313
[Bug c/43248] [4.4/4.5 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at tree-ssa.c:1233
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |minor Keywords||error-recovery, ice-on- ||invalid-code Summary|ICE: tree check: expected |[4.4/4.5 Regression] ICE: |class 'type', have |tree check: expected class |'exceptional' (error_mark) |'type', have 'exceptional' |in |(error_mark) in |useless_type_conversion_p, |useless_type_conversion_p, |at tree-ssa.c:1233 |at tree-ssa.c:1233 Target Milestone|--- |4.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43248
[Bug c/43248] New: ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at tree-ssa.c:1233
Command line:
gcc testcase.c
- testcase.c -
int foo(int i)
{
i ? : (void *){};
}
--
Output - 4.5 r157122, checking:
$ /mnt/svn/gcc-trunk/binary-157122/bin/gcc testcase.c
testcase.c: In function 'foo':
testcase.c:3:3: error: empty scalar initializer
testcase.c:3:3: error: (near initialization for '(anonymous)')
testcase.c:3:7: warning: pointer/integer type mismatch in conditional
expression
testcase.c:3:7: internal compiler error: tree check: expected class 'type',
have 'exceptional' (error_mark) in useless_type_conversion_p, at
tree-ssa.c:1233
Output - 4.4 r157120, checking:
$ /mnt/svn/gcc-4_4/binary-157120-enable-checking/bin/gcc testcase.c
testcase.c: In function 'foo':
testcase.c:3: error: empty scalar initializer
testcase.c:3: error: (near initialization for '(anonymous)')
testcase.c:3: warning: pointer/integer type mismatch in conditional expression
testcase.c:3: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in c_types_compatible_p, at c-objc-common.c:190
Output - 4.5 r157122, disabled checking:
$ gcc-4.5.0-alpha20100225 testcase.c
testcase.c: In function 'foo':
testcase.c:3:3: error: empty scalar initializer
testcase.c:3:3: error: (near initialization for '(anonymous)')
testcase.c:3:7: warning: pointer/integer type mismatch in conditional
expression
testcase.c:3: confused by earlier errors, bailing out
Output - 4.4.3, disabled checking:
$ gcc-4.4.3 testcase.c
testcase.c: In function 'foo':
testcase.c:3: error: empty scalar initializer
testcase.c:3: error: (near initialization for '(anonymous)')
testcase.c:3: warning: pointer/integer type mismatch in conditional expression
testcase.c:3: confused by earlier errors, bailing out
Output - 4.3.4, disabled checking:
$ gcc-4.3.4 testcase.c
testcase.c: In function 'foo':
testcase.c:3: error: empty scalar initializer
testcase.c:3: error: (near initialization for '(anonymous)')
testcase.c:3: warning: pointer/integer type mismatch in conditional expression
It is probably different problem than pr43082, 4.4 ICEs at different place. I
don't have any 4.3 build with checking to test.
--
Summary: ICE: tree check: expected class 'type', have
'exceptional' (error_mark) in useless_type_conversion_p,
at tree-ssa.c:1233
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43248
[Bug fortran/43243] [4.5 Regression] Wrong-code due to missing array temp for DT with pointer component
--- Comment #4 from paul dot richard dot thomas at gmail dot com 2010-03-03 16:15 --- Subject: Re: [4.5 Regression] Wrong-code due to missing array temp for DT with pointer component Tobias, Don't worry, I got it:-) The patch fixes both problems. Cheers Paul On Wed, Mar 3, 2010 at 4:53 PM, burnus at gcc dot gnu dot org wrote: > > > --- Comment #3 from burnus at gcc dot gnu dot org 2010-03-03 15:53 > --- > As it might have not been completely clear from comment 0: > > type t > [...] > integer, pointer :: b(:) > end type > type(t) :: y > y%b => z(::2) > call bar(y%b) ! <<< WRONG-CODE: Here a temporary is missing > > Without the temporary, [1,2,3] instead of [1,3,5] is passed to "bar" and thus > the example fails with a call to ABORT. (The rest of example illustrates a > missed optimization, which is not a regression.) > > > -- > > burnus at gcc dot gnu dot org changed: > > What |Removed |Added > > Known to fail| |4.5.0 > Known to work| |4.3.5 4.4.3 > Priority|P3 |P4 > Summary|[4.5 Regression] Missing |[4.5 Regression] Wrong-code > |array temp for DT with |due to missing array temp > |pointer component |for DT with pointer > | |component > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43243 > > --- You are receiving this mail because: --- > You are on the CC list for the bug, or are watching someone who is. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43243
[Bug tree-optimization/43247] [4.3/4.4 Regression] Icorrect optimization while declaring array[1]
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-03-03 16:08 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c++ |tree-optimization Ever Confirmed|0 |1 Keywords||wrong-code Known to fail||4.3.0 4.3.4 4.4.3 Known to work||4.2.4 4.5.0 Last reconfirmed|-00-00 00:00:00 |2010-03-03 16:08:00 date|| Summary|Icorrect optimization while |[4.3/4.4 Regression] |declaring array[1] |Icorrect optimization while ||declaring array[1] Target Milestone|--- |4.3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43247
[Bug rtl-optimization/40761] [4.4/4.5 Regression] IRA memory hog for insanely nested loops
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-03-03 15:59 --- 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-15 07:21:07 |2010-03-03 15:59:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40761
[Bug fortran/43243] [4.5 Regression] Wrong-code due to missing array temp for DT with pointer component
--- Comment #3 from burnus at gcc dot gnu dot org 2010-03-03 15:53 --- As it might have not been completely clear from comment 0: type t [...] integer, pointer :: b(:) end type type(t) :: y y%b => z(::2) call bar(y%b) ! <<< WRONG-CODE: Here a temporary is missing Without the temporary, [1,2,3] instead of [1,3,5] is passed to "bar" and thus the example fails with a call to ABORT. (The rest of example illustrates a missed optimization, which is not a regression.) -- burnus at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.5.0 Known to work||4.3.5 4.4.3 Priority|P3 |P4 Summary|[4.5 Regression] Missing|[4.5 Regression] Wrong-code |array temp for DT with |due to missing array temp |pointer component |for DT with pointer ||component http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43243
[Bug fortran/43243] [4.5 Regression] Missing array temp for DT with pointer component
--- Comment #1 from paul dot richard dot thomas at gmail dot com 2010-03-03 15:53 --- Subject: Re: [4.5 Regression] Missing array temp for DT with pointer component Yet another in the series :-) I hope that it is the last... This bootstraps and regtests on RHEL5.2/x86_64 - OK for trunk? Paul 2010-03-03 Paul Thomas PR fortran/43243 * trans-array.c (gfc_conv_array_parameter): Contiguous refs to allocatable ultimate components do not need temporaries, whilst ultimate pointer components do. 2010-03-03 Paul Thomas PR fortran/43243 * gfortran.dg/internal_pack_12.f90: New test. --- Comment #2 from paul dot richard dot thomas at gmail dot com 2010-03-03 15:53 --- Created an attachment (id=20010) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20010&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43243
[Bug c++/43206] [4.5 Regression] Revision 145440 caused ICE at cp/pt.c:9249
-- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-03-01 10:59:37 |2010-03-03 15:43:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43206
[Bug rtl-optimization/40761] [4.4/4.5 Regression] IRA memory hog for insanely nested loops
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-03-03 15:42 ---
We shouldn't have deferred BB31 in the first iteration (with just TEN):
:
goto ;
...
:
:
D.2759_1 = b ();
if (D.2759_1 != 0)
goto ;
else
goto ;
:
goto ;
:
return;
Starting iteration 0
...
Block 31 was deferred for a future iteration.
ANTIC_OUT[14] := { }
ANTIC_IN[14] := { }
S[14] := { }
ANTIC_OUT[13] := { }
ANTIC_IN[13] := { }
S[13] := { }
ANTIC_OUT[2] := { }
ANTIC_IN[2] := { }
S[2] := { }
Starting iteration 1
which means we are iterating in non-optimal order - which is postorder.
It looks like post_order_compute computes BS.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40761
[Bug fortran/43244] Invalid statement misinterpreted as FINAL declaration
--- Comment #5 from janus at gcc dot gnu dot org 2010-03-03 15:40 ---
Quick fix for free form:
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c (revision 157195)
+++ gcc/fortran/decl.c (working copy)
@@ -7810,6 +7810,13 @@
bool first, last;
gfc_symbol* block;
+ if (gfc_current_form == FORM_FREE)
+{
+ char c = gfc_peek_ascii_char ();
+ if (!gfc_is_whitespace (c) && c != ':')
+ return MATCH_NO;
+}
+
if (gfc_state_stack->state != COMP_DERIVED_CONTAINS)
{
gfc_error ("FINAL declaration at %C must be inside a derived type "
Would this also be acceptable for fixed form?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43244
[Bug c/43245] add option to control "discarding qualifiers" warnings
--- Comment #3 from manu at gcc dot gnu dot org 2010-03-03 15:36 --- Use -fdiagnostics-show-option to see which option controls a warning. In this case, it will show nothing (this is another bug that will be fixed in GCC 4.6) because, unfortunately, this is a default pedantic warning, so right now your only choice is to use -pedantic-errors. I turned this to a feature request to add an option to control the warning, for example, -Wdiscarded-qualifiers. This is trivial but trunk is on regressions-only mode, so it won't be available until GCC 4.6. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Severity|normal |enhancement Summary|discarding const char * |add option to control |qualifiers cannot be|"discarding qualifiers" |disabled or turned into an |warnings |error | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43245
[Bug fortran/43244] Invalid statement misinterpreted as FINAL declaration
--- Comment #4 from burnus at gcc dot gnu dot org 2010-03-03 15:32 --- Regarding the error message: The problem is the lazy evaluation of error messages. If one sets a breakpoint at "gfc_error" one finds: gfc_error (gmsgid=0xd25bd0 "Syntax error in %s statement at %C") gfc_error (gmsgid=0xd33510 "Invalid character in name at %C") gfc_error (gmsgid=0xd23678 "Syntax error in array constructor at %C") gfc_error (gmsgid=0xd33510 "Invalid character in name at %C") gfc_error (gmsgid=0xd23678 "Syntax error in array constructor at %C") gfc_error (gmsgid=0xd28d28 "FINAL declaration at %C must be inside a derived type CONTAINS section") Where only the last message is printed; I think the "Syntax error" call can also appear in a valid programs (where it is never printed to the screen). One way to force an error message is to use "gfc_error_now" - thus this change for "Syntax error in array constructor" would work. (Caveat: Untested, might have side effects, better fix could exist.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43244
[Bug c/43235] -Wall gives no warning
--- Comment #2 from manu at gcc dot gnu dot org 2010-03-03 15:29 --- Moreover, see http://gcc.gnu.org/wiki/NewWconversion and the -Wconversion option has been improved notably in GCC 4.5, so you should test with that version when available. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43235
[Bug fortran/43169] [OOP] gfortran rejects pure procedure with select type construct
--- Comment #11 from janus at gcc dot gnu dot org 2010-03-03 15:17 --- Fixed with r157196. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43169
[Bug fortran/43169] [OOP] gfortran rejects pure procedure with select type construct
--- Comment #10 from janus at gcc dot gnu dot org 2010-03-03 15:13 --- Subject: Bug 43169 Author: janus Date: Wed Mar 3 15:12:40 2010 New Revision: 157196 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157196 Log: 2010-03-03 Janus Weil PR fortran/43169 * resolve.c (resolve_code): Correctly set gfc_current_ns for EXEC_SELECT_TYPE. (gfc_impure_variable): Make it work with sub-namespaces (BLOCK etc). (gfc_pure): Ditto. 2010-03-03 Janus Weil PR fortran/43169 * gfortran.dg/impure_assignment_3.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/impure_assignment_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43169
[Bug c++/40145] structure inside a static function is exported, producing warning
--- Comment #2 from redi at gcc dot gnu dot org 2010-03-03 15:03 --- 4.4.2 also warns, 4.5.0 doesn't -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40145
[Bug c++/40145] structure inside a static function is exported, producing warning
--- Comment #1 from thiago at kde dot org 2010-03-03 14:46 --- Anyone? This is not a showstopper, but produces unnecessary (and incorrect) warnings. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40145
[Bug c++/43247] Icorrect optimization while declaring array[1]
--- Comment #2 from thiago at kde dot org 2010-03-03 14:44 --- Also: -O1 -ftree-vrp -fno-cprop-registers -fno-defer-pop -fno-guess-branch-probability -fno-if-conversion -fno-if-conversion2 -fno-ipa-pure-const -fno-ipa-reference -fno-merge-constants -fno-omit-frame-pointer -fno-split-wide-types -fno-tree-ch -fno-tree-copy-prop -fno-tree-copyrename -fno-tree-dce -fno-tree-dominator-opts -fno-tree-dse -fno-tree-fre -fno-tree-sink -fno-tree-sra -fno-tree-ter However, if I add -fno-tree-ccp, the program starts to work as expected again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43247
[Bug c++/43247] Icorrect optimization while declaring array[1]
--- Comment #1 from thiago at kde dot org 2010-03-03 14:41 --- Problem also happens on: gcc 4.4.3 on linux 32-bit gcc 4.4.1 on linux ARM (armel gnueabi) Also reproducible with -O1 -ftree-vrp. -- thiago at kde dot org changed: What|Removed |Added CC||thiago at kde dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43247
[Bug c++/43087] [4.5 Regression] ICE in tsubst, at cp/pt.c:9923
--- Comment #17 from manu at gcc dot gnu dot org 2010-03-03 14:40 --- (In reply to comment #13) > It may be a different issue since the original testcase > compiles with older gcc. It is much tougher to get a testcase that compiled before but I managed to get 344K. Delta is still running so it would be better to focus on the other PR for now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43087
[Bug middle-end/42450] [4.5 Regression] another GCC 4.5 ICE on C++ templated code
--- Comment #9 from manu at gcc dot gnu dot org 2010-03-03 14:38 --- (In reply to comment #8) > Created an attachment (id=19938) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19938&action=view) [edit] > smaller testcase > > Here is the smallest testcase I could get out of delta. I have a testcase of only 8K but delta is still running. I think I should be able to reduce it to less than 228 lines. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42450
[Bug c++/43247] New: Icorrect optimization while declaring array[1]
This code should print "WORKS" a couple of time. But with -O2, g++ optimize
the condition away.
It works with -O1
Tested with gcc 4.4.3 on linux x86_64 (Archlinux)
#include
#include
#include
struct QVectorTypedData
{
int array[1];
};
int main(int , char **)
{
QVectorTypedData *d;
d = static_cast(::malloc(sizeof(QVectorTypedData)+
(45-1) * sizeof(int)));
memset(d->array, 0, 45 * sizeof(int));
int *array = d->array;
int count = 0;
for (int i = 0; i < 10; i++) {
fprintf(stderr, "%d %d %d %d\n", i, (i>=3), (i<=8), (i>=3) && (i <=
8));
if (i >= 3 && i <= 8) {
fprintf(stderr, "WORKS!!!\n");
}
array[i] = 4;
}
return 0;
}
--
Summary: Icorrect optimization while declaring array[1]
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ogoffart at kde dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43247
[Bug other/37515] [meta-bug] GCC 4.5 pending patches
--- Comment #1 from manu at gcc dot gnu dot org 2010-03-03 14:33 --- All 4.5 pending patches block 4.6 pending patches. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org OtherBugsDependingO||41998 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37515
[Bug pending/41998] GCC 4.6 pending patches meta-bug
--- Comment #11 from manu at gcc dot gnu dot org 2010-03-03 14:32 --- (In reply to comment #10) > Patch for SH to prevent the generation of the pop instruction in the > delay slot after 'rte' for sh and sh2 targets. Rather than attach patches here, it would be better to link to the mailing message where the patch was approved. Otherwise, it is not clear whether these are tentative patches or approved patches. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41998
[Bug tree-optimization/38497] PRE missing a load PRE which causes a loop to have two BBs
--- Comment #6 from steven at gcc dot gnu dot org 2010-03-03 14:26 --- Well, it is not hoisting, either. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38497
[Bug tree-optimization/43236] -ftree-loop-distribution produces wrong code in reload1.c:delete_output_reload(), bootstrap fails
--- Comment #7 from amonakov at gcc dot gnu dot org 2010-03-03 13:38 --- (In reply to comment #6) > This fixes the -O[123] miscompilations. -Os is slightly harder to fix, since > we > use wrong number of iterations (cond bb is executed 11 times, latch bb with > assignment 10 times). I don't see what is the proper fix for the -Os problem. The loop structure is as follows: i = 20 goto bb4 i-- a[i] = 0 if (i > 10) goto bb3 Thus, bb4 is header, bb3 is latch, number_of_exit_cond_executions() is 11, just_once_each_iteration_p() is true for both bb3 and bb4 (?!) -- amonakov at gcc dot gnu dot org changed: What|Removed |Added CC||amonakov at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43236
[Bug tree-optimization/43236] -ftree-loop-distribution produces wrong code in reload1.c:delete_output_reload(), bootstrap fails
--- Comment #6 from amonakov at gcc dot gnu dot org 2010-03-03 13:06 --- Not a regression, off-by-one error in reverse iteration case is since day one. Patch: diff --git a/gcc/tree-loop-distribution.c b/gcc/tree-loop-distribution.c index 13ac7ea..110abdc 100644 --- a/gcc/tree-loop-distribution.c +++ b/gcc/tree-loop-distribution.c @@ -285,6 +285,8 @@ generate_memset_zero (gimple stmt, tree op0, tree nb_iter, addr_base = fold_convert_loc (loc, sizetype, addr_base); addr_base = size_binop_loc (loc, MINUS_EXPR, addr_base, fold_convert_loc (loc, sizetype, nb_bytes)); + addr_base = size_binop_loc (loc, PLUS_EXPR, addr_base, + TYPE_SIZE_UNIT (TREE_TYPE (op0))); addr_base = fold_build2_loc (loc, POINTER_PLUS_EXPR, TREE_TYPE (DR_BASE_ADDRESS (dr)), DR_BASE_ADDRESS (dr), addr_base); This fixes the -O[123] miscompilations. -Os is slightly harder to fix, since we use wrong number of iterations (cond bb is executed 11 times, latch bb with assignment 10 times). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43236
[Bug fortran/43244] Invalid statement misinterpreted as FINAL declaration
--- Comment #3 from burnus at gcc dot gnu dot org 2010-03-03 12:59 --- (In reply to comment #0) > We should at least make sure the FINAL keyword is separated by spaces > when parsing stuff like this. Be careful with this! In free format that's OK but fixed format has some strange way of interpreting spaces - though I can never remember how it exactly goes. > finalstate(1,(/1:2/))%ID = (/1,103/) >1 > Error: Syntax error in array constructor at (1) Well, what is "[ 1:2 ]" supposed to mean? "1:2" is OK (array section) and also [1,2] and [(i,i=1,2)] which are array elements (by chance contiguous). -- burnus at gcc dot gnu dot org changed: What|Removed |Added Summary|statement misinterpreted as |Invalid statement |FINAL declaration |misinterpreted as FINAL ||declaration http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43244
[Bug pending/41998] GCC 4.6 pending patches meta-bug
--- Comment #10 from kaushik dot phatak at kpitcummins dot com 2010-03-03 12:53 --- Created an attachment (id=20009) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20009&action=view) Patch for SH to prevent the generation of the pop instruction in the delay slot after 'rte' Patch for SH to prevent the generation of the pop instruction in the delay slot after 'rte' for sh and sh2 targets. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41998
[Bug tree-optimization/38497] PRE missing a load PRE which causes a loop to have two BBs
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-03-03 11:03 --- I'm not so sure. We start with : plaintextlen_3 = *a_2(D); : # i_13 = PHI D.2725_5 = *a_2(D); DoHuffIteration (D.2725_5); i_6 = i_13 + 1; if (i_6 <= ) goto ; else goto ; : goto ; : D.2725_7 = *a_2(D); so *a_2 (4) is antic-out in bb3 but dies in bb3 (thus it's not antic-in there). *a_2 (3) is antic-in in bb5 and available in bb2. Thus we insert in bb5: : plaintextlen_3 = *a_2(D); : # i_13 = PHI # prephitmp.3_14 = PHI D.2725_5 = prephitmp.3_14; DoHuffIteration (D.2725_5); i_6 = i_13 + 1; if (i_6 <= ) goto ; else goto ; : pretmp.2_1 = *a_2(D); goto ; : D.2725_7 = *a_2(D); now what is left is hoisting *a_2(D) to after the call. But that's not PRE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38497
[Bug tree-optimization/38497] PRE missing a load PRE which causes a loop to have two BBs
--- Comment #4 from steven at gcc dot gnu dot org 2010-03-03 10:57 ---
I think pinskia means we could transform the test case of comment #0 to:
void DoHuffIteration(int);
int f(int *a)
{
int i;
int plaintextlen=*a;
pretmp = plaintextlen;
for(i = 0; i< 1; i++)
{
DoHuffIteration(pretmp);
pretmp = *a;
}
return pretmp - plaintextlen;
}
which makes this PRE, not hoisting.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
CC|stevenb dot gcc at gmail dot|
|com |
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2010-03-03 10:57:32
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38497
[Bug tree-optimization/38497] PRE missing a load PRE which causes a loop to have two BBs
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-03-03 10:43 --- This isn't PRE but code hoisting which we have a dup for. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||stevenb dot gcc at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38497
[Bug tree-optimization/43236] -ftree-loop-distribution produces wrong code in reload1.c:delete_output_reload(), bootstrap fails
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-03-03 10:38 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||spop at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.4.3 4.5.0 Last reconfirmed|-00-00 00:00:00 |2010-03-03 10:38:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43236
[Bug middle-end/43240] Code does not work at -O1
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-03-03 10:34 --- Works with 4.4.2. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to fail||4.4.1 Known to work||4.4.2 Resolution||FIXED Target Milestone|--- |4.4.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43240
[Bug fortran/43243] [4.5 Regression] Missing array temp for DT with pointer component
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43243
[Bug c/43245] discarding const char * qualifiers cannot be disabled or turned into an error
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-03-03 10:31 --- Because the warning is not controlled by -Wignored-qualifiers (or -Wcast-qual). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-03-03 10:31:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43245
[Bug c/43245] discarding const char * qualifiers cannot be disabled or turned into an error
--- Comment #1 from redi at gcc dot gnu dot org 2010-03-03 10:30 --- -Wignored-qualifiers is for warning about qualifiers on return types, which are ignored. I don't think it has anything to do with discarded qualifiers on function arguments. -pedantic-errors will give an error on your code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43245
[Bug c/43245] New: discarding const char * qualifiers cannot be disabled or turned into an error
When compiling a piece of C-source code, like:
#include
void doit(char *p)
{
p[0] = 'y';
printf("doit: %s\n", p);
}
int main(void)
{
const char *str = "hello there";
/* check whether gcc complains about const qualifier. The
-Werror=ignored-qualifiers did not work (unfortunatelly) */
doit(str);
return 0;
}
with:
gcc-4.3 -o constchar -Wall -Werror=ignored-qualifiers constchar.c
The following (correct) warning is raised:
constchar.c:16: warning: passing argument 1 of 'doit' discards qualifiers from
pointer target type
However, this warning can't be disabled with -Wno-ignored-qualifiers or turned
into an error with -Werror=ignored-qualifiers.
The latter one is the one is most wanted by me. It would be useful if the
compiler becomes more strict in handling const char *, which could point to
read-only memory.
Involved versions:
gcc-4.3 -v
Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --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 --disable-libmudflap
--with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --program-suffix=-4.3
--enable-linux-futex --without-system-libunwind --with-cpu=generic
--build=x86_64-suse-linux
Thread model: posix
gcc version 4.3.3 [gcc-4_3-branch revision 147732] (SUSE Linux)
uname -a
Linux nlbaldev2 2.6.16.60-0.21-smp #1 SMP Tue May 6 12:41:02 UTC 2008 x86_64
x86_64 x86_64 GNU/Linux
cat /etc/SuSE-release
SUSE Linux Enterprise Server 10 (x86_64)
VERSION = 10
PATCHLEVEL = 2
--
Summary: discarding const char * qualifiers cannot be disabled or
turned into an error
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kees dot dekker at infor dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43245
[Bug debug/43229] [4.5 Regression] ice expand_debug_expr, at cfgexpand.c:2957
--- Comment #5 from jakub at gcc dot gnu dot org 2010-03-03 10:02 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43229
[Bug debug/43229] [4.5 Regression] ice expand_debug_expr, at cfgexpand.c:2957
--- Comment #4 from jakub at gcc dot gnu dot org 2010-03-03 09:58 --- Subject: Bug 43229 Author: jakub Date: Wed Mar 3 09:58:11 2010 New Revision: 157191 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157191 Log: PR debug/43229 * cfgexpand.c (expand_debug_expr): Handle DOT_PROD_EXPR, WIDEN_MULT_EXPR and WIDEN_SUM_EXPR. Return NULL without ICE for vector expressions, ADDR_SPACE_CONVERT_EXPR, FIXED_CONVERT_EXPR, OBJ_TYPE_REF and WITH_SIZE_EXPR. * gfortran.dg/pr43229.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr43229.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43229
[Bug fortran/43244] statement misinterpreted as FINAL declaration
--- Comment #2 from janus at gcc dot gnu dot org 2010-03-03 09:54 --- (In reply to comment #0) > With so many compilers rejecting it, I wonder: Is it actually legal? I guess not. Changing the line in question to finalstate(1,1:2)%ID = (/1,103/) makes all compilers accept it (including gfortran trunk and 4.4). -- janus at gcc dot gnu dot org changed: What|Removed |Added Keywords||diagnostic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43244
[Bug fortran/43244] statement misinterpreted as FINAL declaration
--- Comment #1 from janus at gcc dot gnu dot org 2010-03-03 09:49 --- IIRC the parsing of FINAL declarations was implemented by Daniel Kraft. It was committed as r136293. Daniel, could you have a look at this bug? -- janus at gcc dot gnu dot org changed: What|Removed |Added CC||d at domob dot eu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43244
[Bug fortran/43244] New: statement misinterpreted as FINAL declaration
I just encountered a rather strange bug in gfortran. Consider the following code: implicit none type particle integer :: ID end type type(particle), dimension(1,1:3) :: finalState finalstate(1,(/1:2/))%ID = (/1,103/) end This is compiled fine with ifort and pgf95, but gfortran 4.5 trunk says: finalstate(1,(/1:2/))%ID = (/1,103/) 1 Error: FINAL declaration at (1) must be inside a derived type CONTAINS section This is very funny. Seems like the first part of the variable name is interpreted as a FINAL declaration. We should at least make sure the FINAL keyword is separated by spaces when parsing stuff like this. This error message appears on trunk and 4.4. Btw gfortran 4.3 and g95 say: finalstate(1,(/1:2/))%ID = (/1,103/) 1 Error: Syntax error in array constructor at (1) And sunf95's opinion is: finalstate(1,(/1:2/))%ID = (/1,103/) ^ "test.f90", Line = 7, Column = 17: ERROR: Unexpected syntax: "/)" was expected but found ":". With so many compilers rejecting it, I wonder: Is it actually legal? -- Summary: statement misinterpreted as FINAL declaration Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43244
[Bug tree-optimization/43174] Teaching SCEV about ADDR_EXPR causes regression
--- Comment #2 from rakdver at kam dot mff dot cuni dot cz 2010-03-03 09:21 --- Subject: Re: Teaching SCEV about ADDR_EXPR causes regression > This together with the patch mentioned in the previous comment allows to > generate: > ivtmp.0 = &a[0][0] > > L1: > s.0 = PHI(0, s.2) > i.0 = PHI(122, i.1) > ivtmp.1 = PHI(ivtmp.0, ivtmp.4) > > L2: > s.1 = PHI(s.0, s.2) > j.0 = PHI(122, j.1) > ivtmp.2 = PHI(ivtmp.1, ivtmp.3) > s.2 = s.1 + MEM(ivtmp.2) > ivtmp.3 = ivtmp.2 + 4 > j.1 = j.0 - 1 > if (j.1 >= 0) goto L2 > > ivtmp.4 = ivtmp.3 // would be ivtmp.4 = ivtmp.1 + stride > i.1 = i.0 - 1 > if (i.1 >= 0) goto L1 > > The improvement is that ivtmp.1 is not live across the inner loop. > > The approach is to store final values of IVs in a hashtable, mapping SSA_NAME > of initial value in the preheader to aff_tree with final value, and then try > to > replace increments of new IVs with uses of IVs from inner loops (currently I > just implemented a brute force loop over all IV uses to find a useful entry in > that hashtable). > Does this make sense and sound acceptable? the approach seems ok. However, it is not immediately clear that performing the replacement is a good idea -- it trades of register pressure for creating new dependences, i.e., it makes register allocation easier, but scheduling harder. So, some performance testing is necessary to check this, Zdenek -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43174
[Bug fortran/43243] New: [4.5 Regression] Missing array temp for DT with pointer component
Follow up to PR 43173 - but this time for derived types. In the following calls, if the ultimate component is a non-pointer and all previous part-refs have no vector subscripts, there is no need for packing the argument (i.e. creating a temporary). However, if the ultimate component is a pointer, one needs to pack as the test case also shows. Correctness test fails with 4.5.0 20100218 (experimental) [trunk revision 156860] 4.5.0 20100303 (experimental) but works with 4.4.2 [gcc-4_4-branch revision 155966] 4.3.4 [gcc-4_3-branch revision 152973] module m type t integer, allocatable :: a(:) integer, pointer :: b(:) integer :: c(5) end type t end module m subroutine foo(a,d,e,n) use m implicit none integer :: n type(t) :: a type(t), allocatable :: d(:) type(t), pointer :: e(:) call bar( a%a) ! OK - no array temp needed call bar( a%c) ! OK - no array temp needed call bar( a%a(1:n)) ! Missed: No pack needed call bar( a%b(1:n)) ! OK: pack needed call bar( a%c(1:n)) ! Missed: No pack needed call bar(d(1)%a(1:n)) ! Missed: No pack needed call bar(d(1)%b(1:n)) ! OK: pack needed call bar(d(1)%c(1:n)) ! Missed: No pack needed call bar(e(1)%a(1:n)) ! Missed: No pack needed call bar(e(1)%b(1:n)) ! OK: pack needed call bar(e(1)%c(1:n)) ! Missed: No pack needed end subroutine foo use m implicit none integer :: i integer, target :: z(6) type(t) :: y z = [(i, i=1,6)] y%b => z(::2) call bar(y%b) end subroutine bar(x) integer :: x(1:*) print *, x(1:3) if (any (x(1:3) /= [1,3,5])) call abort () end subroutine bar -- Summary: [4.5 Regression] Missing array temp for DT with pointer component Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: wrong-code, missed-optimization Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org OtherBugsDependingO 42361 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43243
