[Bug c++/36961] fails to identify template
--- Comment #6 from igodard at pacbell dot net 2008-07-29 02:32 --- FWIW, Visual Studio has been reported to me as accepting the test case too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36961
[Bug translation/36958] typos in french translation.
--- Comment #3 from joseph at codesourcery dot com 2008-07-29 02:02 --- Subject: Re: typos in french translation. On Mon, 28 Jul 2008, dodji at gcc dot gnu dot org wrote: > Ah okay. So what is the email address to send the translation fixes to ? See the Language-Team entry in the .po file: "Language-Team: French <[EMAIL PROTECTED]>\n" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36958
[Bug c++/36961] fails to identify template
--- Comment #5 from igodard at pacbell dot net 2008-07-29 01:07 --- Please confirm that it is an error with your associates. First, Comeau likes it. Second, other template functions have no trouble identifying a template base class given a derived class. What is different about this case is that the base class is one that takes a template rather than a class or constant. Templates taking templates are unusual, and I'd be not surprised that g++ was insufficiently tested in this area. -- igodard at pacbell dot net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36961
[Bug target/36955] [4.4 Regression] TLS LIBCALL change breaks libstdc++ built with older binutils
--- Comment #13 from amodra at bigpond dot net dot au 2008-07-29 01:04 --- Blah, of course that's the wrong place to add the use_reg. Needs to be a few lines lower. I guess I may as well take this bug and go thru a boot/regress cycle. -- amodra at bigpond dot net dot au changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net |dot org |dot au Status|NEW |ASSIGNED Last reconfirmed|2008-07-29 00:20:29 |2008-07-29 01:04:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36955
[Bug c++/36961] fails to identify template
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-07-29 01:01 --- The error is correct as the type of v2 is foo so it cannot figure out the rest of the template agruments from that type. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36961
[Bug c++/36961] fails to identify template
--- Comment #3 from igodard at pacbell dot net 2008-07-29 00:54 --- p.s. Comeau likes the (correct, second) test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36961
[Bug c++/36961] fails to identify template
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-07-29 00:53 --- >A x3 = att(foo); foo is a class. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36961
[Bug c++/36961] fails to identify template
--- Comment #1 from igodard at pacbell dot net 2008-07-29 00:52 --- Oops - sorry, posted wrong test case: enum A{a}; enum B{b}; enum C{c}; enum D{d}; class bottom {}; template class attr { public: E v; operator E() { return v;} }; template class node, typename attr, typename next> class attrNode : public node, public next {}; template class node> class list1 : public attrNode > {}; class foo : public list1 {}; list1 v1; foo v2; templateclass node, template class> class nodeList > node&att(nodeList& v) { return v; } int main() { A x1 = att(v1); B x2 = att(v1); A x3 = att(v2); } gets you: ~/ootbc/personal/ivan$ g++ foo.cc foo.cc: In function int main(): foo.cc:33: error: no matching function for call to att(foo&) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36961
[Bug c++/36961] New: fails to identify template
enum A{a}; enum B{b}; class bottom {}; template class attr { public: E v; operator E() { return v;} }; template class node, typename attr, typename next> class attrNode : public node, public next {}; template class node> class list1 : public attrNode > {}; class foo : public list1 {}; list1 v1; foo v2; templateclass node, template class> class nodeList > node&att(nodeList& v) { return v; } int main() { A x1 = att(v1); B x2 = att(v1); A x3 = att(foo); } gets you: ~/ootbc/personal/ivan$ g++ foo.cc foo.cc: In function int main(): foo.cc:31: error: expected primary-expression before ) token -- Summary: fails to identify template Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: igodard at pacbell dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36961
[Bug target/36955] [4.4 Regression] TLS LIBCALL change breaks libstdc++ built with older binutils
--- Comment #12 from amodra at bigpond dot net dot au 2008-07-29 00:37 --- So, the easy fix for this bug is (totally untested, not even compiled) Index: gcc/config/rs6000/rs6000.c === --- gcc/config/rs6000/rs6000.c (revision 138134) +++ gcc/config/rs6000/rs6000.c (working copy) @@ -3940,7 +3940,12 @@ rs6000_legitimize_tls_address (rtx addr, else if (DEFAULT_ABI == ABI_AIX && !TARGET_64BIT) insn = gen_tls_gd_aix32 (r3, got, addr, tga, const0_rtx); else if (DEFAULT_ABI == ABI_V4) - insn = gen_tls_gd_sysvsi (r3, got, addr, tga, const0_rtx); + { + insn = gen_tls_gd_sysvsi (r3, got, addr, tga, const0_rtx); + if (TARGET_SECURE_PLT && flag_pic == 2) + use_reg (&CALL_INSN_FUNCTION_USAGE (insn), +pic_offset_table_rtx); + } else gcc_unreachable (); @@ -3962,7 +3967,12 @@ rs6000_legitimize_tls_address (rtx addr, else if (DEFAULT_ABI == ABI_AIX && !TARGET_64BIT) insn = gen_tls_ld_aix32 (r3, got, tga, const0_rtx); else if (DEFAULT_ABI == ABI_V4) - insn = gen_tls_ld_sysvsi (r3, got, tga, const0_rtx); + { + insn = gen_tls_ld_sysvsi (r3, got, tga, const0_rtx); + if (TARGET_SECURE_PLT && flag_pic == 2) + use_reg (&CALL_INSN_FUNCTION_USAGE (insn), +pic_offset_table_rtx); + } else gcc_unreachable (); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36955
[Bug target/36955] [4.4 Regression] TLS LIBCALL change breaks libstdc++ built with older binutils
--- Comment #11 from amodra at bigpond dot net dot au 2008-07-29 00:20 --- When -fPIC, r30 needs to be set to point into the .got2 section for the function, so that r30 is valid for the __tls_get_addr plt call stub. Note that this is a different GOT pointer than that used by @[EMAIL PROTECTED], which points into the .got section (as for the -fpic GOT). If there's anything to boo about it's this, rather than using a particular register for .got2 addressing. -fPIC tls really ought to use the .got2 section too. -- amodra at bigpond dot net dot au changed: What|Removed |Added CC|amodra at bigpond dot net | |dot au | Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-07-29 00:20:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36955
[Bug c++/36943] [c++0x] Use of nested C++0x initializer list for non-aggregate rejected
--- Comment #3 from jason at gcc dot gnu dot org 2008-07-29 00:07 --- fixed, thanks. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36943
[Bug c++/36943] [c++0x] Use of nested C++0x initializer list for non-aggregate rejected
--- Comment #2 from jason at gcc dot gnu dot org 2008-07-29 00:06 --- Subject: Bug 36943 Author: jason Date: Tue Jul 29 00:06:08 2008 New Revision: 138221 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138221 Log: PR c++/36943 * decl.c (reshape_init_r): Allow C++0x initializer lists. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/g++.dg/cpp0x/initlist1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36943
[Bug c++/36960] Reference variable in virtually inherited base corrupted under optimization
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-07-29 00:02 --- Likewise for 4.3.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36960
[Bug c++/36960] Reference variable in virtually inherited base corrupted under optimization
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-07-29 00:01 --- i = 0; upper.D.2127.ref = &i; upper.D.2125._vptr$Middle = &_ZTV5Upper + 12; return *((struct Lower *) &upper + (long unsigned int) *(int *) &_ZTV5Upper)->ref; This works on the trunk correctly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36960
[Bug c++/36960] New: Reference variable in virtually inherited base corrupted under optimization
Apologies if this is a duplicate: I searched existing reports and found tons of hits on "virtual inheritance" and "reference", but couldn't find anything like this. The following program illustrates the problem: << struct Lower { const int& ref; Lower(const int& ref) : ref(ref) { } }; struct Middle : public virtual Lower { Middle(const int& ref) : Lower(ref) { } }; struct Upper : public Middle { Upper(const int& ref) : Lower(ref), Middle(ref) { } int get() { return ref; } }; int main() { int i = 0; Upper upper(i); return upper.get(); } >> Compiling this using 4.2.2 or 4.2.3 with -O2 or higher causes the resulting binary to return a non-zero value; 3.4.2 produces a bug-free binary. I've seen the same effect in more complex code, where gdb gives an obviously wrong address for the "ref" member. Dropping to -O fixes the problem, as do several other changes: * Making "ref" an int (as opposed to an int&) * Making Middle inherit non-virtually from Lower * Accessing "ref" from Middle instead of Upper The constness of the reference has no effect. Issued command-line: g++ -Wall -W -Wundef -Wpointer-arith -g -O2 VirtuallyInheritedReference.cpp Full output from running with "-v --save-temps" is as follows: g++ -v -save-temps -Wall -W -Wundef -Wpointer-arith -g -O2 -c -o /dev/null VirtuallyInheritedReference.cpp << Using built-in specs. Target: i686-pc-linux-gnu Configured with: /mnt/taw/usr/Taw/tmp/gcc-4.2.2/configure --prefix=/usr --disable-nls --libexecdir=/usr/lib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++ --disable-bootstrap Thread model: posix gcc version 4.2.2 /usr/lib/gcc/i686-pc-linux-gnu/4.2.2/cc1plus -E -quiet -v -D_GNU_SOURCE VirtuallyInheritedReference.cpp -mtune=generic -Wall -W -Wundef -Wpointer-arith -fworking-directory -O2 -fpch-preprocess -o VirtuallyInheritedReference.ii ignoring nonexistent directory "/usr/lib/gcc/i686-pc-linux-gnu/4.2.2/../../../../i686-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/i686-pc-linux-gnu/4.2.2/../../../../include/c++/4.2.2 /usr/lib/gcc/i686-pc-linux-gnu/4.2.2/../../../../include/c++/4.2.2/i686-pc-linux-gnu /usr/lib/gcc/i686-pc-linux-gnu/4.2.2/../../../../include/c++/4.2.2/backward /usr/local/include /usr/lib/gcc/i686-pc-linux-gnu/4.2.2/include /usr/include End of search list. /usr/lib/gcc/i686-pc-linux-gnu/4.2.2/cc1plus -fpreprocessed VirtuallyInheritedReference.ii -quiet -dumpbase VirtuallyInheritedReference.cpp -mtune=generic -auxbase-strip /dev/null -g -O2 -Wall -W -Wundef -Wpointer-arith -version -o VirtuallyInheritedReference.s GNU C++ version 4.2.2 (i686-pc-linux-gnu) compiled by GNU C version 4.2.2. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 6ba594205d388e98f3b46dee442d61ac as -V -Qy -o /dev/null VirtuallyInheritedReference.s GNU assembler version 2.18 (i686-pc-linux-gnu) using BFD version (GNU Binutils) 2.18 >> Contents of VirtuallyInheritedReference.ii: << # 1 "VirtuallyInheritedReference.cpp" # 1 "/home/raymond/src/C++/gcc-bugs//" # 1 "" # 1 "" # 1 "VirtuallyInheritedReference.cpp" struct Lower { int& ref; virtual ~Lower() { } Lower(int& ref) : ref(ref) { } }; struct Middle : public virtual Lower { Middle(int& ref) : Lower(ref) { } }; struct Upper : public Middle { Upper(int& ref) : Lower(ref), Middle(ref) { } int get() { return ref; } }; int main() { int i = 0; Upper upper(i); return upper.get(); } >> -- Summary: Reference variable in virtually inherited base corrupted under optimization Product: gcc Version: 4.2.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: raymond at corvil dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36960
[Bug c++/36959] [4.2/4.3/4.4 Regression] C++ front-end causing a static inline function to be emitted
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.1.1 4.4.0 Known to work||3.4.0 Target Milestone|--- |4.2.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36959
[Bug c++/36959] New: [4.2/4.3/4.4 Regression] C++ front-end causing a static inline function to be emitted
Take: static inline int *fromSlotB(void) { static int shuf_BZZZ = 1; return &shuf_BZZZ; } int main(void) { return (int)fromSlotB(); } --- CUT --- At -O2, fromSlotB is still being emitted even though it is unused. It is being marked in cxx_callgraph_analyze_expr: else if (DECL_CONTEXT (t) && TREE_CODE (DECL_CONTEXT (t)) == FUNCTION_DECL) /* If we need a static variable in a function, then we need the containing function. */ mark_decl_referenced (DECL_CONTEXT (t)); For -frepo this might be true but I don't think this is true in general. This regression was introduced to do unit-at-a-time always for C++: http://gcc.gnu.org/ml/gcc-patches/2004-07/msg02615.html -- Summary: [4.2/4.3/4.4 Regression] C++ front-end causing a static inline function to be emitted Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36959
[Bug libstdc++/36949] [C++0x] make_shared does not initialize enable_shared_from_this' internal shared_count
--- Comment #6 from paolo dot carlini at oracle dot com 2008-07-28 23:30 --- Fixed. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36949
[Bug libstdc++/36949] [C++0x] make_shared does not initialize enable_shared_from_this' internal shared_count
--- Comment #5 from paolo at gcc dot gnu dot org 2008-07-28 23:29 --- Subject: Bug 36949 Author: paolo Date: Mon Jul 28 23:28:16 2008 New Revision: 138219 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138219 Log: 2008-07-28 Paolo Carlini <[EMAIL PROTECTED]> PR libstdc++/36949 * include/tr1_impl/boost_shared_ptr.h (__shared_ptr(_Sp_make_shared_tag, _Alloc, _Args&&...): Call __enable_shared_from_this_helper. * testsuite/20_util/shared_ptr/creation/36949.cc: New. Added: trunk/libstdc++-v3/testsuite/20_util/shared_ptr/creation/36949.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/tr1_impl/boost_shared_ptr.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36949
[Bug target/36955] [4.4 Regression] TLS LIBCALL change breaks libstdc++ built with older binutils
--- Comment #10 from pinskia at gcc dot gnu dot org 2008-07-28 23:27 --- >From http://sourceware.org/ml/binutils/2005-05/msg00391.html: Also, the ld support doesn't allow registers other than r30 as a GOT pointer. booo. -- Pinski -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36955
[Bug target/36955] [4.4 Regression] TLS LIBCALL change breaks libstdc++ built with older binutils
--- Comment #9 from janis at gcc dot gnu dot org 2008-07-28 23:21 --- The difference is in setting up r30 before branching to __tls_get_addr, which probably uses r30. -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||amodra at gcc dot gnu dot ||org Target Milestone|4.4.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36955
[Bug libstdc++/36949] [C++0x] make_shared does not initialize enable_shared_from_this' internal shared_count
--- Comment #4 from paolo dot carlini at oracle dot com 2008-07-28 23:09 --- Thanks, fix forthcoming. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-07-28 23:09:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36949
[Bug translation/36958] typos in french translation.
--- Comment #2 from dodji at gcc dot gnu dot org 2008-07-28 22:40 --- Ah okay. So what is the email address to send the translation fixes to ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36958
[Bug target/36955] [4.4 Regression] TLS LIBCALL change breaks libstdc++ built with older binutils
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-07-28 22:29 --- The difference is the saving/restoring of r30. r30 is not used at all as far as I can tell. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|TLS LIBCALL change breaks |[4.4 Regression] TLS LIBCALL |libstdc++ built with older |change breaks libstdc++ |binutils|built with older binutils Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36955
[Bug target/36955] TLS LIBCALL change breaks libstdc++ built with older binutils
--- Comment #7 from janis at gcc dot gnu dot org 2008-07-28 22:26 --- Smaller testcase, in C: int* get_global() { static __thread int global; return &global; } -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36955
[Bug target/36955] TLS LIBCALL change breaks libstdc++ built with older binutils
--- Comment #6 from janis at gcc dot gnu dot org 2008-07-28 21:32 --- The attachments are the output of "objdump -d" (2.16 objdump) of eh_globals.o in the build trees for r135960 and r135961. Let me know if there are things you'd like me to try. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36955
[Bug target/36955] TLS LIBCALL change breaks libstdc++ built with older binutils
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-07-28 21:28 --- Hmm, is this with the relocs? The first thing I noticed is that the loading of the global address is different. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36955
[Bug target/36955] TLS LIBCALL change breaks libstdc++ built with older binutils
--- Comment #4 from janis at gcc dot gnu dot org 2008-07-28 21:19 --- Created an attachment (id=15975) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15975&action=view) disassembly of eh_globals.o after patch This attachment is the disassembly with the patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36955
[Bug target/36955] TLS LIBCALL change breaks libstdc++ built with older binutils
--- Comment #3 from janis at gcc dot gnu dot org 2008-07-28 21:17 --- Created an attachment (id=15974) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15974&action=view) disassembly of eh_globals.o before aptch File libstdc++-v3/libsupc++/eh_globals.cc is compiled differently before and after the patch. This attachment is from before the patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36955
[Bug translation/36958] typos in french translation.
--- Comment #1 from joseph at codesourcery dot com 2008-07-28 20:53 --- Subject: Re: typos in french translation. Translation fixes must go to the language teams. We make no local changes to the .po files, only import unmodified new versions from the TP. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36958
[Bug translation/36958] typos in french translation.
-- 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|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-07-28 20:47:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36958
[Bug translation/36958] New: typos in french translation.
There are many fr.po files in which the word "sans" has been misleadingly typed "sasn". :!find . -name "fr.po" -exec grep -in "sasn" {} /dev/null \; ./gcc/po/fr.po:18353:msgstr "%Jd�claration de � %D � sasn lien suivant une d�claration externe" ./gcc/po/fr.po:21788:msgstr "%Hd�claration sasn effet" ./gcc/po/fr.po:27906:msgstr "%Hd�claration sasn effet" ./libcpp/po/fr.po:1471:#~ msgstr "%Jd�claration de � %D � sasn lien suivant une d�claration externe" ./libcpp/po/fr.po:5057:#~ msgstr "%Hd�claration sasn effet" -- Summary: typos in french translation. Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: translation AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dodji at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36958
[Bug target/36955] TLS LIBCALL change breaks libstdc++ built with older binutils
--- Comment #2 from steven at gcc dot gnu dot org 2008-07-28 20:41 --- Like Pinski said: the code before and after the patch should be identical w.r.t. TLS addresses. Without a more specific test case I'm not even going to look at this. -- steven 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=36955
[Bug ada/36957] ACATS ce3801b ICE emit_move_insn, at expr.c:3381 post tuple merge
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-07-28 20:33 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36957
[Bug ada/36957] ACATS ce3801b ICE emit_move_insn, at expr.c:3381 post tuple merge
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-07-28 20:33 --- Subject: Bug 36957 Author: rguenth Date: Mon Jul 28 20:32:32 2008 New Revision: 138217 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138217 Log: 2008-07-28 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/36957 * tree-flow.h (tree_ssa_useless_type_conversion): Remove. (useless_type_conversion_p): Remove. (types_compatible_p): Remove. * gimple.h (tree_ssa_useless_type_conversion): Declare. (useless_type_conversion_p): Declare. (types_compatible_p): Declare. (gimple_expr_type): Return the base type only if it is trivially convertible to the subtype. Modified: trunk/gcc/ChangeLog trunk/gcc/gimple.h trunk/gcc/tree-flow.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36957
[Bug libstdc++/36949] [C++0x] make_shared does not initialize enable_shared_from_this' internal shared_count
--- Comment #3 from jwakely dot gcc at gmail dot com 2008-07-28 20:27 --- (In reply to comment #2) > Jonathan, can you have a look? If you can confirm the issue, is it just matter > of adding a call to __enable_shared_from_this_helper(_M_refcount, _M_ptr, > _M_ptr) to __shared_ptr(_Sp_make_shared_tag, _Alloc, _Args&&...) ?? Yes, that's the right fix. > PS: I'm going to adjust some arguments around from _Alloc to const _Alloc&... Cool. Thanks for catching this, Daniel. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36949
[Bug fortran/36403] [4.4 Regression] Some fortran tests using eoshift fail on SH
--- Comment #5 from burnus at gcc dot gnu dot org 2008-07-28 20:04 --- > and it seems as though PACK and RESHAPE would suffer from the same problem as > EOSHIFT does Seems so. I glanced through F2008 CD but I could not find more potential problems. > Is it ok if I try to write one generic conv-function for this case and call it > for all the three intrinsics? Yes, of cause. Seemingly all of them have the pattern type of the first argument = type of one of the latter arguments. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36403
[Bug ada/36957] ACATS ce3801b ICE emit_move_insn, at expr.c:3381 post tuple merge
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-07-28 19:21 --- 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|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-07-28 19:21:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36957
[Bug ada/36957] ACATS ce3801b ICE emit_move_insn, at expr.c:3381 post tuple merge
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-07-28 19:19 --- The problem is that the cast in item = (ce3801b__B_1__fix_io__num___XF_1_10_1_16) iftmp.130; is stripped away. item (QImode) is of type type unit size align 16 symtab 0 alias set -1 canonical type 0xb7d9de38 precision 16 min max RM size > sizes-gimplified unsigned QI size unit size align 8 symtab 0 alias set 0 canonical type 0xb7da3000 precision 8 min max RM size > and iftmp.130 is of its base-type (HImode). This happens in fold_gimple_assign case GIMPLE_UNARY_RHS: result = fold_unary (subcode, gimple_expr_type (stmt), gimple_assign_rhs1 (stmt)); where gimple_expr_type always returns the base-type and so makes this a no-op cast. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36957
[Bug tree-optimization/36861] [4.3 Regression] boost's compressed avl confuses GCC
--- Comment #19 from lothar at tradescape dot biz 2008-07-28 18:55 --- Created an attachment (id=15973) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15973&action=view) oprofile logs I compiled optimized executables with and without -fno-strict-aliasing and generated an oprofile log for them: /opt2/linux/ix86/bin/g++-4.3.1 -m64 -O3 -no-strict-aliasing -g -I/opt2/linux/x86_64/include/boost-1_35 -DUSE_OPTIMIZATION=0 -o ./avltest-non ./avltest.cpp /opt2/linux/ix86/bin/g++-4.3.1 -m64 -O3 -fno-strict-aliasing -g -I/opt2/linux/x86_64/include/boost-1_35 -DUSE_OPTIMIZATION=0 -o ./avltest-non ./avltest.cpp sudo opcontrol --reset; sudo opcontrol --start; ./avltest-no; ./avltest-non ; sudo opcontrol --stop opannotate --source --assembly --demangle=smart --threshold=1 ./avltest-no >./avltest-no.oprofile.txt opannotate --source --assembly --demangle=smart --threshold=1 ./avltest-non >./avltest-non.oprofile.txt diff -u ./avltest-no.oprofile.txt ./avltest-non.oprofile.txt ./avltest-diff.oprofile.txt $ time ./avltest-non sizeof(Node)=72 sizeof(NodeSet)=40 creating file ./avltest.img done region.get_address()=0x7f4d43ed1000 region.get_size()=3600056 p_set=0x7f4d43ed1000 p_values=0x7f4d43ed1030 created/inserted 5 entries region.get_address()=0x7f4d43b62000 region.get_size()=3600056 p_set=0x7f4d43b62000 p_values=0x7f4d43b62030 checked 5 entries, result=1249975000 real0m0.614s user0m0.140s sys 0m0.016s $ time ./avltest-no sizeof(Node)=72 sizeof(NodeSet)=40 creating file ./avltest.img done region.get_address()=0x7f7fdce43000 region.get_size()=3600056 p_set=0x7f7fdce43000 p_values=0x7f7fdce43030 created/inserted 5 entries region.get_address()=0x7f7fdcad4000 region.get_size()=3600056 p_set=0x7f7fdcad4000 p_values=0x7f7fdcad4030 checked 5 entries, result=1249975000 real0m22.634s user0m22.277s sys 0m0.120s I hope these tests aid in finding the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36861
[Bug fortran/36403] [4.4 Regression] Some fortran tests using eoshift fail on SH
-- domob at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-06-02 11:29:59 |2008-07-28 18:41:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36403
[Bug fortran/36403] [4.4 Regression] Some fortran tests using eoshift fail on SH
--- Comment #4 from domob at gcc dot gnu dot org 2008-07-28 18:41 --- Thanks for all the hints, Tobias! I've had a look through the F2003 standard about intrinsics taking optional char arguments, and it seems as though PACK and RESHAPE would suffer from the same problem as EOSHIFT does (optional string argument whose type is not even specified as to be always string), and tests showed that here too the call to the library function has one less argument when the optional string argument is not present... This is probably a problem there, too, isn't it? None of those have their own conv_intrinsic_ functions at the moment (for all of them the if matches, as they all return non-scalar values). Is it ok if I try to write one generic conv-function for this case and call it for all the three intrinsics? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36403
[Bug ada/36957] ACATS ce3801b ICE emit_move_insn, at expr.c:3381 post tuple merge
--- Comment #2 from laurent at guerby dot net 2008-07-28 18:29 --- (reg:HI 59 [ T12b ]) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36957
[Bug ada/36957] ACATS ce3801b ICE emit_move_insn, at expr.c:3381 post tuple merge
--- Comment #1 from laurent at guerby dot net 2008-07-28 18:29 --- (gdb) f 2 #2 0x007886d4 in emit_move_insn (x=0x2b6f9e60, y=0x2b6f9d40) at ../../trunk/gcc/expr.c:3380 3380 gcc_assert (mode != BLKmode (gdb) debug_rtx(x) Undefined command: "debug_rtx". Try "help". (gdb) call debug_rtx(x) (reg:QI 64 [ ]) (gdb) call debug_rtx(y) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36957
[Bug ada/36957] New: ACATS ce3801b ICE emit_move_insn, at expr.c:3381 post tuple merge
Post tuple merge, was working at rev 138205 fails at rev 138209 gnatmake -v -v --GCC="/home/guerby/build/gcc/xgcc -B/home/guerby/build/gcc/" -gnatws -O1 -I/home/guerby/build/gcc/testsuite/ada/acats/support ce3801b.adb -largs --GCC="/home/guerby/build/gcc/xgcc -B/home/guerby/build/gcc/" -cargs -v gcc version 4.4.0 20080728 (experimental) [trunk revision 138209] (GCC) COLLECT_GCC_OPTIONS='-c' '-B/home/guerby/build/gcc/' '-gnatws' '-O1' '-I/home/guerby/build/gcc/testsuite/ada/acats/support' '-v' '-gnatez' '-mtune=generic' /home/guerby/build/gcc/gnat1 -I/home/guerby/build/gcc/testsuite/ada/acats/support -quiet -dumpbase ce3801b.adb -O1 -gnatws -gnatez -mtune=generic ce3801b.adb -o /tmp/ccJ0tLNs.s +===GNAT BUG DETECTED==+ | 4.4.0 20080728 (experimental) [trunk revision 138209] (x86_64-unknown-linux-gnu) GCC error:| | in emit_move_insn, at expr.c:3381| | Error detected around /n/14/guerby/install-trunk/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/adainclude/a-tifiio.adb:316| (gdb) r -I/home/guerby/build/gcc/testsuite/ada/acats/support -quiet -dumpbase ce3801b.adb -O1 -gnatws -gnatez -mtune=generic ce3801b.adb Starting program: /home/guerby/build/gcc/gnat1 -I/home/guerby/build/gcc/testsuite/ada/acats/support -quiet -dumpbase ce3801b.adb -O1 -gnatws -gnatez -mtune=generic ce3801b.adb (gdb) r -I/home/guerby/build/gcc/testsuite/ada/acats/support -quiet -dumpbase ce3801b.adb -O1 -gnatws -gnatez -mtune=generic ce3801b.adb Starting program: /home/guerby/build/gcc/gnat1 -I/home/guerby/build/gcc/testsuite/ada/acats/support -quiet -dumpbase ce3801b.adb -O1 -gnatws -gnatez -mtune=generic ce3801b.adb Breakpoint 1, internal_error (gmsgid=0xdac5dc "in %s, at %s:%d") at ../../trunk/gcc/diagnostic.c:629 629 { (gdb) bt #0 internal_error (gmsgid=0xdac5dc "in %s, at %s:%d") at ../../trunk/gcc/diagnostic.c:629 #1 0x007314cc in fancy_abort (file=, line=3381, function=0xdb7aaf "emit_move_insn") at ../../trunk/gcc/diagnostic.c:689 #2 0x007886d4 in emit_move_insn (x=0x2b6f9e60, y=0x2b6f9d40) at ../../trunk/gcc/expr.c:3380 #3 0x008d4a57 in expand_value_return (val=0x2b6f9d40) at ../../trunk/gcc/stmt.c:1539 #4 0x008d5f00 in expand_return (retval=0x2b7009c0) at ../../trunk/gcc/stmt.c:1723 #5 0x0077abbd in expand_expr_real_1 (exp=0x2b700a00, target=0x0, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at ../../trunk/gcc/expr.c:9118 #6 0x00786fe4 in expand_expr_real (exp=0x2b700a00, target=0x2b5a1b00, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at ../../trunk/gcc/expr.c:7086 #7 0x008d4cb9 in expand_expr_stmt (exp=0xdac5dc) at ../../trunk/gcc/expr.h:517 #8 0x00c48f78 in expand_gimple_basic_block (bb=0x2b68ed80) at ../../trunk/gcc/cfgexpand.c:1907 #9 0x00c49c7a in gimple_expand_cfg () at ../../trunk/gcc/cfgexpand.c:2218 #10 0x00862575 in execute_one_pass (pass=0x1141da0) at ../../trunk/gcc/passes.c:1282 #11 0x008627a5 in execute_pass_list (pass=0x1141da0) at ../../trunk/gcc/passes.c:1330 #12 0x00932a1c in tree_rest_of_compilation (fndecl=0x2b5b9200) at ../../trunk/gcc/tree-optimize.c:418 #13 0x00a9f1e0 in cgraph_expand_function (node=0x2b5b9b00) at ../../trunk/gcc/cgraphunit.c:1038 #14 0x00aa0e64 in cgraph_optimize () at ../../trunk/gcc/cgraphunit.c:1100 #15 0x00422da9 in gnat_write_global_declarations () at ../../trunk/gcc/ada/utils.c:4208 #16 0x008e46bf in toplev_main (argc=, argv=) at ../../trunk/gcc/toplev.c:972 #17 0x2ad1d4ca in __libc_start_main () from /lib/libc.so.6 #18 0x0040474a in _start () at ../sysdeps/x86_64/elf/start.S:113 at -O0 it compiles but the generated code SEGV so wrong-code -- Summary: ACATS ce3801b ICE emit_move_insn, at expr.c:3381 post tuple merge Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: wrong-code, ice-on-valid-code Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: laurent at guerby dot net GCC host triplet: x86_64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36957
[Bug tree-optimization/36956] [4.4 Regression] Revision 138207 causes some regressions
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-07-28 18:15 --- The matrix ones are expected. I guess you really don't read the mailing list about the trunk being frozen. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36956
[Bug tree-optimization/36956] New: [4.4 Regression] Revision 138207 causes some regressions
On Linux/x86, revision 138207 causes +FAIL: gcc.dg/format/bitfld-1.c -DWIDE (test for excess errors) +FAIL: gcc.dg/format/bitfld-1.c (test for excess errors) +FAIL: gcc.dg/matrix/matrix-1.c scan-ipa-dump-times matrix-reorg "Flattened 3 dimensions" 1: dump file does not exist +FAIL: gcc.dg/matrix/matrix-2.c scan-ipa-dump-times matrix-reorg "Flattened 2 dimensions" 1: dump file does not exist +FAIL: gcc.dg/matrix/matrix-3.c scan-ipa-dump-times matrix-reorg "Flattened 2 dimensions" 1: dump file does not exist +FAIL: gcc.dg/matrix/matrix-4.c scan-ipa-dump-times matrix-reorg "Flattened" 0: dump file does not exist +FAIL: gcc.dg/matrix/matrix-5.c scan-ipa-dump-times matrix-reorg "Flattened" 0: dump file does not exist +FAIL: gcc.dg/matrix/matrix-6.c scan-ipa-dump-times matrix-reorg "Flattened 2 dimensions" 1: dump file does not exist +FAIL: gcc.dg/matrix/transpose-1.c scan-ipa-dump-times matrix-reorg "Flattened 3 dimensions" 1: dump file does not exist +FAIL: gcc.dg/matrix/transpose-1.c scan-ipa-dump-times matrix-reorg "Transposed" 3: dump file does not exist +FAIL: gcc.dg/matrix/transpose-2.c scan-ipa-dump-times matrix-reorg "Flattened 3 dimensions" 1: dump file does not exist +FAIL: gcc.dg/matrix/transpose-2.c scan-ipa-dump-times matrix-reorg "Transposed" 0: dump file does not exist +FAIL: gcc.dg/matrix/transpose-3.c scan-ipa-dump-times matrix-reorg "Flattened 2 dimensions" 1: dump file does not exist +FAIL: gcc.dg/matrix/transpose-3.c scan-ipa-dump-times matrix-reorg "Transposed" 2: dump file does not exist +FAIL: gcc.dg/matrix/transpose-4.c scan-ipa-dump-times matrix-reorg "Flattened 3 dimensions" 1: dump file does not exist +FAIL: gcc.dg/matrix/transpose-4.c scan-ipa-dump-times matrix-reorg "Transposed" 2: dump file does not exist +FAIL: gcc.dg/matrix/transpose-5.c scan-ipa-dump-times matrix-reorg "Flattened 3 dimensions" 1: dump file does not exist +FAIL: gcc.dg/matrix/transpose-5.c scan-ipa-dump-times matrix-reorg "Transposed" 0: dump file does not exist +FAIL: gcc.dg/matrix/transpose-6.c scan-ipa-dump-times matrix-reorg "Flattened 3 dimensions" 1: dump file does not exist +FAIL: gcc.dg/matrix/transpose-6.c scan-ipa-dump-times matrix-reorg "Transposed" 0: dump file does not exist -- Summary: [4.4 Regression] Revision 138207 causes some regressions Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36956
[Bug target/36955] TLS LIBCALL change breaks libstdc++ built with older binutils
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-07-28 17:47 --- Blah. This makes little sense really though, the generated code should be exactly the same before and after. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36955
[Bug target/36955] New: TLS LIBCALL change breaks libstdc++ built with older binutils
This testcase (yes, it's actually huge): #include int main () { std::cerr << "writing to cerr" << std::endl; } segfaults in libstdc++ when powerpc-linux mainline GCC is configured with --enable-secureplt and uses 2.16 binutils (specifically, I used 2.16.91.0.5 20051219 (SUSE Linux)). It works fine with 2.18 binutils or without --enable-secureplt. The failure begins with this patch: http://gcc.gnu.org/viewcvs?view=rev&rev=135961 r135961 | zadeck | 2008-05-26 23:37:05 + (Mon, 26 May 2008) | 14 lines 2008-05-26 Steven Bosscher <[EMAIL PROTECTED]> * config/rs6000/rs6000.c (rs6000_legitimize_tls_address): Generate new tls_gd_* and tls_ld_* insns instead of an insn sequence. * config/rs6000/rs6000.md (TLSmode, tls_abi_suffix, tls_insn_suffix, tls_sysv_suffix): New mode and mode attribute iterators. (tls_gd_32, tls_gd_64, tls_ld_32, tls_ld_64): Remove. (lts_gd_aix*, tls_gd_sysv*, tls_ld_aix*, tls_ld_sysv*): New patterns. (tls_dtprel_*, tls_dtprel_ha_*, tls_dtprel_lo_*, tls_got_dtprel_*, tls_tprel_*, tls_tprel_ha_*, tls_tprel_lo_*, tls_got_tprel_*, tls_tls_*): Merge 32 bit and 64 bit variants using aforementioned iterators. -- Summary: TLS LIBCALL change breaks libstdc++ built with older binutils Product: gcc Version: 4.4.0 Status: UNCONFIRMED 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: powerpc-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36955
[Bug c++/36767] [4.3/4.4 Regression] Segmentation fault with -fprofile-arcs -O2
--- Comment #13 from dodji at gcc dot gnu dot org 2008-07-28 17:01 --- Created an attachment (id=15972) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15972&action=view) reworked patch Reworked patch to walk BIND_EXPR_VARs only. I think there is no need to walk VAR_DECLs via DECL_EXPR() if we walk BIND_EXPR_VARs. The patch seems to work, regtested on trunk, x86_64. @jakub: thanks for your comments. I did fix the patch accordingly. -- dodji at gcc dot gnu dot org changed: What|Removed |Added Attachment #15957|0 |1 is obsolete|| Attachment #15969|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36767
[Bug target/36919] [4.4 regression] Bootstrap failure on IRIX 6.5: unrecognizable insn in errors.c
--- Comment #4 from michael dot a dot richmond at nasa dot gov 2008-07-28 16:23 --- (In reply to comment #2) > Have you tried revision 138154 or newer? Revision 138154 fixed the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36919
[Bug tree-optimization/36766] [4.4 Regression] natGC.cc:229: internal compiler error: Segmentation fault
--- Comment #20 from rguenth at gcc dot gnu dot org 2008-07-28 16:15 --- I can reproduce this on the trunk after the tuples merge (i686). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2008-07-20 11:15:21 |2008-07-28 16:15:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36766
[Bug tree-optimization/36792] [4.4 Regression] Revision 137631 causes many failures
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-07-28 15:35 --- They have been all XFAILed, with the tuples merge we now get XPASS: gcc.dg/tree-ssa/data-dep-1.c scan-tree-dump-times ltrans "4, \\+, 1" 0 XPASS: gcc.dg/tree-ssa/ltrans-3.c scan-tree-dump-times ltrans "transformed loop" 1 XPASS: gcc.dg/tree-ssa/ssa-fre-13.c scan-tree-dump fre "Inserted .* &a" XPASS: gcc.dg/tree-ssa/ssa-fre-13.c scan-tree-dump fre "Replaced tmp1_.\\(D\\)->data" XPASS: gcc.dg/tree-ssa/ssa-fre-14.c scan-tree-dump fre "Inserted .* &a" XPASS: gcc.dg/tree-ssa/ssa-fre-14.c scan-tree-dump fre "Replaced tmp1.data" XPASS: gcc.dg/tree-ssa/ssa-fre-17.c scan-tree-dump fre "Replaced f.doms\\[0\\].dom with i_" instead which leaves FAIL: gcc.dg/tree-ssa/ssa-fre-7.c scan-tree-dump-times fre "Inserted pretmp" 1 FAIL: gcc.dg/tree-ssa/ssa-fre-7.c scan-tree-dump-times fre "Replaced a.u.f with pretmp" 3 FAIL: gcc.dg/tree-ssa/ssa-fre-7.c scan-tree-dump-times fre "Replaced a.u.k with j" 1 FAIL: gcc.dg/tree-ssa/ssa-fre-7.c scan-tree-dump fre "= VIEW_CONVERT_EXPR\\(j_" FAIL: gcc.dg/tree-ssa/ssa-fre-7.c scan-tree-dump optimized "return j" FAIL: gcc.dg/tree-ssa/ssa-fre-8.c scan-tree-dump-times fre "Replaced u.f with pretmp" 2 FAIL: gcc.dg/tree-ssa/ssa-fre-8.c scan-tree-dump-times fre "Inserted pretmp" 2 FAIL: gcc.dg/tree-ssa/ssa-fre-9.c scan-tree-dump-times fre "Eliminated: 1" 2 FAIL: gcc.dg/tree-ssa/ssa-fre-9.c scan-tree-dump-times fre "Insertions: 1" 2 FAIL: gcc.dg/tree-ssa/ssa-pre-15.c scan-tree-dump optimized "= 0;" unfixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||xfail http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36792
[Bug c++/36767] [4.3/4.4 Regression] Segmentation fault with -fprofile-arcs -O2
--- Comment #12 from jakub at gcc dot gnu dot org 2008-07-28 15:00 --- There are unneeded {} pairs, when there is just one statement in for/if, you should just write if (something) DECL_CONTEXT (x) = current_function_decl; and similar for for (.) if (something) DECL_CONTEXT (var) = current_function_decl. Also, I think it is unnecessary to pass current_function_decl as data to the callback, current_function_decl is accessible in the callback too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36767
[Bug target/36919] [4.4 regression] Bootstrap failure on IRIX 6.5: unrecognizable insn in errors.c
--- Comment #3 from michael dot a dot richmond at nasa dot gov 2008-07-28 13:49 --- (In reply to comment #2) > Have you tried revision 138154 or newer? I don't know what that is -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36919
[Bug target/36919] [4.4 regression] Bootstrap failure on IRIX 6.5: unrecognizable insn in errors.c
--- Comment #2 from hjl dot tools at gmail dot com 2008-07-28 13:42 --- Have you tried revision 138154 or newer? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36919
[Bug tree-optimization/36953] Optimizer generates faulty assembler code when estimating max. floating point value in a for loop
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-07-28 13:12 --- I can reproduce this with 4.2.4, but not with 4.1.3 or 4.3.1. -fno-strict-aliasing fixes it, so I suspect it's a dup of one of the known wrong-code bugs with GCC 4.2.x -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.2.4 Known to work||4.1.3 4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36953
[Bug c++/36954] New: Wrong warning with -Wlogical-op
compiling the following functions with g++ -Wlogical-op leads to a wrong warning - template void Test() { if ((1 == 2) || (true)) { // warning: logical ‘||’ with non-zero constant will always evaluate as true } if ((1 == 2) || (!false)) { } if (false || true) { } } int main() { if ((1 == 2) || (true)) { } } - Warning occurs only in the first if inside the template. > g++-4.3 -v Using built-in specs. Target: x86_64-suse-linux Configured with: ../configure --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3 --enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --program-suffix=-4.3 --enable-version-specific-runtime-libs --enable-linux-futex --without-system-libunwind --with-cpu=generic --build=x86_64-suse-linux Thread model: posix gcc version 4.3.2 20080715 (prerelease) [gcc-4_3-branch revision 137837] (SUSE Linux) -- Summary: Wrong warning with -Wlogical-op Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: olaf at bonorden dot de GCC build triplet: x86_64-suse-linux GCC host triplet: x86_64-suse-linux GCC target triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36954
[Bug target/36919] [4.4 regression] Bootstrap failure on IRIX 6.5: unrecognizable insn in errors.c
--- Comment #1 from michael dot a dot richmond at nasa dot gov 2008-07-28 12:23 --- I get the same error in gcc-4.4-20080725 under MIPS Linux. My last successful bootstrap was 20080718. -- michael dot a dot richmond at nasa dot gov changed: What|Removed |Added CC||michael dot a dot richmond ||at nasa dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36919
[Bug bootstrap/36908] bootstrap forever with BOOT_CFLAGS="-O2 -ftree-loop-distribution"
--- Comment #1 from tomby at gcc dot gnu dot org 2008-07-28 11:53 --- Created an attachment (id=15971) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15971&action=view) Testcase where loop distribution enabled makes run of binary forever Compilation with CFLAGS="-O2" and running of testcase is ok (it finish). Compilation with CLFLAGS="-O2 -ftree-loop-distribution" and running testcase makes it run forever (last loop cycles). Inlined loop from free_alt_states is wrongly distributed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36908
[Bug tree-optimization/36953] Optimizer generates faulty assembler code when estimating max. floating point value in a for loop
--- Comment #2 from tcm dot home at gmx dot de 2008-07-28 11:49 --- *** Bug 36952 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36953
[Bug tree-optimization/36952] Optimizer generates faulty assembler code when estimating max. floating point value in a for loop
--- Comment #1 from tcm dot home at gmx dot de 2008-07-28 11:49 --- *** This bug has been marked as a duplicate of 36953 *** -- tcm dot home at gmx dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36952
[Bug fortran/36652] Internal compiler error: in gfc_conv_expr
-- dfranke at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36652
[Bug fortran/36874] Add shape checks to cshift/eoshift
--- Comment #3 from burnus at gcc dot gnu dot org 2008-07-28 11:21 --- > Why a run-time check? Because the shape might not be known at compile time? And a compile-time check because compile-time checks are nicer ;-) > AFAIK, we can always determine the rank at runtime Yes, the RANK should be known (even) at compile time, but the SHAPE might be only be known at run time. (Shape = how many elements per dimension; rank = number of dimensions.) (By the way, the rank is already checked.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36874
[Bug tree-optimization/36953] Optimizer generates faulty assembler code when estimating max. floating point value in a for loop
--- Comment #1 from tcm dot home at gmx dot de 2008-07-28 11:15 --- Created an attachment (id=15970) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15970&action=view) File generated with g++ -o factor -v -save-temps -Wall -O2 -march=i686 factor.cpp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36953
[Bug tree-optimization/36953] New: Optimizer generates faulty assembler code when estimating max. floating point value in a for loop
Hello, I am working on a larger project processing audio signals in double format. As I needed to estimate the max. Amplitude of a buffer, it returned a faulty value. I debugged the assembler code and realized, that the optimizer created a faulty computation of the maximum. By only changing one instruction, the computation is correct. I've reduced the code to a minimum of code supplementing function calls that fill the buffer with a simple memcpy function. The code is standalone. I'll include the factor.ii which is also a command line program demonstrating the error. I've compiled it with the command line found below. I also tried out leaving the compiler flag -march=i686 away. It just changed my assembler code but didn't get rid of the error. Further down I'll include my analysis of the assembler code. g++ -o factor -Wall -v -O2 -march=i686 factor.cpp: Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --disable-libmudflap --enable-targets=all --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.2.3 (Debian 4.2.3-3) /usr/lib/gcc/i486-linux-gnu/4.2.3/cc1plus -E -quiet -v -D_GNU_SOURCE factor.cpp -march=i686 -Wall -O2 -fpch-preprocess -o factor.ii ignoring nonexistent directory "/usr/local/include/i486-linux-gnu" ignoring nonexistent directory "/usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../i486-linux-gnu/include" ignoring nonexistent directory "/usr/include/i486-linux-gnu" #include "..." search starts here: #include <...> search starts here: /usr/include/c++/4.2 /usr/include/c++/4.2/i486-linux-gnu /usr/include/c++/4.2/backward /usr/local/include /usr/lib/gcc/i486-linux-gnu/4.2.3/include /usr/include End of search list. /usr/lib/gcc/i486-linux-gnu/4.2.3/cc1plus -fpreprocessed factor.ii -quiet -dumpbase factor.cpp -march=i686 -auxbase factor -O2 -Wall -version -o factor.s GNU C++ version 4.2.3 (Debian 4.2.3-3) (i486-linux-gnu) compiled by GNU C version 4.2.3 (Debian 4.2.3-3). GGC heuristics: --param ggc-min-expand=45 --param ggc-min-heapsize=29241 Compiler executable checksum: f63294e1c8ecc1bf2473a5bae1642fbe as -V -Qy -o factor.o factor.s GNU assembler version 2.18.0 (i486-linux-gnu) using BFD version (GNU Binutils for Debian) 2.18.0.20080103 /usr/lib/gcc/i486-linux-gnu/4.2.3/collect2 --eh-frame-hdr -m elf_i386 --hash-style=both -dynamic-linker /lib/ld-linux.so.2 -o factor /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/crt1.o /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/crti.o /usr/lib/gcc/i486-linux-gnu/4.2.3/crtbegin.o -L/usr/lib/gcc/i486-linux-gnu/4.2.3 -L/usr/lib/gcc/i486-linux-gnu/4.2.3 -L/usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/i486-linux-gnu/4.2.3/../../.. factor.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/i486-linux-gnu/4.2.3/crtend.o /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/crtn.o The optimizer generates the error with the following line of code: for (unsigned long i = 0; i < insize; ++i) _factor = std::max(_factor, std::max(-data[i], data[i])); with double * data; (Audio Data) unsigned long insize; (number of doubles in the buffer) double _factor; (currently estimated, global factor) Generated Assembler code from factor.s: // Load data Buffer pointer to eax movl-36(%ebp), %eax // Clear edx (that's our i) xorl%edx, %edx // Load _factor on FP-Stack fldl(%esi) // Have _factor twice on the FP-Stack (Stack: (original)_factor, (current)_factor) fld %st(0) // Start the for-loop jmp .L45 .p2align 4,,7 .L64: // This at the beginning of every iteration i >= 1 // This is the actual consistency error // At this pointer we have the following on the FP-Stack: st(0): (current)_factor, st(1): (original)_factor // After executing this, we'll have st(0): (original)_factor, st(1): (current)_factor, which creates a problem further down // To show what is actually going wrong, I'll label _factor // with original for the original factor that was present when the // for-loop was started and current for the value, that is actually the // correct factor. // Note: To fix the bug, this instruction needs to be fstl %st(1) to have // the current factors in BOTH st(0) and st(1) fxch%st(1) .L45: // Load the Value from the current data Buffer Position onto the stack // FP-Stack: st(0): data[i], st(1): (orig)_factor, st(2): (curr)_factor fldl(%eax) // Negate // FP-Stack: st(0): -data[i], st(1): (orig)_factor, st(2): (curr)_factor fchs // Safe -data[i] to ??? - (why???) fstl-16
[Bug fortran/36652] Internal compiler error: in gfc_conv_expr
--- Comment #2 from j dot wookey at bristol dot ac dot uk 2008-07-28 11:02 --- Updating gfortran to 4.4.0 (20080728) on i386-apple-darwin9.4.0 fixes problem. Thanks for looking at it! -- j dot wookey at bristol dot ac dot uk changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36652
[Bug tree-optimization/36952] New: Optimizer generates faulty assembler code when estimating max. floating point value in a for loop
Hello, I am working on a larger project processing audio signals in double format. As I needed to estimate the max. Amplitude of a buffer, it returned a faulty value. I debugged the assembler code and realized, that the optimizer created a faulty computation of the maximum. By only changing one instruction, the computation is correct. I've reduced the code to a minimum of code supplementing function calls that fill the buffer with a simple memcpy function. The code is standalone. I'll include the factor.ii which is also a command line program demonstrating the error. I've compiled it with the command line found below. I also tried out leaving the compiler flag -march=i686 away. It just changed my assembler code but didn't get rid of the error. Further down I'll include my analysis of the assembler code. g++ -o factor -Wall -v -O2 -march=i686 factor.cpp: Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --disable-libmudflap --enable-targets=all --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.2.3 (Debian 4.2.3-3) /usr/lib/gcc/i486-linux-gnu/4.2.3/cc1plus -E -quiet -v -D_GNU_SOURCE factor.cpp -march=i686 -Wall -O2 -fpch-preprocess -o factor.ii ignoring nonexistent directory "/usr/local/include/i486-linux-gnu" ignoring nonexistent directory "/usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../i486-linux-gnu/include" ignoring nonexistent directory "/usr/include/i486-linux-gnu" #include "..." search starts here: #include <...> search starts here: /usr/include/c++/4.2 /usr/include/c++/4.2/i486-linux-gnu /usr/include/c++/4.2/backward /usr/local/include /usr/lib/gcc/i486-linux-gnu/4.2.3/include /usr/include End of search list. /usr/lib/gcc/i486-linux-gnu/4.2.3/cc1plus -fpreprocessed factor.ii -quiet -dumpbase factor.cpp -march=i686 -auxbase factor -O2 -Wall -version -o factor.s GNU C++ version 4.2.3 (Debian 4.2.3-3) (i486-linux-gnu) compiled by GNU C version 4.2.3 (Debian 4.2.3-3). GGC heuristics: --param ggc-min-expand=45 --param ggc-min-heapsize=29241 Compiler executable checksum: f63294e1c8ecc1bf2473a5bae1642fbe as -V -Qy -o factor.o factor.s GNU assembler version 2.18.0 (i486-linux-gnu) using BFD version (GNU Binutils for Debian) 2.18.0.20080103 /usr/lib/gcc/i486-linux-gnu/4.2.3/collect2 --eh-frame-hdr -m elf_i386 --hash-style=both -dynamic-linker /lib/ld-linux.so.2 -o factor /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/crt1.o /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/crti.o /usr/lib/gcc/i486-linux-gnu/4.2.3/crtbegin.o -L/usr/lib/gcc/i486-linux-gnu/4.2.3 -L/usr/lib/gcc/i486-linux-gnu/4.2.3 -L/usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/i486-linux-gnu/4.2.3/../../.. factor.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/i486-linux-gnu/4.2.3/crtend.o /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/crtn.o The optimizer generates the error with the following line of code: for (unsigned long i = 0; i < insize; ++i) _factor = std::max(_factor, std::max(-data[i], data[i])); with double * data; (Audio Data) unsigned long insize; (number of doubles in the buffer) double _factor; (currently estimated, global factor) Generated Assembler code from factor.s: // Load data Buffer pointer to eax movl-36(%ebp), %eax // Clear edx (that's our i) xorl%edx, %edx // Load _factor on FP-Stack fldl(%esi) // Have _factor twice on the FP-Stack (Stack: (original)_factor, (current)_factor) fld %st(0) // Start the for-loop jmp .L45 .p2align 4,,7 .L64: // This at the beginning of every iteration i >= 1 // This is the actual consistency error // At this pointer we have the following on the FP-Stack: st(0): _factor(current), st(1): _factor(original) // After executing this, we'll have st(0): _factor(original), st(1): _factor(current), which creates a problem further down // To show what is actually going wrong, I'll label _factor fxch%st(1) .L45: fldl(%eax) fchs fstl-16(%ebp) fldl(%eax) fucomi %st(1), %st fcmovbe %st(1), %st fstp%st(1) fucomi %st(2), %st fstp%st(2) fxch%st(1) fcmovbe %st(1), %st addl$1, %edx addl$8, %eax cmpl%ebx, %edx jne .L64 fstp%st(1) fstpl (%esi) .L43: cmpb$0, 8(%esi) je .L53 -- Summary: Optimizer generates faulty assembler code when estimating max. floating point value in
[Bug middle-end/32581] make profiledbootstrap - stageprofile - gcc/ada/a-except.adb:1301: error: control flow in the middle of basic block 20
--- Comment #8 from tim at bishnet dot net 2008-07-28 10:52 --- For what it's worth, I just wanted to add a "me too". I'm building on Solaris 9 sparc using gcc 4.2.4 to build with. The error occurs with 4.3.1 and the 20080724 snapshot. /u1/src/garstow/devel/gcc/work/build/./prev-gcc/xgcc -B/u1/src/garstow/devel/gcc/work/build/./prev-gcc/ -B/usr/local/sparc-sun-solaris2.9/bin/ -c -g -O2 -fprofile-generate -gnatpg -gnata -g -O1 -fno-inline \ -nostdinc -I- -I. -Iada -I../../../work/gcc-4.3-20080724/gcc/ada ../../../work/gcc-4.3-20080724/gcc/ada/a-except.adb -o ada/a-except.o ../../../work/gcc-4.3-20080724/gcc/ada/a-except.adb: In function 'Ada.Exceptions.Raise_From_Controlled_Operation': ../../../work/gcc-4.3-20080724/gcc/ada/a-except.adb:1305: error: control flow in the middle of basic block 20 ../../../work/gcc-4.3-20080724/gcc/ada/a-except.adb:1305: error: control flow in the middle of basic block 20 ../../../work/gcc-4.3-20080724/gcc/ada/a-except.adb:1305: error: control flow in the middle of basic block 20 ../../../work/gcc-4.3-20080724/gcc/ada/a-except.adb:1305: error: control flow in the middle of basic block 20 ../../../work/gcc-4.3-20080724/gcc/ada/a-except.adb:1305: error: control flow in the middle of basic block 20 +===GNAT BUG DETECTED==+ | 4.3.2 20080724 (prerelease) (sparc-sun-solaris2.9) GCC error:| | verify_flow_info failed | | Error detected around ../../../work/gcc-4.3-20080724/gcc/ada/a-except.adb:1305| | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:398 make[4]: *** [ada/a-except.o] Error 1 make[4]: Leaving directory `/u1/src/garstow/devel/gcc/work/build/gcc' make[3]: *** [all-stageprofile-gcc] Error 2 make[3]: Leaving directory `/u1/src/garstow/devel/gcc/work/build' make[2]: *** [stageprofile-bubble] Error 2 make[2]: Leaving directory `/u1/src/garstow/devel/gcc/work/build' make[1]: *** [profiledbootstrap] Error 2 make[1]: Leaving directory `/u1/src/garstow/devel/gcc/work/build' make: *** [build-work/build/Makefile] Error 2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32581
[Bug c++/36767] [4.3/4.4 Regression] Segmentation fault with -fprofile-arcs -O2
--- Comment #11 from dodji at gcc dot gnu dot org 2008-07-28 10:52 --- Created an attachment (id=15969) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15969&action=view) update vars more specifically, adding BIND_EXPR After talking with Jakub, it appeared that I was forgetting to update VAR_DECLS that were attached to a BIND_EXPR. Walking those VAR_DECLS appears to fix the problem. Regtesting now. Will update the patch with a proper testcase when regtesting passes. Please feel free to comment in the meantime. -- dodji at gcc dot gnu dot org changed: What|Removed |Added Attachment #15968|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36767
[Bug fortran/36874] Add shape checks to cshift/eoshift
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-07-28 10:48 --- Why a run-time check? AFAIK, we can always determine the rank at runtime, so unless somebody messes with our array descriptors big time, we should be safe. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-07-28 10:48:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36874
[Bug fortran/36915] Unneccessary array temporary for same_array_ptr = const * same_array_ptr
--- Comment #4 from tkoenig at gcc dot gnu dot org 2008-07-28 10:38 --- Confirmed. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-07-28 10:38:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36915
[Bug fortran/36933] unneeded temporary with derived type containing an array as argument
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-07-28 10:38 --- No temporary is done if the first argument of the matmul intrinsic is a (3,3) array. Interesting. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Summary|unneeded temporary |unneeded temporary with ||derived type containing an ||array as argument http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36933
[Bug fortran/36931] unneeded temporary for array intrinsic binop scalar
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-07-28 09:52 --- Another test case: $ cat foo.f90 program main real, dimension(2,2) :: a real, dimension(2) :: b call random_number(a) b = sum(a,dim=1) + 0.4 end program main $ gfortran -Warray-temporaries foo.f90 foo.f90:5.6: b = sum(a,dim=1) + 0.4 1 Warning: Creating array temporary at (1) -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Summary|unneeded temporary |unneeded temporary for array ||intrinsic binop scalar http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36931
[Bug fortran/36825] F2008: libgfortran I/O+intrinsics: Rank > 7 arrays [will break presumably break library ABI]
--- Comment #9 from tkoenig at gcc dot gnu dot org 2008-07-28 09:46 --- See http://gcc.gnu.org/wiki/ArrayDescriptorUpdate -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-07-28 09:46:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36825
[Bug c++/36767] [4.3/4.4 Regression] Segmentation fault with -fprofile-arcs -O2
--- Comment #10 from dodji at gcc dot gnu dot org 2008-07-28 07:19 --- Created an attachment (id=15968) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15968&action=view) try scanning DECL_EXPR instead of VAR_DECLs directly. @Jason: I have tried scanning DECL_EXPR and setting only VAR_DECL that are children of DECL_EXPR. It does not work. This patch is what I have done. Maybe I have done something bad ? My understanding is that by walking DECL_EXPRs and getting their associated VAR_DECL (using DECL_EXPR_DECL), all VAR_DECLs should be touched because every single variable must be declared at least once. So, are there cases where a VAR_DECL has never had a parent DECL_EXPR ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36767