[Bug target/49411] [4.6/4.7] ICE: unrecognizable insn with -mxop in _mm_roti_epi8 with negative number
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49411 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-15 06:32:20 UTC --- Created attachment 24533 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24533 gcc47-pr49411.patch Untested fix. Alternatively, we could for the rotation instead just always mask the immediate operand (the only docs I found about these intrinsics was MSFT documentation which didn't say anything on invalid count, but even said that the count is preferrably an integer instead of unconditionally an integer). Therefore, perhaps we could mask it if it is constant and expand using rotlmode3 expander if it is not CONST_INT.
[Bug inline-asm/49410] Internal compiler error in change-stack at reg-stack.c:2540
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49410 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX --- Comment #1 from Uros Bizjak ubizjak at gmail dot com 2011-06-15 07:04:50 UTC --- asm( fldpi; fmulp; fsqrt : =t (x) : 0 (n) : st(1)); Actually, ICE on invalid code, but this is how gcc says that something is wrong with x87 asm.
[Bug target/49349] gfortran.dg/char_result_3.f90 fails with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49349 --- Comment #3 from Alexander Monakov amonakov at gcc dot gnu.org 2011-06-15 08:08:32 UTC --- Author: amonakov Date: Wed Jun 15 08:08:27 2011 New Revision: 175075 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175075 Log: PR target/49349 * sel-sched.c (find_place_for_bookkeeping): Add new parameter (fence_to_rewind). Use it to notice when bookkeeping will be placed above a fence. Update comments. (generate_bookkeeping_insn): Rewind fence when bookkeeping code is placed just above it. Do not allow NULL place_to_insert. Modified: trunk/gcc/ChangeLog trunk/gcc/sel-sched.c
[Bug target/49349] gfortran.dg/char_result_3.f90 fails with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49349 Alexander Monakov amonakov at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Alexander Monakov amonakov at gcc dot gnu.org 2011-06-15 08:09:06 UTC --- Fixed.
[Bug fortran/49416] New: wrong -fbounds-check with 2 dimensional arrays reshape
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49416 Summary: wrong -fbounds-check with 2 dimensional arrays reshape Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: koval.pe...@gmail.com The bug arises when -fbounds-check option and reshape intrinsic are used. gfortran --version GNU Fortran (Ubuntu 4.4.3-4ubuntu5) 4.4.3 Copyright (C) 2010 Free Software Foundation, Inc. The program below results in a runtime error (when compiled with -fbounds-check option), although it runs normally without -fbounds-check option. program check_reshape implicit none real(8), allocatable :: a(:,:) allocate(a(2,-2:2)) write(6,*) reshape(a, (/ 10 /)) end program !check_reshape
[Bug fortran/49416] wrong -fbounds-check with 2 dimensional arrays reshape
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49416 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-06-15 08:40:10 UTC --- Works with version 4.5.2, 4.6.0, and trunk, but not with version 4.4.4.
[Bug fortran/45129] I/O edit descriptors: Warn if the format field is too small for the E and F edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45129 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2011-06-15 08:55:00 UTC --- (In reply to comment #4) The question is whether the warning should be only printed if the problem definitely occurs or only if it likely [...] In this case, ifort prints with -stand f03: The field width is too small for the number of fractional digits. ifort 12.0 changed the warning to a remark (printed by default): remark #8291: Recommended relationship between field width 'W' and the number of fractional digits 'D' in this edit descriptor is 'W=D+7'. 1000FORMAT(e10.4) remark #8290: Recommended relationship between field width 'W' and the number of fractional digits 'D' in this edit descriptor is 'W=D+3'. 22 Format (F2.2)
[Bug fortran/49417] New: [4.6/4.7 Regression] [OOP] ICE on invalid CLASS component declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49417 Summary: [4.6/4.7 Regression] [OOP] ICE on invalid CLASS component declaration Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org Reported by Andrew Benson at http://gcc.gnu.org/ml/fortran/2011-06/msg00119.html: module Nodes type :: nodeWrapper end type nodeWrapper type, extends(nodeWrapper) :: treeNode class(nodeWrapper) :: subComponent end type treeNode end module Nodes ICEs with 4.6 and 4.7 trunk, while it is correctly rejected with 4.5.
[Bug debug/49382] -O2 -g: DW_AT_location at the very first PC is already modified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49382 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-15 09:56:36 UTC --- Author: jakub Date: Wed Jun 15 09:56:33 2011 New Revision: 175076 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175076 Log: PR debug/49382 * dwarf2out.c (dw_loc_list_node): Add force field. (add_var_loc_to_decl): For PARM_DECL, attempt to keep the incoming location in the list, even if it is modified before first real insn. (output_loc_list): Emit empty ranges with force flag set. (dw_loc_list): If first range of a PARM_DECL is empty, set force flag. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c
[Bug bootstrap/49415] [4.7 Regression] Revision 175071 fails to bootstrap on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49415 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug debug/49382] -O2 -g: DW_AT_location at the very first PC is already modified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49382 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-15 09:59:15 UTC --- Should be fixed on the trunk.
[Bug c++/49409] some possible new warnings for strange code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49409 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2011.06.15 10:03:26 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-15 10:03:26 UTC --- confirmed.
[Bug fortran/49417] [4.6/4.7 Regression] [OOP] ICE on invalid CLASS component declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49417 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code CC||burnus at gcc dot gnu.org Target Milestone|--- |4.6.1 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-06-15 10:15:25 UTC --- ==15300== Invalid read of size 1 ==15300==at 0x502B83: parse_spec (parse.c:2110) ==15300==by 0x503B42: gfc_parse_file (parse.c:4113) ==15300==by 0x53D3F5: gfc_be_parse_file (f95-lang.c:250) Which is parse_derived's (!) 2109 default: 2110 unexpected_statement (st);
[Bug bootstrap/49415] [4.7 Regression] Revision 175071 fails to bootstrap on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49415 --- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot com 2011-06-15 10:31:50 UTC --- On Wed, 15 Jun 2011, dominiq at lps dot ens.fr wrote: ../../work/gcc/config/darwin-protos.h:57:51: error: ISO C forbids forward references to 'enum' types [-Werror=edantic] ../../work/gcc/config/darwin-protos.h:58:11: error: 'enum machine_mode' declared inside parameter list [-Werror] ../../work/gcc/config/darwin-protos.h:58:11: error: its scope is only this definition or declaration, which is probably not what you want [-Werror] Please try wrapping the problem prototype in #ifdef RTX_CODE, like some other prototypes in that header. (Including machmode.h in i386-common.c might cause other problems, and certainly would be against modularity. Ideally tm.h and tm_p.h would be split into common parts and parts used only in the compiler proper, but that's a long way off.)
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #99 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-06-15 10:32:08 UTC --- New build failure with gold and gcc 4.7.0 20110615: ake[6]: Entering directory `/var/tmp/mozilla-central/moz-build-dir/js/src/shell' js.cpp c++ -o js.o -c -I../../../dist/system_wrappers_js -include /var/tmp/mozilla-central/js/src/config/gcc_hidden.h -DEXPORT_JS_API -DOSTYPE=\Linux3.0\ -DOSARCH=Linux -I/var/tmp/mozilla-central/js/src -I.. -I/var/tmp/mozilla-central/js/src/shell -I. -I../../../dist/include -I../../../dist/include/nsprpub -I/var/tmp/mozilla-central/moz-build-dir/dist/include/nspr-fPIC -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros -Werror=return-type -pedantic -Wno-long-long -march=native -ffunction-sections -fdata-sections -fno-strict-aliasing -pthread -pipe -DNDEBUG -DTRIMMED -fprofile-generate -O3 -DMOZILLA_CLIENT -include ../js-confdefs.h -MD -MF .deps/js.pp /var/tmp/mozilla-central/js/src/shell/js.cpp jsworkers.cpp c++ -o jsworkers.o -c -I../../../dist/system_wrappers_js -include /var/tmp/mozilla-central/js/src/config/gcc_hidden.h -DEXPORT_JS_API -DOSTYPE=\Linux3.0\ -DOSARCH=Linux -I/var/tmp/mozilla-central/js/src -I.. -I/var/tmp/mozilla-central/js/src/shell -I. -I../../../dist/include -I../../../dist/include/nsprpub -I/var/tmp/mozilla-central/moz-build-dir/dist/include/nspr-fPIC -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros -Werror=return-type -pedantic -Wno-long-long -march=native -ffunction-sections -fdata-sections -fno-strict-aliasing -pthread -pipe -DNDEBUG -DTRIMMED -fprofile-generate -O3 -DMOZILLA_CLIENT -include ../js-confdefs.h -MD -MF .deps/jsworkers.pp /var/tmp/mozilla-central/js/src/shell/jsworkers.cpp /var/tmp/mozilla-central/js/src/shell/jsworkers.cpp: In member function ‘void js::workers::MainQueue::destroy(JSContext*)’: /var/tmp/mozilla-central/js/src/shell/jsworkers.cpp:371:16: warning: deleting object of polymorphic class type ‘js::workers::MainQueue’ which has non-virtual destructor might cause undefined behaviour [-Wdelete-non-virtual-dtor] /var/tmp/mozilla-central/js/src/shell/jsworkers.cpp: In member function ‘bool js::workers::ThreadPool::start(JSContext*)’: /var/tmp/mozilla-central/js/src/shell/jsworkers.cpp:511:20: warning: deleting object of polymorphic class type ‘js::workers::WorkerQueue’ which has non-virtual destructor might cause undefined behaviour [-Wdelete-non-virtual-dtor] /var/tmp/mozilla-central/js/src/shell/jsworkers.cpp: In member function ‘void js::workers::ThreadPool::shutdown(JSContext*)’: /var/tmp/mozilla-central/js/src/shell/jsworkers.cpp:548:16: warning: deleting object of polymorphic class type ‘js::workers::WorkerQueue’ which has non-virtual destructor might cause undefined behaviour [-Wdelete-non-virtual-dtor] /var/tmp/mozilla-central/js/src/shell/jsworkers.cpp: In static member function ‘static void js::workers::Worker::jsFinalize(JSContext*, JSObject*)’: /var/tmp/mozilla-central/js/src/shell/jsworkers.cpp:690:20: warning: deleting object of polymorphic class type ‘js::workers::Worker’ which has non-virtual destructor might cause undefined behaviour [-Wdelete-non-virtual-dtor] /var/tmp/mozilla-central/js/src/shell/jsworkers.cpp: In static member function ‘static js::workers::Worker* js::workers::Worker::create(JSContext*, js::workers::WorkerParent*, JSString*, JSObject*)’: /var/tmp/mozilla-central/js/src/shell/jsworkers.cpp:1073:16: warning: deleting object of polymorphic class type ‘js::workers::Worker’ which has non-virtual destructor might cause undefined behaviour [-Wdelete-non-virtual-dtor] In file included from /var/tmp/mozilla-central/js/src/shell/js.cpp:97:0: /var/tmp/mozilla-central/js/src/jsobjinlines.h: In member function ‘void JSObject::setArrayLength(uint32)’: /var/tmp/mozilla-central/js/src/jsobjinlines.h:367:24: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] /usr/bin/python2.7 /var/tmp/mozilla-central/js/src/config/pythonpath.py -I../config /var/tmp/mozilla-central/js/src/config/expandlibs_exec.py --uselist -- c++ -o js -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros -Werror=return-type -pedantic -Wno-long-long -march=native -ffunction-sections -fdata-sections -fno-strict-aliasing -pthread -pipe -DNDEBUG -DTRIMMED -fprofile-generate -O3 js.o jsworkers.o -lpthread -fprofile-generate -Wl,-rpath-link,/bin -Wl,-rpath-link,/var/tmp/mozilla-central/moz-build-dir/dist/lib -L../../../dist/bin -L../../../dist/lib -L/var/tmp/mozilla-central/moz-build-dir/dist/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl ../editline/libeditline.a
[Bug tree-optimization/49318] [4.7 Regression] 177.mesa in SPEC CPU 2000 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49318 Ira Rosen irar at il dot ibm.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Ira Rosen irar at il dot ibm.com 2011-06-15 10:45:17 UTC --- Fixed.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #100 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-06-15 10:44:52 UTC --- Please note that this error only happens during a profiled build. Normal build seems to be OK.
[Bug c++/49418] New: openmp default(none) in template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49418 Summary: openmp default(none) in template function Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: gcc-...@safetymail.info Compilation fails, if within a template function a const argument is used within an openmp parallel region with default(none). If shared(x) is specified also a predetermined 'shared' error is produced. Error: $ g++ -fopenmp pf.cc pf.cc: In function 'void g(T)': pf.cc:11:45: error: 'x' is predetermined 'shared' for 'shared' pf.cc: In function 'void f(T) [with T = int]': pf.cc:5:8: error: 'x' not specified in enclosing parallel pf.cc:5:8: error: enclosing parallel pf.cc: In function 'void g(T) [with T = int]': pf.cc:12:8: error: 'x' not specified in enclosing parallel pf.cc:12:8: error: enclosing parallel Version: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/home/me/gcc/libexec/gcc/i686-pc-cygwin/4.6.0/lto-wrapper.exe Target: i686-pc-cygwin Configured with: ./configure --enable-languages=c,c++ --prefix=/home/me/gcc --enable-libgomp Thread model: single gcc version 4.6.0 (GCC)
[Bug c++/49418] openmp default(none) in template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49418 --- Comment #1 from gcc-bug at safetymail dot info 2011-06-15 11:07:12 UTC --- Created attachment 24534 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24534 test case
[Bug target/49419] New: [4.6/4.7 regression] gcc -O2 miscompiles gp2c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49419
Summary: [4.6/4.7 regression] gcc -O2 miscompiles gp2c
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@ubuntu.com
[forwarded from http://bugs.debian.org/630567]
fails with -O2/-O3, works with -O1/-Os with 20110611 4.6 branch, 20110531
trunk, apparently on {powerpc,mips,mipsel,s390}-linux.
gcc-4.6 miscompiles gp2c on several platforms including powerpc, see
https://buildd.debian.org/status/package.php?p=gp2c
On powerpc (32 bit):
The function 'listostack' in src/utils.c is miscompiled with -O2.
Please find a testcase.
gcc-4.6 -O2 -Wall gccbug.c -o gccbug ./gccbug
zsh: segmentation fault ./gccbug
gcc-4.6 -O1 -Wall gccbug.c -o gccbug ./gccbug
nb=2
0: 1
1: 2
#include stdio.h
#include stdlib.h
typedef struct
{
enum {LEAF=0, NODE=1} f;/*node function*/
int x; /*node left child*/
int y; /*node right child*/
} node;
node *tree;
int listtostack(int n, int f, int *stack, int nbmax)
{
int x,i,nb;
if (n==-1) return 0;
for(x=n,i=0;tree[x].f==f inbmax;x=tree[x].x,i++);
if (i==nbmax)
exit(1);
nb=i+1;
for(x=n;i0;stack[i]=tree[x].y,x=tree[x].x,i--);
stack[0]=x;
return nb;
}
#define STACKSZ 3
int main(void)
{
int stack[STACKSZ];
int i,nb;
tree = (node *)calloc(STACKSZ,sizeof(node));
tree[0].f = NODE;
tree[0].x = 1;
tree[0].y = 2;
nb=listtostack(0,1,stack,STACKSZ);
printf(nb=%d\n,nb);
for(i=0;inb;i++)
printf(%d: %d\n,i,stack[i]);
return 0;
}
[Bug tree-optimization/48613] [4.6/4.7 Regression] ICE: vector VEC(ipa_node_params_t,base) index domain error with -O0 -flto -findirect-inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48613 --- Comment #6 from Martin Jambor jamborm at gcc dot gnu.org 2011-06-15 11:22:38 UTC --- Author: jamborm Date: Wed Jun 15 11:22:35 2011 New Revision: 175077 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175077 Log: 2011-06-15 Martin Jambor mjam...@suse.cz PR tree-optimization/48613 * ipa-prop.c (ipa_prop_write_jump_functions): Return immediately if ipa_node_params_vector is NULL. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-prop.c
[Bug target/49385] Invalid RTL intstruction for ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49385 --- Comment #3 from revital.eres at linaro dot org 2011-06-15 11:26:32 UTC --- (In reply to comment #0) Created attachment 24504 [details] The test to reproduce the RTL instruction. I see the following invalid mem to mem RTL instruction in test2.c.189r.sched1 btw, the first dump file which contains this invalid mem-mem instruction is combine.
[Bug c++/49420] New: [C++0x] compiler segfault using result_of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49420 Summary: [C++0x] compiler segfault using result_of Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: jarr...@cse.unsw.edu.au Created attachment 24535 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24535 result of segfaults The compiler segfaults in the attached code. It uses result_of of a struct which has an operator() with a return type defined by recursive instantiations of decltype. g++ --std=gnu++0x result_of_segfault.ii ‘ In file included from result_of_segfault.cpp:1:0: /home/jarryd/current/soft/install-latest/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/type_traits: In instantiation of ‘std::_Result_of_implfalse, false, array_get, A, int, int, int’: /home/jarryd/current/soft/install-latest/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/type_traits:1806:12: required from ‘struct std::result_ofarray_get(A, int, int, int)’ result_of_segfault.cpp:33:33: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/home/jarryd/current/soft/install-latest/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /home/jarryd/current/soft/src/gcc-svn/configure --prefix=/home/jarryd/current/soft/install-latest --disable-multilib --enable-languages=c,c++,go : (reconfigured) /home/jarryd/current/soft/src/gcc-svn/configure --prefix=/home/jarryd/current/soft/install-latest --disable-multilib --enable-languages=c,c++,go,lto --no-create --no-recursion : (reconfigured) /home/jarryd/current/soft/src/gcc-svn/configure --prefix=/home/jarryd/current/soft/install-latest --disable-multilib --enable-languages=c,c++,go,lto --no-create --no-recursion Thread model: posix gcc version 4.7.0 20110615 (experimental) (GCC)
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #101 from Mike Hommey mh+gcc at glandium dot org 2011-06-15 11:38:01 UTC --- (In reply to comment #100) Please note that this error only happens during a profiled build. Normal build seems to be OK. FWIW: https://bugzilla.mozilla.org/show_bug.cgi?id=664387
[Bug target/49419] [4.6/4.7 regression] gcc -O2 miscompiles gp2c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49419 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.1
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #102 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-06-15 11:44:22 UTC --- Jan, this is caused by: commit 8c1fce46fc02e43e82b05f49894690133a1bcdcf Author: hubicka hubicka@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Fri Jun 10 20:06:48 2011 + Reverting the commit fixes the problem.
[Bug target/49419] [4.6/4.7 regression] gcc -O2 miscompiles gp2c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49419 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2011-06-15 11:54:27 UTC --- Same breakage also seen on m68k-linux.
[Bug target/49419] [4.6/4.7 regression] gcc -O2 miscompiles gp2c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49419 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-15 11:55:40 UTC --- Confirmed, seems VRP2 removes changes the for(x=n;i0;stack[i]=tree[x].y,x=tree[x].x,i--); loop into endless loop. Looking into it.
[Bug fortran/49417] [4.6/4.7 Regression] [OOP] ICE on invalid CLASS component declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49417 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.06.15 11:56:15 AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org |gnu.org | Target Milestone|4.6.1 |--- Ever Confirmed|0 |1 --- Comment #2 from janus at gcc dot gnu.org 2011-06-15 11:56:15 UTC --- Mine (I'm working on a patch). Apparently we fail to check for the 'class_ok' attribute.
[Bug target/49421] New: [arm] suboptimal choice of working regs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49421
Summary: [arm] suboptimal choice of working regs
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ph...@gnu.org
If a leaf function requires one more working register than can be accomodated
in the call-clobbered set, gcc currently tends to push r4 and use that next.
However, in the specific case of a leaf function, it would be better to push lr
and use that as the working register, since then the return can be done with a
single pop. Consider the made-up example:
int f(int *a, int *b, int *c, int *d)
{
int i;
for (i = 0; i 4; i++)
if (a[i] || b[i] || c[i] || d[i])
return 1;
return 0;
}
which compiles (-march=armv6 -mtune=arm1136jf-s -O2) to:
f:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
movip, #0
strr4, [sp, #-4]!
.L3:
ldrr4, [r0, ip]
cmpr4, #0
bne.L7
ldrr4, [r1, ip]
cmpr4, #0
bne.L7
ldrr4, [r2, ip]
cmpr4, #0
bne.L7
ldrr4, [r3, ip]
addip, ip, #4
cmpr4, #0
bne.L7
cmpip, #16
bne.L3
movr0, r4
.L2:
ldmfdsp!, {r4}
bxlr
.L7:
movr0, #1
b.L2
If lr had been pushed instead of r4 then the return could have simply been pop
{lr}.
Also, since this is arm11, it is no more expensive to push two words than one.
If the compiler had stacked both r4 and lr, it would have freed up an extra
register for the loop which would probably have allowed the loads to be
scheduled better.
[Bug target/49419] [4.6/4.7 regression] gcc -O2 miscompiles gp2c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49419
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-15
12:19:00 UTC ---
So, i_47 which is the i value on entry of the second loop is determined to be
[0, +INF(OVF)] and something goes wrong afterwards. The bug will be there, but
I should note that VRP should easily prove that i never overflows.
Simpler testcases for that:
void bar (void);
void foo (int x, int y)
{
if (x y)
{
if (x == __INT_MAX__)
bar ();
}
}
void baz (int x, int y, int z)
{
if (x y || x z)
{
if (x == __INT_MAX__)
bar ();
}
}
Here IMNSHO vrp should optimize the call to bar away, as when x is smaller than
some variable of the same type, it can't be the maximum of that type, because
even if the other number is __INT_MAX__, x must be smaller than that.
[Bug target/49419] [4.6/4.7 regression] gcc -O2 miscompiles gp2c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49419
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-15
12:29:51 UTC ---
Perhaps even for:
void bar (void);
int test (int);
int fn (int x, int y)
{
int i;
for (i = 0; i y test (i); i++)
;
if (i == y)
return;
if (i == __INT_MAX__)
bar ();
}
we should be able to determine that bar can't be called. In the loop body
i is known to be i y, after the loop i = y but the i == y test rules out the
equality again, so we end up again with i y which is certainly i
__INT_MAX__.
[Bug bootstrap/49415] [4.7 Regression] Revision 175071 fails to bootstrap on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49415 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-06-15 12:33:06 UTC --- Please try wrapping the problem prototype in #ifdef RTX_CODE, like some other prototypes in that header. --- /opt/gcc/_clean/gcc/config/darwin-protos.h2011-04-06 13:56:07.0 +0200 +++ /opt/gcc/work/gcc/config/darwin-protos.h2011-06-15 13:34:23.0 +0200 @@ -54,8 +54,11 @@ extern void machopic_finish (FILE *); extern int machopic_reloc_rw_mask (void); extern section *machopic_select_section (tree, int, unsigned HOST_WIDE_INT); + +#ifdef RTX_CODE extern section *machopic_select_rtx_section (enum machine_mode, rtx, unsigned HOST_WIDE_INT); +#endif /* RTX_CODE */ extern section *darwin_function_section (tree, enum node_frequency, bool, bool); extern void darwin_function_switched_text_sections (FILE *, tree, bool); I am now at stage3 (1.5 hour more to go for full bootstrap).
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #103 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-06-15 12:34:20 UTC --- Even with 8c1fce46fc0 reverted libxul fails to link during a profiledbuild. Normal build is fine. with bfd: /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld: ../../layout/ipc/RenderFrameParent.o: relocation R_X86_64_PC32 against undefined hidden symbol `nsRefPtrmozilla::layers::ImageContainer::~nsRefPtr()' can not be used when making a shared object /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: Bad value with gold: /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: /var/tmp/mozilla-central/moz-build-dir/toolkit/library/../../layout/ipc/RenderFrameParent.o: requires dynamic reloc which may overflow at runtime; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: /var/tmp/mozilla-central/moz-build-dir/toolkit/library/../../content/events/src/nsEventStateManager.o: requires dynamic reloc which may overflow at runtime; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: /var/tmp/mozilla-central/moz-build-dir/toolkit/library/../../content/xul/templates/src/nsRuleNetwork.o: requires dynamic reloc which may overflow at runtime; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: /var/tmp/mozilla-central/moz-build-dir/toolkit/library/../../gfx/thebes/GLContextProviderGLX.o: requires dynamic reloc which may overflow at runtime; recompile with -fPIC /var/tmp/mozilla-central/moz-build-dir/toolkit/library/../../intl/uconv/ucvlatin/nsUnicodeToUCS2BE.o:nsUnicodeToUCS2BE.cpp:function vtable for nsUnicodeToUTF16BE: warning: relocation refers to discarded section /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: hidden symbol 'nsUnicodeToUTF16BE::~nsUnicodeToUTF16BE()' is not defined locally /var/tmp/mozilla-central/moz-build-dir/toolkit/library/../../intl/uconv/ucvlatin/nsUnicodeToUCS2BE.o:nsUnicodeToUCS2BE.cpp:function vtable for nsUnicodeToUTF16LE: warning: relocation refers to discarded section /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: hidden symbol 'nsUnicodeToUTF16LE::~nsUnicodeToUTF16LE()' is not defined locally /var/tmp/mozilla-central/moz-build-dir/toolkit/library/../../intl/uconv/ucvcn/nsGBKToUnicode.o:nsGBKToUnicode.cpp:function vtable for nsGBKToUnicode: warning: relocation refers to discarded section /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: hidden symbol 'nsGBKToUnicode::~nsGBKToUnicode()' is not defined locally /var/tmp/mozilla-central/moz-build-dir/toolkit/library/../../intl/uconv/ucvcn/nsGBKToUnicode.o:nsGBKToUnicode.cpp:function vtable for nsGB18030ToUnicode: warning: relocation refers to discarded section /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: hidden symbol 'nsGB18030ToUnicode::~nsGB18030ToUnicode()' is not defined locally /var/tmp/mozilla-central/moz-build-dir/toolkit/library/../../parser/htmlparser/src/nsHTMLTokens.o:nsHTMLTokens.cpp:function vtable for CAttributeToken: warning: relocation refers to discarded section /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: hidden symbol 'CAttributeToken::~CAttributeToken()' is not defined locally /var/tmp/mozilla-central/moz-build-dir/toolkit/library/../../layout/generic/nsGfxScrollFrame.o:nsGfxScrollFrame.cpp:function vtable for nsHTMLScrollFrame: warning: relocation refers to discarded section ...
[Bug fortran/49417] [4.6/4.7 Regression] [OOP] ICE on invalid CLASS component declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49417 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.1
[Bug middle-end/27226] [4.1 Regression] Compiler looses track of alignment for emit_block_move
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27226 niva at niisi dot msk.ru changed: What|Removed |Added CC||niva at niisi dot msk.ru --- Comment #19 from niva at niisi dot msk.ru 2011-06-15 12:46:58 UTC --- (In reply to comment #18) Fixed. I tried to checkout rev 117018 from svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch/ and build the compiler configured as follows: Configured with: /home/niva/tests/gcc-117018/configure --target=mips64-none-elf --enable-threads=no --disable-shared --enable-long-long --enable-c99 --enable-languages=c --enable-multilib --enable-symvers=gnu --disable-libmudflap --disable-libssp --disable-libgcc_eh --with-newlib --with-dwarf2 --with-system-zlib --enable-checking=release --enable-generated-files-in-srcdir --verbose --prefix=/home/niva/local --srcdir=/home/niva/tests/gcc-117018 --enable-cpp I've compiled the file memcpy-1.c: mips64-none-elf-gcc memcpy-1.c -O2 -fno-show-column -S -o memcpy-1.s117018 and got the assembler code with lbu instructions: lui $3,%hi($LC0+2) addiu $2,$3,%lo($LC0+2) lbu $5,%lo($LC0+2)($3) lbu $4,5($2) lbu $6,1($2) lbu $7,2($2) lbu $8,3($2) lbu $9,4($2) Eventually this bug was not fixed in gcc-4.1.2. But the compiler built in the same way from the trunk (r116641) generated the code with lhu instructions: lui $2,%hi($LC0+2) addiu $3,$2,%lo($LC0+2) lhu $5,%lo($LC0+2)($2) lhu $4,4($3) lhu $6,2($3) lui $2,%hi(c) addiu $3,$2,%lo(c) sh $4,4($3) sh $5,%lo(c)($2) j $31 sh $6,2($3) Probably some significant changes from trunk were not applied to gcc-4_1-branch.
[Bug c++/49412] __dso_handle should be hidden
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49412 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-06/msg01153.htm ||l --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2011-06-15 13:14:08 UTC --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01153.html
[Bug target/49422] New: [arm] unable to find a register to spill in class 'VFP_LO_REGS'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49422
Summary: [arm] unable to find a register to spill in class
'VFP_LO_REGS'
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ph...@gnu.org
Target: arm-linux
Created attachment 24536
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24536
testcase
$ arm-oe-linux-gnueabi-gcc -fPIC -mfpu=vfp -O2 s_span.i -march=armv6j
-mtune=arm1136jf-s -mfloat-abi=softfp -ffast-math -S
swrast/s_span.c: In function '_swrast_write_rgba_span':
swrast/s_span.c:1297:1: error: unable to find a register to spill in class
'VFP_LO_REGS'
swrast/s_span.c:1297:1: error: this is the insn:
(insn 2389 2380 3422 269 (set (subreg:SI (reg:QI 2169) 0)
(unsigned_fix:SI (fix:SF (reg/v:SF 78 s15 [orig:685 a ] [685]
swrast/s_span.c:867 670 {fixuns_truncsfsi2}
(expr_list:REG_DEAD (reg/v:SF 78 s15 [orig:685 a ] [685])
(nil)))
swrast/s_span.c:1297: confused by earlier errors, bailing out
$
[Bug bootstrap/49415] [4.7 Regression] Revision 175071 fails to bootstrap on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49415 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-06-15 13:47:43 UTC --- I have bootstrapped revision 175077 with the patch in comment #2.
[Bug target/49423] New: [arm] internal compiler error: in push_minipool_fix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423 Summary: [arm] internal compiler error: in push_minipool_fix Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: ph...@gnu.org $ arm-oe-linux-gnueabi-gcc -march=armv7-a -O2 -S -mfloat-abi=softfp -mfpu=vfp svga_tgsi_insn.i svga_tgsi_insn.c: In function 'svga_shader_emit_instructions': svga_tgsi_insn.c:2969:1: internal compiler error: in push_minipool_fix, at config/arm/arm.c:12138 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. $
[Bug target/49423] [arm] internal compiler error: in push_minipool_fix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423 --- Comment #1 from philb at gnu dot org 2011-06-15 13:50:23 UTC --- Created attachment 24537 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24537 testcase
[Bug lto/49424] New: ICE in lhd_set_decl_assembler_name at langhooks.c:158 with '-flto'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49424
Summary: ICE in lhd_set_decl_assembler_name at langhooks.c:158
with '-flto'
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jason.vas.d...@gmail.com
When building qt-4.7.1 (from git: git://anongit.kde.org/qt-kde.git )
with GCC 4.6.0, built unmodified source in gcc-4.6.0.tar.bz2, on a
Linux x86_64 platform ( binutils: 2.21.51.20110407 glibc:2.13 kernel: 2.38.8.8)
g++ suffers an internal compiler error when compiling Qt's
qt-kde/src/3rdparty/javascriptcore/JavaScriptCore/API/JSStringRef.cpp :
...
/usr/bin/g++ -c -march=x86-64 -mtune=k8 -O2 -g -pipe -flto -Wall -Wreturn-type
-fno-strict-aliasing -Wcast-align -Wchar-subscripts -Wformat-security
-Wreturn-type -Wno-unused-parameter -Wno-sign-compare -Wno-switch
-Wno-switch-enum -Wundef -Wmissing-noreturn -Winit-self -fno-stack-protector -g
-fvisibility=hidden -fvisibility-inlines-hidden -D_REENTRANT -fPIC ...
src/3rdparty/javascriptcore/JavaScriptCore/API/JSStringRef.cpp
/usr/x/kde/4.1/KDE/qt-kde/src/3rdparty/javascriptcore/JavaScriptCore/API/JSStringRef.cpp:
In function 'JSStringGetUTF8CString':
/usr/x/kde/4.1/KDE/qt-kde/src/3rdparty/javascriptcore/JavaScriptCore/API/JSStringRef.cpp:112:1:
internal compiler error: in lhd_set_decl_assembler_name, at langhooks.c:158
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
When I remove the '-flto' option, this ICE does not occur and the compilation
succeeds .
Line 112 of that source file is the end of file :
bool JSStringIsEqualToUTF8CString(JSStringRef a, const char* b)
{
JSStringRef bBuf = JSStringCreateWithUTF8CString(b);
bool result = JSStringIsEqual(a, bBuf);
JSStringRelease(bBuf);
return result;
} // this is line 112
// FILE ENDS
If you need any more info here, let me know.
Thanks Regards, Jason
[Bug libstdc++/37477] [Core 475] std::uncaught_exception() returns wrong value after entering terminate() in some cases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37477 --- Comment #7 from Maxime van Noppen maxime at altribe dot org 2011-06-15 14:15:38 UTC --- Created attachment 24538 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24538 Exhibits uncaught return values
[Bug libstdc++/37477] [Core 475] std::uncaught_exception() returns wrong value after entering terminate() in some cases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37477 Maxime van Noppen maxime at altribe dot org changed: What|Removed |Added CC||maxime at altribe dot org --- Comment #8 from Maxime van Noppen maxime at altribe dot org 2011-06-15 14:16:38 UTC --- I just attached a testcase which seems likely related to this bug. Tested with g++ (GCC) 4.6.0 20110603 on x86_64 linux.
[Bug debug/48459] [4.6/4.7 Regression] avr: Assertion failure with -gdwarf-2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48459 --- Comment #26 from Richard Henderson rth at gcc dot gnu.org 2011-06-15 14:40:58 UTC --- (In reply to comment #25) (Assuming that backporting implies the emission of DWARF2 CFI) Is it not possible to drop DWARF2 CFI feature (which is optional) and still make 4.6x build successful? It is quite possible that some target might want to do this. Um. Why? This is not using dwarf2 cfi for unwinding; that is still using setjmp. This is using dwarf2 cfi for debugging, which is exactly what you asked for when you said -gdwarf-2. If you mean the assembler .cfi directives, you do not need that in order for the build to succeed. But that is detected at configure time; if you have an assembler that accepts them we will emit them, otherwise we'll emit the cfi data as .byte. If you mean something else, I don't know what it is.
[Bug lto/49424] ICE in lhd_set_decl_assembler_name at langhooks.c:158 with '-flto'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49424 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-15 14:48:04 UTC --- This is fixed on the 4.6 branch. *** This bug has been marked as a duplicate of bug 48207 ***
[Bug debug/48207] ICE in lhd_set_decl_assembler_name, at langhooks.c:158
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48207 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||jason.vas.dias at gmail dot ||com --- Comment #12 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-15 14:48:04 UTC --- *** Bug 49424 has been marked as a duplicate of this bug. ***
[Bug target/49392] [arm] spurious EABI version mismatches when LTO enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49392 philb at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from philb at gnu dot org 2011-06-15 14:57:32 UTC --- I just tried a different linker and that does seem to have made the problem go away. So I guess there is no gcc bug here. Thanks.
[Bug target/49419] [4.6/4.7 regression] gcc -O2 miscompiles gp2c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49419 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-15 14:59:50 UTC --- Anyway, the bug is elsewhere, in particular I'd say the bug is that we use the normal SSA_NAME as init value of the second loop instead of the SSA_NAME initialized from ASSERT_EXPR for that. The interesting stmts are: # iD.1254_47 = PHI [pr49419.c : 15:67] iD.1254_70(6), [pr49419.c : 15:67] iD.1254_69(8), 0(3), 0(21) ... iD.1254_86 = ASSERT_EXPR iD.1254_47, iD.1254_47 != nbmaxD.1250_17(D); ... iD.1254_85 = ASSERT_EXPR iD.1254_86, iD.1254_86 0; ... # iD.1254_50 = PHI [pr49419.c : 19:60] iD.1254_40(18), iD.1254_85(12) and the second loop sees i_85 as the initial value. Now, first the i_47 setter is walked, with just one of the edges with value 0 executable, so i_47 has [0, 0] range there. Then i_86 is walked, and as var's range is VR_RANGE, while limit range is VR_ANTI_RANGE, surprisingly symbolic range ~[nbmax_17(D), nbmax_17(D)] wins. I'd think [0, 0] would be much better to return, both because it is not symbolic, is quite narrow and is range instead of anti range. After a while, i_50 stmt is walked several times, including using adjust_range_with_scev, which uses i_47 instead of i_85 as init for some reason. At that point it sees it has [0, 0] range and so computes something from that. After a while, i_47 stmt is visited several times, last time resulting into [0, +INF(OVF)] range (see other comments that it ought to be improved, but uninteresting for this bug). So, the PHI setting i_47 is returning SSA_PROP_INTERESTING, which results in all succ edges of that bb to be marked for revisiting. We revisit i_86 stmt, but that again returns the same (uninteresting) ~[nbmax_17(D), nbmax_17(D)] range, which also means that it is SSA_PROP_NOT_INTERESTING. That bb contains just: [pr49419.c : 18:6] nbD.1255_24 = iD.1254_86 + 1; [pr49419.c : 19:3] if (iD.1254_86 0) after it, but as i_86's VR didn't change, no other VRs in that bb change either, which means none of the succ bb's of this bb are queued for revisiting. So, I think we should arrange for the actual current ASSERT_EXPR SSA_NAME to be used as init during scev if possible, instead of the original one, and furthermore I believe extract_range_from_assert_expr should do a better job.
[Bug target/49411] [4.6/4.7] ICE: unrecognizable insn with -mxop in _mm_roti_epi8 with negative number
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49411 --- Comment #4 from Quentin Neill qneill at gcc dot gnu.org 2011-06-15 15:38:27 UTC --- Hi Jakub, Thanks for looking at this. I think we need an nargs==3 case for the Compare/Predicate generation (_mm_com*) intrinsics as well. And did you mean to test the value of INTVAL(op) in the nargs==4 vpermil case before throwing an error? -- Quentin
[Bug c++/49412] __dso_handle should be hidden
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49412 --- Comment #3 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-06-15 15:50:28 UTC --- Author: hjl Date: Wed Jun 15 15:50:22 2011 New Revision: 175080 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175080 Log: Mark __dso_handle hidden if assembler supports it. 2011-06-15 H.J. Lu hongjiu...@intel.com PR c++/49412 * decl.c (get_dso_handle_node): Mark __dso_handle hidden if assembler supports hidden visibility. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c
[Bug target/49411] [4.6/4.7] ICE: unrecognizable insn with -mxop in _mm_roti_epi8 with negative number
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49411 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-15 15:57:29 UTC --- FYI, a newer patch has been posted: http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01139.html I don't think it is necessary to test the op of vpermil again if it is CONST_INT, we know it is not 0..3 because otherwise insn_data[icode].operand[i + 1].predicate (op, mode) would be true. _mm_com* don't seem to have an constant argument, just two vector arguments, so there is nothing to check. The immediate comes directly from the table and so is known to be ok.
[Bug c++/49412] __dso_handle should be hidden
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49412 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2011-06-15 16:02:12 UTC --- Fixed.
[Bug tree-optimization/49419] [4.6/4.7 regression] gcc -O2 miscompiles gp2c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49419 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.06.15 16:02:59 Component|target |tree-optimization Ever Confirmed|0 |1
[Bug c++/49420] [C++0x] compiler segfault using result_of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49420 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.06.15 16:16:05 CC||jason at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug driver/49371] xgcc: error: unrecognized option '-pie' on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49371 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||ramana.radhakrishnan at arm ||dot com, robertcnelson at ||gmail dot com --- Comment #30 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-06-15 16:17:48 UTC --- It seems to affect also armv7l-unknown-linux-gnueabi (see http://gcc.gnu.org/ml/gcc-testresults/2011-06/msg01644.html ).
[Bug target/49411] [4.6/4.7] ICE: unrecognizable insn with -mxop in _mm_roti_epi8 with negative number
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49411 --- Comment #6 from Quentin Neill qneill at gcc dot gnu.org 2011-06-15 16:39:47 UTC --- (In reply to comment #5) newer patch has been posted Thanks; I will test this on AMD HW. test the op of vpermil Okay. _mm_com* I spotted them in the opcode tables, but had forgotten how those work. I'm looking into lwpval/ins, bextr (there is an immediate) and vcvtps*
[Bug ada/49425] New: ACATS test C974008 fails if run after test C761011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49425
Summary: ACATS test C974008 fails if run after test C761011
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tero.koski...@iki.fi
ACATS test C974008 fails when it is run after test C761011 in a same process.
Testcase:
#!/bin/sh
wget -c http://www.ada-auth.org/acats-files/3.0/acats_30.tar.Z
tar zxf acats_30.tar.Z
cp support/{repbody.ada,repspec.ada} .
cp ./c7/c761011.a ./c9/c974008.a .
gnatchop -w *.a
cat test3.adbEOF
with c761011;
with c974008; -- c974009 also fails
procedure test3 is
begin
c761011;
c974008;
end;
EOF
cat impdef.adsEOF
package impdef is
Switch_To_New_Task : constant Duration := 0.001;
end;
EOF
gnatmake test3
./test3
##ENDOFTESTCASE
Actual output:
,.,. C761011 ACATS 3.0 11-06-15 19:35:32
C761011 Check that if a finalize propagates an exception, other
finalizes due to be performed are performed.
- C761011 Finalization of normal object.
- C761011 Finalization of anonymous object.
- C761011 Finalization because of exit of loop.
- C761011 Finalization because of goto statement.
- C761011 Finalization because of return statement.
- C761011 Finalization because of exception propagation.
C761011 PASSED .
,.,. C974008 ACATS 3.0 11-06-15 19:35:32
C974008 Asynchronous Select: Trigger is a call to a waiting task
entry and completes immediately.
* C974008 Abortable part started.
C974008 FAILED .
Expected output:
,.,. C761011 ACATS 3.0 11-06-15 19:35:32
C761011 Check that if a finalize propagates an exception, other
finalizes due to be performed are performed.
- C761011 Finalization of normal object.
- C761011 Finalization of anonymous object.
- C761011 Finalization because of exit of loop.
- C761011 Finalization because of goto statement.
- C761011 Finalization because of return statement.
- C761011 Finalization because of exception propagation.
C761011 PASSED .
,.,. C974008 ACATS 3.0 11-06-15 19:35:24
C974008 Asynchronous Select: Trigger is a call to a waiting task
entry and completes immediately.
C974008 PASSED .
I have tested this on Fedora 15/i386 with GCC 4.6.0 from Fedora packages:
$ gnatls -v
GNATLS 4.6.0 20110530 (Red Hat 4.6.0-9)
...
$
[Bug target/44618] [4.4/4.5/4.6 regression] wrong code with -frename-registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44618 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Summary|[4.4/4.5/4.6/4.7|[4.4/4.5/4.6 regression] |regression] wrong code with |wrong code with |-frename-registers |-frename-registers --- Comment #26 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-15 16:44:12 UTC --- Committed to the trunk so far apparently: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174997
[Bug c++/49399] [C++0x] substitution failure error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49399 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jason at gcc dot gnu.org Resolution||INVALID --- Comment #10 from Jason Merrill jason at gcc dot gnu.org 2011-06-15 16:47:02 UTC --- Closing. Feel free to open a bug report requesting implementation of DR 1170.
[Bug rtl-optimization/44194] struct returned by value generates useless stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #20 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-06-15 16:48:45 UTC --- Fixed on trunk. Thanks for tackling this, Easwaran.
[Bug rtl-optimization/49414] gcc.dg/pr44194-1.c fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49414 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.06.15 16:52:22 CC||ebotcazou at gcc dot ||gnu.org Target Milestone|--- |4.7.0 Summary|gcc.dg/pr44194-1.c failed |gcc.dg/pr44194-1.c fails Ever Confirmed|0 |1 --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-06-15 16:52:22 UTC --- Indeed.
[Bug ada/49425] ACATS test C974008 fails if run after test C761011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49425 --- Comment #1 from Tero Koskinen tero.koskinen at iki dot fi 2011-06-15 16:52:47 UTC --- (In reply to comment #0) Testcase: gnatchop -w *.a Oops, this line should be: gnatchop -w *.a *.ada
[Bug c/49426] New: unwarranted warning from -Wsign-compare
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49426
Summary: unwarranted warning from -Wsign-compare
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@meyering.net
In the following function, the compiler can deduce that c
is positive when it is compared with k, so should not emit a warning:
$ cat k.c
int
f (int c, unsigned int k)
{
if (c 0)
return -1;
return c k;
}
$ gcc -c -O2 -Wsign-compare k.c
k.c: In function 'f':
k.c:6:12: warning: comparison between signed and unsigned integer expressions
[-Wsign-compare]
Using built-in specs.
COLLECT_GCC=/p/bin/gcc
COLLECT_LTO_WRAPPER=/h/p/p/gcc-2011-06-14.11h16/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /h/j/w/co/gcc-svn/configure --prefix=/p/p/gcc-2011-06-14.11h16
--disable-multilib --disable-libmudflap --disable-nls --enable-languages=c
Thread model: posix
gcc version 4.7.0 20110613 (experimental) (GCC)
[Bug rtl-optimization/49414] gcc.dg/pr44194-1.c fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49414
--- Comment #2 from Easwaran Raman eraman at google dot com 2011-06-15
16:58:57 UTC ---
The DSE opportunity doesn't arise in ia32 since the struct is returned through
stack. Is the following patch restricting the test to x86_64 ok? (I have tested
that it works correctly on x86_64, but don't know how to test it gets excluded
on other platforms)
===
--- gcc/testsuite/gcc.dg/pr44194-1.c(revision 175063)
+++ gcc/testsuite/gcc.dg/pr44194-1.c(working copy)
@@ -1,4 +1,4 @@
-/* { dg-do compile } */
+/* { dg-do compile { target x86_64-*-* } } */
/* { dg-options -O2 -fdump-rtl-dse1 } */
#include stdint.h
[Bug rtl-optimization/49414] gcc.dg/pr44194-1.c fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49414 --- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-06-15 16:59:54 UTC --- It seems to me that the test should just be skipped for targets that always return structures in memory, i.e. most 32-bit targets.
[Bug rtl-optimization/49414] gcc.dg/pr44194-1.c fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49414
--- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-06-15
17:03:31 UTC ---
The DSE opportunity doesn't arise in ia32 since the struct is returned through
stack. Is the following patch restricting the test to x86_64 ok? (I have
tested
that it works correctly on x86_64, but don't know how to test it gets excluded
on other platforms)
x86-64 is too restrictive, the test should pass on SPARC64 as well. I'd
suggest
/* { dg-require-effective-target lp64 } */
with a comment saying that this is an approximation. Preapproved if it works.
[Bug c++/49356] [C++0x] decltype fails with recursive template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49356 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||froydnj at gcc dot gnu.org, ||jason at gcc dot gnu.org Resolution||INVALID --- Comment #1 from Jason Merrill jason at gcc dot gnu.org 2011-06-15 17:05:38 UTC --- The problem here is that t(f) is an rvalue, so it can't bind to the non-const T parameter in the recursive call. Nathan has a patch in the works that should produce more helpful diagnostics for this sort of situation.
[Bug c++/49292] [c++0x] non_const_var_error ICE for error when mixing static_assert, template, and constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49292 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jason at gcc dot gnu.org Resolution||FIXED --- Comment #1 from Jason Merrill jason at gcc dot gnu.org 2011-06-15 17:08:23 UTC --- This works now; I think it was fixed by my 6/9 patch.
[Bug rtl-optimization/49414] gcc.dg/pr44194-1.c fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49414 --- Comment #5 from eraman at gcc dot gnu.org 2011-06-15 17:20:25 UTC --- Author: eraman Date: Wed Jun 15 17:20:20 2011 New Revision: 175082 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175082 Log: 2011-06-15 Easwaran Raman era...@google.com PR rtl-optimization/49414 * gcc.dg/pr44194-1.c: Restrict test to 64-bit targets. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr44194-1.c
[Bug c++/49251] [C++0x][parameter pack expanding] unused parameter warning with unpacking empty tuples
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49251 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.06.15 17:31:05 CC||jason at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug c++/49229] [C++0x][SFINAE] ICE with variadics and depending non-type default parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49229 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.06.15 17:39:59 CC||jason at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug lto/49302] [4.7 Regression] FAIL: gcc.dg/lto/20110201-1 c_lto_20110201-1_0.o-c_lto_20110201-1_0.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49302 Michael Meissner meissner at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||meissner at gcc dot gnu.org AssignedTo|unassigned at gcc dot |wschmidt at gcc dot gnu.org |gnu.org |
[Bug lto/49302] [4.7 Regression] FAIL: gcc.dg/lto/20110201-1 c_lto_20110201-1_0.o-c_lto_20110201-1_0.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49302 William J. Schmidt wschmidt at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #13 from William J. Schmidt wschmidt at gcc dot gnu.org 2011-06-15 17:45:05 UTC --- Fixed.
[Bug rtl-optimization/49414] gcc.dg/pr44194-1.c fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49414 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-06-15 17:57:06 UTC --- For the record, it also fails on powerpc-apple-darwin9.8.0 (see http://gcc.gnu.org/ml/gcc-testresults/2011-06/msg01771.html ). Could it also be the cause of new failures in gfortran FAIL: gfortran.dg/dependency_25.f90 -O1 execution test FAIL: gfortran.dg/dependency_25.f90 -O2 execution test FAIL: gfortran.dg/dependency_25.f90 -Os execution test FAIL: gfortran.dg/der_array_1.f90 -O1 execution test FAIL: gfortran.dg/der_array_1.f90 -O2 execution test FAIL: gfortran.dg/der_array_1.f90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/der_array_1.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/der_array_1.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/der_array_1.f90 -O3 -g execution test FAIL: gfortran.dg/structure_constructor_1.f03 -O1 execution test FAIL: gfortran.dg/structure_constructor_1.f03 -O2 execution test FAIL: gfortran.dg/structure_constructor_1.f03 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/structure_constructor_1.f03 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/structure_constructor_1.f03 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/structure_constructor_1.f03 -O3 -g execution test ?
[Bug c++/48322] [C++0x] Plural variadic parameter packs are not expanded well
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48322 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||paolo.carlini at oracle dot ||com --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2011-06-15 18:01:56 UTC --- *** Bug 49225 has been marked as a duplicate of this bug. ***
[Bug c++/49225] [C++0x] Weird SFINAE behavior with variadic templates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49225 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jason at gcc dot gnu.org Resolution||DUPLICATE --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2011-06-15 18:01:56 UTC --- Yeah, this is a tricky one. *** This bug has been marked as a duplicate of bug 48322 ***
[Bug c++/49251] [C++0x][parameter pack expanding] unused parameter warning with unpacking empty tuples
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49251 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||lene13 at gmail dot com --- Comment #1 from Jason Merrill jason at gcc dot gnu.org 2011-06-15 18:06:43 UTC --- *** Bug 49339 has been marked as a duplicate of this bug. ***
[Bug c++/49339] [C++0x][lambda][unused-parameter]g++ reports unused parameter even it's referenced in function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49339 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2011-06-15 18:06:43 UTC --- This will be fixed by my patch for 49251. *** This bug has been marked as a duplicate of bug 49251 ***
[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38470 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||jim at meyering dot net --- Comment #9 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-06-15 18:15:44 UTC --- *** Bug 49426 has been marked as a duplicate of this bug. ***
[Bug c/49426] unwarranted warning from -Wsign-compare
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49426 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||manu at gcc dot gnu.org Resolution||DUPLICATE --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-06-15 18:15:44 UTC --- See duplicate for long explanation of why this won't be fixed soon. *** This bug has been marked as a duplicate of bug 38470 ***
[Bug c++/45399] [C++0x] Warning for \0 in raw strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45399 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug c++/45378] [C++0x] Narrowing error not detected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45378 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug c++/44160] [C++0x] a mysterious error on __func__ in a lambda expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44160 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug c++/45399] [C++0x] Warning for \0 in raw strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45399 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #9 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-06-15 18:40:40 UTC --- (In reply to comment #8) No objection I think. Alternatively there could be a switch to control this warning. Or both. I wish clang published a list of their warning options, so we can keep compatibility. According to this: https://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticKinds.def?revision=39294view=markupsortby=revpathrev=63060 They have three different warnings for this but I am not sure if the options are called -Wnull-in-char, -Wnull-in-string, and -Wnull-in-file.
[Bug c/43772] Errant -Wlogical-op warning when testing limits
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
eggert at gnu dot org changed:
What|Removed |Added
CC||eggert at gnu dot org
--- Comment #7 from eggert at gnu dot org 2011-06-15 19:18:57 UTC ---
I get the same bug with GCC 4.6.0 (x86-64). Here's a test case:
long long
emacs_lseek (int fd, long long offset, int whence)
{
return -1-9223372036854775807LL = offset offset = 9223372036854775807LL;
}
This is abstracted from real EMACS source code: the real code is verifying
that an EMACS_INT value fits within off_t. Both types happen to be
'long long' here, but they might not be the same types on other platforms.
When compiled with gcc -S -Wlogical-op t.c, I get:
t.c: In function 'emacs_lseek':
t.c:5:3: warning: logical 'and' of mutually exclusive tests is always false
[-Wlogical-op]
which is obviously bogus.
Using rather than works around the bug, but that's not a
satisfactory solution in general.
[Bug c++/49225] [C++0x] Weird SFINAE behavior with variadic templates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49225 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-06-15 19:20:34 UTC --- I see. Thus for the time being I'm probably going to use something like the workaround suggested by Daniel in private email.
[Bug c++/43912] [C++0x] lambda debug info does not describe captured variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43912 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug rtl-optimization/44194] struct returned by value generates useless stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
--- Comment #21 from Easwaran Raman eraman at google dot com 2011-06-15
20:34:32 UTC ---
The DSE patch still leaves 2 redundant stores. The following patch will enable
DSE to remove those two stores. Does this look ok?
Index: gcc/testsuite/gcc.dg/pr44194-1.c
===
--- gcc/testsuite/gcc.dg/pr44194-1.c(revision 175082)
+++ gcc/testsuite/gcc.dg/pr44194-1.c(working copy)
@@ -13,5 +13,5 @@ void func() {
struct ints s = foo();
bar(s.a, s.b);
}
-/* { dg-final { scan-rtl-dump global deletions = 2 dse1 } } */
+/* { dg-final { scan-rtl-dump global deletions = 4 dse1 } } */
/* { dg-final { cleanup-rtl-dump dse1 } } */
Index: gcc/calls.c
===
--- gcc/calls.c(revision 175081)
+++ gcc/calls.c(working copy)
@@ -3005,8 +3005,9 @@ expand_call (tree exp, rtx target, int ignore)
tree nt = build_qualified_type (rettype,
(TYPE_QUALS (rettype)
| TYPE_QUAL_CONST));
-
+ tree target_expr = create_tmp_reg (rettype, NULL);
target = assign_temp (nt, 0, 1, 1);
+ set_mem_expr (target, target_expr);
}
if (! rtx_equal_p (target, valreg))
[Bug target/49427] New: v850e-elf wants 850e/v850e-common.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49427 Summary: v850e-elf wants 850e/v850e-common.c Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: amyl...@gcc.gnu.org CC: ni...@redhat.com Blocks: 47093 Target: v850e-elf The build fails with: make[2]: *** No rule to make target `../../../gcc/gcc/common/config/v850e/v850e-common.c', needed by `v850e-common.o'. Stop.
[Bug c/49428] New: Wrong FP calculation that yields 0.0.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49428
Summary: Wrong FP calculation that yields 0.0.
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ecologicyb...@gmail.com
Created attachment 24539
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24539
for reproducing the bug.
There's a bug that it sometimes returns 0. instead of 0.6000 ns
when the cpu freq. is definitively around 1. GHz
gcc test.c ; ./a.out [ gcc (Debian 4.5.2-8) 4.5.2 ]
double nanoseconds_by_cpu_cycle(uint64_t frequency) {
double ns;
ns = 10.0L / ((double)frequency);
return(ns);
}
Here the objdump.
08048547 nanoseconds_by_cpu_cycle:
8048547: 55 push %ebp
8048548: 89 e5 mov%esp,%ebp
804854a: 83 ec 20sub$0x20,%esp
804854d: 8b 45 08mov0x8(%ebp),%eax
8048550: 89 45 e8mov%eax,-0x18(%ebp)
8048553: 8b 45 0cmov0xc(%ebp),%eax
8048556: 89 45 ecmov%eax,-0x14(%ebp)
8048559: df 6d e8fildll -0x18(%ebp)
804855c: 83 7d ec 00 cmpl $0x0,-0x14(%ebp)
8048560: 79 08 jns804856a
nanoseconds_by_cpu_cycle+0x23
8048562: db 2d 50 88 04 08 fldt 0x8048850
8048568: de c1 faddp %st,%st(1)
804856a: dd 5d e0fstpl -0x20(%ebp)
804856d: dd 45 e0fldl -0x20(%ebp)
8048570: db 2d 60 88 04 08 fldt 0x8048860
8048576: de f1 fdivp %st,%st(1)
8048578: dd 5d f8fstpl -0x8(%ebp)
804857b: dd 45 f8fldl -0x8(%ebp)
804857e: c9 leave
804857f: c3 ret
I see that FP generation code is buggy, i don't see why there's a
conditional branch jns although there's a risk of division by
zero that never happened.
10.0L / ((double)156800LL aprox.) did give me 0.0 wrongly.
Could be a side-effect of NaN, +Infty or -Infty?
[Bug rtl-optimization/44194] struct returned by value generates useless stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #22 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-06-15 21:09:18 UTC --- The DSE patch still leaves 2 redundant stores. OK, I missed this, reopening... The following patch will enable DSE to remove those two stores. Does this look ok? Calling into the gimplifier from the RTL expander doesn't look appropriate. More fundamentally, it's a little unfortunate to spill to memory a value returned in registers. Can we try to use emit_group_move_into_temps here instead (under the appropriate circumstances)?
[Bug rtl-optimization/49414] gcc.dg/pr44194-1.c fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49414 Steve Ellcey sje at cup dot hp.com changed: What|Removed |Added CC||sje at cup dot hp.com --- Comment #7 from Steve Ellcey sje at cup dot hp.com 2011-06-15 21:23:51 UTC --- I am also seeing some new failures on IA64 HP-UX (maybe Linux too, I am not sure because my Linux run had other problems). I see the same Fortran failures that Dominique sees. I also get a failure with gcc.dg/struct-by-value-1.c and I definitively tracked that failure down to r175063. I haven't verified that the Fortran failures started with this exact version. Should these bugs (mine and Dominiques) be a separate bug report? They look different then the IA32 failure.
[Bug rtl-optimization/49414] gcc.dg/pr44194-1.c fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49414 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #8 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-06-15 21:42:16 UTC --- Yes, please open a PR for the new execution failures and make it depend on the original PR rtl-optimization/44194. This one is fixed.
[Bug rtl-optimization/49429] New: dse.c changes to fix PR44194 (r175063) cause execution failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49429 Summary: dse.c changes to fix PR44194 (r175063) cause execution failures Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: s...@cup.hp.com CC: era...@google.com Depends on: 44194 Target: ia64-hp-hpux11* powerpc-apple-darwin9.8.0 The fix for PR 44194, version r175063, causes failures on ia64-hp-hpux11.23 and powerpc-apple-darwin9.8.0. gcc.dg/struct-by-value-1.c fails on HP-UX with -O2 optimization. This was the test I used on HP-UX to track down the specific version that caused the failure. These fortran tests fail on both platforms and I think are caused by the same checkin: FAIL: gfortran.dg/dependency_25.f90 -O1 execution test FAIL: gfortran.dg/dependency_25.f90 -O2 execution test FAIL: gfortran.dg/dependency_25.f90 -Os execution test FAIL: gfortran.dg/der_array_1.f90 -O1 execution test FAIL: gfortran.dg/der_array_1.f90 -O2 execution test FAIL: gfortran.dg/der_array_1.f90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/der_array_1.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/der_array_1.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/der_array_1.f90 -O3 -g execution test FAIL: gfortran.dg/structure_constructor_1.f03 -O1 execution test FAIL: gfortran.dg/structure_constructor_1.f03 -O2 execution test FAIL: gfortran.dg/structure_constructor_1.f03 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/structure_constructor_1.f03 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/structure_constructor_1.f03 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/structure_constructor_1.f03 -O3 -g execution test
[Bug rtl-optimization/49429] dse.c changes to fix PR44194 (r175063) cause execution failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49429 --- Comment #1 from Easwaran Raman eraman at google dot com 2011-06-15 22:22:05 UTC --- Can you please attach the dse1 dump with and without my patch so that I can look into it? I will also try to build a IA64 cross compiler and see if I can spot what's happening, but I don't have access to a ia64 to run the tests.
[Bug rtl-optimization/49429] dse.c changes to fix PR44194 (r175063) cause execution failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49429 --- Comment #2 from Steve Ellcey sje at cup dot hp.com 2011-06-15 22:37:24 UTC --- Created attachment 24540 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24540 Cut down version of gcc.dg/struct-by-value-1.c This is a cutdown version of gcc.dg/struct-by-value-1.c that executes correctly when compiled with -O2 before r175063 but calls abort after the change.
[Bug rtl-optimization/49429] dse.c changes to fix PR44194 (r175063) cause execution failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49429 --- Comment #3 from Steve Ellcey sje at cup dot hp.com 2011-06-15 22:38:15 UTC --- Created attachment 24541 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24541 dse dump of x.c before change was made
[Bug rtl-optimization/49429] dse.c changes to fix PR44194 (r175063) cause execution failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49429 --- Comment #4 from Steve Ellcey sje at cup dot hp.com 2011-06-15 22:39:26 UTC --- Created attachment 24542 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24542 dse dump of x.c after change was made
[Bug target/49427] v850e-elf wants 850e/v850e-common.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49427 --- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot com 2011-06-15 22:52:07 UTC --- It appears the v850 targets duplicate a lot of standard settings tm_p_file=v850/v850-protos.h tmake_file=v850/t-v850 md_file=v850/v850.md extra_modes=v850/v850-modes.def out_file=v850/v850.c extra_options=v850/v850.opt all of which could be avoided by setting cpu_type (which would also fix this issue). In general targets setting out_file directly like that are suspect and indicate a missing case in the code setting cpu_type.
