[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 #7 from Jakub Jelinek 2011-06-18 06:43:41 UTC --- Author: jakub Date: Sat Jun 18 06:43:38 2011 New Revision: 175165 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175165 Log: PR target/49411 * config/i386/i386.c (ix86_expand_multi_arg_builtins): If last_arg_constant and last argument doesn't match its predicate, for xop_vpermil23 error out and for xop_rotl3 if it is CONST_INT, mask it, otherwise expand using rotl3. (ix86_expand_sse_pcmpestr, ix86_expand_sse_pcmpistr): Fix spelling of error message. * config/i386/sse.md (sse4a_extrqi, sse4a_insertqi, vcvtps2ph, *vcvtps2ph, *vcvtps2ph_store, vcvtps2ph256): Use const_0_to_255_operand instead of const_int_operand. Revert: 2011-05-09 Uros Bizjak * config/i386/sse.md (blendbits): Remove mode attribute. (_blend): Use const_int_operand instead of const_0_to__operand for operand 3 predicate. Check integer value of operand 3 in insn constraint. * gcc.target/i386/testimm-1.c: New test. * gcc.target/i386/testimm-2.c: New test. * gcc.target/i386/testimm-3.c: New test. * gcc.target/i386/testimm-4.c: New test. * gcc.target/i386/testimm-5.c: New test. * gcc.target/i386/testimm-6.c: New test. * gcc.target/i386/testimm-7.c: New test. * gcc.target/i386/testimm-8.c: New test. * gcc.target/i386/xop-vpermil2px-2.c: New test. * gcc.target/i386/xop-rotate1-int.c: New test. * gcc.target/i386/xop-rotate2-int.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/testimm-1.c trunk/gcc/testsuite/gcc.target/i386/testimm-2.c trunk/gcc/testsuite/gcc.target/i386/testimm-3.c trunk/gcc/testsuite/gcc.target/i386/testimm-4.c trunk/gcc/testsuite/gcc.target/i386/testimm-5.c trunk/gcc/testsuite/gcc.target/i386/testimm-6.c trunk/gcc/testsuite/gcc.target/i386/testimm-7.c trunk/gcc/testsuite/gcc.target/i386/testimm-8.c trunk/gcc/testsuite/gcc.target/i386/xop-rotate1-int.c trunk/gcc/testsuite/gcc.target/i386/xop-rotate2-int.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/sse.md trunk/gcc/testsuite/ChangeLog
[Bug c++/49458] [C++0x] Obvious candidate for conversion to function lvalue rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49458 --- Comment #2 from Jason Merrill 2011-06-18 05:58:42 UTC --- Author: jason Date: Sat Jun 18 05:58:38 2011 New Revision: 175164 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175164 Log: PR c++/49458 * call.c (convert_class_to_reference_1): Allow binding function lvalue to rvalue reference. Added: trunk/gcc/testsuite/g++.dg/cpp0x/rv-func2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog
[Bug libgcj/49314] md5test, shatest output FAILs on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49314 --- Comment #12 from Jack Howarth 2011-06-18 05:54:49 UTC --- (In reply to comment #11) > Further investigation revealed part of what's going on: the test in > gnu::gcj::convert::IOConverter::iconv_init fails with EINVAL on Tru64 > UNIX, but the byte swapping is still needed. If I hack the function to > return true, both the testcase and md5test/shatest succeed. > > The question now is what's a clean fix for this issue, rather than > hardcoding the result? > > Rainer Does http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01375.html have any impact on this bug?
[Bug c++/49462] New: comparison of const bool and pointer does not yield an error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49462 Summary: comparison of const bool and pointer does not yield an error Product: gcc Version: 4.5.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: frederic.b...@m4x.org The following code should produce the error "ISO C++ forbids comparison between pointer and integer" when compiled with g++ -std=c++98 -pedantic-errors. When the bool is not const or volatile of const volatile, the error is produced. Only when bool is "only" const, the error is not produced. Same problem with all comparison operators ==, !=, <, <=, >, >=. int * pi=0; bool const b=0; pi==b; b==pi;
[Bug target/49461] New: boehm-gc and gcj incompatible with pie
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49461 Summary: boehm-gc and gcj incompatible with pie Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: howa...@nitro.med.uc.edu When built with -pie linkage on intel darwin, the boehm-gc test suite fails the tests... FAIL: boehm-gc.c/gctest.c -O2 execution test FAIL: boehm-gc.c/leak_test.c -O2 execution test FAIL: boehm-gc.c/thread_leak_test.c -O2 execution test FAIL: boehm-gc.lib/staticrootstest.c -O2 execution test at both -m32 and -m64. Likewise gcj crashes when ecj1 is built with -pie linkage. This crash appears as... [MacPro:~] howarth% gcj-fsf-4.7 --main=testme -O testme.java -pie -v Using built-in specs. Reading specs from /sw/lib/gcc4.7/lib/gcc/x86_64-apple-darwin11.0.0/4.7.0/../../../libgcj.spec rename spec startfile to startfileorig rename spec lib to liborig COLLECT_GCC=gcj-fsf-4.7 COLLECT_LTO_WRAPPER=/sw/lib/gcc4.7/libexec/gcc/x86_64-apple-darwin11.0.0/4.7.0/lto-wrapper Target: x86_64-apple-darwin11.0.0 Configured with: ../gcc-4.7-20110617/configure --prefix=/sw --prefix=/sw/lib/gcc4.7 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.7/info --enable-languages=c,c++,fortran,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.7 --enable-checking=yes --enable-cloog-backend=isl Thread model: posix gcc version 4.7.0 20110617 (experimental) (GCC) COLLECT_GCC_OPTIONS='-fsaw-java-file' '-mmacosx-version-min=10.7.0' '-O' '-pie' '-v' '-fbootclasspath=./:/sw/lib/gcc4.7/share/java/libgcj-4.7.0.jar' '-shared-libgcc' '-mtune=core2' /sw/lib/gcc4.7/libexec/gcc/x86_64-apple-darwin11.0.0/4.7.0/ecj1 testme.java -fbootclasspath=./:/sw/lib/gcc4.7/share/java/libgcj-4.7.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1l/n78sywl52lz6kkys6nv7mnphgp/T//ccxj1zOQ.zip -fzip-target /var/folders/1l/n78sywl52lz6kkys6nv7mnphgp/T//ccXXudTY.jar Exception in thread "main" java.lang.ClassFormatError: org.eclipse.jdt.internal.compiler.Compiler (erroneous exception handler info) at java.lang.VMClassLoader.defineClass(libgcj.12.dylib) at java.lang.ClassLoader.defineClass(libgcj.12.dylib) at java.security.SecureClassLoader.defineClass(libgcj.12.dylib) at java.net.URLClassLoader.findClass(libgcj.12.dylib) at java.lang.ClassLoader.loadClass(libgcj.12.dylib) at java.lang.ClassLoader.loadClass(libgcj.12.dylib) at org.eclipse.jdt.internal.compiler.impl.CompilerOptions.resetDefaults(CompilerOptions.java:963) at org.eclipse.jdt.internal.compiler.impl.CompilerOptions.(CompilerOptions.java:371) at org.eclipse.jdt.internal.compiler.impl.CompilerOptions.(CompilerOptions.java:363) at org.eclipse.jdt.internal.compiler.batch.Main.initialize(Main.java:3548) at org.eclipse.jdt.internal.compiler.batch.Main.(Main.java:1435) at org.eclipse.jdt.internal.compiler.batch.Main.(Main.java:1423) at org.eclipse.jdt.internal.compiler.batch.GCCMain.(GCCMain.java:62) at org.eclipse.jdt.internal.compiler.batch.GCCMain.main(GCCMain.java:498) The problems with gcj can be avoided by passing -no_pie via SYSTEMSPEC in gcj.spec.in. The test suite results for libjava are reasonable with that change http://gcc.gnu.org/ml/gcc-testresults/2011-06/msg01853.html
[Bug target/49446] avr-g++ does not optimize when using bitshift in inlined function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49446 Georg-Johann Lay changed: What|Removed |Added Target||avr CC||gjl at gcc dot gnu.org --- Comment #2 from Georg-Johann Lay 2011-06-17 21:58:20 UTC --- Not very helpful without source to reproduce, see http://gcc.gnu.org/bugs/#need
[Bug target/49446] avr-g++ does not optimize when using bitshift in inlined function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49446 HotHead changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from HotHead 2011-06-17 21:38:20 UTC --- duplicate of 33049 *** This bug has been marked as a duplicate of bug 33049 ***
[Bug target/33049] [avr] bit extraction non optimal, inversing logic solves problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33049 HotHead changed: What|Removed |Added CC||gcc at emailgo dot de --- Comment #15 from HotHead 2011-06-17 21:38:20 UTC --- *** Bug 49446 has been marked as a duplicate of this bug. ***
[Bug fortran/49400] Proc-pointer declaration in BLOCK construct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49400 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.06.17 20:54:14 AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org 2011-06-17 20:54:14 UTC --- (In reply to comment #0) > Currently, one gets: > > test.f90:8.8: > > Procedure(Real),Pointer :: p > 1 > Error: Unclassifiable statement at (1) Fixing this is trivial: Index: gcc/fortran/decl.c === --- gcc/fortran/decl.c(revision 175150) +++ gcc/fortran/decl.c(working copy) @@ -4970,6 +4970,7 @@ gfc_match_procedure (void) case COMP_MODULE: case COMP_SUBROUTINE: case COMP_FUNCTION: +case COMP_BLOCK: m = match_procedure_decl (); break; case COMP_INTERFACE:
[Bug rtl-optimization/49429] [4.7 Regression] dse.c changes to fix PR44194 (r175063) cause execution failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49429 --- Comment #10 from Steve Ellcey 2011-06-17 20:49:22 UTC --- With regards to the question in comment #9, you would probably do better asking it on the gcc-patches mailing list then in the comment of this bug report since more people would see it on the mailing list.
[Bug c++/49458] [C++0x] Obvious candidate for conversion to function lvalue rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49458 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.06.17 20:44:28 CC||jason at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Jason Merrill 2011-06-17 20:44:28 UTC --- I agree that #2 should be a candidate, since it returns a function lvalue, and frvref can bind to a function lvalue. That is a bug. I also agree with your interpretation of the standard on the other points, but that seems unintentional, so I'm going to raise the issue with the committee.
[Bug rtl-optimization/49429] [4.7 Regression] dse.c changes to fix PR44194 (r175063) cause execution failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49429
--- Comment #9 from Easwaran Raman 2011-06-17
20:43:04 UTC ---
(In reply to comment #8)
> Compiling x.c with a ia64-unknown-linux cross compiler, setting a breakpoint
> in
> can_escape(), I see that,
>
>
> (gdb) p debug_rtx (body)
> (set (mem/s/c:DI (reg/f:DI 341) [2 s1+0 S8 A64])
> (reg:DI 112 in0))
>
> This is part of an instruction that gets removed:
> (insn 4 3 6 2 (set (mem/s/c:DI (reg/f:DI 341) [2 s1+0 S8 A64])
> (reg:DI 112 in0)) y.c:23 5 {movdi_internal}
> (expr_list:REG_DEAD (reg:DI 112 in0)
> (nil)))
>
> (gdb) p expr->base.code
> $24 = PARM_DECL
> (gdb) p may_be_aliased (expr)
> $23 = 0 '\000'
>
> So can_escape() returns false. But later on, in the same BB, I see:
>
>
> (insn 36 30 37 2 (set (reg:DI 120 out0)
> (reg/f:DI 357)) 5 {movdi_internal}
> (expr_list:REG_EQUAL (plus:DI (reg/f:DI 328 sfp)
> (const_int 62 [0x3e]))
> (nil)))
> (insn 37 36 38 2 (set (reg:DI 121 out1)
> (reg/f:DI 341)) 5 {movdi_internal}
> (expr_list:REG_DEAD (reg/f:DI 341)
> (expr_list:REG_EQUAL (plus:DI (reg/f:DI 328 sfp)
> (const_int 96 [0x60]))
> (nil
> (insn 38 37 39 2 (set (reg:DI 122 out2)
> (const_int 31 [0x1f])) 5 {movdi_internal}
> (nil))
> (call_insn 39 38 42 2 (parallel [
> (set (reg:DI 8 r8)
> (call (mem:DI (symbol_ref:DI ("memcpy") [flags 0x41]
> ) [0 memcpy S8 A64])
> (const_int 1 [0x1])))
> (clobber (reg:DI 320 b0))
> (clobber (scratch:DI))
> (clobber (scratch:DI))
> ]) 332 {call_value_gp}
> (expr_list:REG_DEAD (reg:DI 122 out2)
> (expr_list:REG_DEAD (reg:DI 121 out1)
> (expr_list:REG_DEAD (reg:DI 120 out0)
> (expr_list:REG_UNUSED (reg:DI 8 r8)
> (expr_list:REG_EH_REGION (const_int 0 [0])
> (nil))
> (expr_list:REG_DEP_TRUE (use (reg:DI 1 r1))
> (expr_list:REG_DEP_TRUE (use (reg:DI 122 out2))
> (expr_list:REG_DEP_TRUE (use (reg:DI 121 out1))
> (expr_list:REG_DEP_TRUE (use (reg:DI 120 out0))
> (nil))
>
> reg 341 is passed as source argument of a memcpy. Why does the expression
> return 0 for may_be_aliased()?
Could someone tell why may_be_aliased returns false in this case? I would
expect TREE_ADDRESSABLE to be true, but that's not the case. It seems to me
some other bug is exposed by the DSE patch.
[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 changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #4 from Jason Merrill 2011-06-17 20:13:24 UTC --- Fixed for 4.7.0.
[Bug c++/43912] [C++0x] lambda debug info does not describe captured variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43912 --- Comment #3 from Jason Merrill 2011-06-17 20:08:06 UTC --- Author: jason Date: Fri Jun 17 20:08:01 2011 New Revision: 175158 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175158 Log: PR c++/43912 Generate proxy VAR_DECLs for better lambda debug info. * cp-tree.h (FUNCTION_NEEDS_BODY_BLOCK): Add lambda operator(). (LAMBDA_EXPR_PENDING_PROXIES): New. (struct tree_lambda_expr): Add pending_proxies. * name-lookup.c (pushdecl_maybe_friend_1): Handle capture shadowing. (qualify_lookup): Use is_lambda_ignored_entity. * parser.c (cp_parser_lambda_expression): Don't adjust field names. Call insert_pending_capture_proxies. (cp_parser_lambda_introducer): Use this_identifier. (cp_parser_lambda_declarator_opt): Call the object parameter of the op() "__closure" instead of "this". (cp_parser_lambda_body): Call build_capture_proxy. * semantics.c (build_capture_proxy, is_lambda_ignored_entity): New. (insert_pending_capture_proxies, insert_capture_proxy): New. (is_normal_capture_proxy, is_capture_proxy): New. (add_capture): Add __ to field names here, return capture proxy. (add_default_capture): Use this_identifier, adjust to expect add_capture to return a capture proxy. (outer_lambda_capture_p, thisify_lambda_field): Remove. (finish_id_expression, lambda_expr_this_capture): Adjust. (build_lambda_expr): Initialize LAMBDA_EXPR_PENDING_PROXIES. * pt.c (tsubst_copy_and_build): Check that LAMBDA_EXPR_PENDING_PROXIES is null. Added: trunk/gcc/testsuite/g++.dg/debug/dwarf2/lambda1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.def trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/name-lookup.c trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/warn/Wshadow-6.C
[Bug fortran/48699] [4.6/4.7 Regression] [OOP] MOVE_ALLOC inside SELECT TYPE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48699 --- Comment #18 from janus at gcc dot gnu.org 2011-06-17 20:03:07 UTC --- Author: janus Date: Fri Jun 17 20:03:04 2011 New Revision: 175151 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175151 Log: 2011-06-17 Janus Weil PR fortran/48699 * check.c (gfc_check_move_alloc): If 'TO' argument is polymorphic, make sure the vtab is present. 2011-06-17 Janus Weil PR fortran/48699 * gfortran.dg/move_alloc_5.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/move_alloc_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/testsuite/ChangeLog
[Bug c++/49460] g++: Internal error: Segmentation fault (program cc1plus) using -O2 or -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49460 --- Comment #1 from Roger Jarrett 2011-06-17 19:41:29 UTC --- Created attachment 24555 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24555 preprocessed source file SmartInliner.ii (gzipped) preprocessed file gzipped to allow upload
[Bug c++/49460] New: g++: Internal error: Segmentation fault (program cc1plus) using -O2 or -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49460 Summary: g++: Internal error: Segmentation fault (program cc1plus) using -O2 or -O3 Product: gcc Version: 4.5.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: rjarr...@mathworks.com using GCC 4.5.3 one (and only one) file from our code base caused the compiler to Segfault. Set severity to normal because this only occurred in 1 file out of 10k+ and workaround is available. Workaround compile with -O1 or -O0 This issue does not occur when compiling with GCC4.4.5 or GCC 4.3.4 Version information: GNU C++ (GCC) version 4.5.3 (i686-pc-linux-gnu) compiled by GNU C version 4.5.3, GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C++ (GCC) version 4.5.3 (i686-pc-linux-gnu) compiled by GNU C version 4.5.3, GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: caed1e0856fbbe32553e2b8828f0c55c g++: Internal error: Segmentation fault (program cc1plus) System type: Debian Linux 6.01 (glnx86 and glnxa64) GCC build/configuration options: (glnx86 build shown) gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/mathworks/hub/3rdparty/internal/290712/glnx86/gcc-4.5.3/bin/../libexec/gcc/i686-pc-linux-gnu/4.5.3/lto-wrapper Target: i686-pc-linux-gnu Configured with: /mathworks/devel/sandbox/greg/Amake.3p1/3p/sources/gcc-4.5/configure --prefix=/hub/3rdparty/internal/290712/glnx86/gcc-4.5.3 --with-gmp=/mathworks/devel/sandbox/greg/Amake.3p1/3p/derived/glnx86/gcc-4.5/gmp --with-mpfr=/mathworks/devel/sandbox/greg/Amake.3p1/3p/derived/glnx86/gcc-4.5/mpfr --with-mpc=/mathworks/devel/sandbox/greg/Amake.3p1/3p/derived/glnx86/gcc-4.5/mpc --enable-languages=c,c++,fortran --with-as=/hub/3rdparty/internal/290712/glnx86/gcc-4.5.3/bin/as --with-ld=/hub/3rdparty/internal/290712/glnx86/gcc-4.5.3/bin/ld Thread model: posix gcc version 4.5.3 (GCC) gcc version 4.4.5 (Debian 4.4.5-8) Compile line options/command line: COLLECT_GCC_OPTIONS='-c' '-o' '/tmp/SM.o' '-I../../src/cgir_xform/include' '-I../../src/include' '-I../../derived/glnx86/src/include' '-I../../src/cgir_xform' '-I../include' '-I../../include' '-I//mathworks/hub/3rdparty/R2012a/293758/glnx86/boost/include' '-I//mathworks/hub/3rdparty/R2012a/287824/glnx86/unique_ptr' '-I//mathworks/hub/3rdparty/R2012a/289443/glnx86/gmp/include' '-I//mathworks/hub/3rdparty/R2012a/288615/glnx86/mpfr/include' '-DMAKEHEADER_KEYWORDS' '-DMAKEHEADER_KEYWORDS' '-DNEEDS_MX_ERRWARN_MSG_ID_AND_TXT' '-DSL_INTERNAL' '-DCGIR_HANDWRITTEN_HEADERS' '-I../../simulink/include' '-DMODULE_CGIR' '-DBUILDING_CGIR_XFORM' '-O2' '-D_POSIX_C_SOURCE=199506L' '-D_LARGEFILE_SOURCE' '-D_FILE_OFFSET_BITS=64' '-v' '-save-temps' '-shared-libgcc' '-mtune=generic' '-march=pentiumpro' /mathworks/hub/3rdparty/internal/290712/glnx86/gcc-4.5.3/bin/../libexec/gcc/i686-pc-linux-gnu/4.5.3/cc1plus -fpreprocessed SmartInliner.ii -quiet -dumpbase SmartInliner.cpp -mtune=generic -march=pentiumpro -auxbase-strip /tmp/SM.o -O2 -version -o SmartInliner.s --- SmartInliner.ii has attached to this file
[Bug libfortran/49296] [4.6/4.7 Regression] Wrong END OF FILE error for list-directed I/O with strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49296 Janne Blomqvist changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-06/msg00896.htm ||l --- Comment #9 from Janne Blomqvist 2011-06-17 19:10:43 UTC --- Patch: http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00896.html Simplified testcase: http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01355.html
[Bug debug/49459] attribute((mode(byte))) in a typedef produces wrong debug information
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49459 Richard Henderson changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||wrong-debug Last reconfirmed||2011.06.17 18:56:47 Component|c |debug CC||rth at gcc dot gnu.org Ever Confirmed|0 |1 Known to fail||4.5.1, 4.6.0 --- Comment #1 from Richard Henderson 2011-06-17 18:56:47 UTC --- Confirmed. <1><5e>: Abbrev Number: 5 (DW_TAG_variable) <5f> DW_AT_name: foo <63> DW_AT_decl_file : 1 <64> DW_AT_decl_line : 4 <65> DW_AT_type: <0x32> <69> DW_AT_external: 1 <6a> DW_AT_declaration : 1 <1><32>: Abbrev Number: 4 (DW_TAG_typedef) <33> DW_AT_name: e1 <36> DW_AT_decl_file : 1 <37> DW_AT_decl_line : 1 <38> DW_AT_type: <0x1d> <1><1d>: Abbrev Number: 2 (DW_TAG_enumeration_type) <1e> DW_AT_byte_size : 4 <1f> DW_AT_decl_file : 1 <20> DW_AT_decl_line : 1 <21> DW_AT_sibling : <0x32> Note that DW_AT_byte_size == 4. We never change the size of the type based on the attribute attached to the typedef.
[Bug target/49454] [4.7 Regression] /usr/include/libio.h:336:3: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49454 Steve Ellcey changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.06.17 18:30:10 CC||sje at cup dot hp.com Depends on||49429 Ever Confirmed|0 |1 --- Comment #1 from Steve Ellcey 2011-06-17 18:30:10 UTC --- This is caused by r175063, the same change that caused pr49429.
[Bug c/49459] New: attribute((mode(byte))) in a typedef produces wrong debug information
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49459 Summary: attribute((mode(byte))) in a typedef produces wrong debug information Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: pkon...@gcc.gnu.org Created attachment 24554 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24554 Test case The attached test case shows attribute((mode(byte))) used to produce enums that are one byte long rather than the usual 4. The compiler actually sees the correct value of sizeof() but GDB (7.2) does not. This can be seen by compiling the test case; gdb shows the value of s1 as 1, but sizeof(foo) as 4. When compiled with GCC 3.3.3, s1 and sizeof(foo) both show up as 1, as expected.
[Bug c++/49458] New: [C++0x] Obvious candidate for conversion to function lvalue rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49458
Summary: [C++0x] Obvious candidate for conversion to function
lvalue rejected
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hst...@ca.ibm.com
CC: micha...@ca.ibm.com
Host: powerpc64-unknown-linux-gnu
Target: powerpc64-unknown-linux-gnu
According to the 2011 FCD, subclause 13.3.1.6 [over.match.ref] paragraph 1:
>>>
The conversion functions of S and its base classes are considered, except that
for copy-initialization, only the non-explicit conversion functions are
considered. Those that are not hidden within S and yield type "lvalue reference
to cv2 T2" (when 8.5.3 requires an lvalue result) or "cv2 T2" or
"rvalue reference to cv2 T2" (when 8.5.3 requires an rvalue result), where
"cv1 T" is reference-compatible (8.5.3) with "cv2 T2", are candidate functions.
<<<
Both lvalue references and rvalue references to function types require binding
to function lvalues. The following test case is expected to compile clean.
GCC still does not compile if #1 is commented out.
GCC will compile if #2 is commented out, but that behaviour is unsupported by
the referenced wording.
In particular, #2 should be a candidate and (from the wording) #1 is not for
conversion to a function lvalue.
### Self-contained source (a.cpp):> cat a.cpp
typedef void ftype();
void foo() { }
struct A {
operator ftype&&(void); // #1
operator ftype&(void) { return foo; } // #2
};
ftype &&frvref = A();
### Compiler invocation:
g++-4.6.0 -std=c++0x -o a.o -c a.cpp
### Compiler output:
a.cpp:9:20: error: invalid initialization of reference of type ‘void (&&)()’
from expression of type ‘A’
### g++ -v output:> g++-4.6.0 -v
Using built-in specs.
COLLECT_GCC=g++-4.6.0
COLLECT_LTO_WRAPPER=/data/gcc/libexec/gcc/powerpc64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: powerpc64-unknown-linux-gnu
Configured with: ./configure --prefix=/data/gcc --program-suffix=-4.6.0
--disable-libssp --disable-libgcj --enable-version-specific-runtime-libs
--with-cpu=default32 --enable-secureplt --with-long-double-128 --enable-shared
--enable-__cxa_atexit --enable-threads=posix --enable-languages=c,c++,fortran
--with-gmp=/usr/local
Thread model: posix
gcc version 4.6.0 (GCC)
[Bug gcov-profile/7970] Arc profiling doesn't work reliably on global destructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7970 David Hammen changed: What|Removed |Added CC||dhammen at odysseysr dot ||com --- Comment #5 from David Hammen 2011-06-17 17:45:30 UTC --- This bug *still* exists as of i686-apple-darwin10-g++-4.2.1. The problem is apparently the collision of two at_exit() handlers, with C++'s global destructor coming in last.
[Bug tree-optimization/49457] New: integer comparison does not vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49457
Summary: integer comparison does not vectorize
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch
float __attribute__ ((aligned(16))) a[1024];
float __attribute__ ((aligned(16))) b[1024];
// does not vectorize
void tVi() {
for (int i=0; i!=1024; ++i) {
int j = a[i];
b[i] = (j==0) ? a[i] : - a[i];
}
}
// nicely vectorize...
void tVf() {
for (int i=0; i!=1024; ++i) {
int j = a[i];
float z = j;
b[i] = (z==0) ? a[i] : - a[i];
}
}
c++ -Ofast -c testVectCond.cpp -msse4.2
otool -V -t testVectCond.o | c++filt
testVectCond.o:
(__TEXT,__text) section
tVi():
xorl%eax,%eax
0002movss0x0096(%rip),%xmm2
000aleaq_a(%rip),%rcx
0011nopltVi()(%rax)
0018nopltVi()(%rax,%rax)
0020movss(%rcx,%rax),%xmm0
0025cvttss2si%xmm0,%edx
0029movaps%xmm0,%xmm1
002cxorps%xmm2,%xmm1
002ftestl%edx,%edx
0031je0x0036
0033movaps%xmm1,%xmm0
0036leaq_b(%rip),%rdx
003dmovss%xmm0,(%rdx,%rax)
0042addq$0x04,%rax
0046cmpq$0x1000,%eax
004cjne0x0020
004erepz/ret
tVf():
0050movaps0x0059(%rip),%xmm4
0057xorl%eax,%eax
0059xorps%xmm3,%xmm3
005cleaq_a(%rip),%rcx
0063leaq_b(%rip),%rdx
006anopwtVi()(%rax,%rax)
0070movaps(%rcx,%rax),%xmm2
0074cvttps2dq%xmm2,%xmm0
0078cvtdq2ps%xmm0,%xmm0
007bcmpps$0x4,%xmm3,%xmm0
007fmovaps%xmm2,%xmm1
0082xorps%xmm4,%xmm1
0085andps%xmm0,%xmm1
0088andnps%xmm2,%xmm0
008borps%xmm1,%xmm0
008emovaps%xmm0,(%rdx,%rax)
0092addq$0x10,%rax
0096cmpq$0x1000,%eax
009cjne0x0070
009erepz/ret
I'm using
g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin10.7.0/4.7.0/lto-wrapper
Target: x86_64-apple-darwin10.7.0
Configured with: ./configure --enable-languages=c,c++,fortran --enable-lto
--with-build-config=bootstrap-lto CFLAGS='-O2 -ftree-vectorize -fPIC'
CXXFLAGS='-O2 -fPIC -ftree-vectorize -fvisibility-inlines-hidden'
Thread model: posix
gcc version 4.7.0 20110528 (experimental) (GCC)
[Bug tree-optimization/49452] comp-goto-2.c regresses in testing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452 --- Comment #3 from Eric Botcazou 2011-06-17 16:55:48 UTC --- > I haven't looked at in great detail yet to analyse what causes this problem > but > it appears to have appeared in the last week or so. Maybe r175063 (significant dse.c change).
[Bug tree-optimization/49452] comp-goto-2.c regresses in testing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot
||gnu.org
--- Comment #2 from Eric Botcazou 2011-06-17
16:51:41 UTC ---
> NORETURN attribute marked to it but there's no reason why this should be
> marked
> as NORETURN - surely there is a flow of control that allows control to go out
> of the function.
>
>
> x(a)
> {
> __label__ xlab;
> void y(a)
> {
> void *x = &&llab;
> if (a==-1)
> goto *x;
> if (a==0)
> goto xlab;
> llab:
> y (a-1);
> }
> y (a);
> xlab:;
> return a;
> }
Yes, but this isn't a return, this is a non-local goto so NORETURN is correct.
[Bug tree-optimization/49444] IV-OPTs changes an unaligned loads into aligned loads incorrectly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49444 --- Comment #5 from Andrew Pinski 2011-06-17 16:25:04 UTC --- (In reply to comment #4) > > Well, that will then still run into the indirect-ref issue as > the expansion for target-mem-refs and mem-refs works the same way. > Only targets that support movmisalign will generate unaligned > loads (which targets currently only define for vector modes I think). It works in the case which I reported because the mode is BLKmode. I tried to get a testcase that would still fail after this but I could not find one as IV-OPTs would use a->b for that still. Thanks, Andrew Pinski
[Bug libgcj/49314] md5test, shatest output FAILs on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49314 --- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-06-17 16:15:55 UTC --- Further investigation revealed part of what's going on: the test in gnu::gcj::convert::IOConverter::iconv_init fails with EINVAL on Tru64 UNIX, but the byte swapping is still needed. If I hack the function to return true, both the testcase and md5test/shatest succeed. The question now is what's a clean fix for this issue, rather than hardcoding the result? Rainer
[Bug debug/48459] [4.6/4.7 Regression] avr: Assertion failure with -gdwarf-2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48459 Richard Henderson changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #32 from Richard Henderson 2011-06-17 16:04:43 UTC --- Fixed with: 2011-06-17 Richard Henderson Backport from mainline 2011-03-22 Richard Henderson * dwarf2out.c (dwarf2out_frame_debug_expr) [rule 11]: Handle post_dec.
[Bug c++/47606] [trans-mem] internal compiler error in expand_block_tm with O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47606 Richard Henderson changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #9 from Richard Henderson 2011-06-17 16:03:54 UTC --- Gah. Wrong PR.
[Bug c++/47606] [trans-mem] internal compiler error in expand_block_tm with O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47606 Richard Henderson changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Richard Henderson 2011-06-17 16:03:03 UTC --- Fixed with: 2011-06-17 Richard Henderson Backport from mainline 2011-03-22 Richard Henderson * dwarf2out.c (dwarf2out_frame_debug_expr) [rule 11]: Handle post_dec.
[Bug bootstrap/49383] [4.7 regression] powerpc64-linux bootstrap failure due to ice in cgraph_only_called_directly_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49383
--- Comment #2 from Peter Bergner 2011-06-17
15:53:39 UTC ---
We die on this assert:
gcc_assert (cgraph_function_or_thunk_node (node, NULL) == node);
Here's a couple of dumps of the two decls if that helps.
(gdb) frame 1
(gdb) ptree node->decl
>
SI
size
unit size
align 32 symtab 0 alias set -1 canonical type 0xfffb6fe9108 method
basetype
arg-types
chain >>
pointer_to_this >
addressable used public static decl_5 SI file
/home/bergner/gcc/gcc-mainline-20110614/libstdc++-v3/libsupc++/array_type_info.cc
line 29 col 1 align 32 context
initial abstract_origin
arguments
readonly unsigned SI size unit size
align 32 symtab 4095 alias set -1 canonical type 0xfffb6fe8fb8>
readonly used unsigned SI file
/home/bergner/gcc/gcc-mainline-20110614/libstdc++-v3/libsupc++/array_type_info.cc
line 30 col 21 size unit size
align 32 context
abstract_origin arg-type >
result
ignored VOID file
/home/bergner/gcc/gcc-mainline-20110614/libstdc++-v3/libsupc++/array_type_info.cc
line 31 col 2
align 8 context >
full-name "__cxxabiv1::__array_type_info::~__array_type_info()"
pending-inline-info 0xfffb6d25c50
(mem:SI (symbol_ref:SI ("_ZN10__cxxabiv117__array_type_infoD1Ev") [flags
0x1] ) [0 S4 A32])
struct-function 0xfffb6e08890 chain >
(gdb) p cgraph_function_or_thunk_node (node, NULL)
$9 = (struct cgraph_node *) 0xfffb6fb9000
(gdb) ptree $9->decl
>
SI
size
unit size
align 32 symtab 0 alias set -1 canonical type 0xfffb6fe9108 method
basetype
arg-types
chain >>
pointer_to_this >
asm_written public static decl_5 SI file
/home/bergner/gcc/gcc-mainline-20110614/libstdc++-v3/libsupc++/array_type_info.cc
line 29 col 1 align 32 context
initial abstract_origin
arguments
readonly unsigned SI size unit size
align 32 symtab 4095 alias set -1 canonical type 0xfffb6fe8fb8>
readonly used unsigned SI file
/home/bergner/gcc/gcc-mainline-20110614/libstdc++-v3/libsupc++/array_type_info.cc
line 30 col 21 size unit size
align 32 context
abstract_origin
(mem/f/c/i:SI (plus:SI (reg/f:SI 113 sfp)
(const_int 8 [0x8])) [0 this+0 S4 A32]) arg-type
incoming-rtl (reg:SI 3 3 [ this ])>
result
ignored VOID file
/home/bergner/gcc/gcc-mainline-20110614/libstdc++-v3/libsupc++/array_type_info.cc
line 31 col 2
align 8 context >
full-name "__cxxabiv1::__array_type_info::~__array_type_info()"
pending-inline-info 0xfffb6d25b70
(mem:SI (symbol_ref:SI ("_ZN10__cxxabiv117__array_type_infoD2Ev") [flags
0x1] ) [0 S4 A32]) chain
>
[Bug debug/48459] [4.6/4.7 Regression] avr: Assertion failure with -gdwarf-2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48459 Richard Henderson changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #31 from Richard Henderson 2011-06-17 15:50:27 UTC --- You're right. And now I remember the other patch to dwarf2out.c that went along with fixing up the errors in avr.c wrt dwarf2. I must backport them both.
[Bug target/43603] gcc-4.4.3 ICE on ia64 with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43603 --- Comment #24 from Andrey Belevantsev 2011-06-17 15:08:55 UTC --- Thanks for reminder, I've started bootstap and test on ia64 and x86-64.
[Bug libstdc++/49445] Undefined reference to std::atomic "operator float"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49445 --- Comment #5 from Juan Pedro Bolívar Puente 2011-06-17 14:41:03 UTC --- You are right, I thought it worked for all fundamental types but reviewing the proposal [1] makes me realise I was wrong. It remains unclear wether user defined enums should work ... Thanks a lot for the fast reply and sorry for the mistake. [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html
[Bug libgcj/49314] md5test, shatest output FAILs on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49314 --- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-06-17 14:06:12 UTC --- > pr49441 is a totally different issue. That bug manifests itself as a runtime > error with unresolved symbols from libiconv. I still don't understand why we > just don't link libgcj directly against libiconv to avoid needing libgcj.spec > to pass anything for libiconv. Fully agreed: the gcc runtime libraries should just be self-contained. Rainer
[Bug target/43603] gcc-4.4.3 ICE on ia64 with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43603 --- Comment #23 from devurandom at gmx dot net 2011-06-17 14:04:50 UTC --- (In reply to comment #22) > (In reply to comment #20) > > Created attachment 24112 [details] > > backported patch > > > > Good. Then attached is the initial backport, I have just verified that it > > passes the testcase. It would be great if the Gentoo folks could test it in > > their setup, too. If all goes well, I will apply it to 4_4-branch at the > > beginning of May. > Is this applied to any branch yet? Confirming that the attached patch allows compilation of Erlang 14B03 when applied to GCC 4.4.5.
[Bug libgcj/49456] New: getstacktrace and getallthreads tests timeout on IRIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49456 Summary: getstacktrace and getallthreads tests timeout on IRIX Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org CC: tro...@gcc.gnu.org, a...@gcc.gnu.org Host: mips-sgi-irix6.5 Target: mips-sgi-irix6.5 Build: mips-sgi-irix6.5 The last two failing libjava tests on IRIX 6.5 are getstacktrace and getallthreads, both of which timeout. At first I thought this might be related to PR libgcj/49455, but unlike that case the present tests also hang if running with a debug-enabled libgcj.so.
[Bug libgcj/49314] md5test, shatest output FAILs on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49314 Jack Howarth changed: What|Removed |Added CC||howarth at nitro dot ||med.uc.edu --- Comment #9 from Jack Howarth 2011-06-17 14:01:23 UTC --- (In reply to comment #8) > > --- Comment #7 from Dominique d'Humieres > > 2011-06-17 13:04:17 UTC --- > > Could this pr be related to pr49441? > > No: the iconv functions only live in libiconv (no stubs in libc), and > that is present in libgcj.spec and linked into the test programs. > > Rainer pr49441 is a totally different issue. That bug manifests itself as a runtime error with unresolved symbols from libiconv. I still don't understand why we just don't link libgcj directly against libiconv to avoid needing libgcj.spec to pass anything for libiconv.
[Bug libgcj/49455] New: Thread_Interrupt Looper subtest FAILs on IRIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49455 Summary: Thread_Interrupt Looper subtest FAILs on IRIX Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org CC: tro...@gcc.gnu.org, a...@gcc.gnu.org Host: mips-sgi-irix6.5 Target: mips-sgi-irix6.5 Build: mips-sgi-irix6.5 The Looper subtest of Thread_Interrupt FAILs on IRIX 6.5, as can be seen in the following diff between expected and found outputs: --- /vol/gcc/src/hg/trunk/local/libjava/testsuite/libjava.lang/Thread_Interrupt.out Mon Mar 1 20:33:06 2010 +++ Thread_Interrupt.outFri Jun 10 17:14:23 2011 @@ -3,6 +3,6 @@ sleep() interrupted - ok Busy waiting -interrupted - ok +Error: Busy wait was not interrupted. join() interrupted - ok Unfortunately, if running the test under gdb, it just hangs in the first subtest, so the only hope was adding debug printfs. Strangely, when I added fprintf (stderr, ": \n") calls to all functions in posix-threads.cc, the test suddenly passes when ignoring the debug output. I'm somewhat at at loss how to further debug this.
[Bug target/49454] New: [4.7 Regression] /usr/include/libio.h:336:3: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49454 Summary: [4.7 Regression] /usr/include/libio.h:336:3: internal compiler error: Segmentation fault Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org Host: hppa*-*-* (32-bit) Target: hppa*-*-* (32-bit) Build: hppa*-*-* (32-bit) /home/dave/gnu/gcc/objdir/./gcc/xgcc -B/home/dave/gnu/gcc/objdir/./gcc/ -B/home/ dave/opt/gnu/gcc/gcc-4.5/hppa-linux/bin/ -B/home/dave/opt/gnu/gcc/gcc-4.5/hppa-l inux/lib/ -isystem /home/dave/opt/gnu/gcc/gcc-4.5/hppa-linux/include -isystem /h ome/dave/opt/gnu/gcc/gcc-4.5/hppa-linux/sys-include-g -O2 -O2 -g -O2 -DIN_G CC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototyp es -Wold-style-definition -isystem ./include -fPIC -DELF=1 -DLINUX=1 -g -DHAVE _GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -fbuilding-libgcc -fno-stack -protector -I. -I. -I../.././gcc -I../../../gcc/libgcc -I../../../gcc/libgcc/. -I../../../gcc/libgcc/../gcc -I../../../gcc/libgcc/../include-o _negdi2.o - MT _negdi2.o -MD -MP -MF _negdi2.dep -DL_negdi2 -c ../../../gcc/libgcc/../gcc/li bgcc2.c \ -fvisibility=hidden -DHIDE_EXPORTS In file included from /usr/include/stdio.h:75:0, from ../../../gcc/libgcc/../gcc/tsystem.h:87, from ../../../gcc/libgcc/../gcc/libgcc2.c:29: /usr/include/libio.h:336:3: internal compiler error: Segmentation fault This is in stage2. First seen in revision 175083. 175007 was ok.
[Bug c++/49450] not possible to call explicit destructor of std::string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49450 Johnny Willemsen changed: What|Removed |Added Resolution|FIXED |INVALID --- Comment #4 from Johnny Willemsen 2011-06-17 13:39:20 UTC --- correct status
[Bug bootstrap/49383] [4.7 regression] powerpc64-linux bootstrap failure due to ice in cgraph_only_called_directly_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49383 William J. Schmidt changed: What|Removed |Added CC||wschmidt at gcc dot gnu.org --- Comment #1 from William J. Schmidt 2011-06-17 13:37:45 UTC --- Here's a backtrace: #0 fancy_abort (file=0x10d1b918 "/home/wschmidt/gcc/gcc-mainline-pr49383/gcc/cgraph.c", line=3012, function=0x10d1b870 "cgraph_only_called_directly_p") at /home/wschmidt/gcc/gcc-mainline-pr49383/gcc/diagnostic.c:893 #1 0x103db28c in cgraph_only_called_directly_p (node=Unhandled dwarf expression opcode 0xf3 ) at /home/wschmidt/gcc/gcc-mainline-pr49383/gcc/cgraph.c:3012 #2 0x10991bbc in call_ABI_of_interest (fndecl=Unhandled dwarf expression opcode 0xf3 ) at /home/wschmidt/gcc/gcc-mainline-pr49383/gcc/config/rs6000/rs6000.c:7422 #3 0x109a4848 in init_cumulative_args (cum=0xfffd4d0, fntype=0xfffb6ff9108, libname=Unhandled dwarf expression opcode 0xf3 ) at /home/wschmidt/gcc/gcc-mainline-pr49383/gcc/config/rs6000/rs6000.c:7485 #4 0x1039ed88 in expand_call (exp=0xfffb6f6fa00, target=0x0, ignore=Unhandled dwarf expression opcode 0xf3 ) at /home/wschmidt/gcc/gcc-mainline-pr49383/gcc/calls.c:2248 #5 0x1049c724 in expand_expr_real_1 (exp=0xfffb6f6fa00, target=, tmode=Unhandled dwarf expression opcode 0xf3 ) at /home/wschmidt/gcc/gcc-mainline-pr49383/gcc/expr.c:9351 #6 0x103aff98 in expand_call_stmt (stmt=0xfffb7034c80) at /home/wschmidt/gcc/gcc-mainline-pr49383/gcc/cfgexpand.c:1870 #7 expand_gimple_stmt_1 (stmt=0xfffb7034c80) at /home/wschmidt/gcc/gcc-mainline-pr49383/gcc/cfgexpand.c:1907 #8 expand_gimple_stmt (stmt=0xfffb7034c80) at /home/wschmidt/gcc/gcc-mainline-pr49383/gcc/cfgexpand.c:2054 #9 0x103b1434 in expand_gimple_basic_block (bb=0xfffb6ea96b8) at /home/wschmidt/gcc/gcc-mainline-pr49383/gcc/cfgexpand.c:3637 #10 0x103b7d24 in gimple_expand_cfg () at /home/wschmidt/gcc/gcc-mainline-pr49383/gcc/cfgexpand.c:4120 #11 0x10670860 in execute_one_pass (pass=0x10fd0a28) at /home/wschmidt/gcc/gcc-mainline-pr49383/gcc/passes.c:2023 #12 0x10670c50 in execute_pass_list (pass=0x10fd0a28) at /home/wschmidt/gcc/gcc-mainline-pr49383/gcc/passes.c:2078 #13 0x107b2cc0 in tree_rest_of_compilation (fndecl=0xfffb6f8c900) at /home/wschmidt/gcc/gcc-mainline-pr49383/gcc/tree-optimize.c:416 #14 0x103e1d20 in cgraph_expand_function (node=0xfffb6fc9240) at /home/wschmidt/gcc/gcc-mainline-pr49383/gcc/cgraphunit.c:1768 #15 0x103e41a8 in cgraph_expand_all_functions () at /home/wschmidt/gcc/gcc-mainline-pr49383/gcc/cgraphunit.c:1827 #16 cgraph_optimize () at /home/wschmidt/gcc/gcc-mainline-pr49383/gcc/cgraphunit.c:2090 #17 0x103e49c8 in cgraph_finalize_compilation_unit () at /home/wschmidt/gcc/gcc-mainline-pr49383/gcc/cgraphunit.c:1269 #18 0x101b5d54 in cp_write_global_declarations () at /home/wschmidt/gcc/gcc-mainline-pr49383/gcc/cp/decl2.c:4006 #19 0x1073bbf8 in compile_file () at /home/wschmidt/gcc/gcc-mainline-pr49383/gcc/toplev.c:587 #20 do_compile () at /home/wschmidt/gcc/gcc-mainline-pr49383/gcc/toplev.c:1924 #21 toplev_main () at /home/wschmidt/gcc/gcc-mainline-pr49383/gcc/toplev.c:1996 #22 0x100b3f34 in main (argc=, argv=) at /home/wschmidt/gcc/gcc-mainline-pr49383/gcc/main.c:36
[Bug c++/49450] not possible to call explicit destructor of std::string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49450 Johnny Willemsen changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from Johnny Willemsen 2011-06-17 13:34:58 UTC --- user error
[Bug c++/49450] not possible to call explicit destructor of std::string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49450 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #2 from Daniel Krügler 2011-06-17 13:32:44 UTC --- (In reply to comment #0) > We want to use C++0x unions with a std::string as member (see for example > http://www2.research.att.com/~bs/C++0xFAQ.html#unions). At the moment we want > to call the ~string we get an error. Your program is not conforming according to the standard. You need to write s.std::string::~string(); instead.
[Bug libfortran/48787] Invalid UP/DOWN rounding with F editing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48787 --- Comment #23 from Dominique d'Humieres 2011-06-17 13:32:33 UTC --- For 'gcc version 4.6.0 20110313 (experimental) [trunk revision 170921p5] (GCC)' I get 7501. -7501.
[Bug libobjc/36610] objc_msg_sendv is broken for targets which pass argument via registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36610
--- Comment #25 from Dominique d'Humieres
2011-06-17 13:29:33 UTC ---
I have the following patch in my working tree without regression
--- /opt/gcc/_clean/gcc/testsuite/objc.dg/torture/forward-1.m2011-06-07
16:48:47.0 +0200
+++ /opt/gcc/work/gcc/testsuite/objc.dg/torture/forward-1.m2011-06-07
17:10:00.0 +0200
@@ -1,7 +1,5 @@
/* { dg-do run } */
/* See if -forward:: is able to work. */
-/* { dg-xfail-run-if "PR36610" { ! { { i?86-*-* x86_64-*-* } && ilp32 } } {
"-fgnu-runtime" } { "" } } */
-/* { dg-skip-if "Needs OBJC2 Implementation" { *-*-darwin* && { lp64 } } {
"-fnext-runtime" } { "" } } */
#include
#include
[Bug libobjc/36610] objc_msg_sendv is broken for targets which pass argument via registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36610 --- Comment #24 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-06-17 13:23:39 UTC --- > --- Comment #23 from Nicola Pero 2011-06-14 > 18:26:40 UTC --- [...] > Summarizing, I would close the bug, or leave it open but just to remind me/us > to: > > * remove the existing forwarding code from libobjc; > > * remove the forward-1.m testcase; Since the test now seems to pass everywhere, we could just remove the xfail instead. > * add new testcases for the libobjc forwarding hooks. As these are the > official > ways to use forwarding (and the only ones available), we should have > testcases. Agreed, but that's orthogonal to the issue at hand. Whatever is done, we should soon remove the annoying XFAILs of objc.dg/torture/forward-1.m. Thanks. Rainer
[Bug libfortran/48787] Invalid UP/DOWN rounding with F editing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48787 --- Comment #22 from Thomas Henlich 2011-06-17 13:22:42 UTC --- This is kind of bad: print "(RU,F7.0)", 7500.0 ! 8. expected 7500. print "(RD,F7.0)", -7500.0 ! -8. expected -7500.
[Bug c++/49453] New: Accepts invalid syntax for partial specialization of class template where the specialization is a class template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49453
Summary: Accepts invalid syntax for partial specialization of
class template where the specialization is a class
template
Product: gcc
Version: 4.3.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nimantha.siriward...@googlemail.com
Example:
#include
template
struct foo{
typedef F value_type;
};
template
struct bar{};
//template<> <- works if commented out or not
template
struct bar >
{
typename foo::value_type val;
};
int main(void)
{
typedef foo F;
typedef bar B;
B b;
b.val = 10;
std::cout << b.val << std::endl;
return 0;
};
I have been led to believe that this is incorrect behaviour, have tested on
4.4.4 and 4.5.1 and this appears to be the same.
[Bug libgcj/49314] md5test, shatest output FAILs on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49314 --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-06-17 13:09:06 UTC --- > --- Comment #7 from Dominique d'Humieres > 2011-06-17 13:04:17 UTC --- > Could this pr be related to pr49441? No: the iconv functions only live in libiconv (no stubs in libc), and that is present in libgcj.spec and linked into the test programs. Rainer
[Bug java/49441] @LDLIBICONV@ lost from installed libgcj.spec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49441 --- Comment #4 from Dominique d'Humieres 2011-06-17 13:05:33 UTC --- PR49314 reports also problems with iconv and java.
[Bug libgcj/49314] md5test, shatest output FAILs on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49314 --- Comment #7 from Dominique d'Humieres 2011-06-17 13:04:17 UTC --- Could this pr be related to pr49441?
[Bug java/49441] @LDLIBICONV@ lost from installed libgcj.spec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49441 --- Comment #3 from Jack Howarth 2011-06-17 12:50:52 UTC --- How is gcj supposed to properly find its linkage libraries on x86_64 linux when using -m32? Since only a single copy of libgcj.spec is installed and used for both the default -m64 and -m32, this seems impossible to handle both via that mechanism (ie passing -L/usr/lib64 -liconv for -m64 and -L/usr/lib -liconv for -m32). It seems much better to simply drop @LDLIBICONV@ entirely from libgcj,spec.in and move @LDLIBICONV@ onto the linkage of libgcj itself (since it seems to be the only place were the iconv symbols are generated or used).
[Bug libstdc++/49445] Undefined reference to std::atomic "operator float"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49445 --- Comment #4 from Marc Glisse 2011-06-17 12:07:53 UTC --- (In reply to comment #3) > It looks like C++11 only defines atomic and atomic, so a > link-time error on atomic seems ok, no? Sorry, please ignore the above comment, I should have read the standard properly before posting.
[Bug tree-optimization/49452] New testsuite failures with arm-linux-gnueabi comp-goto failing with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452
--- Comment #1 from Ramana Radhakrishnan 2011-06-17
12:02:10 UTC ---
One of the differences I must say I noticed is that at O2 - the call to y has a
NORETURN attribute marked to it but there's no reason why this should be marked
as NORETURN - surely there is a flow of control that allows control to go out
of the function.
x(a)
{
__label__ xlab;
void y(a)
{
void *x = &&llab;
if (a==-1)
goto *x;
if (a==0)
goto xlab;
llab:
y (a-1);
}
y (a);
xlab:;
return a;
}
(call_insn/c/i 11 10 12 3 (parallel [
(call (mem:SI (symbol_ref:SI ("y.2104") [flags 0x3] ) [0 y S4 A32])
(const_int 0 [0]))
(use (const_int 0 [0]))
(clobber (reg:SI 14 lr))
])
/home/ramrad01/sources/fsf/trunk/gcc/testsuite/gcc.c-torture/execute/comp-goto-2.c:23
-1
(expr_list:REG_NORETURN (const_int 0 [0])
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil)))
(expr_list:REG_DEP_TRUE (use (reg:SI 0 r0))
(expr_list:REG_DEP_TRUE (use (reg:SI 12 ip))
(nil
[Bug tree-optimization/49452] New: New testsuite failures with arm-linux-gnueabi comp-goto failing with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452 Summary: New testsuite failures with arm-linux-gnueabi comp-goto failing with Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: ram...@gcc.gnu.org Host: i686-linux-gnu Target: arm-linux-gnueabi These failures have shown up in the last few days with arm-linux-gnueabi FAIL: gcc.c-torture/execute/comp-goto-2.c execution, -O2 FAIL: gcc.c-torture/execute/comp-goto-2.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/comp-goto-2.c execution, -O3 -g FAIL: gcc.c-torture/execute/comp-goto-2.c execution, -Os FAIL: gcc.c-torture/execute/comp-goto-2.c execution, -O2 -flto -flto-partition=none FAIL: gcc.c-torture/execute/comp-goto-2.c execution, -O2 -flto I haven't looked at in great detail yet to analyse what causes this problem but it appears to have appeared in the last week or so. GCC was configured as : --target=arm-none-linux-gnueabi --enable-languages=c,c++,fortran --with-cpu=cortex-a9 --with-fpu=neon --with-float=softfp cheers Ramana
[Bug libgcj/49451] New: FileHandleGcTest FAILS on IRIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49451
Summary: FileHandleGcTest FAILS on IRIX
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcj
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: tro...@gcc.gnu.org, a...@gcc.gnu.org, hans.bo...@hp.com
Host: mips-sgi-irix6.5
Target: mips-sgi-irix6.5
Build: mips-sgi-irix6.5
The FileHandleGcTest FAILS on IRIX 6.5 (both N32 and N64 ABIs):
FAIL: FileHandleGcTest execution - source compiled test
FAIL: FileHandleGcTest -findirect-dispatch execution - source compiled test
FAIL: FileHandleGcTest -O3 execution - source compiled test
FAIL: FileHandleGcTest -O3 -findirect-dispatch execution - source compiled test
In the log, I find:
/proc open failed
This message is ultimately from boehm-gc/dyn_load.c
(GC_register_dynamic_libraries) or boehm-gc/os_dep.c (GC_dirty_init). I had to
add a discriminator to the message to find it's the former. Running the test
under par, I find
1061mS[ 3]FileHandleGcTest(69051502): open("/dev/null", O_RDONLY, 0666) =
1023
1062mS[ 3]FileHandleGcTest(69051502): open("/dev/null", O_RDONLY, 0666) errno
= 24 (Too many open files)
1063mS[ 3]FileHandleGcTest(69051502): open("/proc/69051502", O_RDONLY, 0)
errn
o = 24 (Too many open files)
1063mS[ 3]FileHandleGcTest(69051502): write(2, "/proc open failed\n", 18) =
18
open 1056 0.07 72.78
When in gnu/java/nio/channels/natFileChannelPosix.cc (FileChannelImpl::open) an
open call fails, the code runs
::java::lang::System::gc ();
::java::lang::System::runFinalization ();
to try and free fds. Unfortunately, in boehm-gc
(GC_register_dynamic_libraries)
an attempt is made to open /proc/, which of course fails and calls
abort().
This doesn't happen on either Solaris or Tru64 UNIX because those use their
own implementations of GC_register_dynamic_libraries which don't need
additional file descriptors.
I guess something similar can be implemented on IRIX, using __rld_obj_head
described in rld(5). I''ll probably give it a try.
[Bug libstdc++/49445] Undefined reference to std::atomic "operator float"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49445 Marc Glisse changed: What|Removed |Added CC||marc.glisse at normalesup ||dot org --- Comment #3 from Marc Glisse 2011-06-17 11:43:16 UTC --- It looks like C++11 only defines atomic and atomic, so a link-time error on atomic seems ok, no?
[Bug rtl-optimization/48542] unchanged variables in code which calls setjmp may be clobbered (including the return-address)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48542 Hans-Peter Nilsson changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.7.0 |4.3.6 Summary|mmix code which calls |unchanged variables in code |setjmp/longjmp may not |which calls setjmp may be |work. |clobbered (including the ||return-address) --- Comment #18 from Hans-Peter Nilsson 2011-06-17 11:38:05 UTC --- Fixed on all open branches. Plus title change to reflect the general nature of the bug. Actually s/variables/registers/ but let's keep it user-friendly when we can.
[Bug c++/49450] not possible to call explicit destructor of std::string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49450 --- Comment #1 from Johnny Willemsen 2011-06-17 11:32:51 UTC --- g++-4.6 (SUSE Linux) 4.6.0 20110505 [gcc-4_6-branch revision 173419] Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug tree-optimization/49115] [4.5/4.6 Regression] invalid return value optimization (?) when exception is thrown and caught
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49115 --- Comment #4 from Richard Guenther 2011-06-17 11:27:41 UTC --- Author: rguenth Date: Fri Jun 17 11:27:37 2011 New Revision: 175148 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175148 Log: 2011-06-17 Richard Guenther Backport from mainline 2011-05-23 Richard Guenther PR tree-optimization/49115 * tree-ssa-alias.c (stmt_kills_ref_p_1): If the assignment is not necessarily carried out, do not claim it kills the ref. * tree-ssa-dce.c (mark_aliased_reaching_defs_necessary_1): Likewise. * g++.dg/torture/pr49115.C: New testcase. Added: branches/gcc-4_6-branch/gcc/testsuite/g++.dg/torture/pr49115.C Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/gcc/tree-ssa-alias.c branches/gcc-4_6-branch/gcc/tree-ssa-dce.c
[Bug rtl-optimization/48542] mmix code which calls setjmp/longjmp may not work.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48542 --- Comment #17 from Hans-Peter Nilsson 2011-06-17 11:25:56 UTC --- Author: hp Date: Fri Jun 17 11:25:53 2011 New Revision: 175147 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175147 Log: PR rtl-optimization/48542 * gcc.dg/torture/pr48542.c: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/torture/pr48542.c Modified: branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/48542] mmix code which calls setjmp/longjmp may not work.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48542 --- Comment #16 from Hans-Peter Nilsson 2011-06-17 11:24:57 UTC --- Author: hp Date: Fri Jun 17 11:24:55 2011 New Revision: 175146 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175146 Log: PR rtl-optimization/48542 * reload.c (find_equiv_reg): Stop looking when finding a setjmp-type call. * reload1.c (reload_as_needed): Invalidate all reload registers when crossing a setjmp-type call. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/reload.c branches/gcc-4_3-branch/gcc/reload1.c
[Bug target/43603] gcc-4.4.3 ICE on ia64 with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43603 --- Comment #22 from devurandom at gmx dot net 2011-06-17 11:21:02 UTC --- (In reply to comment #20) > Created attachment 24112 [details] > backported patch > > Good. Then attached is the initial backport, I have just verified that it > passes the testcase. It would be great if the Gentoo folks could test it in > their setup, too. If all goes well, I will apply it to 4_4-branch at the > beginning of May. Is this applied to any branch yet?
[Bug rtl-optimization/48542] mmix code which calls setjmp/longjmp may not work.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48542 --- Comment #15 from Hans-Peter Nilsson 2011-06-17 11:20:41 UTC --- Author: hp Date: Fri Jun 17 11:20:38 2011 New Revision: 175145 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175145 Log: PR rtl-optimization/48542 * gcc.dg/torture/pr48542.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/torture/pr48542.c Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/48542] mmix code which calls setjmp/longjmp may not work.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48542 --- Comment #14 from Hans-Peter Nilsson 2011-06-17 11:20:05 UTC --- Author: hp Date: Fri Jun 17 11:20:01 2011 New Revision: 175144 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175144 Log: PR rtl-optimization/48542 * reload.c (find_equiv_reg): Stop looking when finding a setjmp-type call. * reload1.c (reload_as_needed): Invalidate all reload registers when crossing a setjmp-type call. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/reload.c branches/gcc-4_4-branch/gcc/reload1.c
[Bug rtl-optimization/48542] mmix code which calls setjmp/longjmp may not work.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48542 --- Comment #13 from Hans-Peter Nilsson 2011-06-17 11:18:39 UTC --- Author: hp Date: Fri Jun 17 11:18:37 2011 New Revision: 175142 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175142 Log: PR rtl-optimization/48542 * gcc.dg/torture/pr48542.c: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/torture/pr48542.c Modified: branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/48542] mmix code which calls setjmp/longjmp may not work.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48542 --- Comment #12 from Hans-Peter Nilsson 2011-06-17 11:17:37 UTC --- Author: hp Date: Fri Jun 17 11:17:34 2011 New Revision: 175141 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175141 Log: PR rtl-optimization/48542 * reload.c (find_equiv_reg): Stop looking when finding a setjmp-type call. * reload1.c (reload_as_needed): Invalidate all reload registers when crossing a setjmp-type call. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/reload.c branches/gcc-4_5-branch/gcc/reload1.c
[Bug rtl-optimization/48542] mmix code which calls setjmp/longjmp may not work.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48542 --- Comment #11 from Hans-Peter Nilsson 2011-06-17 11:15:39 UTC --- Author: hp Date: Fri Jun 17 11:15:35 2011 New Revision: 175140 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175140 Log: PR rtl-optimization/48542 * gcc.dg/torture/pr48542.c: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/torture/pr48542.c Modified: branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/48542] mmix code which calls setjmp/longjmp may not work.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48542 --- Comment #10 from Hans-Peter Nilsson 2011-06-17 11:13:42 UTC --- Author: hp Date: Fri Jun 17 11:13:38 2011 New Revision: 175139 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175139 Log: PR rtl-optimization/48542 * reload.c (find_equiv_reg): Stop looking when finding a setjmp-type call. * reload1.c (reload_as_needed): Invalidate all reload registers when crossing a setjmp-type call. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/reload.c branches/gcc-4_6-branch/gcc/reload1.c
[Bug c++/49450] New: not possible to call explicit destructor of std::string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49450
Summary: not possible to call explicit destructor of
std::string
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jwillem...@remedy.nl
We want to use C++0x unions with a std::string as member (see for example
http://www2.research.att.com/~bs/C++0xFAQ.html#unions). At the moment we want
to call the ~string we get an error.
Reproducer:
#include
int main ()
{
std::string s;
s.~string();
return 0;
}
message
g++-4.6 -c t.cpp
t.cpp: In function ‘int main()’:
t.cpp:6:11: error: expected class-name before ‘(’ token
[Bug ada/48835] Porting GNAT to GNU/Linux/m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835 --- Comment #14 from Mikael Pettersson 2011-06-17 10:02:21 UTC --- Partial success: I've just managed to bootstrap gcc-4.1.2 w/ gnat on m68k-linux. Lots of patches applied though.
[Bug libgcj/49314] md5test, shatest output FAILs on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49314 --- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-06-17 09:56:50 UTC --- As a quick hack, I've just removed the definition of HAVE_ICONV and rebuilt libgcj.so. This way, testsuite results are clean. I'll have to further investigate (preferably with a small C program) what's going on here. Rainer
[Bug libstdc++/49445] Undefined reference to std::atomic "operator float"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49445 --- Comment #2 from Juan Pedro Bolívar Puente 2011-06-17 09:35:29 UTC --- Created attachment 24553 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24553 Test case for the "undefined reference" on atom bug raskolnikov@nexus9:~$ make CXXFLAGS=-std=c++0x test_atom g++ -std=c++0xtest_atom.cpp -o test_atom /tmp/ccS68VP3.o: In function `main': test_atom.cpp:(.text+0x18): undefined reference to `std::atomic::operator float() const' collect2: ld returned 1 exit status make: *** [test_atom] Error 1
[Bug tree-optimization/49361] [4.7 Regression] Huge 470.lbm regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49361 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #5 from Richard Guenther 2011-06-17 09:11:27 UTC --- Fixed.
[Bug tree-optimization/49444] IV-OPTs changes an unaligned loads into aligned loads incorrectly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49444 --- Comment #4 from Richard Guenther 2011-06-17 09:06:22 UTC --- (In reply to comment #3) > Something like this: > Index: tree-ssa-loop-ivopts.c > === > --- tree-ssa-loop-ivopts.c(revision 61384) > +++ tree-ssa-loop-ivopts.c(working copy) > @@ -6066,6 +6066,8 @@ rewrite_use_address (struct ivopts_data >tree base_hint = NULL_TREE; >tree ref, iv; >bool ok; > + unsigned align; > + tree type; > >adjust_iv_update_pos (cand, use); >ok = get_computation_aff (data->current_loop, use, cand, use->stmt, &aff); > @@ -6087,7 +6089,10 @@ rewrite_use_address (struct ivopts_data > base_hint = var_at_stmt (data->current_loop, cand, use->stmt); > >iv = var_at_stmt (data->current_loop, cand, use->stmt); > - ref = create_mem_ref (&bsi, TREE_TYPE (*use->op_p), &aff, > + align = get_object_alignment (*use->op_p, BIGGEST_ALIGNMENT); > + type = TREE_TYPE (*use->op_p); > + type = build_aligned_type (type, align); > + ref = create_mem_ref (&bsi, type, &aff, > reference_alias_ptr_type (*use->op_p), > iv, base_hint, data->speed); >copy_ref_info (ref, *use->op_p); Well, that will then still run into the indirect-ref issue as the expansion for target-mem-refs and mem-refs works the same way. Only targets that support movmisalign will generate unaligned loads (which targets currently only define for vector modes I think).
[Bug libstdc++/49445] Undefined reference to std::atomic "operator float"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49445 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.06.17 09:04:32 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2011-06-17 09:04:32 UTC --- Testcase?
[Bug libmudflap/49449] -fmudflapth -lmudflapth problems with -fvisibility=hidden, missing posix_memalign wrapper and pointers in varargs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49449 Richard Guenther changed: What|Removed |Added CC||fche at redhat dot com --- Comment #1 from Richard Guenther 2011-06-17 09:03:13 UTC --- The mudflap code is unfortunately completely unmaintained.
[Bug fortran/47516] testsuite failure: realloc_on_assign_2.f03 (with --disable-bootstrap)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47516 Tobias Burnus changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #6 from Tobias Burnus 2011-06-17 08:59:44 UTC --- Close as fixed as a patch has been committed. I assume, no one can reproduce it any more?
[Bug libgcj/49315] Throw_2 SEGVs on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49315 Rainer Orth changed: What|Removed |Added Target|alpha-dec-osf5.1b |alpha-dec-osf5.1b ||mips-sgi-irix6.5 Status|UNCONFIRMED |RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-06/msg01239.htm ||l Host|alpha-dec-osf5.1b |alpha-dec-osf5.1b, ||mips-sgi-irix6.5 AssignedTo|unassigned at gcc dot |ro at gcc dot gnu.org |gnu.org | Resolution||FIXED Target Milestone|--- |4.7.0 Build|alpha-dec-osf5.1b |alpha-dec-osf5.1b ||mips-sgi-irix6.5 --- Comment #2 from Rainer Orth 2011-06-17 08:36:17 UTC --- Fixed for 4.7.0, also fixes the same problem on IRIX 6.5.
[Bug libgcj/49315] Throw_2 SEGVs on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49315 --- Comment #1 from Rainer Orth 2011-06-17 08:33:17 UTC --- Author: ro Date: Fri Jun 17 08:33:13 2011 New Revision: 175138 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175138 Log: PR libgcj/49315 * include/solaris-signal.h: Rename to ... * include/posix-signal.h: ... this. (SA_FLAGS): Define. (SIGNAL_HANDLER): Handle non-SA_SIGINFO case. (sa_signal_handler): Define. (_INIT_SIG_HANDLER): New macro. (INIT_SEGV, INIT_FPE): Use it. * configure.ac (SIGNAL_HANDLER): Use it on alpha*-dec-osf*, mips-sgi-irix*, *-*-solaris2* * configure: Regenerate. * include/aix-signal.h: Refer to AIX. * configure.host (alpha*-dec-osf*): Enable can_unwind_signal. (mips-sgi-irix6*): Likewise. Added: trunk/libjava/include/posix-signal.h - copied, changed from r175137, trunk/libjava/include/solaris-signal.h Removed: trunk/libjava/include/solaris-signal.h Modified: trunk/libjava/ChangeLog trunk/libjava/configure trunk/libjava/configure.ac trunk/libjava/configure.host trunk/libjava/include/aix-signal.h
[Bug rtl-optimization/44194] struct returned by value generates useless stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194 --- Comment #28 from rguenther at suse dot de 2011-06-17 08:21:30 UTC --- On Thu, 16 Jun 2011, eraman at google dot com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194 > > --- Comment #27 from Easwaran Raman 2011-06-16 > 17:14:38 UTC --- > (In reply to comment #26) > > On Wed, 15 Jun 2011, xinliangli at gmail dot com wrote: > > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194 > > > > > > davidxl changed: > > > > > >What|Removed |Added > > > > > > CC||xinliangli at gmail dot > > > com > > > > > > --- Comment #23 from davidxl 2011-06-15 > > > 23:14:50 UTC --- > > > (In reply to comment #22) > > > > > 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. > > > > It also should use create_tmp_var, not create_tmp_reg. But I wonder why > > memory allocated via assign_temp isn't marked in a way to let dse > > do its job (I guess dse thinks that memory escapes?). > If the mem rtx doesn't have a tree_expression associated with it, DSE assumes > the memory escapes. Hmm, ok. I guess it can't really do better. > > > > 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)? > > > > > > It would be nice if the expander does not spill the return into memory in > > > the > > > first place if possible. On other hand tagging compiler created memory > > > location with temp decls so that aliaser has the symbolic information > > > seems a > > > useful mechanism. > > > > Sure - but I wonder why assign_temp doesn't do something equivalent > > that doesn't require a automatic VAR_DECL to be created. > > > > Where does the aliaser catch things with the VAR_DECL around that > > it doesn't without it? > > Is it just that when I create a VAR_DECL, TREE_ADDRESSABLE is false and > may_be_aliased returns true? false, yes. Richard.
[Bug tree-optimization/49442] [4.5/4.6/4.7 Regression] Misaligned store support pessimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49442
--- Comment #3 from Jakub Jelinek 2011-06-17
08:15:38 UTC ---
ICC apparently has __assume_aligned (ptr, align) for this, and also
#pragma vector {aligned,unaligned,always,nontemporal}.
For alignment, I'd say having both hard alignment and likely alignment hints
somewhere in the code would be better than ptr_align attribute on the
arguments,
so something like
__builtin_assume_aligned (ptr, align[, misalign])
and
__builtin_likely_aligned (ptr, align[, misalign]);
would be helpful. The question is if they shouldn't return the pointer again,
and let the user write it in the form
ptr = __builtin_assume_aligned (ptr, 16);
which would be optimized away when we compute the alignment.
[Bug other/49448] gcc configure script wrongly detect TARGET_BIG_ENDIAN_DEFAULT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49448 --- Comment #1 from Andreas Schwab 2011-06-17 07:26:12 UTC --- It should use $target_cpu.
[Bug libmudflap/49449] New: -fmudflapth -lmudflapth problems with -fvisibility=hidden, missing posix_memalign wrapper and pointers in varargs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49449 Summary: -fmudflapth -lmudflapth problems with -fvisibility=hidden, missing posix_memalign wrapper and pointers in varargs Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libmudflap AssignedTo: unassig...@gcc.gnu.org ReportedBy: p...@mandriva.com.br These are just issues I found when attempting to use mudflap: o Mudflap fails to find symbol main in a test application due to propagating -fvisibility=hidden in CFLAGS. o The code also uses posix_memalign to allocate memory on 16 bytes boundaries, what causes a massive amount of violation warnings. o It tells about faults when receiving pointers as arguments to a varargs function. Overall I adapted the code I did want to test, so this is just a suggestion for enhancement. At least adding a posix_memalign wrapper should be trivial, but not sure about the others. Tested on x86_64 gcc version 4.6.0 20110610.
[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 #30 from Anitha Boyapati 2011-06-17 07:07:34 UTC --- Created attachment 24552 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24552 Make log for gcc-4_6-branch for comment 28 (In reply to comment #29) > Works For Me. > > [rth@anchor bld-avr-46]$ size avr/avr25/libgcc/_lshrdi3.o >text databssdechexfilename > 244 0 0244 f4 > avr/avr25/libgcc/_lshrdi3.o I have clean built multiple times now and it fails all the times with the same message. I have got atleast one response in avr-gcc-list reporting the same error. Also attached the log. Can you double check if dwarf2 is enabled? svn entries file - dir 175135 http://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch http://gcc.gnu.org/svn/gcc --- http://lists.gnu.org/archive/html/avr-gcc-list/2011-06/msg00034.html
