[Bug ada/42140] GNAT appears to misbehave with limited tagged types and possibly finalization
--- Comment #1 from gcc at coreland dot ath dot cx 2009-11-22 05:27 --- By "causes a crash" above, I meant that the generated code crashes at the highlighted line. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42140
[Bug ada/42140] New: GNAT appears to misbehave with limited tagged types and possibly finalization
I'm working on a small project to create an abstraction over directories and archives. I've managed to write some code that seems simple enough (using tagged limited types) and even though the code appears to be valid, it seems to either trigger bugs in the runtime (causing crashes on execution) or fails to compile: Both Debian GCC 4.3, GNAT GPL 2009 and FreeBSD GCC 4.4 fail with the following: pfseudo-archiver-directory.adb:24:41: wrong type for return_subtype_indication pfseudo-archiver-directory.adb:46:35: wrong type for return_subtype_indication GCC SVN (r154285) fails to build with a strange error: arc_dir_003.adb:25:32: "_master" conflicts with declaration at line 21 The output of -gnatG shows this error to be apparently incorrect: error := false; B_1 : declare _master : constant integer := system__soft_links__current_master.all; A6bM : integer renames _master; type A6b is access all pfseudo__archiver__Tarchive_tC; R7b : A6b := pfseudo__archiver__directory. The code is available here: http://git.coreland.ath.cx/gitweb.cgi?p=pfseudo/.git;a=summary $ git clone http://git.coreland.ath.cx/pfseudo/.git Configure and build with: $ echo 'gcc' > conf-adacomp $ echo 'gnatbind' > conf-adabind $ echo 'gnatlink' > conf-adalink $ make $ make tests Here's another case from a prototype that causes a crash on GCC 4.4 but, ironically, gives every impression of compiling and running on earlier versions (4.3, GPL 2009): with Ada.Streams.Stream_IO; with Ada.Finalization; package Archiver is type Archiver_t is tagged limited private; type Archive_t is tagged limited private; function Open_Archive (Archiver : in Archiver_t; Path : in String) return Archive_t'Class; function Stream (Archive : in Archive_t) return Ada.Streams.Stream_IO.Stream_Access; private package Stream_IO renames Ada.Streams.Stream_IO; type Archiver_t is tagged limited null record; type Archive_t is new Ada.Finalization.Limited_Controlled with record Name : access String; File : Stream_IO.File_Type; end record; end Archiver; package body Archiver is function Open_Archive (Archiver : in Archiver_t; Path : in String) return Archive_t'Class is pragma Unreferenced (Archiver); begin -- This line causes a segmentation fault. return A : Archive_t'Class := Archive_t'(Ada.Finalization.Limited_Controlled with others => <>) do A.Name := new String'(Path); Stream_IO.Open (Name => A.Name.all, File => A.File, Mode => Stream_IO.In_File); end return; end Open_Archive; function Stream (Archive : in Archive_t) return Ada.Streams.Stream_IO.Stream_Access is begin return Stream_IO.Stream (Archive.File); end Stream; end Archiver; with Ada.Text_IO; with Ada.Streams.Stream_IO; with Archiver; procedure Main is A : Archiver.Archiver_t; S : constant Ada.Streams.Stream_IO.Stream_Access := Archiver.Stream (Archiver.Open_Archive (A, "file.zip")); X : Integer; begin X := Integer'Input (S); Ada.Text_IO.Put_Line (Integer'Image (X)); end Main; -- Summary: GNAT appears to misbehave with limited tagged types and possibly finalization Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gcc at coreland dot ath dot cx GCC host triplet: x86_64-portbld-freebsd7.2, i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42140
[Bug c++/42139] Compiling firefox trunk with 4.5 fails with 'out of memory allocating 4072 bytes after a total of xxx bytes'
--- Comment #1 from ehren dot m at gmail dot com 2009-11-22 02:10 --- Created an attachment (id=19079) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19079&action=view) jsxml.ii -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42139
[Bug fortran/41807] [4.5/4.4 Regression] data statement with nested type constructors
--- Comment #21 from jvdelisle at gcc dot gnu dot org 2009-11-22 02:10 --- Fixed on trunk. Note I inadvertently left off the PR number in the commit. It was: SendingChangeLog Sendingresolve.c Sendingtrans-const.c Transmitting file data ... Committed revision 154418. I will backport this to 4.4 in a day. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41807
[Bug fortran/41807] [4.5/4.4 Regression] data statement with nested type constructors
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2009-11-22 02:06 --- Subject: Bug 41807 Author: jvdelisle Date: Sun Nov 22 02:06:26 2009 New Revision: 154420 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154420 Log: 2009-11-21 Jerry DeLisle PR fortran/41807 * trans-const.c (gfc_conv_const): Fix typo in comment. Replace assert with error message if not constant. * resolve.c (next_data_value): Delete check for constant. Modified: trunk/gcc/fortran/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41807
[Bug c++/42139] New: Compiling firefox trunk with 4.5 fails with 'out of memory allocating 4072 bytes after a total of xxx bytes'
### Here's the output of compilation together with -v and -save-temps: [eh...@germany src]$ /home/ehren/gcc-4.5/dist/bin/g++ -o jsxml.o -c -I./../../dist/system_wrappers_js -include /home/ehren/mozilla-central/js/src/config/gcc_hidden.h -DOSTYPE=\"Linux2.6.27.21-170.2.56.fc10\" -DOSARCH=Linux -DEXPORT_JS_API -I/home/ehren/mozilla-central/js/src -I. -I./../../dist/include -I./../../dist/include/nsprpub -I/home/ehren/mozilla-central/objdir-ff-release/dist/include/nspr -I/home/ehren/mozilla-central/js/src -fPIC -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros -Wno-long-long -pedantic -fno-strict-aliasing -pthread -pipe -DNDEBUG -DTRIMMED -O3 -fstrict-aliasing-DMOZILLA_CLIENT -include ./js-confdefs.h -Wp,-MD,.deps/jsxml.pp /home/ehren/mozilla-central/js/src/jsxml.cpp -v -save-temps g++: warning: -pipe ignored because -save-temps specified Using built-in specs. COLLECT_GCC=/home/ehren/gcc-4.5/dist/bin/g++ COLLECT_LTO_WRAPPER=/home/ehren/gcc-4.5/dist/libexec/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper Target: i686-pc-linux-gnu Configured with: ../srcdir/configure --without-libstdcxx --enable-checking --disable-bootstrap CFLAGS='-g3 -O0' --enable-languages=c,c++ --enable-__cxa_atexit --prefix=/home/ehren/gcc-4.5/dist/ Thread model: posix gcc version 4.5.0 20091122 (experimental) (GCC) COLLECT_GCC_OPTIONS='-o' 'jsxml.o' '-c' '-I./../../dist/system_wrappers_js' '-include' '/home/ehren/mozilla-central/js/src/config/gcc_hidden.h' '-DOSTYPE="Linux2.6.27.21-170.2.56.fc10"' '-DOSARCH=Linux' '-DEXPORT_JS_API' '-I/home/ehren/mozilla-central/js/src' '-I.' '-I./../../dist/include' '-I./../../dist/include/nsprpub' '-I/home/ehren/mozilla-central/objdir-ff-release/dist/include/nspr' '-I/home/ehren/mozilla-central/js/src' '-fPIC' '-fno-rtti' '-fno-exceptions' '-Wall' '-Wpointer-arith' '-Woverloaded-virtual' '-Wsynth' '-Wno-ctor-dtor-privacy' '-Wno-non-virtual-dtor' '-Wcast-align' '-Wno-invalid-offsetof' '-Wno-variadic-macros' '-Wno-long-long' '-pedantic' '-pthread' '-pipe' '-DNDEBUG' '-DTRIMMED' '-O3' '-fstrict-aliasing' '-DMOZILLA_CLIENT' '-include' './js-confdefs.h' '-v' '-save-temps' '-shared-libgcc' '-mtune=generic' /home/ehren/gcc-4.5/dist/libexec/gcc/i686-pc-linux-gnu/4.5.0/cc1plus -E -quiet -v -I./../../dist/system_wrappers_js -I/home/ehren/mozilla-central/js/src -I. -I./../../dist/include -I./../../dist/include/nsprpub -I/home/ehren/mozilla-central/objdir-ff-release/dist/include/nspr -I/home/ehren/mozilla-central/js/src -D_GNU_SOURCE -D_REENTRANT -DOSTYPE="Linux2.6.27.21-170.2.56.fc10" -DOSARCH=Linux -DEXPORT_JS_API -DNDEBUG -DTRIMMED -DMOZILLA_CLIENT -include /home/ehren/mozilla-central/js/src/config/gcc_hidden.h -include ./js-confdefs.h -MD .deps/jsxml.pp /home/ehren/mozilla-central/js/src/jsxml.cpp -mtune=generic -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros -Wno-long-long -pedantic -fPIC -fno-rtti -fno-exceptions -fstrict-aliasing -O3 -fpch-preprocess -o jsxml.ii ignoring nonexistent directory "/home/ehren/gcc-4.5/dist/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../i686-pc-linux-gnu/include" ignoring nonexistent directory "./../../dist/include/nsprpub" ignoring duplicate directory "/home/ehren/mozilla-central/js/src" #include "..." search starts here: #include <...> search starts here: ./../../dist/system_wrappers_js /home/ehren/mozilla-central/js/src . ./../../dist/include /home/ehren/mozilla-central/objdir-ff-release/dist/include/nspr /home/ehren/gcc-4.5/dist/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../include/c++/4.5.0 /home/ehren/gcc-4.5/dist/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../include/c++/4.5.0/i686-pc-linux-gnu /home/ehren/gcc-4.5/dist/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../include/c++/4.5.0/backward /usr/local/include /home/ehren/gcc-4.5/dist/include /home/ehren/gcc-4.5/dist/lib/gcc/i686-pc-linux-gnu/4.5.0/include /home/ehren/gcc-4.5/dist/lib/gcc/i686-pc-linux-gnu/4.5.0/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-o' 'jsxml.o' '-c' '-I./../../dist/system_wrappers_js' '-include' '/home/ehren/mozilla-central/js/src/config/gcc_hidden.h' '-DOSTYPE="Linux2.6.27.21-170.2.56.fc10"' '-DOSARCH=Linux' '-DEXPORT_JS_API' '-I/home/ehren/mozilla-central/js/src' '-I.' '-I./../../dist/include' '-I./../../dist/include/nsprpub' '-I/home/ehren/mozilla-central/objdir-ff-release/dist/include/nspr' '-I/home/ehren/mozilla-central/js/src' '-fPIC' '-fno-rtti' '-fno-exceptions' '-Wall' '-Wpointer-arith' '-Woverloaded-virtual' '-Wsynth' '-Wno-ctor-dtor-privacy' '-Wno-non-virtual-dtor' '-Wcast-align' '-Wno-invalid-offsetof' '-Wno-variadic-macros' '-Wno-long-long' '-pedantic' '-pthread' '-pipe' '-DNDEBUG' '-DTRIMMED' '-O3' '-fstrict-aliasing' '-DMOZILLA_CLIENT' '-include' './js-confdefs.h' '-v' '-save-temps' '-shared-libgcc' '-mtune=generic' /home/eh
[Bug fortran/41807] [4.5/4.4 Regression] data statement with nested type constructors
--- Comment #19 from jvdelisle at gcc dot gnu dot org 2009-11-22 02:05 --- Subject: Bug 41807 Author: jvdelisle Date: Sun Nov 22 02:05:12 2009 New Revision: 154419 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154419 Log: 2009-11-21 Jerry DeLisle PR fortran/41807 * gfortran.dg/data_value_1.f90: Update test. * gfortran.dg/array_constructor_32.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/array_constructor_32.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/data_value_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41807
[Bug debug/42138] New: ICE on h8300 target
h8300-elf-gcc -mint32 -mh -O2 -fomit-frame-pointer -g test.c test.c: In function 'sys_pwrite64': test.c:19: internal compiler error: in compute_frame_pointer_to_fb_displacement, at dwarf2out.c:12228 test.c struct foo { int foo; }; struct foo *fget_light(int fd); long sys_pwrite64(unsigned int fd, const char *buf, int count, int pos) { struct foo *file; int ret = -9; int fput_needed; file = fget_light(fd); if (file->foo & 16) ret = vfs_write(file, buf, count, &pos); return ret; } -- Summary: ICE on h8300 target Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ysato at users dot sourceforge dot jp GCC host triplet: x86_64-linux-gnu GCC target triplet: h8300-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42138
[Bug c++/42137] error: expected constructor, destructor, or type conversion before �{� token
--- Comment #2 from denis dot onischenko at gmail dot com 2009-11-21 23:45 --- Created an attachment (id=19078) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19078&action=view) compiler output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42137
[Bug c++/42137] error: expected constructor, destructor, or type conversion before �{� token
--- Comment #1 from denis dot onischenko at gmail dot com 2009-11-21 23:45 --- Created an attachment (id=19077) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19077&action=view) preprocessed c++ source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42137
[Bug c++/42137] New: error: expected constructor, destructor, or type conversion before �{� token
"error: expected constructor, destructor, or type conversion before Â{Â token" when compiling attached file from ppl sources with gcc 4.5.0 rev 154407 -- Summary: error: expected constructor, destructor, or type conversion before Â{Â token Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: denis dot onischenko at gmail dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42137
[Bug middle-end/42025] [4.5 Regression] ICE verify_stmts failed (non-trivial conversion at assignment)
--- Comment #8 from jamborm at gcc dot gnu dot org 2009-11-21 23:43 --- Fixed. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42025
[Bug fortran/42131] Weird translation of DO loops
--- Comment #8 from tkoenig at gcc dot gnu dot org 2009-11-21 23:42 --- Subject: Re: Weird translation of DO loops On Sat, 2009-11-21 at 23:23 +, rguenther at suse dot de wrote: > That's better. Not yet correct, though, this causes regressions for program main character*9 line line = ' 10 1 -3' read (unit=line,fmt='(3I3)') m1, m2, m3 print *,m1,m2,m3 do i=m1, m2, m3 print *,i end do end program main I'll have to look some more. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
[Bug fortran/42131] Weird translation of DO loops
--- Comment #7 from rguenther at suse dot de 2009-11-21 23:23 --- Subject: Re: Weird translation of DO loops On Sat, 21 Nov 2009, tkoenig at gcc dot gnu dot org wrote: > --- Comment #6 from tkoenig at gcc dot gnu dot org 2009-11-21 23:07 > --- > Created an attachment (id=19076) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19076&action=view) > --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19076&action=view) > proposed patch > > This patch generates > > D.1336 = m1; > D.1337 = m2; > D.1338 = m3; > i = D.1336; > if (D.1338 > 0) > { > if (D.1337 < D.1336) goto L.2; > } > else > { > if (D.1337 > D.1336) goto L.2; > } > countm1.1 = (character(kind=4)) (D.1337 - D.1336) / (character(kind=4)) > D.1338; > while (1) > { > { > > Is this better, or did I overlook anything? That's better. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
[Bug fortran/42131] Weird translation of DO loops
--- Comment #6 from tkoenig at gcc dot gnu dot org 2009-11-21 23:07 --- Created an attachment (id=19076) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19076&action=view) proposed patch This patch generates D.1336 = m1; D.1337 = m2; D.1338 = m3; i = D.1336; if (D.1338 > 0) { if (D.1337 < D.1336) goto L.2; } else { if (D.1337 > D.1336) goto L.2; } countm1.1 = (character(kind=4)) (D.1337 - D.1336) / (character(kind=4)) D.1338; while (1) { { Is this better, or did I overlook anything? -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
[Bug c++/42132] [C++0x] SFINAE failure with cv-qualifiers
--- Comment #5 from paolo dot carlini at oracle dot com 2009-11-21 23:05 --- Thanks for the analysis, Jason. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42132
[Bug middle-end/42025] [4.5 Regression] ICE verify_stmts failed (non-trivial conversion at assignment)
--- Comment #7 from jamborm at gcc dot gnu dot org 2009-11-21 22:57 --- Subject: Bug 42025 Author: jamborm Date: Sat Nov 21 22:56:36 2009 New Revision: 154413 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154413 Log: 2009-11-21 Martin Jambor PR middle-end/42025 * tree-sra.c (access_precludes_ipa_sra_p): New function. (splice_param_accesses): Check all accesses by calling access_precludes_ipa_sra_p. (sra_ipa_modify_expr): Rename argument erite to dont_convert and do not convert types if it is true. (sra_ipa_modify_assign): Convert types in case of mismatch. * testsuite/gcc.c-torture/compile/pr42025-1.c: New test. * testsuite/gcc.c-torture/compile/pr42025-2.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr42025-1.c trunk/gcc/testsuite/gcc.c-torture/compile/pr42025-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-sra.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42025
[Bug c/42136] Inconsistent strict-aliasing warning with cast from char[]
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-21 22:56 --- !alias_sets_conflict_p (set1, set2) should really be alias_set_subset_of with all the added false positives from the very imprecise frontend code that this would cause. Thus, the cast from short[] also should warn. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2009-11-21 22:56:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42136
[Bug c/42136] New: Inconsistent strict-aliasing warning with cast from char[]
Source: typedef union u { unsigned i; unsigned short s[2]; unsigned char c[4]; } u; char c[4] __attribute__((aligned)); short s[2] __attribute__((aligned)); int f1() { return ((union u*)s)->i; } int f2() { return ((union u*)c)->i; } Using gcc 4.5: > gcc -O3 -fstrict-aliasing -Wall -S wstrict_aliasing_char.c wstrict_aliasing_char.c: In function 'f2': wstrict_aliasing_char.c:13:17: warning: dereferencing type-punned pointer will break strict-aliasing rules I would expect either both or neither of the functions to warn, since pointer casting to unions is given in the manual as something that violates strict-aliasing, although gcc doesn't seem to actually take advantage of this. Instead, it looks like the warning is hardcoded to apply to a cast from char (c-common.c:1746 in r1554411): alias_set_type set1 = get_alias_set (TREE_TYPE (TREE_OPERAND (expr, 0))); alias_set_type set2 = get_alias_set (TREE_TYPE (type)); if (set1 != set2 && set2 != 0 && (set1 == 0 || !alias_sets_conflict_p (set1, set2))) { warning (OPT_Wstrict_aliasing, "dereferencing type-punned " "pointer will break strict-aliasing rules"); return true; } This came up during some x264 work, but it's taken care of now with some __attribute__((may_alias)). -- Summary: Inconsistent strict-aliasing warning with cast from char[] Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: astrange at ithinksw dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42136
[Bug fortran/41807] [4.5/4.4 Regression] data statement with nested type constructors
--- Comment #18 from jvdelisle at gcc dot gnu dot org 2009-11-21 22:15 --- Here is a tentative patch. I removed the offending code and ran the testsuite to see what would happen. The only failure was the test case associated with patch that caused the regression. This failure was an ICE on and assert. So i thought, why not just replace that assert with the error message, and it appears to work. It even sort of make sense, its not very intrusive, and it passes regression testing on x86-64. Any opinions? Shall we just uuse this? Index: trans-const.c === --- trans-const.c (revision 154411) +++ trans-const.c (working copy) @@ -340,7 +340,7 @@ void gfc_conv_constant (gfc_se * se, gfc_expr * expr) { /* We may be receiving an expression for C_NULL_PTR or C_NULL_FUNPTR. If - so, they expr_type will not yet be an EXPR_CONSTANT. We need to make + so, the expr_type will not yet be an EXPR_CONSTANT. We need to make it so here. */ if (expr->ts.type == BT_DERIVED && expr->ts.u.derived && expr->ts.u.derived->attr.is_iso_c) @@ -353,7 +353,11 @@ gfc_conv_constant (gfc_se * se, gfc_expr * expr) } } - gcc_assert (expr->expr_type == EXPR_CONSTANT); + if (expr->expr_type != EXPR_CONSTANT) +{ + gfc_error ("non-constant DATA value at %L", &expr->where); + return; +} if (se->ss != NULL) { Index: resolve.c === --- resolve.c (revision 154411) +++ resolve.c (working copy) @@ -11083,9 +11083,6 @@ next_data_value (void) { while (mpz_cmp_ui (values.left, 0) == 0) { - if (!gfc_is_constant_expr (values.vnode->expr)) - gfc_error ("non-constant DATA value at %L", - &values.vnode->expr->where); if (values.vnode->next == NULL) return FAILURE; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41807
[Bug c++/42132] [C++0x] SFINAE failure with cv-qualifiers
--- Comment #4 from jason at gcc dot gnu dot org 2009-11-21 22:08 --- Actually, the decltype variant isn't a SFINAE issue either; SFINAE only applies to function templates because it's part of deduction. For a simpler example: template struct A { void f (T::type); }; A a; This is ill-formed, we don't discard f from A. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42132
[Bug tree-optimization/39960] [4.5 Regression] struct-reorg is broken
--- Comment #7 from hjl dot tools at gmail dot com 2009-11-21 22:08 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39960
[Bug c++/42132] [C++0x] SFINAE failure with cv-qualifiers
--- Comment #3 from jason at gcc dot gnu dot org 2009-11-21 21:51 --- 14.9.2/8: Only invalid types and expressions in the immediate context of the function type and its template parameter types can result in a deduction failure. [ Note: The evaluation of the substituted types and expressions can result in side effects such as the instantiation of class template specializations and/or function template specializations, the generation of implicitly-defined functions, etc. Such side effects are not in the immediate context and can result in the program being ill-formed. end note ] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42132
[Bug c++/42132] [C++0x] SFINAE failure with cv-qualifiers
--- Comment #2 from jason at gcc dot gnu dot org 2009-11-21 21:41 --- >Shouldn't SFINAE cause those invalid instantiations to be ignored, silently >removing the invalid overloads from the overload set, leaving just the one I'm >trying to call? No, SFINAE only applies to function signatures; if considering a signature triggers an invalid instantiation, that makes the program ill-formed. I think the version without result_of ought to work, however. -- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-21 21:41:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42132
[Bug fortran/42131] Weird translation of DO loops
--- Comment #5 from toon at moene dot org 2009-11-21 21:40 --- > The middle-end prefers do { } while () loop style so it knows the loop is > always executed. And the Fortran Standard describes the loops being built (by compilers) just so: 1. First you determine what is m1, m2, m3 2. Then you initialize the do loop counter with m1 3. Then you determine the loop count (m2 - m1 + m3) / m3 4. If the loop count is zero or negative, you skip the loop 5. Otherwise, you traverse the loop body at least once. Or, to return to our example (and fix the mistake Thomas Koenig noted): DO I = M1, M2, M3 B(I) = A(I) ENDDO turns into ITEMP = (M2 - M1 + M3) / M3 ! The iteration count IF (ITEMP <= 0) GOTO 200 ! Past this point, the loop is executed I = M1 ! at least once. 100 CONTINUE B(I) = A(I) ITEMP = ITEMP - 1 I = I + M3 IF (ITEMP > 0) GOTO 100 200 CONTINUE therewith following the (normative) text of the Standard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
[Bug c++/42132] [C++0x] SFINAE failure with cv-qualifiers
--- Comment #1 from paolo dot carlini at oracle dot com 2009-11-21 21:11 --- No excuses, just use --permissive! ;) Seriously, it would be nice if Jason could confirm this is glitch in the extended SFINAE implementation, which, in case, could be relatively easy to fix, I suspect... -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||paolo dot carlini at oracle ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42132
[Bug testsuite/42135] New: FAIL: libgomp.graphite/force-parallel-2.c execution test
Since revision 150792, the test libgomp.graphite/force-parallel-2.c (introduced in revision 150755) fails on *-apple-darwin9. AFAICT the array x[1][1] is allocated in stack and is too big for the 64Mb hard limit on darwin. One solution could be to replace 1 with 4000. Also the following patch works. --- /opt/gcc/_gcc_clean/libgomp/testsuite/libgomp.graphite/graphite.exp 2009-08-14 19:16:39.0 +0200 +++ /opt/gcc/gcc-4.5-work/libgomp/testsuite/libgomp.graphite/graphite.exp 2009-11-20 16:32:46.0 +0100 @@ -33,10 +33,24 @@ if ![check_effective_target_fgraphite] { } # Flags for force-parallel-*.c testcases. -set PARALLEL_CFLAGS "-ansi -pedantic-errors -O2 \ --ftree-parallelize-loops=4 -floop-parallelize-all \ --fdump-tree-parloops-details -fdump-tree-optimized \ --fno-loop-strip-mine -fdump-tree-graphite-all" +if { ![istarget *-*-darwin*] } { +set PARALLEL_CFLAGS "-ansi -pedantic-errors -O2 \ +-ftree-parallelize-loops=4 -floop-parallelize-all \ +-fdump-tree-parloops-details -fdump-tree-optimized \ +-fno-loop-strip-mine -fdump-tree-graphite-all" + } elseif { ![is-effective-target lp64] } { +set PARALLEL_CFLAGS "-ansi -pedantic-errors -O2 \ +-ftree-parallelize-loops=4 -floop-parallelize-all \ +-fdump-tree-parloops-details -fdump-tree-optimized \ +-fno-loop-strip-mine -fdump-tree-graphite-all \ +-Wl,-stack_size,0x2000,-stack_addr,0xa000" + } else { +set PARALLEL_CFLAGS "-ansi -pedantic-errors -O2 \ +-ftree-parallelize-loops=4 -floop-parallelize-all \ +-fdump-tree-parloops-details -fdump-tree-optimized \ +-fno-loop-strip-mine -fdump-tree-graphite-all \ +-Wl,-stack_size,0x2000" + } # Initialize `dg'. dg-init What is the best solution? or is there a better one? -- Summary: FAIL: libgomp.graphite/force-parallel-2.c execution test Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: *-apple-darwin9 GCC host triplet: *-apple-darwin9 GCC target triplet: *-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42135
[Bug fortran/38530] ICE with the example for c_funloc
--- Comment #4 from dominiq at lps dot ens dot fr 2009-11-21 20:46 --- This PR and PR42119 are fixed by the patch in comment #1 of PR42119 without regression. It also fixes the test in comment #7 pf PR34199. As far as I can understand the comment /* ??? This should be considered a front-end bug. We should not be generating ADDR_EXPR of something that isn't an LVALUE. The only exception here is STRING_CST. */ there is something wrong in gfortran. Is the patch in comment #2 a step in the right direction? As a side note, it would be nice to have the companion C code to have an executable test in the manual. -- dominiq at lps dot ens dot fr changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38530
[Bug fortran/42131] Weird translation of DO loops
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-11-21 19:24 --- The middle-end prefers do { } while () loop style so it knows the loop is always executed. It even tries to transform other loop forms into this by copying the loop header. So if the FE already can cheaply produce this it would be prefered. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
[Bug c++/27402] error on SFINAE
--- Comment #2 from paolo dot carlini at oracle dot com 2009-11-21 19:16 --- This works with 4.4.x and current mainline. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Known to fail||4.1.0 4.3.3 Known to work||4.4.0 4.5.0 Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27402
[Bug tree-optimization/42078] [4.5 Regression] ICE in gimple_assign_set_rhs_code
--- Comment #9 from aoliva at gcc dot gnu dot org 2009-11-21 19:12 --- Fixed -- aoliva at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42078
[Bug tree-optimization/42078] [4.5 Regression] ICE in gimple_assign_set_rhs_code
-- aoliva at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aoliva at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42078
[Bug middle-end/42127] Verify_flow_info: Wrong frequency of block. Profiled bootstrap failed.
--- Comment #3 from hubicka at ucw dot cz 2009-11-21 18:54 --- Subject: Re: Verify_flow_info: Wrong frequency of block. Profiled bootstrap failed. > > > --- Comment #2 from b3timmons at speedymail dot org 2009-11-21 17:37 > --- > (In reply to comment #0) > > GCC 4.5.0 20091119 (r154346) > > > > ../../gcc-4.5/gcc/gengtype-parse.c: In function > > âarray_and_function_declarators_optâ: > > ../../gcc-4.5/gcc/gengtype-parse.c:508:1: error: verify_flow_info: Wrong > > frequency of block 13 -184951 > > ../../gcc-4.5/gcc/gengtype-parse.c:508:1: internal compiler error: > > verify_flow_info failed > > > > Also happens on x86_64-unknown-linux-gnu under r154408: > > ../../gcc/gcc/c-parser.c: In function c_parser_next_token_is: > ../../gcc/gcc/c-parser.c:336:1: error: verify_flow_info: Wrong frequency of > block 7 -199641 Looks like overflow in frequency scaling. I will look into this. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42127
[Bug fortran/42131] Weird translation of DO loops
--- Comment #3 from tkoenig at gcc dot gnu dot org 2009-11-21 18:31 --- (In reply to comment #2) > Sorry, Steve - my mistake. > > The original message should have been: > > To illustrate this with a simple example: > > DO I = M1, M2, M3 >B(I) = A(I) > ENDDO > > would be most easily, and straightforwardly, implemented as follows: > > IF (M3 > 0 .AND. M1 > M2) GOTO 200 ! Loop executed zero times > IF (M3 < 0 .AND. M1 < M2) GOTO 200 ! Ditto > ITEMP = (M2 - M1 + M3) / M3 ! Temporary loop counter > I = M1 > 100 CONTINUE > B(I) = A(I) > ITEMP = ITEMP - 1 ! Adjust internal loop counter > I = I + M3 ! Adjust DO loop variable > IF (ITEMP >= 0) GOTO 100 > 200 CONTINUE As written, this executes the assignment one time too many. The last but one line should read: IF (ITEMP > 0) GOTO 100 What we generate has the test at the bottom of the loop, whereas 8.1.6.4.2 puts the test of the iteration count first. What we could generate, IMHO, is read (*,*) m1, m2, m3 ITEMP = (M2 - M1 + M3) / M3 ! Temporary loop counter print *,'itemp=',itemp I = M1 100 CONTINUE IF (ITEMP <= 0) GOTO 200 print *,i I = I + M3 ! Adjust DO loop variable ITEMP = ITEMP - 1 ! Adjust internal loop counter GOTO 100 200 CONTINUE print *,"final : i = ", i end Does this have any drawbacks? Would the middle end recognize this for vectorization and loop unrolling? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
[Bug middle-end/42127] Verify_flow_info: Wrong frequency of block. Profiled bootstrap failed.
--- Comment #2 from b3timmons at speedymail dot org 2009-11-21 17:37 --- (In reply to comment #0) > GCC 4.5.0 20091119 (r154346) > > ../../gcc-4.5/gcc/gengtype-parse.c: In function > âarray_and_function_declarators_optâ: > ../../gcc-4.5/gcc/gengtype-parse.c:508:1: error: verify_flow_info: Wrong > frequency of block 13 -184951 > ../../gcc-4.5/gcc/gengtype-parse.c:508:1: internal compiler error: > verify_flow_info failed > Also happens on x86_64-unknown-linux-gnu under r154408: ../../gcc/gcc/c-parser.c: In function c_parser_next_token_is: ../../gcc/gcc/c-parser.c:336:1: error: verify_flow_info: Wrong frequency of block 7 -199641 -- b3timmons at speedymail dot org changed: What|Removed |Added CC||b3timmons at speedymail dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42127
[Bug fortran/42131] Weird translation of DO loops
--- Comment #2 from toon at moene dot org 2009-11-21 17:33 --- Sorry, Steve - my mistake. The original message should have been: To illustrate this with a simple example: DO I = M1, M2, M3 B(I) = A(I) ENDDO would be most easily, and straightforwardly, implemented as follows: IF (M3 > 0 .AND. M1 > M2) GOTO 200 ! Loop executed zero times IF (M3 < 0 .AND. M1 < M2) GOTO 200 ! Ditto ITEMP = (M2 - M1 + M3) / M3 ! Temporary loop counter I = M1 100 CONTINUE B(I) = A(I) ITEMP = ITEMP - 1 ! Adjust internal loop counter I = I + M3 ! Adjust DO loop variable IF (ITEMP >= 0) GOTO 100 200 CONTINUE I hope this makes clear what's weird about the way the Fortran Frontend does it now. The example code follows the Standard as close as possible (it only doesn't check that m3 isn't zero, which isn't allowed), except that I follow Note 8.7 instead of the reasoning in the "sequence of steps". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
[Bug middle-end/42103] [4.4 regression] packed 64-bit field reports as violation of strict aliasing rules
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-11-21 17:29 --- static inline void put_unaligned_uint64(void *p, uint64_t datum) { struct { uint64_t d; } __attribute__((packed)) *pp = p; pp->d = datum; } int iax_ie_append_versioned_uint64(struct iax_ie_data *ied, unsigned char ie, unsigned char version, uint64_t value) { struct _local { unsigned char version; uint64_t value; } __attribute__((packed)) newval = { version, }; put_unaligned_uint64(&newval.value, htonll(value)); return iax_ie_append_raw(ied, ie, &newval, (int) sizeof(newval)); } This code accesses an object of type uint64_t via a pointer to a struct containing an uint64_t which is an alias violation. I don't see put_unaligned_uint32 being used, and only in the context of the use of put_unaligned_uint64 it is appearant to the compiler that you violate C aliasing rules. You probably instead want to use sth like typedef uint64_t __attribute__((aligned(1))) unaligned_uint64_t; static inline void put_unaligned_uint64(void *p, uint64_t datum) { unaligned_uint64_t *pp = p; *pp = datum; } -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42103
[Bug c++/41727] inner template specialization on non-type arg template causes ICE
--- Comment #2 from cppljevans at suddenlink dot net 2009-11-21 16:46 --- Created an attachment (id=19075) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19075&action=view) zip archive with test case and Makefile and compile output The recently attached .zip file contains: M Filemode Length Date Time File - -- --- - -rw-r--r-- 1621 21-Nov-2009 09:40:04 bug.value_wrap.cpp -rw-r--r-- 1061 21-Nov-2009 09:57:30 bug.value_wrap.report -rw-r--r-- 1215 21-Nov-2009 09:53:30 Makefile - -- --- - 3897 3 files The .cpp File is the source file which was compiled with the Makefile to produce the .report file. The .report shows the compilation of the .cpp with every possible combination of {defined,undefined} properties for Macros in {OUTER_ARG0_SPECIALIZED,INNER_ARG1_NON_TYPE}. All compiles with -DOUTER_ARG0_SPECIALIZED succeed. Both compiles with -UOUTER_ARG0_SPECIALIZED fail; however, the one with -DINNER_ARG1_NON_TYPE produces the ICE. I suspect the problem is related to the attempt to substitute an outer template argument into the slot for an inner template parameter as noted in the following post to the gcc.devel newsgroup: http://article.gmane.org/gmane.comp.gcc.devel/110111/match=pt+c+most_specialized_class -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41727
[Bug fortran/42131] Weird translation of DO loops
--- Comment #1 from kargl at gcc dot gnu dot org 2009-11-21 16:26 --- (In reply to comment #0) > To illustrate this with a simple example: > > DO I = M1, M2, M3 >B(I) = A(I) > ENDDO > > would be most easily, and atraightforwardly, implemented as follows: > > IF (M3 > 0 .AND. M1 < M2) GOTO 200 ! Loop executed zero times > IF (M3 < 0 .AND. M1 > M2) GOTO 200 ! Ditto First, I just woke up 10 minutes ago and still have 1/2 of cup of coffee, but the logic above looks wrong. do i = 1, 2, 1 print *, i end do should produce 1 2 Here, we have m1 = 1, m2 = 2, m3 = 1 > IF (M3 > 0 .AND. M1 < M2) GOTO 200 ! Loop executed zero times -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
[Bug c++/42133] undiagnosed uninitialized variable
--- Comment #1 from kornelix at yahoo dot de 2009-11-21 16:21 --- Sorry, -Wall will indeed trigger a diagnostic. Please erase this report. Mike -- kornelix at yahoo dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42133
[Bug c++/42133] New: undiagnosed uninitialized variable
#include int main(int argc, char *argv[]) { int click; click++; printf("click is %d \n",click); return 0; } compile and execute: test $: g++ -o gccbug gccbug.cpp test $: ./gccbug click is 1 In this case click is set to zero. When I found this bug in a more complex program click had been set to -1 initially. -- Summary: undiagnosed uninitialized variable Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kornelix at yahoo dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42133
[Bug target/42113] [4.3/4.4/4.5 Regression] Internal Compiler error with -O3, breaking commit known
--- Comment #7 from mattst88 at gmail dot com 2009-11-21 16:15 --- I can confirm that the attached patch fixes the issue. Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42113
[Bug c/36470] sizeof UTF-32 is 2 on AVR
--- Comment #4 from hutchinsonandy at gcc dot gnu dot org 2009-11-21 15:06 --- Test and now passes for avr and m32 targets. gcc.dg/utf32-1.c gcc.dg/utf32-2.c gcc.dg/utf32-3.c I will remove XFAIL in cleanup patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36470
[Bug c++/42132] New: [C++0x] SFINAE failure with cv-qualifiers
Consider a simplified form of std::bind that just wraps a functor and calls it, preserving the cv-qualifiers on the wrapper: #include using std::declval; template struct result_of; template struct result_of { typedef decltype( declval()( declval()... ) ) type; }; template struct Binder { Fn functor; typename result_of::type call() { return functor(); } typename result_of::type call() const { return functor(); } typename result_of::type call() volatile { return functor(); } typename result_of::type call() const volatile { return functor(); } }; struct F { int operator()() { return 0; } }; int main() { Binder b = { }; b.call(); } This gives: bind.cc: In instantiation of 'result_of': bind.cc:26:3: instantiated from 'Binder' bind.cc:52:13: instantiated from here bind.cc:11:65: error: passing 'const F' as 'this' argument of 'int F::operator()()' discards qualifiers bind.cc:11:65: error: passing 'const F' as 'this' argument of 'int F::operator()()' discards qualifiers bind.cc: In instantiation of 'result_of': bind.cc:32:3: instantiated from 'Binder' bind.cc:52:13: instantiated from here bind.cc:11:65: error: passing 'volatile F' as 'this' argument of 'int F::operator()()' discards qualifiers bind.cc:11:65: error: passing 'volatile F' as 'this' argument of 'int F::operator()()' discards qualifiers bind.cc: In instantiation of 'result_of': bind.cc:38:3: instantiated from 'Binder' bind.cc:52:13: instantiated from here bind.cc:11:65: error: passing 'const volatile F' as 'this' argument of 'int F::operator()()' discards qualifiers bind.cc:11:65: error: passing 'const volatile F' as 'this' argument of 'int F::operator()()' discards qualifiers using: Using built-in specs. COLLECT_GCC=/home/jwakely/gcc/4.x/bin/g++ COLLECT_LTO_WRAPPER=/home/jwakely/gcc/4.x/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../src/gcc/configure --prefix=/n/14/jwakely/gcc/4.x --with-mpfr=/opt/cfarm/mpfr-2.4.1 --with-gmp=/opt/cfarm/gmp-4.2.4 --enable-libstdcxx-time=rt --enable-languages=c,c++ --disable-bootstrap : (reconfigured) ../src/gcc/configure --prefix=/n/14/jwakely/gcc/4.x --with-mpfr=/opt/cfarm/mpfr-2.4.1 --with-gmp=/opt/cfarm/gmp-4.2.4 --enable-libstdcxx-time=rt --enable-languages=c,c++ --disable-bootstrap Thread model: posix gcc version 4.5.0 20091121 (experimental) (GCC) The problem is that overload resolution for b.call() causes result_of::type to be instantiated, which gives an error when "cv-qual" does not match the cv-quals of Fn::operator() Shouldn't SFINAE cause those invalid instantiations to be ignored, silently removing the invalid overloads from the overload set, leaving just the one I'm trying to call? This is blocking my attempts to make std::bind conform to the C++0x WP, particularly forwarding cv-quals. If g++ is right, what extra hoops do I need to jump through to make the code above work? I get the same result if I use decltype directly, rather than via result_of, which is why I think this is a sfinae bug, not a problem with using result_of here: #include using std::declval; template struct Binder { Fn functor; decltype( declval()() ) call() { return functor(); } decltype( declval()() ) call() const { return functor(); } decltype( declval()() ) call() volatile { return functor(); } decltype( declval()() ) call() const volatile { return functor(); } }; struct F { int operator()() { return 0; } }; int main() { Binder b = { }; b.call(); } bind.cc: In instantiation of 'Binder': bind.cc:43:13: instantiated from here bind.cc:17:3: error: passing 'const F' as 'this' argument of 'int F::operator()()' discards qualifiers bind.cc: In instantiation of 'Binder': bind.cc:43:13: instantiated from here bind.cc:23:3: error: passing 'volatile F' as 'this' argument of 'int F::operator()()' discards qualifiers bind.cc: In instantiation of 'Binder': bind.cc:43:13: instantiated from here bind.cc:29:3: error: passing 'const volatile F' as 'this' argument of 'int F::operator()()' discards qualifiers N.B. tr1::bind can handle this because tr1::result_of doesn't preserve cv-quals, which means it gives the wrong result when operator() is overloaded for different cv qualifiers. -- Summary: [C++0x] SFINAE failure with cv-qualifiers Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: redi at gcc dot gnu dot org OtherBugsDependingO 35569 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42132
[Bug middle-end/42103] [4.4 regression] packed 64-bit field reports as violation of strict aliasing rules
--- Comment #4 from tlesher at digium dot com 2009-11-21 14:05 --- (In reply to comment #3) > (In reply to comment #2) > > I've also confirmed that using the 'may_alias' attribute in the 64-bit > > version > > suppresses the warning, although I think this qualifies as a workaround, > > not a > > fix to the problem. I'm also not sure how our project leaders would > > consider > > such a workaround, given that the intent behind extra warnings is to make > > the > > code better. > > It is not a work around, it fixes the aliasing issue in your code. > Let us suppose that you are correct, that there is an aliasing issue in my code. Why would code that differs only by length of type generate an aliasing warning on 64-bit but remain silent on 32-bit? Does not that point to a similar aliasing problem in the 32-bit case? Why does gcc not generate a warning in that case? Or if gcc is correct in not generating a warning for 32-bit, why is it correct to generate that warning for 64-bit? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42103
[Bug tree-optimization/42108] [4.4/4.5 Regression] Vectorizer cannot deal with PAREN_EXPR gracefully, 50% performance regression
--- Comment #17 from rguenth at gcc dot gnu dot org 2009-11-21 13:58 --- I have filed PR42131 for the DO loop translation issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug fortran/42131] New: Weird translation of DO loops
Split out from PR42108. The loop is not unrolled because the frontend presents us with very funny obfuscated code: do k=i,nnd,n temp=temp+(x(k)-x(k+jmini))**2 end do gets translated to { character(kind=4) countm1.6; integer(kind=4) D.1551; integer(kind=4) D.1550; integer(kind=4) D.1549; D.1549 = i; D.1550 = *nnd; D.1551 = *n; k = D.1549; if (D.1551 > 0) { if (D.1550 < D.1549) goto L.6;, countm1.6 = (character(kind=4)) (D.1550 - D.1549) / (character(kind=4)) D.1551;; } else { if (D.1550 > D.1549) goto L.6;, countm1.6 = (character(kind=4)) (D.1549 - D.1550) / (character(kind=4)) -D.1551;; } while (1) { { real(kind=8) D.1556; real(kind=8) D.1555; D.1555 = (((*x)[(integer(kind=8)) k + -1] - (*x)[(integer(kind=8)) (k + jmini) + -1])); D.1556 = D.1555 * D.1555; temp = temp + D.1556; } L.5:; k = k + D.1551; if (countm1.6 == 0) goto L.6; countm1.6 = countm1.6 + 4294967295; } L.6:; } The funny conditional initialization of countm1.6 makes the analysis of the number of iterations of this loop impossible (not to mention the conversions to character(kind=4)). Toon suggests: The Standard doesn't prescribe the code the Frontend generates - however, to be sure one follows the Standard, it's most easy to simply implement the steps given. To illustrate this with a simple example: DO I = M1, M2, M3 B(I) = A(I) ENDDO would be most easily, and atraightforwardly, implemented as follows: IF (M3 > 0 .AND. M1 < M2) GOTO 200 ! Loop executed zero times IF (M3 < 0 .AND. M1 > M2) GOTO 200 ! Ditto ITEMP = (M2 - M1 + M3) / M3 ! Temporary loop count I = M1 100 CONTINUE B(I) = A(I) ITEMP = ITEMP - 1 ! Adjust internal loop counter I = I + M3 ! Adjust DO loop variable IF (ITEMP > 0) GOTO 100 200 CONTINUE That there are two induction variables in this loop is inconsequential - one of them should be eliminated by induction variable elimination (at least, that was the case with g77 and the RTL loop optimization pass). which I would agree with. I btw cannot see the difference between if (D.1551 > 0) { if (D.1550 < D.1549) goto L.6;, countm1.6 = (character(kind=4)) (D.1550 - D.1549) / (character(kind=4)) D.1551;; } else { if (D.1550 > D.1549) goto L.6;, countm1.6 = (character(kind=4)) (D.1549 - D.1550) / (character(kind=4)) -D.1551;; } and if ((D.1551 > 0 && D.1550 < D.1549) || (D.1551 < 0 && D.1550 > D.1549)) goto L.6; countm1.6 = (character(kind=4)) (D.1550 - D.1549) / (character(kind=4)) D.1551; where the unconditional initialization of countm1.6 is the important difference (I'm sure the zero-trip-count check can be done more efficiently). -- Summary: Weird translation of DO loops Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
[Bug middle-end/42127] Verify_flow_info: Wrong frequency of block. Profiled bootstrap failed.
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2009-11-21 13:40 --- This maybe related to r154291 (tree-optimize.c (execute_fixup_cfg): Rescale frequencies.) Counts are not rescaled for entry block and exit block. Then in counts_to_freqs(), their frequencies become very large. Then overflow into a negative number in EDGE_FREQUENCY() in find_many_sub_basic_blocks(). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42127
[Bug c/39985] Type qualifiers not actually ignored on function return type
--- Comment #1 from gcc at magfr dot user dot lysator dot liu dot se 2009-11-21 12:24 --- Created an attachment (id=19074) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19074&action=view) Test case - g++ -Wignored-qualifiers test.C gives confusing results In C++ it becomes even worse since the types are used more. As it stands right now it becomes ridiculous: $ g++ -Wignored-qualifiers test.C test.C:12: warning: type qualifiers ignored on function return type test.C:12: error: conflicting return type specified for virtual const int D1::F() test.C:5: error: overriding virtual int B1::F() test.C:20: warning: type qualifiers ignored on function return type test.C:27: error: conflicting return type specified for virtual int D2::F() test.C:20: error: overriding virtual const int B2::F() Are the type qualifiers ignored or are they not? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39985
[Bug tree-optimization/42108] [4.4/4.5 Regression] Vectorizer cannot deal with PAREN_EXPR gracefully, 50% performance regression
--- Comment #16 from rguenther at suse dot de 2009-11-21 12:19 --- Subject: Re: [4.4/4.5 Regression] Vectorizer cannot deal with PAREN_EXPR gracefully, 50% performance regression On Sat, 21 Nov 2009, toon at moene dot org wrote: > --- Comment #15 from toon at moene dot org 2009-11-21 12:11 --- > > I don't see that the standard suggests the specific code the Frontend > > generates. In fact it should be valid to increment the DO variable > > by m3 and express the exit test in terms of the DO variable as well. > > The Standard doesn't prescribe the code the Frontend generates - however, to > be > sure one follows the Standard, it's most easy to simply implement the steps > given. > > To illustrate this with a simple example: > > DO I = M1, M2, M3 >B(I) = A(I) > ENDDO > > would be most easily, and atraightforwardly, implemented as follows: > > IF (M3 > 0 .AND. M1 < M2) GOTO 200 ! Loop executed zero times > IF (M3 < 0 .AND. M1 > M2) GOTO 200 ! Ditto > ITEMP = (M2 - M1 + M3) / M3 ! Temporary loop count > I = M1 > 100 CONTINUE > B(I) = A(I) > ITEMP = ITEMP - 1 ! Adjust internal loop counter > I = I + M3 ! Adjust DO loop variable > IF (ITEMP > 0) GOTO 100 > 200 CONTINUE > > That there are two induction variables in this loop is inconsequential - one > of > them should be eliminated by induction variable elimination (at least, that > was > the case with g77 and the RTL loop optimization pass). Sure, but the frontend generates if (M3 > 0) ITEMP = (M2 - M1) / M3 else ITEMP = (M1 - M2) / -M3 I = M1 100 CONTINUE B(I) = A(I) I = I + M3 if (ITEMP == 0) GOTO 200 ITEMP = ITEMP - 1 GOTO 100 200 CONTINUE The conditional setting of ITEMP is what confuses GCC. Also I don't see the test for zero-time executing loops (but maybe I omitted it from my pasting in comment #12). Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug tree-optimization/42108] [4.4/4.5 Regression] Vectorizer cannot deal with PAREN_EXPR gracefully, 50% performance regression
--- Comment #15 from toon at moene dot org 2009-11-21 12:11 --- > I don't see that the standard suggests the specific code the Frontend > generates. In fact it should be valid to increment the DO variable > by m3 and express the exit test in terms of the DO variable as well. The Standard doesn't prescribe the code the Frontend generates - however, to be sure one follows the Standard, it's most easy to simply implement the steps given. To illustrate this with a simple example: DO I = M1, M2, M3 B(I) = A(I) ENDDO would be most easily, and atraightforwardly, implemented as follows: IF (M3 > 0 .AND. M1 < M2) GOTO 200 ! Loop executed zero times IF (M3 < 0 .AND. M1 > M2) GOTO 200 ! Ditto ITEMP = (M2 - M1 + M3) / M3 ! Temporary loop count I = M1 100 CONTINUE B(I) = A(I) ITEMP = ITEMP - 1 ! Adjust internal loop counter I = I + M3 ! Adjust DO loop variable IF (ITEMP > 0) GOTO 100 200 CONTINUE That there are two induction variables in this loop is inconsequential - one of them should be eliminated by induction variable elimination (at least, that was the case with g77 and the RTL loop optimization pass). If you think that the Frontend does something different / in addition to the above, feel free to open a separate PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug rtl-optimization/42116] ice on valid code (unrecognizable insn)
--- Comment #9 from ltuikov at yahoo dot com 2009-11-21 12:01 --- The ICE is generated when cross-compiling libgcc2.c at line 547. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42116
[Bug target/40959] build fails - No rule to make target `/usr/ports/lang/gcc43/work/build/ia64-portbld-freebsd8.0/libgcc/crtfastmath.o', needed by `T_TARGET'. Stop.
--- Comment #12 from mexas at bristol dot ac dot uk 2009-11-21 11:47 --- I see.. So what is the way forward? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40959
[Bug rtl-optimization/42116] ice on valid code (unrecognizable insn)
--- Comment #8 from ltuikov at yahoo dot com 2009-11-21 11:35 --- Created an attachment (id=19073) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19073&action=view) Assembly output ICE compiling a cross compiler for ARC with gcc 4.4.2. -- ltuikov at yahoo dot com changed: What|Removed |Added Attachment #19066|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42116
[Bug rtl-optimization/42116] ice on valid code (unrecognizable insn)
--- Comment #7 from ltuikov at yahoo dot com 2009-11-21 11:34 --- Created an attachment (id=19072) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19072&action=view) Preprocessed source code ICE compiling a cross compiler for ARC with gcc 4.4.2. -- ltuikov at yahoo dot com changed: What|Removed |Added Attachment #19065|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42116
[Bug rtl-optimization/42116] ice on valid code (unrecognizable insn)
--- Comment #6 from ltuikov at yahoo dot com 2009-11-21 11:31 --- Compiling gcc 4.4.2 cross compiler for ARC gives ICE, unrecognizable insn: [lu...@localhost libgcc]$/home/luben/ware/gcc-4.4.2-arc-build/./gcc/xgcc -v -sav e-temps -B/home/luben/ware/gcc-4.4.2-arc-build/./gcc/ -B/opt/arc-tools/arc-elf32/bin/ -B/opt/arc-tools/arc-elf32/lib/ -isystem /opt/arc-tools/arc-elf32/include -isystem /opt/arc-tools/arc-elf32/sys-include -g -O2 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I../../../gcc-4.4.2/libgcc -I../../../gcc-4.4.2/libgcc/. -I../../../gcc-4.4.2/libgcc/../gcc -I../../../gcc-4.4.2/libgcc/../include -o _ffsdi2.o -MT _ffsdi2.o -MD -MP -MF _ffsdi2.dep -DL_ffsdi2 -c ../../../gcc-4.4.2/libgcc/../gcc/libgcc2.c Reading specs from /home/luben/ware/gcc-4.4.2-arc-build/./gcc/specs Target: arc-elf32 Configured with: ../gcc-4.4.2/configure --prefix=/opt/arc-tools --target=arc-elf32 --program-prefix=arc- --with-build-time-tools=/opt/arc-tools/bin --enable-multilib --disable-tls --enable-languages=c,c++ --disable-nls --with-headers --with-newlib --with-libs='/opt/arc-tools/lib /opt/arc-tools/lib64' Thread model: single gcc version 4.4.2 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-B/home/luben/ware/gcc-4.4.2-arc-build/./gcc/' '-B/opt/arc-tools/arc-elf32/bin/' '-B/opt/arc-tools/arc-elf32/lib/' '-isystem' '/opt/arc-tools/arc-elf32/include' '-isystem' '/opt/arc-tools/arc-elf32/sys-include' '-g' '-O2' '-O2' '-g' '-O2' '-DIN_GCC' '-DCROSS_DIRECTORY_STRUCTURE' '-W' '-Wall' '-Wwrite-strings' '-Wstrict-prototypes' '-Wmissing-prototypes' '-Wcast-qual' '-Wold-style-definition' '-isystem' './include' '-g' '-DIN_LIBGCC2' '-D__GCC_FLOAT_NOT_NEEDED' '-I.' '-I.' '-I../.././gcc' '-I../../../gcc-4.4.2/libgcc' '-I../../../gcc-4.4.2/libgcc/.' '-I../../../gcc-4.4.2/libgcc/../gcc' '-I../../../gcc-4.4.2/libgcc/../include' '-o' '_ffsdi2.o' '-MT' '_ffsdi2.o' '-MD' '-MP' '-MF' '_ffsdi2.dep' '-DL_ffsdi2' '-c' /home/luben/ware/gcc-4.4.2-arc-build/./gcc/cc1 -E -quiet -v -I. -I. -I../.././gcc -I../../../gcc-4.4.2/libgcc -I../../../gcc-4.4.2/libgcc/. -I../../../gcc-4.4.2/libgcc/../gcc -I../../../gcc-4.4.2/libgcc/../include -iprefix /home/luben/ware/gcc-4.4.2-arc-build/gcc/../lib/gcc/arc-elf32/4.4.2/ -isystem /home/luben/ware/gcc-4.4.2-arc-build/./gcc/include -isystem /home/luben/ware/gcc-4.4.2-arc-build/./gcc/include-fixed -MD _ffsdi2.d -MF _ffsdi2.dep -MP -MT _ffsdi2.o -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DL_ffsdi2 -isystem /opt/arc-tools/arc-elf32/include -isystem /opt/arc-tools/arc-elf32/sys-include -isystem ./include ../../../gcc-4.4.2/libgcc/../gcc/libgcc2.c -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -g -g -g -fworking-directory -O2 -O2 -O2 -fpch-preprocess -o libgcc2.i ignoring nonexistent directory "/opt/arc-tools/arc-elf32/include" ignoring nonexistent directory "./include" ignoring nonexistent directory "/home/luben/ware/gcc-4.4.2-arc-build/gcc/../lib/gcc/arc-elf32/4.4.2/include" ignoring nonexistent directory "/home/luben/ware/gcc-4.4.2-arc-build/gcc/../lib/gcc/arc-elf32/4.4.2/include-fixed" ignoring nonexistent directory "/home/luben/ware/gcc-4.4.2-arc-build/gcc/../lib/gcc/arc-elf32/4.4.2/../../../../arc-elf32/sys-include" ignoring nonexistent directory "/home/luben/ware/gcc-4.4.2-arc-build/gcc/../lib/gcc/arc-elf32/4.4.2/../../../../arc-elf32/include" ignoring nonexistent directory "/home/luben/ware/gcc-4.4.2-arc-build/gcc/../lib/gcc/../../lib/gcc/arc-elf32/4.4.2/include" ignoring nonexistent directory "/home/luben/ware/gcc-4.4.2-arc-build/gcc/../lib/gcc/../../lib/gcc/arc-elf32/4.4.2/include-fixed" ignoring nonexistent directory "/home/luben/ware/gcc-4.4.2-arc-build/gcc/../lib/gcc/../../lib/gcc/arc-elf32/4.4.2/../../../../arc-elf32/sys-include" ignoring nonexistent directory "/home/luben/ware/gcc-4.4.2-arc-build/gcc/../lib/gcc/../../lib/gcc/arc-elf32/4.4.2/../../../../arc-elf32/include" ignoring duplicate directory "." ignoring duplicate directory "../../../gcc-4.4.2/libgcc/." #include "..." search starts here: #include <...> search starts here: . ../.././gcc ../../../gcc-4.4.2/libgcc ../../../gcc-4.4.2/libgcc/../gcc ../../../gcc-4.4.2/libgcc/../include /home/luben/ware/gcc-4.4.2-arc-build/./gcc/include /home/luben/ware/gcc-4.4.2-arc-build/./gcc/include-fixed /opt/arc-tools/arc-elf32/sys-include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-B/home/luben/ware/gcc-4.4.2-arc-build/./gcc/' '-B/opt/arc-tools/arc-elf32/bin/' '-B/opt/arc-tools/arc-elf32/lib/' '-isystem' '/opt/arc-tools/arc-elf32/include' '-isystem' '/opt/arc-tools/arc-elf32/sys-include' '-g' '-O2' '-O2' '-g' '-O2' '-DIN_GCC' '-DCROSS_DIRECTORY_STRUCTURE' '-W' '-Wall' '-Wwrite-strings' '-Wstrict-prototypes' '-Wmissing-prototypes' '-Wcast-qual' '-W
[Bug rtl-optimization/42116] ice on valid code (unrecognizable insn)
--- Comment #5 from ltuikov at yahoo dot com 2009-11-21 11:25 --- Also observed with gcc 4.4.2. -- ltuikov at yahoo dot com changed: What|Removed |Added Version|4.2.1 |4.4.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42116
[Bug target/42100] soft float flags missings from libgcc.a (and others) if no --with-float given at configure time
--- Comment #2 from rearnsha at gcc dot gnu dot org 2009-11-21 10:56 --- This is a known problem, but I'm not going to fix it. The difficulty is that it will break object compatibility for a large number of users upgrading from older versions of the compiler (the attributes will conflict) forcing them to recompile everything (and in some cases that's not possible). The attribute system used in the arm-elf configuration is very primitive and not extensible, so it was entirely reworked as part of the ARM ABI standardization effort. Finally the arm-elf configuration is heading rapidly towards obsolescence so I would strongly recommend all developers moving towards the arm-eabi port. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added CC||rearnsha at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42100
[Bug inline-asm/37195] different variables get the same overlapping memory address in inline assembly
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-11-21 09:15 --- *** Bug 41294 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37195
[Bug inline-asm/41294] "=&rm" constraints give overlapping memory addresses
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-11-21 09:15 --- *** This bug has been marked as a duplicate of 37195 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41294
[Bug inline-asm/40124] Inline asm should support limited control flow
--- Comment #14 from pinskia at gcc dot gnu dot org 2009-11-21 09:13 --- Mark this as fixed for 4.5: http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Extended%20asm%20with%20gotoAs of GCC version 4.5, asm goto may be used to have the assembly jump to one or more C labels. In this form, a fifth section after the clobber list contains a list of all C labels to which the assembly may jump. Each label operand is implicitly self-named. The asm is also assumed to fall through to the next statement. This form of asm is restricted to not have outputs. This is due to a internal restriction in the compiler that control transfer instructions cannot have outputs. This restriction on asm goto may be lifted in some future version of the compiler. In the mean time, asm goto may include a memory clobber, and so leave outputs in memory. int frob(int x) { int y; asm goto ("frob %%r5, %1; jc %l[error]; mov (%2), %%r5" : : "r"(x), "r"(&y) : "r5", "memory" : error); return y; error: return -1; } In this (inefficient) example, the frob instruction sets the carry bit to indicate an error. The jc instruction detects this and branches to the error label. Finally, the output of the frob instruction (%r5) is stored into the memory for variable y, which is later read by the return statement. void doit(void) { int i = 0; asm goto ("mfsr %%r1, 123; jmp %%r1;" ".pushsection doit_table;" ".long %l0, %l1, %l2, %l3;" ".popsection" : : : "r1" : label1, label2, label3, label4); __builtin_unreachable (); label1: f1(); return; label2: f2(); return; label3: i = 1; label4: f3(i); } In this (also inefficient) example, the mfsr instruction reads an address from some out-of-band machine register, and the following jmp instruction branches to that address. The address read by the mfsr instruction is assumed to have been previously set via some application-specific mechanism to be one of the four values stored in the doit_table section. Finally, the asm is followed by a call to __builtin_unreachable to indicate that the asm does not in fact fall through. #define TRACE1(NUM) \ do { \ asm goto ("0: nop;" \ ".pushsection trace_table;" \ ".long 0b, %l0;" \ ".popsection" \ : : : : trace#NUM); \ if (0) { trace#NUM: trace(); } \ } while (0) #define TRACE TRACE1(__COUNTER__) In this example (which in fact inspired the asm goto feature) we want on rare occasions to call the trace function; on other occasions we'd like to keep the overhead to the absolute minimum. The normal code path consists of a single nop instruction. However, we record the address of this nop together with the address of a label that calls the trace function. This allows the nop instruction to be patched at runtime to be an unconditional branch to the stored label. It is assumed that an optimizing compiler will move the labeled block out of line, to optimize the fall through path from the asm. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40124
[Bug inline-asm/40124] Inline asm should support limited control flow
--- Comment #13 from pinskia at gcc dot gnu dot org 2009-11-21 09:12 --- Reopening to ... -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40124
[Bug middle-end/41924] graphite miscompiles aermod
--- Comment #5 from spop at gcc dot gnu dot org 2009-11-21 09:09 --- My automatic testers are still failing one of the aermod tests, see for example pb05.sum from: http://groups.google.com/group/gcc-graphite-test/browse_thread/thread/4afb9c19aa8a10c7 -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41924
[Bug middle-end/41924] graphite miscompiles aermod
--- Comment #4 from spop at gcc dot gnu dot org 2009-11-21 09:04 --- Yes, this should be fixed now in the Graphite branch, and it will be fixed in trunk after the merge that I am preparing. Sebastian -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41924
[Bug c/42126] gcc optimizes line away/optimizes to an endless loop
--- Comment #5 from codemasterhs at yahoo dot de 2009-11-21 09:02 --- (In reply to comment #4) > The pointer is not declared volatile. > > static struct smpMsg_t * volatile freeList; > > would be a volatile pointer. > Ok, this worked. So where has to be the volatile keyword, so that everything works? I mean I thought "volatile TYPE (like int, char and so on) foo" is right, isn´t it? Or does this only not work for pointers? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42126
[Bug middle-end/42130] [graphite-branch] dealII fails
--- Comment #1 from grosser at gcc dot gnu dot org 2009-11-21 08:50 --- Created an attachment (id=19071) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19071&action=view) Small C++ testcase showing the same behavior -O2 -fno-tree-ch are required options Fails on execution Submitted by: Alexander Monakov -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42130
[Bug middle-end/42130] New: [graphite-branch] dealII fails
Compilation with only graphite-identity fails: "-O3 -fno-loop-interchange -fno-loop-block -fno-loop-strip-mine" -- Running 447.dealII train base amd64-m64-gcc43-nn default /home/grosser/spec/bin/specinvoke -d /home/grosser/spec/benchspec/CPU2006/447.dealII/run/run_base_train_amd64-m64-gcc43-nn.0007 -e speccmds.err -o speccmds.stdout -f speccmds.cmd -C 447.dealII: copy 0 non-zero return code (exit code=0, signal=11) -- without graphite identity it works: -O3 -fno-graphite-identity -fno-loop-interchange -fno-loop-block -fno-loop-strip-mine -fno-graphite -- Summary: [graphite-branch] dealII fails Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: grosser at gcc dot gnu dot org ReportedBy: grosser at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42130
[Bug middle-end/41924] graphite miscompiles aermod
--- Comment #3 from grosser at gcc dot gnu dot org 2009-11-21 08:32 --- Li, Is this bug solved with a newer cloog version? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41924