[Bug other/26208] Serious problem with unwinding through signal frames
--- Comment #32 from ebotcazou at gcc dot gnu dot org 2008-07-07 08:33 --- Jakub, the patch contains a workaround for the missing S in the CIE augmentation string for old kernels on PPC. Is this problem really specific to PPC? It seems that I'm seeing it on x86 too with 2.6.8 and 2.6.16 kernels. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26208
[Bug target/36745] [4.4 Regression] ICE in gen_reg_rtx, at emit-rtl.c:868
--- Comment #2 from mueller at gcc dot gnu dot org 2008-07-07 09:00 --- Created an attachment (id=15868) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15868action=view) slightly shorter (different testcase, same bug) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36745
[Bug target/36570] segmentation fault
--- Comment #7 from aldot at gcc dot gnu dot org 2008-07-07 09:20 --- Closing as INVALID as suggested by the reporter. -- aldot at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36570
[Bug preprocessor/36453] PR36320 breaks boost
--- Comment #4 from mueller at gcc dot gnu dot org 2008-07-07 09:25 --- well, lets keep it at that for now -- mueller at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36453
[Bug target/36745] [4.4 Regression] ICE in gen_reg_rtx, at emit-rtl.c:868
--- Comment #3 from krebbel at gcc dot gnu dot org 2008-07-07 12:35 --- The shorter testcase does not fail with -O2 -fPIC on GCC rev. 137553. But I can confirm the ICE with the first example. For large GOTs (4k) we rewrite a symbol reference as a GOTENT relocation in the LEGITIMIZE_ADDRESS hook. A reference to the original SYM_REF stays as REG_EQUAL note. The note is used by GCSE to propagate the SYM_REF directly into the asm operand. So the legitimize_address hook is called for this operand during reload - since the fix needs an additional pseudo it crashes. -- krebbel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |krebbel at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-07-07 12:35:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36745
[Bug fortran/36747] New: Internal compiler error
When compiling this stripped down fragment of code: subroutine dmnwgenod() integer dmnwmaxno,dmnwmaxme Parameter ( dmnwmaxno = 60, dmnwmaxme = 200 ) integer dmnwmemli(dmnwmaxme,dmnwmaxno), dmnwnodco common / dmwpnodes / dmnwmemli, dmnwnodco integer nodmco,nodwml(dmnwmaxme) integer i,mnodiid,dmvwmaiid do 110 i=1,nodmco nodwml(i) = dmvwmaiid(dmnwmemli(i,mnodiid)) 110 continue return end c: if dmnwnodco is deleted from the integer definition and the common block, this subroutine compiles! Command to compile: gfortran-4.3 -m64 -O -c -fimplicit-none -fno-underscoring -fno-automatic -Wuninitialized error.f System: gfortran -v Using built-in specs. Target: x86_64-suse-linux Configured with: ../configure --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3 --enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit--enable-libstdcxx-allocator=new --disable-libstdcxx-pch --program-suffix=-4.3 --enable-version-specific-runtime-libs --enable-linux-futex --without-system-libunwind --with-cpu=generic --build=x86_64-suse-linux Thread model: posix gcc version 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036] (SUSE Linux) We get following error message: internal compiler error: in set_uids_in_ptset, at tree-ssa-structalias.c:4785 This subroutine has always compiled successfully on g77 and gfortran 4.2 systems. -- Summary: Internal compiler error Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gabriel dot barton at acutgmbh dot de GCC build triplet: ? GCC host triplet: x86_64 GNU/Linux GCC target triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36747
[Bug middle-end/36726] [4.4 Regression] ICE in move_stmt_r, at tree-cfg.c:5699 with -fopenmp
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-07-07 13:34:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36726
[Bug middle-end/36747] ICE in set_uids_in_ptset, at tree-ssa-structalias.c:4785 with -O
--- Comment #1 from burnus at gcc dot gnu dot org 2008-07-07 13:34 --- I can reproduce this with 4.3.1 (and -O). It works with 4.2.1 and 4.4.0. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Component|fortran |middle-end Keywords||ice-on-valid-code Summary|Internal compiler error |ICE in set_uids_in_ptset, at ||tree-ssa-structalias.c:4785 ||with -O http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36747
[Bug debug/36748] New: scev const-prop pass adds bad line numbers
I'm testing inlined function support for GCC. When I compile the attached testcase with GCC (Debian's 4.3 package or unmodified trunk) and -g -O2, break main in the patched GDB puts a breakpoint at the start of main and again inside the inlined copy of factorial. This happens because there are several bits of code associated with the line containing main's opening brace. The bad line numbers are introduced by pass_scev_cprop (why is this dumped into sccp; having a dump named sccp shortly after one named store_ccp is confusing). Here's the relevant piece of the diff between 096t.lim and 099t.sccp: @@ -88,7 +100,11 @@ bb 8: # mult_acc.12_13 = PHI mult_acc.12_15(6) - # value_16 = PHI value_14(6) + [../break.c : 13] D.2700_29 = value_11 + -1; + [../break.c : 13] D.2701_7 = (unsigned int) D.2633_10; + [../break.c : 13] D.2702_30 = 2 - D.2701_7; + [../break.c : 13] D.2703_31 = (int) D.2702_30; + value_16 = D.2700_29 + D.2703_31; bb 9: # mult_acc.12_19 = PHI mult_acc.12_13(8), 1(4) There are no other lines associated with break.c:13 in the dump at this point. The location came from internal_get_tmp_var. 644 if (EXPR_HAS_LOCATION (val)) 645 SET_EXPR_LOCUS (mod, EXPR_LOCUS (val)); 646 else 647 SET_EXPR_LOCATION (mod, input_location); input_location has nothing to do with anything at this point. -- Summary: scev const-prop pass adds bad line numbers Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: drow at gcc dot gnu dot org GCC host triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36748
[Bug middle-end/36747] ICE in set_uids_in_ptset, at tree-ssa-structalias.c:4785 with -O
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-07-07 13:51 --- I think this was fixed by 2008-06-25 Richard Guenther [EMAIL PROTECTED] * tree-ssa-structalias.c (fieldoff_compare): Make sure to not overflow the result type. as I can no longer reproduce this on the branch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36747
[Bug debug/36748] scev const-prop pass adds bad line numbers
--- Comment #1 from drow at gcc dot gnu dot org 2008-07-07 13:56 --- Created an attachment (id=15869) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15869action=view) Test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36748
[Bug c++/36749] New: sizeof returns 0 for class
The class contains only one array member with unspecified size has a zero size. The problem was reproduced on gcc 3.3.6 (Knoppix), 4.1.2 (Gentoo x86), 3.4.4. Also array with the zero size elements was created. The test file is attached. -- Summary: sizeof returns 0 for class Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: limanski at narod dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36749
[Bug c++/36749] sizeof returns 0 for class
--- Comment #1 from limanski at narod dot ru 2008-07-07 14:02 --- Created an attachment (id=15870) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15870action=view) The test file for the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36749
[Bug c++/36749] sizeof returns 0 for class
--- Comment #2 from paolo dot carlini at oracle dot com 2008-07-07 14:24 --- The problem is one of diagnostic: the code should be just rejected because Foo is an incomplete type. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36749
[Bug c++/36749] sizeof returns 0 for class
--- Comment #3 from limanski at narod dot ru 2008-07-07 14:29 --- (In reply to comment #2) The problem is one of diagnostic: the code should be just rejected because Foo is an incomplete type. But the instanse of Foo can be created and both sizeof(Foo) and sizeof(foo) are equals to zero. Do you mean that this behavior is correct? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36749
[Bug c++/36749] sizeof returns 0 for class
--- Comment #4 from paolo dot carlini at oracle dot com 2008-07-07 14:38 --- I mean the entire snippet should be just rejected in the first place. In other terms, this is an accept-invalid. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||accepts-invalid Last reconfirmed|-00-00 00:00:00 |2008-07-07 14:38:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36749
[Bug c++/13699] Extern C routine in different namespaces accepted with different exception signature
--- Comment #3 from dseketel at redhat dot com 2008-07-07 14:54 --- Created an attachment (id=15871) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15871action=view) first attempt at trying to fix the bug This patch checks that re-declaration of extern C functions complies with the exception specification constraints. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13699
[Bug target/36713] [4.4 regression] r137252 breaks -O2 optimization on x86_64-unknown-linux-gnu
--- Comment #23 from rguenth at gcc dot gnu dot org 2008-07-07 15:12 --- Subject: Bug 36713 Author: rguenth Date: Mon Jul 7 15:11:29 2008 New Revision: 137571 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137571 Log: 2008-07-07 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/36713 * tree-flow-inline.h (is_call_used): New function. * tree-nrv.c (dest_safe_for_nrv_p): Use it. * tree-tailcall.c (suitable_for_tail_opt_p): Likewise. * tree-outof-ssa.c (create_temp): Set call-used flag if required. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-flow-inline.h trunk/gcc/tree-nrv.c trunk/gcc/tree-outof-ssa.c trunk/gcc/tree-tailcall.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36713
[Bug target/36713] [4.4 regression] r137252 breaks -O2 optimization on x86_64-unknown-linux-gnu
--- Comment #24 from rguenth at gcc dot gnu dot org 2008-07-07 15:16 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36713
[Bug middle-end/36726] [4.4 Regression] ICE in move_stmt_r, at tree-cfg.c:5699 with -fopenmp
--- Comment #2 from jakub at gcc dot gnu dot org 2008-07-07 15:27 --- Subject: Bug 36726 Author: jakub Date: Mon Jul 7 15:26:35 2008 New Revision: 137572 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137572 Log: PR middle-end/36726 * f95-lang.c (poplevel): Don't ever add subblocks to global_binding_level. * gfortran.dg/gomp/pr36726.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/gomp/pr36726.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/f95-lang.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36726
[Bug middle-end/36726] [4.4 Regression] ICE in move_stmt_r, at tree-cfg.c:5699 with -fopenmp
--- Comment #3 from jakub at gcc dot gnu dot org 2008-07-07 15:33 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36726
[Bug c/36750] New: -Wmissing-field-initializers relaxation request
While trying to compile coreutils with -Wextra,
I noticed many warnings due to automatic variables
initialized with { 0, }.
As I understand it, since C90 the above will initialize
[all members of] the type to that used in static scope,
including any unused padding space in the structure.
I.E. the following is valid:
mbstate_t m = { 0, };
int i = { 0, };
struct { int a; int b; } s = { 0, };
It would be great if gcc would relax this warning
when a trailing ',' is specified as that would be clear indication
that one wants to init all [other] elements to 0, and that
we haven't just forgotten some members.
At least the warning should be suppressed for the specific
most common case is where { 0, } is specified.
thanks.
--
Summary: -Wmissing-field-initializers relaxation request
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: P at draigBrady dot com
GCC build triplet: i386-redhat-linux
GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36750
[Bug target/36701] [4.4 Regression] unaligned access in gcc.c-torture/execute/complex-7.c
--- Comment #4 from hjl dot tools at gmail dot com 2008-07-07 17:50 --- Revision 137575 is the cause and revision 137575 doesn't help. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36701
[Bug fortran/36751] New: assignment between allocatable arrays of different size causes glibc error
If I assign allocatable arrays of different size I get a glibc error and a backtrace. This happens with every version of gfortran I've tried, including 4.1, 4.3, and 4.4. The workaround is easy enough, but perhaps the compiler could be improved also. Here's the output: $gfortran --version GNU Fortran (GCC) 4.1.2 20071124 (Red Hat 4.1.2-42) Copyright (C) 2007 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING $gfortran -o repro_g repro.f90 ./repro_g *** glibc detected *** ./repro_g: free(): invalid next size (fast): 0x14d314d0 *** === Backtrace: = /lib64/libc.so.6[0x359ae71634] /lib64/libc.so.6(cfree+0x8c)[0x359ae74c5c] /usr/lib64/libgfortran.so.1(_gfortran_deallocate+0x26)[0x2ad9cffa72a6] ./repro_g[0x4009f4] ./repro_g[0x400a2e] /lib64/libc.so.6(__libc_start_main+0xf4)[0x359ae1d8b4] ./repro_g[0x400609] === Memory map: 0040-00401000 r-xp fd:06 5493742 /home/steve/lang/f90/repro_g 0060-00601000 rw-p fd:06 5493742 /home/steve/lang/f90/repro_g 14d2b000-14d4c000 rw-p 14d2b000 00:00 0 359aa0-359aa1a000 r-xp fd:00 12636395 /lib64/ld-2.5.so 359ac1a000-359ac1b000 r--p 0001a000 fd:00 12636395 /lib64/ld-2.5.so 359ac1b000-359ac1c000 rw-p 0001b000 fd:00 12636395 /lib64/ld-2.5.so 359ae0-359af4a000 r-xp fd:00 12636396 /lib64/libc-2.5.so 359af4a000-359b149000 ---p 0014a000 fd:00 12636396 /lib64/libc-2.5.so 359b149000-359b14d000 r--p 00149000 fd:00 12636396 /lib64/libc-2.5.so 359b14d000-359b14e000 rw-p 0014d000 fd:00 12636396 /lib64/libc-2.5.so 359b14e000-359b153000 rw-p 359b14e000 00:00 0 359b20-359b282000 r-xp fd:00 12636403 /lib64/libm-2.5.so 359b282000-359b481000 ---p 00082000 fd:00 12636403 /lib64/libm-2.5.so 359b481000-359b482000 r--p 00081000 fd:00 12636403 /lib64/libm-2.5.so 359b482000-359b483000 rw-p 00082000 fd:00 12636403 /lib64/libm-2.5.so 35a9c0-35a9c0d000 r-xp fd:00 12636418 /lib64/libgcc_s-4.1.2-20080102.so.1 35a9c0d000-35a9e0d000 ---p d000 fd:00 12636418 /lib64/libgcc_s-4.1.2-20080102.so.1 35a9e0d000-35a9e0e000 rw-p d000 fd:00 12636418 /lib64/libgcc_s-4.1.2-20080102.so.1 2ad9cff7b000-2ad9cff7c000 rw-p 2ad9cff7b000 00:00 0 2ad9cff95000-2ad9cff96000 rw-p 2ad9cff95000 00:00 0 2ad9cff96000-2ad9d002c000 r-xp fd:00 1293923 /usr/lib64/libgfortran.so.1.0.0 2ad9d002c000-2ad9d022b000 ---p 00096000 fd:00 1293923 /usr/lib64/libgfortran.so.1.0.0 2ad9d022b000-2ad9d022d000 rw-p 00095000 fd:00 1293923 /usr/lib64/libgfortran.so.1.0.0 2ad9d022d000-2ad9d022f000 rw-p 2ad9d022d000 00:00 0 2ad9d400-2ad9d4021000 rw-p 2ad9d400 00:00 0 2ad9d4021000-2ad9d800 ---p 2ad9d4021000 00:00 0 7fffdab19000-7fffdab2f000 rw-p 7fffdab19000 00:00 0 [stack] ff60-ffe0 ---p 00:00 0 [vdso] Aborted $ -- Summary: assignment between allocatable arrays of different size causes glibc error Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sdirkse at gams dot com GCC host triplet: x86_64-redhat-linux GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36751
[Bug fortran/36751] assignment between allocatable arrays of different size causes glibc error
--- Comment #1 from sdirkse at gams dot com 2008-07-07 18:00 --- Created an attachment (id=15872) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15872action=view) test case No flags required to reproduce: gfortran -o repro repro.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36751
[Bug c++/35396] possible incorrect opitmization due to missed dependency
--- Comment #2 from hjl dot tools at gmail dot com 2008-07-07 18:03 --- I can reproduce it on Linux/x86. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com GCC build triplet|i686-pc-cygwin | GCC host triplet|i686-pc-cygwin | GCC target triplet|i686-pc-cygwin | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35396
[Bug rtl-optimization/36672] IRA + -fno-pic ICE in emit_swap_insn, at reg-stack.c:829
--- Comment #2 from vmakarov at redhat dot com 2008-07-07 18:07 --- Incorrect order in reload insn chain results in wrong reload inheritance which crashed the compiler. The patch solving the problem will follow soon. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36672
[Bug c/36752] New: assembler error and segfault when compiling a wine 1.0 souce program with -O2
assembler error and segfault when compiling a wine 1.0 souce program with -O2
cd /ahbakup/sysbuild/wine-1.0/dlls/user32/tests;gcc -c -I. -I.
-I../../../include -I../../../include -D_REENTRANT -fPIC -Wall -pipe
-fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings
-Wtype-limits -Wpointer-arith -g -O2 -o menu.o menu.c
{standard input}: Assembler messages:
{standard input}:7412: Warning: end of file not at end of a line; newline
inserted
{standard input}:7745: Error: unknown pseudo-op: `.l'
gcc: Internal error: Segmentation fault (program cc1)
no error and good object code when the -O2 is removed.
version information
gcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-cpu=generic --build=i386-redhat-linux
Thread model: posix
gcc version 4.3.0 20080428 (Red Hat 4.3.0-8) (GCC)
I will try to attach the core ...
--
Summary: assembler error and segfault when compiling a wine 1.0
souce program with -O2
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: johnlumby at hotmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36752
[Bug rtl-optimization/36672] IRA + -fno-pic ICE in emit_swap_insn, at reg-stack.c:829
--- Comment #3 from vmakarov at gcc dot gnu dot org 2008-07-07 18:14 --- Subject: Bug 36672 Author: vmakarov Date: Mon Jul 7 18:13:13 2008 New Revision: 137581 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137581 Log: 2008-07-07 Vladimir Makarov [EMAIL PROTECTED] PR preprocessor/36672 * ira.c (chain_insn_order): New variable. (chain_freq_compare, chain_bb_compare): Use it. (ira_sort_insn_chain): Set it up. Modified: branches/ira/gcc/ChangeLog branches/ira/gcc/ira.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36672
[Bug target/34780] Bootstrapping libstdc++-v3 failed
--- Comment #9 from rwild at gcc dot gnu dot org 2008-07-07 18:16 --- Subject: Bug 34780 Author: rwild Date: Mon Jul 7 18:16:04 2008 New Revision: 137582 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137582 Log: gcc/ PR target/34780 * unwind-pe.h (size_of_encoded_value): add attribute unused. Modified: trunk/gcc/ChangeLog trunk/gcc/unwind-pe.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34780
[Bug target/34780] Bootstrapping libstdc++-v3 failed
--- Comment #10 from rwild at gcc dot gnu dot org 2008-07-07 18:17 --- Subject: Bug 34780 Author: rwild Date: Mon Jul 7 18:17:08 2008 New Revision: 137583 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137583 Log: gcc/ PR target/34780 * unwind-pe.h (size_of_encoded_value): add attribute unused. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/unwind-pe.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34780
[Bug other/36752] assembler error and segfault when compiling a wine 1.0 souce program with -O2
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-07-07 18:18 --- --with-bugurl=http://bugzilla.redhat.com/bugzilla Why are you reporting this bug to us, when it says to report it to redhat? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |other Summary|assembler error and segfault|assembler error and segfault |when compiling a wine 1.0 |when compiling a wine 1.0 |souce program with -O2 |souce program with -O2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36752
[Bug rtl-optimization/36673] IRA -O3 -fno-pic ICE in save_con_fun_n, at caller-save.c:1389
--- Comment #3 from vmakarov at redhat dot com 2008-07-07 18:21 --- The case when saving mode or saving pseudo are different in the data-flow equation was missed when the save/restore placement optimization was written. Fortunately, the case was catched by the assertion. The patch solving the problem will follow soon. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36673
[Bug rtl-optimization/36673] IRA -O3 -fno-pic ICE in save_con_fun_n, at caller-save.c:1389
--- Comment #4 from vmakarov at gcc dot gnu dot org 2008-07-07 18:22 --- Subject: Bug 36673 Author: vmakarov Date: Mon Jul 7 18:21:28 2008 New Revision: 137585 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137585 Log: 2008-07-07 Vladimir Makarov [EMAIL PROTECTED] PR target/36673 * caller-saves.c (restore_con_fun_n, save_con_fun_n): Clear the result if mode or pseudo is different. Modified: branches/ira/gcc/ChangeLog branches/ira/gcc/caller-save.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36673
[Bug rtl-optimization/36663] IRA ICE in save_call_clobbered_regs at caller-save.c:1949
--- Comment #2 from vmakarov at gcc dot gnu dot org 2008-07-07 18:29 --- Subject: Bug 36663 Author: vmakarov Date: Mon Jul 7 18:28:37 2008 New Revision: 137586 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137586 Log: 2008-07-07 Vladimir Makarov [EMAIL PROTECTED] PR target/36663 * caller-saves.c (free_con_fun_n): Use liveness info. Modified: branches/ira/gcc/ChangeLog branches/ira/gcc/caller-save.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36663
[Bug other/36752] assembler error and segfault when compiling a wine 1.0 souce program with -O2
--- Comment #2 from johnlumby at hotmail dot com 2008-07-07 18:29 --- Created an attachment (id=15873) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15873action=view) core dump -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36752
[Bug rtl-optimization/36663] IRA ICE in save_call_clobbered_regs at caller-save.c:1949
--- Comment #3 from vmakarov at redhat dot com 2008-07-07 18:30 --- Liveness info was missed in data-flow equation calculation for set free when the save/restore placement optimization was written. Fortunately, the case was catched by an assertion. The patch solving the problem has been submitted (please see above). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36663
[Bug other/36752] assembler error and segfault when compiling a wine 1.0 souce program with -O2
--- Comment #3 from johnlumby at hotmail dot com 2008-07-07 18:33 --- Subject: RE: assembler error and segfault when compiling a wine 1.0 souce program with -O2 Well, good question. I started off trying to report it to redhat , but the redhat bugzilla page asks what component, and none correspond to gcc ,so I then came here. If you want me to send it to redhat, let me know what to enter on the redhat bugzilla. Do you not think this is a gcc bug? John Date: Mon, 7 Jul 2008 18:18:32 + Subject: [Bug other/36752] assembler error and segfault when compiling a wine 1.0 souce program with -O2 To: [EMAIL PROTECTED] From: [EMAIL PROTECTED] --- Comment #1 from pinskia at gcc dot gnu dot org 2008-07-07 18:18 --- --with-bugurl=http://bugzilla.redhat.com/bugzilla Why are you reporting this bug to us, when it says to report it to redhat? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |other Summary|assembler error and segfault|assembler error and segfault |when compiling a wine 1.0 |when compiling a wine 1.0 |souce program with -O2 |souce program with -O2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36752 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. _ Try Chicktionary, a game that tests how many words you can form from the letters given. Find this and more puzzles at Live Search Games! http://g.msn.ca/ca55/207 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36752
[Bug fortran/36751] assignment between allocatable arrays of different size causes glibc error
--- Comment #2 from dominiq at lps dot ens dot fr 2008-07-07 18:37 --- I don't see that on ppc/intel Darwin9, but the following modified code gives at run time: PROGRAM repro IMPLICIT NONE REAL(KIND=8), ALLOCATABLE :: a2(:,:), a(:,:) INTEGER(KIND=4) :: i, m, n m = 4 n = 3 ALLOCATE(a(m,n)) a = reshape((/(i,i=1,m*n)/),(/m,n/)) n = n - 1 ALLOCATE(a2(m,n)) ! this is the problematic assignment: is this legal?? a2 = a print *, a2 print *, shape(a), shape(a2) deallocate(a2) END PROGRAM repro [karma] f90/bug% gfc pr36751_db.f90 [karma] f90/bug% a.out 1.02.3. 4.5.6. 7.8. 4 3 4 2 a.out(39419) malloc: *** error for object 0x2006b0: incorrect checksum for freed object - object was probably modified after being freed. *** set a breakpoint in malloc_error_break to debug a.out(39419) malloc: *** error for object 0x200670: incorrect checksum for freed object - object was probably modified after being freed. *** set a breakpoint in malloc_error_break to debug I am not sure the code is valid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36751
[Bug middle-end/36583] [4.3/4.4 Regression] ICE on 5282/5206 at -O2
--- Comment #3 from eric dot norum at usask dot ca 2008-07-07 18:41 --- When I compile for an MC68040 target I don't get the fault. So the problem may be in the ColdFire-specific parts of the compiler. /usr/local/rtems/rtems-4.9/bin/m68k-rtems4.9-gcc --pipe -B/usr/local/rtems/rtems-4.9/m68k-rtems4.9/mvme167/lib/ -specs bsp_specs -qrtems -fasm -c -mcpu=68040 -DUNIX-ansi -O2 -g -fno-omit-frame-pointer -g -Wall -DRTEMS_NETWORK_CONFIG_DNS_DOMAINNAME=aps.anl.gov -DRTEMS_NETWORK_CONFIG_DNS_DOMAINNAME=aps.anl.gov -I. -I../O.Common -I. -I.. -I../../../include/os/RTEMS -I../../../include ../dbAccess.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36583
[Bug target/34780] Bootstrapping libstdc++-v3 failed
--- Comment #11 from rwild at gcc dot gnu dot org 2008-07-07 18:55 --- The reported failure is fixed. However, building with --enable-maintainer-mode still fails due to this error, already described in http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00452.html: bin/sh ../libtool --tag CXX --mode=compile /tmp/gcc/build/./gcc/xgcc -shared-libgcc -B/tmp/gcc/build/./gcc -nostdinc++ -L/tmp/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/tmp/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/tmp/gcc-test/x86_64-unknown-linux-gnu/bin/ -B/tmp/gcc-test/x86_64-unknown-linux-gnu/lib/ -isystem /tmp/gcc-test/x86_64-unknown-linux-gnu/include -isystem /tmp/gcc-test/x86_64-unknown-linux-gnu/sys-include -I/tmp/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/tmp/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include -I/tmp/gcc/gcc/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Werror -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE-c -o locale_init.lo ../../../../gcc/libstdc++-v3/src/locale_init.cc libtool: compile: /tmp/gcc/build/./gcc/xgcc -shared-libgcc -B/tmp/gcc/build/./gcc -nostdinc++ -L/tmp/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/tmp/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/tmp/gcc-test/x86_64-unknown-linux-gnu/bin/ -B/tmp/gcc-test/x86_64-unknown-linux-gnu/lib/ -isystem /tmp/gcc-test/x86_64-unknown-linux-gnu/include -isystem /tmp/gcc-test/x86_64-unknown-linux-gnu/sys-include -I/tmp/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/tmp/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include -I/tmp/gcc/gcc/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Werror -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -c ../../../../gcc/libstdc++-v3/src/locale_init.cc -fPIC -DPIC -o .libs/locale_init.o cc1plus: warnings being treated as errors ../../../../gcc/libstdc++-v3/src/locale_init.cc: In static member function 'static const std::locale std::locale::classic()': ../../../../gcc/libstdc++-v3/src/locale_init.cc:247: error: dereferencing type-punned pointer will break strict-aliasing rules make[2]: *** [locale_init.lo] Error 1 make[2]: Leaving directory `/tmp/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/tmp/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3' make: *** [all] Error 2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34780
[Bug c++/35396] possible incorrect optimization due to missed dependency
--- Comment #3 from hjl dot tools at gmail dot com 2008-07-07 19:00 ---
The testcase is invalid. Please try
#define DECL_CMPSWP(S,T,X) \
static inline T machine_cmpswp##S (volatile void *ptr, T value, T comparand ) \
{ \
T result; \
\
__asm__ __volatile__(lock\ncmpxchg X %2,%1 \
: =a(result), =m(*(T *)ptr) \
: q(value), m (*(T *)ptr), 0(comparand)); \
return result; \
}
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35396
[Bug c/36753] New: Forward propagation interacts badly with global register variable
The attached test case is supposed to print '31337' when run.
Correct output:
[EMAIL PROTECTED] factor]$ gcc -O1 testcase.c
[EMAIL PROTECTED] factor]$ ./a.out
31337
Correct output:
[EMAIL PROTECTED] factor]$ gcc -O2 -fno-forward-propagate testcase.c
[EMAIL PROTECTED] factor]$ ./a.out
31337
*Incorrect* output:
[EMAIL PROTECTED] factor]$ gcc -O2 testcase.c
[EMAIL PROTECTED] factor]$ ./a.out
0
We can plainly see the problem in the disassemble for the broken() function.
With -O2 -fno-forward-propagate,
broken:
leaq8(%r14), %rax
movq%rax, %r14
movq$31337, (%rax)
ret
With -O2:
broken:
addq$8, %r14
movq$31337, 8(%r14)
ret
===
#include stdbool.h
#include stdio.h
register unsigned long *ds asm(r14);
__attribute__((noinline)) void broken(bool value)
{
*++ds = 31337;
}
int main()
{
unsigned long stack[2];
stack[0] = 0;
stack[1] = 0;
ds = stack;
broken(true);
printf(%ld\n,*ds);
}
===
--
Summary: Forward propagation interacts badly with global register
variable
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: slava at factorcode dot org
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=36753
[Bug middle-end/36753] Forward propagation interacts badly with global register variable
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|major |normal Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36753
[Bug middle-end/36753] [4.3/4.4 Regression] Forward propagation interacts badly with global register variable
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-07-07 19:26 --- global register should really not be used anyways :). They are an example of a bad extension. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code Summary|Forward propagation |[4.3/4.4 Regression] Forward |interacts badly with global |propagation interacts badly |register variable |with global register ||variable Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36753
[Bug target/36701] [4.4 Regression] unaligned access in gcc.c-torture/execute/complex-7.c
--- Comment #5 from hjl dot tools at gmail dot com 2008-07-07 19:37 ---
A small testcase:
[EMAIL PROTECTED] good]$ cat ../complex-7.c
volatile _Complex float f1 = 1.1f + 2.2if;
volatile _Complex float f2 = 3.3f + 4.4if;
volatile _Complex float f3 = 5.5f + 6.6if;
volatile _Complex float f4 = 7.7f + 8.8if;
volatile _Complex float f5 = 9.9f + 10.1if;
extern void abort (void);
extern void exit (int);
__attribute__((noinline)) void
check_float (int a, _Complex float a1, _Complex float a2,
_Complex float a3, _Complex float a4, _Complex float a5)
{
if (a1 != f1 || a2 != f2 || a3 != f3 || a4 != f4 || a5 != f5)
abort ();
}
int
main (void)
{
check_float (0, f1, f2, f3, f4, f5);
exit (0);
}
[EMAIL PROTECTED] good]$
diff -upr bad/complex-7.c.133r.expand good/complex-7.c.133r.expand
--- bad/complex-7.c.133r.expand 2008-07-07 12:33:14.0 -0700
+++ good/complex-7.c.133r.expand2008-07-07 12:33:40.0 -0700
@@ -5,115 +5,115 @@
;; Generating RTL for tree basic block 2
;; D.1272 = REALPART_EXPR a1
-(insn 62 61 63 ../complex-7.c:14 (set (reg:DI 419)
+(insn 42 41 43 ../complex-7.c:14 (set (reg:DI 401)
(reg/f:DI 335 virtual-stack-vars)) -1 (nil))
-(insn 63 62 64 ../complex-7.c:14 (set (reg/f:DI 420)
+(insn 43 42 44 ../complex-7.c:14 (set (reg/f:DI 402)
(plus:DI (reg/f:DI 335 virtual-stack-vars)
-(const_int 4 [0x4]))) -1 (nil))
+(const_int 8 [0x8]))) -1 (nil))
-(insn 64 63 0 ../complex-7.c:14 (set (reg:SF 373 [ D.1272 ])
-(mem/s/c:SF (reg/f:DI 420) [0 a1+0 S4 A32])) -1 (nil))
+(insn 44 43 0 ../complex-7.c:14 (set (reg:SF 373 [ D.1272 ])
+(mem/s/c:SF (reg/f:DI 402) [0 a1+0 S4 A64])) -1 (nil))
The alignment of the first argument passed on stack is wrong.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36701
[Bug fortran/36029] Off-by-one runtime bounds checking message
-- burnus at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||27766 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-07-07 19:38:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36029
[Bug fortran/36754] New: Compile-time bound-checking for allocatable arrays with known bonds
The following bounds problem is not detected with gfortran at compile time (it is at run time): integer,allocatable :: a(:) integer :: b(1) allocate(a(12)) b = a(1:12) end Expected: The same output as NAG f95 has: Error: a.f90, line 4: Different vector lengths (1 and 12) -- Summary: Compile-time bound-checking for allocatable arrays with known bonds Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org OtherBugsDependingO 27766 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36754
[Bug libfortran/34670] bounds checking for array intrinsics
--- Comment #7 from tkoenig at gcc dot gnu dot org 2008-07-07 19:44 --- Subject: Bug 34670 Author: tkoenig Date: Mon Jul 7 19:43:33 2008 New Revision: 137594 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137594 Log: 2008-07-07 Thomas Koenig [EMAIL PROTECTED] PR fortran/36341 PR fortran/34670 * m4/matmul.m4: Add bounds checking. * m4/matmull.m4: Likewise. * generated/matmul_c10.c: Regenerated. * generated/matmul_c16.c: Regenerated. * generated/matmul_c4.c: Regenerated. * generated/matmul_c8.c: Regenerated. * generated/matmul_i1.c: Regenerated. * generated/matmul_i16.c: Regenerated. * generated/matmul_i2.c: Regenerated. * generated/matmul_i4.c: Regenerated. * generated/matmul_i8.c: Regenerated. * generated/matmul_l16.c: Regenerated. * generated/matmul_l4.c: Regenerated. * generated/matmul_l8.c: Regenerated. * generated/matmul_r10.c: Regenerated. * generated/matmul_r16.c: Regenerated. * generated/matmul_r4.c: Regenerated. * generated/matmul_r8.c: Regenerated. 2008-07-07 Thomas Koenig [EMAIL PROTECTED] PR fortran/36341 PR fortran/34670 * gfortran.dg/matmul_bounds_2.f90: New test. * gfortran.dg/matmul_bounds_3.f90: New test. * gfortran.dg/matmul_bounds_4.f90: New test. * gfortran.dg/matmul_bounds_5.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/matmul_bounds_2.f90 trunk/gcc/testsuite/gfortran.dg/matmul_bounds_3.f90 trunk/gcc/testsuite/gfortran.dg/matmul_bounds_4.f90 trunk/gcc/testsuite/gfortran.dg/matmul_bounds_5.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/generated/matmul_c10.c trunk/libgfortran/generated/matmul_c16.c trunk/libgfortran/generated/matmul_c4.c trunk/libgfortran/generated/matmul_c8.c trunk/libgfortran/generated/matmul_i1.c trunk/libgfortran/generated/matmul_i16.c trunk/libgfortran/generated/matmul_i2.c trunk/libgfortran/generated/matmul_i4.c trunk/libgfortran/generated/matmul_i8.c trunk/libgfortran/generated/matmul_l16.c trunk/libgfortran/generated/matmul_l4.c trunk/libgfortran/generated/matmul_l8.c trunk/libgfortran/generated/matmul_r10.c trunk/libgfortran/generated/matmul_r16.c trunk/libgfortran/generated/matmul_r4.c trunk/libgfortran/generated/matmul_r8.c trunk/libgfortran/m4/matmul.m4 trunk/libgfortran/m4/matmull.m4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34670
[Bug fortran/36341] MATMUL: Bounds check missing (run time)
--- Comment #15 from tkoenig at gcc dot gnu dot org 2008-07-07 19:44 --- Subject: Bug 36341 Author: tkoenig Date: Mon Jul 7 19:43:33 2008 New Revision: 137594 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137594 Log: 2008-07-07 Thomas Koenig [EMAIL PROTECTED] PR fortran/36341 PR fortran/34670 * m4/matmul.m4: Add bounds checking. * m4/matmull.m4: Likewise. * generated/matmul_c10.c: Regenerated. * generated/matmul_c16.c: Regenerated. * generated/matmul_c4.c: Regenerated. * generated/matmul_c8.c: Regenerated. * generated/matmul_i1.c: Regenerated. * generated/matmul_i16.c: Regenerated. * generated/matmul_i2.c: Regenerated. * generated/matmul_i4.c: Regenerated. * generated/matmul_i8.c: Regenerated. * generated/matmul_l16.c: Regenerated. * generated/matmul_l4.c: Regenerated. * generated/matmul_l8.c: Regenerated. * generated/matmul_r10.c: Regenerated. * generated/matmul_r16.c: Regenerated. * generated/matmul_r4.c: Regenerated. * generated/matmul_r8.c: Regenerated. 2008-07-07 Thomas Koenig [EMAIL PROTECTED] PR fortran/36341 PR fortran/34670 * gfortran.dg/matmul_bounds_2.f90: New test. * gfortran.dg/matmul_bounds_3.f90: New test. * gfortran.dg/matmul_bounds_4.f90: New test. * gfortran.dg/matmul_bounds_5.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/matmul_bounds_2.f90 trunk/gcc/testsuite/gfortran.dg/matmul_bounds_3.f90 trunk/gcc/testsuite/gfortran.dg/matmul_bounds_4.f90 trunk/gcc/testsuite/gfortran.dg/matmul_bounds_5.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/generated/matmul_c10.c trunk/libgfortran/generated/matmul_c16.c trunk/libgfortran/generated/matmul_c4.c trunk/libgfortran/generated/matmul_c8.c trunk/libgfortran/generated/matmul_i1.c trunk/libgfortran/generated/matmul_i16.c trunk/libgfortran/generated/matmul_i2.c trunk/libgfortran/generated/matmul_i4.c trunk/libgfortran/generated/matmul_i8.c trunk/libgfortran/generated/matmul_l16.c trunk/libgfortran/generated/matmul_l4.c trunk/libgfortran/generated/matmul_l8.c trunk/libgfortran/generated/matmul_r10.c trunk/libgfortran/generated/matmul_r16.c trunk/libgfortran/generated/matmul_r4.c trunk/libgfortran/generated/matmul_r8.c trunk/libgfortran/m4/matmul.m4 trunk/libgfortran/m4/matmull.m4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36341
[Bug fortran/36670] Missing compile-time checks on sum and product
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-07-07 19:46 --- Subject: Bug 36670 Author: tkoenig Date: Mon Jul 7 19:45:55 2008 New Revision: 137595 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137595 Log: 2008-07-07 Thomas Koenig [EMAIL PROTECTED] PR fortran/36670 * iresolve.c (gfc_resolve_product): Set shape of return value from array. (gfc_resolve_sum): Likewise. 2008-07-07 Thomas Koenig [EMAIL PROTECTED] PR fortran/36670 * gfortran.dg/product_sum_bounds_1.f90: New test case. Added: trunk/gcc/testsuite/gfortran.dg/product_sum_bounds_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/iresolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36670
[Bug fortran/36341] MATMUL: Bounds check missing
--- Comment #16 from tkoenig at gcc dot gnu dot org 2008-07-07 19:47 --- Fixed both for compile-time and run-time on trunk. Closing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|MATMUL: Bounds check missing|MATMUL: Bounds check missing |(run time) | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36341
[Bug fortran/36670] Missing compile-time checks on sum and product
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-07-07 19:48 --- Fixed on trunk. Closing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36670
[Bug fortran/36754] Compile-time bound-checking for allocatable arrays with known bonds
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-07-07 19:51 --- Confirmed. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-07-07 19:51:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36754
[Bug fortran/36754] Compile-time bound-checking for allocatable arrays with known bonds
--- Comment #2 from dominiq at lps dot ens dot fr 2008-07-07 19:57 --- Confirmed. How do I get: pr36754.f90:4.1: b = a(1:12) 1 Error: Different shape for array assignment at (1) on dimension 1 (1 and 12) ? I don't have that many patches left. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36754
[Bug c++/34963] [4.3/4.4 regression] ICE completely broken destructor
--- Comment #4 from simartin at gcc dot gnu dot org 2008-07-07 20:42 --- Subject: Bug 34963 Author: simartin Date: Mon Jul 7 20:42:03 2008 New Revision: 137598 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137598 Log: gcc/cp/ 2008-07-07 Simon Martin [EMAIL PROTECTED] PR c++/34963 * decl.c (grokdeclarator): Reset storage_class and staticp for friend functions declared with a storage class qualifier. gcc/testsuite/ 2008-07-07 Simon Martin [EMAIL PROTECTED] PR c++/34963 * g++.dg/parse/dtor13.C: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/parse/dtor13.C Modified: branches/gcc-4_3-branch/gcc/cp/ChangeLog branches/gcc-4_3-branch/gcc/cp/decl.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34963
[Bug libfortran/36755] New: Avoid fork/exec in chmod intrinsic
The chmod intrinsic should be implemented with chmod () instead of fork/exec. -- Summary: Avoid fork/exec in chmod intrinsic Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libfortran 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=36755
[Bug libfortran/36755] Avoid fork/exec in chmod intrinsic
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-07-07 21:00 --- Why is really an issue anyways? chmod should not be used too much anyways. -- 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=36755
[Bug target/36756] New: g++.dg/tls-3.C ICE with section-anchors, unit-at-a-time, no-toplevel-reorder
Test g++.dg/gomp/tls-3.C started failing on powerpc-unknown-linux-gnu with an
ICE in rs6000_emit_move when the -O0 defaults were changed for
-funit-at-a-time, -fsection-anchors, and -ftop-level-reorder. This smaller C
test:
__thread int i;
int
foo ()
{
static __thread int k;
return k;
}
gets the same ICE for earlier compilers back to 4.2.0 (when section anchors
were added) when compiled with -funit-at-a-time -fsection-anchors
-fno-toplevel-reorder.
--
Summary: g++.dg/tls-3.C ICE with section-anchors, unit-at-a-time,
no-toplevel-reorder
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org
GCC target triplet: powerpc-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36756
[Bug middle-end/36757] New: __builtin_signbit should be type-generic
The function __builtin_signbit should be type-generic so that libraries can define the standard signbit macro with #define signbit(x) __builtin_signbit(x). (Mentioned several times before in the context of discussions of the other type-generic built-in functions, but doesn't seem to be filed in Bugzilla at present.) It's necessary to avoid the type-generic signbit expanding to call a library function that may not exist, but as all currently supported floating-point formats do have a sign bit specified in signbit_ro I believe the case of failing to expand inline can be made into an abort. -- Summary: __builtin_signbit should be type-generic Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36757
[Bug middle-end/36758] New: address addition moved out of the loop
Take the following testcase:
extern int f0(int *);
void
f1()
{
int x;
while (f0(x));
}
-- CUT ---
Currently GCC produces:
addi 31,1,112
.p2align 3,,7
.L2:
mr 3,31
bl f0
nop
cmpdi 7,3,0
bne 7,.L2
Notice how there is mr 3, 31 inside the loop. At least on the Cell, the mr and
addi both have the same cycle count so we should not be moving the addition
outside of the loop. This will save at least one volatile register which
should reduce code size. This is a definite win for code size.
--
Summary: address addition moved out of the loop
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: powerpc*-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36758
[Bug middle-end/36758] [4.3/4.4 Regression] address addition moved out of the loop
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-07-07 21:36 --- 4.1.1 actually did the right thing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.3.0 4.4.0 Known to work||4.1.1 Summary|address addition moved out |[4.3/4.4 Regression] address |of the loop |addition moved out of the ||loop Target Milestone|--- |4.3.2 Version|unknown |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36758
[Bug fortran/36759] New: C_LOC and characters greater then one in length.
When I compile the code: PROGRAM main USE, INTRINSIC :: ISO_C_BINDING IMPLICIT NONE CHARACTER(LEN=2), TARGET :: arg1 = '12' TYPE(c_ptr) :: A A = c_loc(arg1) END PROGRAM main I get the error: A = c_loc(arg1) 1 Error: CHARACTER argument 'arg1' to 'c_loc' at (1) must have a length of 1 I'm not sure where this restriction comes from (it's not part of the standard). All the other fortran compilers (at least g95, ifort, and pgf90) support character LEN 1. Actually they support CHARACTER(LEN=*) when declared in a subroutine. -- Summary: C_LOC and characters greater then one in length. Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brtnfld at hdfgroup dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36759
[Bug middle-end/36758] [4.3/4.4 Regression] address addition moved out of the loop
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-07-07 21:51 --- (In reply to comment #1) 4.1.1 actually did the right thing. That is it produced: .L.f1: mflr 0 std 0,16(1) stdu 1,-128(1) .p2align 4,,15 .L3: addi 3,1,112 bl f0 nop cmpdi 7,3,0 bne 7,.L3 addi 1,1,128 ld 0,16(1) mtlr 0 blr .long 0 .byte 0,0,0,1,128,0,0,0 .size f1,.-.L.f1 .ident GCC: (GNU) 4.1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36758
[Bug target/36756] g++.dg/tls-3.C ICE with section-anchors, unit-at-a-time, no-toplevel-reorder
--- Comment #1 from janis at gcc dot gnu dot org 2008-07-07 21:59 --- There's an ICE in the same place for libgomp.fortran/appendix_a/a.22.7.f90. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36756
[Bug target/36701] [4.4 Regression] unaligned access in gcc.c-torture/execute/complex-7.c
--- Comment #6 from hjl dot tools at gmail dot com 2008-07-07 22:25 ---
assign_parm_remove_parallels:
if (GET_CODE (entry_parm) == PARALLEL GET_MODE (entry_parm) != BLKmode)
{
rtx parmreg = gen_reg_rtx (GET_MODE (entry_parm));
emit_group_store (parmreg, entry_parm, NULL_TREE,
GET_MODE_SIZE (GET_MODE (entry_parm)));
entry_parm = parmreg;
}
is incorrect for ia64 HFA. You can't do
rtx parmreg = gen_reg_rtx (GET_MODE (entry_parm));
when entry_parm is HFA passed in GR:
(parallel:SC [
(expr_list:REG_DEP_TRUE (reg:DI 117 in5 [ a5 ])
(const_int 0 [0x0]))
])
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36701
[Bug target/36701] [4.4 Regression] unaligned access in gcc.c-torture/execute/complex-7.c
--- Comment #7 from drow at gcc dot gnu dot org 2008-07-07 22:31 --- Subject: Re: [4.4 Regression] unaligned access in gcc.c-torture/execute/complex-7.c On Mon, Jul 07, 2008 at 10:25:08PM -, hjl dot tools at gmail dot com wrote: is incorrect for ia64 HFA. You can't do rtx parmreg = gen_reg_rtx (GET_MODE (entry_parm)); when entry_parm is HFA passed in GR: What does HFA mean? Why can't you copy it into a reg:SC? This shouldn't change the incoming location of the argument; it's generating code at the start of the function to retrieve the argument. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36701
[Bug target/36736] [4.3 Regression] gfortran unrecognizable insn on sh4
--- Comment #7 from kkojima at gcc dot gnu dot org 2008-07-07 22:31 --- Subject: Bug 36736 Author: kkojima Date: Mon Jul 7 22:30:53 2008 New Revision: 137602 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137602 Log: Backport from mainline: PR target/36736 2008-02-29 Kaz Kojima [EMAIL PROTECTED] * config/sh/sh.c (sh_secondary_reload): Handle loading a float constant to fpul. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/config/sh/sh.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36736
[Bug middle-end/36753] [4.3/4.4 Regression] Forward propagation interacts badly with global register variable
--- Comment #2 from schlieper at unc dot edu 2008-07-07 22:38 --- If it's a bad language extension, why is it implemented? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36753
[Bug middle-end/36753] [4.3/4.4 Regression] Forward propagation interacts badly with global register variable
--- Comment #3 from slava at factorcode dot org 2008-07-07 22:41 --- So is this extension bad/deprecated or not? I'd appreciate a clarification from the gcc team. If the resolution is that this feature should simply not be used, I would strongly suggest removing it. Otherwise I'm not sure what to think; do I invest the effort in refactoring my code to not rely on this extension, or can I count on it being supported going forward? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36753
[Bug fortran/36759] C_LOC and characters greater then one in length.
--- Comment #1 from burnus at gcc dot gnu dot org 2008-07-07 22:41 --- A = c_loc(arg1) 1 Error: CHARACTER argument 'arg1' to 'c_loc' at (1) must have a length of 1 I'm not sure where this restriction comes from (it's not part of the standard). One could argue that one should allow it as vendor extension, however, the restriction is in the standard: Interoperability of intrinsic types A Fortran intrinsic type with particular type parameter values is interoperable with a C type if the type and kind type parameter value are listed in the table on the same row as that C type; if the type is character, interoperability also requires that the length type parameter be omitted or be specified by an initialization expression whose value is one. For interoperability one thus should use instead of character(len=2) :: str rather character(len=1,kind=c_char) :: str(2) (This is also the case for dummy arguments of BIND(C) procedures, though there one can as pass a string as actual argument, cf. storage sequence.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36759
[Bug middle-end/36753] [4.3/4.4 Regression] Forward propagation interacts badly with global register variable
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-07-07 22:42 --- (In reply to comment #2) If it's a bad language extension, why is it implemented? Because someone thought it was nice but it really hard to get correct as it changes the ABI. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36753
[Bug fortran/36754] Compile-time bound-checking for allocatable arrays with known bonds
--- Comment #3 from burnus at gcc dot gnu dot org 2008-07-07 22:46 --- b = a(1:12) Error: Different shape for array assignment at (1) on dimension 1 (1 and 12) ? I don't have that many patches left. Hmm, I currently get the same (with all gfortrans I have). I really wonder why I did not get this before. Let me recheck tomorrow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36754
[Bug c++/36760] New: Simple std::bind use causes warnings with -Wextra
Consider:
#include functional
void f() {}
void g() { std::bind(f)(); }
Compiling this with g++-svn -c -std=c++0x -Wextra gives:
In file included from
/home/eelis/soft/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../include/c++/4.4.0/functional:75,
from t.cpp:1:
/home/eelis/soft/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../include/c++/4.4.0/tr1_impl/functional:
In function void g():
/home/eelis/soft/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../include/c++/4.4.0/tr1_impl/functional:1226:
warning: type qualifiers ignored on function return type
/home/eelis/soft/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../include/c++/4.4.0/tr1_impl/functional:1213:
warning: type qualifiers ignored on function return type
/home/eelis/soft/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../include/c++/4.4.0/tr1_impl/functional:1201:
warning: type qualifiers ignored on function return type
--
Summary: Simple std::bind use causes warnings with -Wextra
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36760
[Bug c++/36641] erroneous ambiguous error for subclasses overloaded templated interfaces
--- Comment #2 from bangerth at dealii dot org 2008-07-07 23:17 --- Yes, the code is indeed ambiguous. Both icc and pgCC also agree. W. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36641
[Bug c++/36628] [c++0x] incorrect decltype() handling of conditional operator
--- Comment #3 from dgregor at gcc dot gnu dot org 2008-07-07 23:28 --- The problem here is that fold() is simplifying the expression before we look at its type. The simplification here turns something that's not a function call (a conditional expression) into a function call, thereby triggering a different branch in the decltype code (which returns the return type of a function being called). -- dgregor at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-07-07 23:28:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36628
[Bug c++/36699] not compile code, but must
--- Comment #1 from bangerth at dealii dot org 2008-07-07 23:30 --- Not a bug: type arguments to templates need to be *named* types with external linkage. The declaration of 'x' uses an unnamed structure, the declaration of 'z' a type of function-scope (and so internal) linkage. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36699
[Bug c++/36760] Simple std::bind use causes warnings with -Wextra
--- Comment #1 from paolo dot carlini at oracle dot com 2008-07-07 23:35 --- Doug, I'm sorry, can you have a look to this one too? I'm slightly confused, we have PR 36052, and then PR 30601, ... Seems that the warning is intended?!? Do we have to change bind?!? -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||doug dot gregor at gmail dot ||com, paolo dot carlini at ||oracle dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36760
[Bug c++/36749] sizeof returns 0 for class
--- Comment #5 from bangerth at dealii dot org 2008-07-07 23:36 --- Zero-sized arrays are a GNU extension to the C++ standard. Since the compiler can't know the size of the object, sizeof returns zero. This behavior is documented in the Extensions part of the GCC manual, in the Arrays of Length Zero section. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36749
[Bug c++/36749] sizeof returns 0 for class
--- Comment #6 from paolo dot carlini at oracle dot com 2008-07-07 23:40 --- I see, thanks Wolfgang, I didn't check -pedantic, my bad... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36749
[Bug target/36701] [4.4 Regression] unaligned access in gcc.c-torture/execute/complex-7.c
--- Comment #8 from hjl dot tools at gmail dot com 2008-07-08 01:19 ---
HFA stands for homogeneous floating point aggregates as specified in
IA-64 Software Conventions and Runtime Architecture Guide. To pass
complex float, if we run out of available FP argument registers,
we will pass it in GP register. For a simple testcase:
---
extern _Complex float f5;
int
check_float (int a, _Complex float a1, _Complex float a2,
_Complex float a3, _Complex float a4, _Complex float a5)
{
return (a5 != f5);
}
---
(gdb) call debug_rtx (entry_parm)
(parallel:SC [
(expr_list:REG_DEP_TRUE (reg:DI 117 in5 [ a5 ])
(const_int 0 [0x0]))
])
Here DI is 64bit with 8byte alignment.
rtx parmreg = gen_reg_rtx (GET_MODE (entry_parm));
turns it into
(concat:SC (reg:SF 380)
(reg:SF 381))
It has 4 byte alignment.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36701
[Bug c++/36760] Simple std::bind use causes warnings with -Wextra
--- Comment #2 from paolo dot carlini at oracle dot com 2008-07-08 01:40 --- By the way, apparently, even after the fix for c++/32256 and c++/32368, warnings keep coming from inside the system headers... Any idea why, Tom? Another case would be this one: http://gcc.gnu.org/ml/libstdc++/2008-06/msg00080.html Is it because these warnings are really spuriously coming from the middle-end per the audit trail of the latter issue, PR 36633 ? Thus, assuming we generically want this warning (as I understand from the audit trails of PR 30601), the real issue is fixing the C++ front-end to not pass bogus stuff to the middle-end? Or the two issues are different? One final remark: if we add -Wsystem-headers to the command line *many* more type qualifiers ignored warning are emitted, a tiny part somehow escapes... -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||manu at gcc dot gnu dot org, ||tromey at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-07-08 01:40:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36760
[Bug c++/36760] Simple std::bind use causes warnings with -Wextra
--- Comment #3 from paolo dot carlini at oracle dot com 2008-07-08 02:02 --- Or this pure C++ case is really just a missing TREE_NO_WARNING set somewhere (check_return_expr?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36760
[Bug c++/36760] Simple std::bind use causes warnings with -Wextra
--- Comment #4 from tromey at gcc dot gnu dot org 2008-07-08 02:45 --- My guess is that comment #3 is the right theory, because this warning is issued from the front end. I did not investigate deeply though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36760
