[Bug ada/40986] [4.4 regression] Assert_Failure sinfo.adb:360, error detected at a-unccon.ads:23:27
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40986 --- Comment #8 from Markus Schöpflin 2012-03-14 08:28:45 UTC --- 4.6.0 and 4.6.1 still fail, see comments #3 & #6. Unfortunately I can't adjust 'known to fail'.
[Bug c++/52521] [C++11] user defined literals and order of declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52521 --- Comment #5 from Jakub Jelinek 2012-03-14 08:30:45 UTC --- Author: jakub Date: Wed Mar 14 08:30:23 2012 New Revision: 185375 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185375 Log: PR c++/52521 * parser.c (lookup_literal_operator): Return fn only if processed all arguments from args vector and argtypes is void_list_node. * g++.dg/cpp0x/udlit-args2.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/udlit-args2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/52406] [4.7 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52406 Igor Zamyatin changed: What|Removed |Added CC||izamyatin at gmail dot com --- Comment #10 from Igor Zamyatin 2012-03-14 08:47:54 UTC --- This caused http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52580
[Bug tree-optimization/52571] vectorizer changes alignment of common symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52571 --- Comment #4 from rguenther at suse dot de 2012-03-14 09:35:12 UTC --- On Tue, 13 Mar 2012, ian at airs dot com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52571 > > --- Comment #3 from Ian Lance Taylor 2012-03-13 > 15:48:36 UTC --- > I agree: if the symbol is always common, the linker should use the largest > alignment. But the symbol need not always be common. Consider one file with > "unsigned long int *p;" and another file with "unsigned long int *p = &i;". > That is a valid use of common symbols. But now gcc might mark the common > symbol as having an alignment of 16, while leaving the definition with an > alignment of 8. The rules of common symbol linking mean that the definition > will override the common symbol. But the definition might have an alignment > of > 8, and it might not be possible for the linker to fix that--and in any case, > the linker won't even try. > > In other words, common symbols are special. You can't assume that anything > you > change about them will stick, because they might become, in effect, an > undefined symbol. I suspect that vect_can_force_dr_alignment_p should be > checking DECL_COMMON for exactly the reasons that it checks DECL_EXTERNAL. Ok, thanks for the clarification, I'll produce a patch. Richard.
[Bug middle-end/52134] Does not fold (x * 4) & -4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52134 --- Comment #8 from rguenther at suse dot de 2012-03-14 09:39:31 UTC --- On Tue, 13 Mar 2012, pinskia at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52134 > > --- Comment #6 from Andrew Pinski 2012-03-13 > 22:08:12 UTC --- > CCP could also remove the &: > Visiting statement: > D.1713_2 = t_1(D) * 4; > which is likely CONSTANT > Lattice value changed to CONSTANT Lattice value changed to CONSTANT > 0x0 (0x0fffc). Adding SSA edges to worklist. > > Visiting statement: > D.1712_3 = D.1713_2 & 4294967292; > which is likely CONSTANT > Lattice value changed to CONSTANT Lattice value changed to CONSTANT > 0x0 (0x0fffc). Adding SSA edges to worklist. > > .. > Visiting statement: > D.1710_2 = t_1(D) * 4; > which is likely CONSTANT > Lattice value changed to CONSTANT Lattice value changed to CONSTANT > 0x0 (0xfffc). Adding SSA edges to > worklist. > > Visiting statement: > D.1709_3 = D.1710_2 & -4; > which is likely CONSTANT > Lattice value changed to CONSTANT Lattice value changed to CONSTANT > 0x0 (0xfffc). Adding SSA edges to > worklist. > > > See how the lattice's already have its last 3 bits unset. In fact I think we > should only do this in the ccp/vrp passes to remove the & rather than fold. Yeah, CCP and VRP can do this as well. In fact folding bit-operations with the bit-CCP lattice is an obvious improvement, best done in ccp_fold_stmt which is called at lattice substitution time. Richard.
[Bug tree-optimization/43768] VRP destroys loop form
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43768 --- Comment #2 from rguenther at suse dot de 2012-03-14 09:39:55 UTC --- On Tue, 13 Mar 2012, pinskia at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43768 > > --- Comment #1 from Andrew Pinski 2012-03-13 > 23:38:08 UTC --- > Is this still true? I don't think so.
[Bug middle-end/52580] [4.8 Regression] 171.swim performance drop on x86 – vectorization doesn’t happen anymore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52580 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-03-14 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2012-03-14 09:40:54 UTC --- I will have a look.
[Bug libgcj/52579] [4.8 regression] i386_w32_fallback_frame_state should care ffi raw-closure stub function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52579 Richard Guenther changed: What|Removed |Added Version|4.7.0 |4.8.0 Target Milestone|--- |4.8.0
[Bug c++/14710] Warning about useless casts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14710 Paolo Carlini changed: What|Removed |Added CC||paolo.carlini at oracle dot ||com --- Comment #5 from Paolo Carlini 2012-03-14 10:36:10 UTC --- Jason, what do you think about this very old request? Implementing the warning itself should be pretty trivial (and we could have outside -Wall and -Wextra, thus should bother no one), but I'm not sure we really want it. Then I'm not sure where we want to draw the line, eg, in the provided snippet I'm not 100% sure about the base class case.
[Bug c++/52582] [4.7/4.8 Regression] g++ ICE when compiling qt-4.8.0 with -O2 on PPC (32bit)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52582 --- Comment #4 from Richard Guenther 2012-03-14 10:41:29 UTC --- Does Index: gcc/gimple-fold.c === --- gcc/gimple-fold.c (revision 185376) +++ gcc/gimple-fold.c (working copy) @@ -143,6 +143,8 @@ canonicalize_constructor_val (tree cval) if (cfun && gimple_referenced_vars (cfun)) add_referenced_var (base); } + else if (base && TREE_CODE (base) == FUNCTION_DECL) + cgraph_get_create_node (base); /* Fixup types in global initializers. */ if (TREE_TYPE (TREE_TYPE (cval)) != TREE_TYPE (TREE_OPERAND (cval, 0))) cval = build_fold_addr_expr (TREE_OPERAND (cval, 0)); @@ -3115,6 +3117,11 @@ gimple_get_virt_method_for_binfo (HOST_W if (!can_refer_decl_in_current_unit_p (fn)) return NULL_TREE; + /* Make sure we create a cgraph node for functions we'll reference. + They can be non-existent if the reference comes from an entry + of an external vtable for example. */ + cgraph_get_create_node (fn); + return fn; } help?
[Bug rtl-optimization/52573] [4.5/4.6/4.7/4.8 regression] regrename creates overlapping register allocations for output operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52573 Andreas Schwab changed: What|Removed |Added CC||bernds at gcc dot gnu.org --- Comment #1 from Andreas Schwab 2012-03-14 10:45:43 UTC --- 7197e17802ace9fc937f5b58f171a3711920b0dd is the first bad commit commit 7197e17802ace9fc937f5b58f171a3711920b0dd Author: bernds Date: Thu Nov 26 21:41:42 2009 + PR rtl-opt/38582 * regrename.c (struct du_head): New members id, conflicts, hard_conflicts and cannot_rename.
[Bug preprocessor/52566] #include in c++ namespace scope doesn't work properly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52566 --- Comment #3 from Jonathan Wakely 2012-03-14 10:46:54 UTC --- If you want to use #pragma once the simplest solution might be to put a unique comment in each file, with e.g. just the filename, or a description of its purpose
[Bug rtl-optimization/38582] excessive time in rename registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38582 --- Comment #8 from Andreas Schwab 2012-03-14 10:47:50 UTC --- This is apparently causing bug 52573.
[Bug middle-end/52578] Fails to fold another size difference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52578 --- Comment #2 from Richard Guenther 2012-03-14 10:51:38 UTC --- Author: rguenth Date: Wed Mar 14 10:51:34 2012 New Revision: 185378 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185378 Log: 2012-03-14 Richard Guenther PR middle-end/52578 * fold-const.c (fold_unary_loc): Fold (T1)(T2)x to (T1)x if the outermost conversion is a sign-change only. (fold_binary_loc): Disregard widening and sign-changing conversions when we determine if two variables are equal for reassociation. * tree-ssa-forwprop.c (combine_conversions): Fold (T1)(T2)x to (T1)x if the outermost conversion is a sign-change only. * gcc.dg/pr52578.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr52578.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-forwprop.c
[Bug c++/14710] Warning about useless casts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14710
--- Comment #6 from Jonathan Wakely 2012-03-14
10:52:18 UTC ---
I can see some value in the base class case too, but whether it's useless
depends on context, here the exact same casts are not redundant because they
select between two overloads:
struct A { int a; };
struct B : A { int b; };
void func(A *);
void func(B *);
int main()
{
B b;
func((A*)&b);
func(static_cast(&b));
}
Should it apply in templates? When casting to reference types as well as
pointers? That might give a warning for std::forward and similar cases, which
are entirely correct.
[Bug middle-end/48124] [4.5/4.6/4.7 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48124 Richard Guenther changed: What|Removed |Added Known to work||4.8.0 Summary|[4.5/4.6/4.7/4.8|[4.5/4.6/4.7 Regression] |Regression] likely wrong|likely wrong code bug |code bug| Known to fail||4.7.0 --- Comment #20 from Richard Guenther 2012-03-14 10:56:57 UTC --- Fixed for 4.8. Don't hold your breath for a backport of this patch (it should apply cleanly to 4.7 though, but not to anything earlier).
[Bug target/52080] Stores to bitfields introduce a store-data-race on adjacent data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52080 Richard Guenther changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.8.0 Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #14 from Richard Guenther 2012-03-14 10:57:32 UTC --- Fixed for 4.8.
[Bug target/52080] Stores to bitfields introduce a store-data-race on adjacent data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52080 --- Comment #13 from Richard Guenther 2012-03-14 10:55:16 UTC --- Author: rguenth Date: Wed Mar 14 10:55:09 2012 New Revision: 185379 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185379 Log: 2012-03-14 Richard Guenther * tree.h (DECL_BIT_FIELD_REPRESENTATIVE): New define. * stor-layout.c (start_bitfield_representative): New function. (finish_bitfield_representative): Likewise. (finish_bitfield_layout): Likewise. (finish_record_layout): Call finish_bitfield_layout. * tree.c (free_lang_data_in_decl): Only free DECL_QUALIFIER for QUAL_UNION_TYPE fields. * tree-streamer-in.c (lto_input_ts_field_decl_tree_pointers): Stream DECL_BIT_FIELD_REPRESENTATIVE. * tree-streamer-out.c (write_ts_field_decl_tree_pointers): Likewise. PR middle-end/52080 PR middle-end/52097 PR middle-end/48124 * expr.c (get_bit_range): Unconditionally extract bitrange from DECL_BIT_FIELD_REPRESENTATIVE. (expand_assignment): Adjust call to get_bit_range. * gcc.dg/torture/pr48124-1.c: New testcase. * gcc.dg/torture/pr48124-2.c: Likewise. * gcc.dg/torture/pr48124-3.c: Likewise. * gcc.dg/torture/pr48124-4.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/torture/pr48124-1.c trunk/gcc/testsuite/gcc.dg/torture/pr48124-2.c trunk/gcc/testsuite/gcc.dg/torture/pr48124-3.c trunk/gcc/testsuite/gcc.dg/torture/pr48124-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c trunk/gcc/stor-layout.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-streamer-in.c trunk/gcc/tree-streamer-out.c trunk/gcc/tree.c trunk/gcc/tree.h
[Bug middle-end/52097] ICE: in get_bit_range, at expr.c:4535 with -O -flto -fexceptions -fnon-call-exceptions --param allow-store-data-races=0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52097 --- Comment #12 from Richard Guenther 2012-03-14 10:55:17 UTC --- Author: rguenth Date: Wed Mar 14 10:55:09 2012 New Revision: 185379 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185379 Log: 2012-03-14 Richard Guenther * tree.h (DECL_BIT_FIELD_REPRESENTATIVE): New define. * stor-layout.c (start_bitfield_representative): New function. (finish_bitfield_representative): Likewise. (finish_bitfield_layout): Likewise. (finish_record_layout): Call finish_bitfield_layout. * tree.c (free_lang_data_in_decl): Only free DECL_QUALIFIER for QUAL_UNION_TYPE fields. * tree-streamer-in.c (lto_input_ts_field_decl_tree_pointers): Stream DECL_BIT_FIELD_REPRESENTATIVE. * tree-streamer-out.c (write_ts_field_decl_tree_pointers): Likewise. PR middle-end/52080 PR middle-end/52097 PR middle-end/48124 * expr.c (get_bit_range): Unconditionally extract bitrange from DECL_BIT_FIELD_REPRESENTATIVE. (expand_assignment): Adjust call to get_bit_range. * gcc.dg/torture/pr48124-1.c: New testcase. * gcc.dg/torture/pr48124-2.c: Likewise. * gcc.dg/torture/pr48124-3.c: Likewise. * gcc.dg/torture/pr48124-4.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/torture/pr48124-1.c trunk/gcc/testsuite/gcc.dg/torture/pr48124-2.c trunk/gcc/testsuite/gcc.dg/torture/pr48124-3.c trunk/gcc/testsuite/gcc.dg/torture/pr48124-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c trunk/gcc/stor-layout.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-streamer-in.c trunk/gcc/tree-streamer-out.c trunk/gcc/tree.c trunk/gcc/tree.h
[Bug middle-end/48124] [4.5/4.6/4.7/4.8 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48124 --- Comment #19 from Richard Guenther 2012-03-14 10:55:17 UTC --- Author: rguenth Date: Wed Mar 14 10:55:09 2012 New Revision: 185379 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185379 Log: 2012-03-14 Richard Guenther * tree.h (DECL_BIT_FIELD_REPRESENTATIVE): New define. * stor-layout.c (start_bitfield_representative): New function. (finish_bitfield_representative): Likewise. (finish_bitfield_layout): Likewise. (finish_record_layout): Call finish_bitfield_layout. * tree.c (free_lang_data_in_decl): Only free DECL_QUALIFIER for QUAL_UNION_TYPE fields. * tree-streamer-in.c (lto_input_ts_field_decl_tree_pointers): Stream DECL_BIT_FIELD_REPRESENTATIVE. * tree-streamer-out.c (write_ts_field_decl_tree_pointers): Likewise. PR middle-end/52080 PR middle-end/52097 PR middle-end/48124 * expr.c (get_bit_range): Unconditionally extract bitrange from DECL_BIT_FIELD_REPRESENTATIVE. (expand_assignment): Adjust call to get_bit_range. * gcc.dg/torture/pr48124-1.c: New testcase. * gcc.dg/torture/pr48124-2.c: Likewise. * gcc.dg/torture/pr48124-3.c: Likewise. * gcc.dg/torture/pr48124-4.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/torture/pr48124-1.c trunk/gcc/testsuite/gcc.dg/torture/pr48124-2.c trunk/gcc/testsuite/gcc.dg/torture/pr48124-3.c trunk/gcc/testsuite/gcc.dg/torture/pr48124-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c trunk/gcc/stor-layout.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-streamer-in.c trunk/gcc/tree-streamer-out.c trunk/gcc/tree.c trunk/gcc/tree.h
[Bug middle-end/52578] Fails to fold another size difference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52578 Richard Guenther changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #3 from Richard Guenther 2012-03-14 10:55:36 UTC --- Fixed.
[Bug target/52474] Regression: AVR-GCC: arithmetics produce completely wrong result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52474
--- Comment #4 from Georg-Johann Lay 2012-03-14
11:11:47 UTC ---
Created attachment 26889
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26889
main.s: FSF Assembler output
Here is the assembler output of the main mudule generated with
$ avr-gcc -mmcu=atmega168 -S main.c -O2 -dp
If you see the same code your problem is somewhere else.
If you see different code for these options, the problem comes from non-FSF
changes. As indicated in comment #0 there is a call to __mulhisi3 which is not
present in the attached main.s and is not part of the FSF sources, see
http://gcc.gnu.org/viewcvs/branches/gcc-4_5-branch/gcc/config/avr/avr.md?content-type=text%2Fplain&view=co
__mulhisi3 is present in avr-gcc 4.7 but that implementation is from scratch
and does not use __mulhisi3 patches floating around.
(In reply to comment #3)
> OK, so talking to the debian maintainer, the GCC version I'm using is based
> upon patches available here:
>
> http://distribute.atmel.no/tools/opensource/avr-gcc/
>
> Here is a test case. I'm unsure how to make a test case for code
> to be executed on a microcontroller because I need to make some
> assumptions about the board so that the result can be shown to
> the user somehow (flash a LED, whatever...)
Please, do not make assumptions on the hardware. The more assumptions you make
the more artificial barriert you build up. Just can use exit and abort from
stdlib.h to indicate the problem.
If you want to avoid that GCC uses knowledge on functions, you can
short __attribute__((noinline,noclone))
query (void)
{
return 0;
}
[Bug go/52583] New: Several new go testsuite failues on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583 Bug #: 52583 Summary: Several new go testsuite failues on Solaris Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go AssignedTo: i...@airs.com ReportedBy: r...@gcc.gnu.org Host: *-*-solaris2.* Target: *-*-solaris2.* Build: *-*-solaris2.* Recently, a couple of go and libgo testsuite failures have occured on Solaris where results were clean before: * i386-pc-solaris2.11: Running target unix/-m64 FAIL: go.go-torture/execute/select-1.go execution, -O2 -fomit-frame-pointer -finline-functions FAIL: go.go-torture/execute/select-1.go execution, -O2 -fomit-frame-pointer -finline-functions -funroll-loops FAIL: go.test/test/chan/powser1.go execution, -O2 -g panic: runtime error: invalid memory address or nil pointer dereference === libgo tests === Running target unix FAIL: log FAIL: net FAIL: net/http FAIL: net/http/httputil === libgo Summary for unix === # of expected passes119 # of unexpected failures4 Running target unix/-m64 FAIL: log FAIL: net FAIL: exp/norm FAIL: go/doc FAIL: net/http FAIL: net/http/httptest FAIL: net/http/httputil FAIL: net/rpc FAIL: old/netchan === libgo Summary for unix/-m64 === # of expected passes114 # of unexpected failures9 --- FAIL: log.TestAll (0.02 seconds) log_test.go:66: log output should match "^.*/[A-Za-z0-9_\\-]+\\.go:(54|56): hello 23 world$" is ":0: hello 23 world" log_test.go:66: log output should match "^[A-Za-z0-9_\\-]+\\.go:(54|56): hello 23 world$" is ":0: hello 23 world" log_test.go:66: log output should match "^[A-Za-z0-9_\\-]+\\.go:(54|56): hello 23 world$" is ":0: hello 23 world" log_test.go:66: log output should match "^XXX[0-9][0-9][0-9][0-9]/[0-9][0-9]/[0-9][0-9] [0-9][0-9]:[0-9][0-9]:[0-9][0-9]\\.[0-9][0-9][0-9][0-9][0-9][0-9] .*/[A-Za-z0-9_\\-]+\\.go:(54|56): hello 23 world$" is "XXX2012/03/12 20:22:43.453671 :0: hello 23 world" log_test.go:66: log output should match "^XXX[0-9][0-9][0-9][0-9]/[0-9][0-9]/[0-9][0-9] [0-9][0-9]:[0-9][0-9]:[0-9][0-9]\\.[0-9][0-9][0-9][0-9][0-9][0-9] [A-Za-z0-9_\\-]+\\.go:(54|56): hello 23 world$" is "XXX2012/03/12 20:22:43.455184 :0: hello 23 world" FAIL FAIL: log --- FAIL: net.TestMulticastListener (0.00 seconds) sockoptip.go:67: First ListenMulticastUDP failed: setsockopt: Invalid argument pollServer WaitFD: select: Bad file number panic: test timed out FAIL: net pollServer WaitFD: select: Bad file number panic: test timed out FAIL: net/http pollServer WaitFD: select: Bad file number panic: test timed out FAIL: net/http/httputil 64-bit: 2012/03/12 20:47:35 Test RPC server listening on 127.0.0.1:51903 2012/03/12 20:47:35 Test HTTP RPC server listening on 127.0.0.1:53240 2012/03/12 20:47:35 rpc: rpc: can't find method Arith.BadOperation 2012/03/12 20:47:35 rpc: rpc: can't find method Arith.Unknown 2012/03/12 20:47:35 rpc: gob: type mismatch: no fields matched compiling decoder for Args 2012/03/12 20:47:35 NewServer test RPC server listening on 127.0.0.1:61566 2012/03/12 20:47:35 rpc: rpc: can't find method Arith.BadOperation 2012/03/12 20:47:35 rpc: rpc: can't find method Arith.Unknown 2012/03/12 20:47:35 rpc: gob: type mismatch: no fields matched compiling decoder for Args 2012/03/12 20:47:36 method ReplyNotPointer reply type not a pointer: rpc.Reply 2012/03/12 20:47:36 rpc Register: type ReplyNotPointer has no exported methods of suitable type 2012/03/12 20:47:36 ArgNotPublic argument type not exported: *rpc.local 2012/03/12 20:47:36 rpc Register: type ArgNotPublic has no exported methods of suitable type 2012/03/12 20:47:36 method ReplyNotPublic reply type not exported: *rpc.local 2012/03/12 20:47:36 rpc Register: type ReplyNotPublic has no exported methods of suitable type panic: runtime error: invalid memory address or nil pointer dereference FAIL: net/rpc unexpected fault address 28 throw: fault FAIL: old/netchan * sparc-sun-solaris2.11: no go failures === libgo tests === Running target unix FAIL: net FAIL: net/http FAIL: net/http/httputil FAIL: text/template FAIL: testing/quick === libgo Summary for unix === # of expected passes118 # of unexpected failures5 Running target unix/-m64 FAIL: log FAIL: net FAIL: net/http FAIL: net/http/httputil === libgo Summary for unix/-m64 === # of expected passes119 # of unexpected failures4 causes seem to be the same on Solaris/x86. I haven't yet investigated in more detail. RAiner
[Bug c++/14710] Warning about useless casts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14710 --- Comment #7 from Paolo Carlini 2012-03-14 11:47:30 UTC --- Indeed, I was vaguely considering similar things..
[Bug target/52474] Regression: AVR-GCC: arithmetics produce completely wrong result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52474 --- Comment #5 from Georg-Johann Lay 2012-03-14 12:54:04 UTC --- Created attachment 26890 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26890 mulhisi.c:Test program Test program showing that the non-FSF patches introduce a wrong multiply. Running the program with avrtest prints a = 1 b = -32768 ab = -32768 ab2 = 1678
[Bug target/52474] Regression: AVR-GCC: arithmetics produce completely wrong result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52474 Georg-Johann Lay changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #6 from Georg-Johann Lay 2012-03-14 12:56:04 UTC --- Closed as INVALID. Obviously, the toolchain you use comes with bad patches.
[Bug middle-end/52584] New: Fails to constant fold vector upper/lower half BIT_FIELD_REFs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52584
Bug #: 52584
Summary: Fails to constant fold vector upper/lower half
BIT_FIELD_REFs
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: rgue...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
Target: x86_64-*-*
int main()
{
int a = 1;
typedef int v4si __attribute__ ((vector_size (8 * sizeof(int;
v4si x;
v4si y;
y = x + a;
foo(y);
return 0;
}
shows a missed optimization in how we fold BIT_FIELD_REFs that select
the upper/lower part of a vector:
:
D.1719_9 = BIT_FIELD_REF ;
D.1721_10 = BIT_FIELD_REF <{ 1, 1, 1, 1, 1, 1, 1, 1 }, 128, 0>;
D.1722_11 = D.1719_9 + D.1721_10;
D.1723_12 = BIT_FIELD_REF ;
D.1725_13 = BIT_FIELD_REF <{ 1, 1, 1, 1, 1, 1, 1, 1 }, 128, 128>;
D.1726_14 = D.1723_12 + D.1725_13;
y_5 = {D.1722_11, D.1726_14};
foo (y_5);
return 0;
we should have constant-folded D.1721_10 and D.1725_13.
[Bug tree-optimization/52571] vectorizer changes alignment of common symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52571 --- Comment #5 from Richard Guenther 2012-03-14 13:00:49 UTC --- Author: rguenth Date: Wed Mar 14 13:00:44 2012 New Revision: 185380 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185380 Log: 2012-03-14 Richard Guenther PR tree-optimization/52571 * tree-vect-data-refs.c (vect_compute_data_ref_alignment): Move flag_section_anchors check ... (vect_can_force_dr_alignment_p): ... here. Do not re-align DECL_COMMON variables. * gcc.dg/vect/vect-2.c: Initialize arrays. * gcc.dg/vect/no-section-anchors-vect-34.c: Likewise. * gcc.target/i386/recip-vec-divf.c: Use -fno-common. * gcc.target/i386/recip-vec-sqrtf.c: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/no-section-anchors-vect-34.c trunk/gcc/testsuite/gcc.dg/vect/vect-2.c trunk/gcc/testsuite/gcc.target/i386/recip-vec-divf.c trunk/gcc/testsuite/gcc.target/i386/recip-vec-sqrtf.c trunk/gcc/tree-vect-data-refs.c
[Bug c++/52582] [4.7/4.8 Regression] g++ ICE when compiling qt-4.8.0 with -O2 on PPC (32bit)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52582 --- Comment #5 from Richard Guenther 2012-03-14 13:01:52 UTC --- Author: rguenth Date: Wed Mar 14 13:01:46 2012 New Revision: 185381 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185381 Log: 2012-03-14 Richard Guenther PR middle-end/52582 * gimple-fold.c (canonicalize_constructor_val): Make sure we have a cgraph node for a FUNCTION_DECL that comes from a constructor. (gimple_get_virt_method_for_binfo): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-fold.c
[Bug tree-optimization/52571] vectorizer changes alignment of common symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52571 Richard Guenther changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Richard Guenther 2012-03-14 13:01:01 UTC --- Fixed.
[Bug target/52474] Regression: AVR-GCC: arithmetics produce completely wrong result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52474 --- Comment #7 from Georg-Johann Lay 2012-03-14 13:03:54 UTC --- Note: The assembler code in attachment 26890 is from 30-gcc-4.5.1-fixedpoint-3-4-2010.patch http://distribute.atmel.no/tools/opensource/avr-gcc/gcc-4.5.1
[Bug fortran/52585] New: Dummy procedure pointer loses its pointer association status
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52585 Bug #: 52585 Summary: Dummy procedure pointer loses its pointer association status Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: math...@nag.co.uk $ uname -a Linux stonehenge 3.2.9-2.fc16.x86_64 #1 SMP Mon Mar 5 20:55:39 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux $ gfortran --version GNU Fortran (GCC) 4.8.0 20120314 (experimental) [trunk revision 185372] $ cat p_assoc.f90 module m0 abstract interface subroutine sub end subroutine sub end interface interface subroutine s(ss) import sub procedure(sub), pointer, intent(in) :: ss end subroutine s end interface end module m0 use m0, only : sub, s procedure(sub) :: sub2, pp pointer :: pp pp => sub2 if (.not. associated(pp,sub2)) stop 'FAIL' call s(pp) end subroutine s(ss) use m0, only : sub procedure(sub), pointer, intent(in) :: ss procedure(sub) :: sub2 if (.not. associated(ss,sub2)) stop 'FAIL2' end subroutine s subroutine sub2 end subroutine sub2 $ gfortran p_assoc.f90 ; ./a.out STOP FAIL2
[Bug fortran/47007] Values from namelist file should not depend on locale settings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007 --- Comment #16 from PierreC 2012-03-14 13:42:13 UTC --- I bumped into this problem using f2py to interface a Fortran library into Python. The read statement upon an internal buffer depends on the locale...
[Bug go/52586] New: libgo fails to build for mipsel64-linux-gnu (reference to undefined name 'SYS_GETDENTS64')
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52586 Bug #: 52586 Summary: libgo fails to build for mipsel64-linux-gnu (reference to undefined name 'SYS_GETDENTS64') Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go AssignedTo: i...@airs.com ReportedBy: d...@gcc.gnu.org seen with 4.7.0 rc1 + updates. this is a multilib enabled build, the build succeeds for the two 32bit abi's. complete build log at https://buildd.debian.org/status/fetch.php?pkg=gcc-4.7&arch=mipsel&ver=4.7.0~rc1-2&stamp=1331693034 need to start a local build ... /bin/mkdir -p syscall; files=`echo ../../../../src/libgo/go/syscall/env_unix.go ../../../../src/libgo/go/syscall/syscall_errno.go ../../../../src/libgo/go/syscall/libcall_support.go ../../../../src/libgo/go/syscall/libcall_posix.go ../../../../src/libgo/go/syscall/socket.go ../../../../src/libgo/go/syscall/sockcmsg_unix.go ../../../../src/libgo/go/syscall/str.go ../../../../src/libgo/go/syscall/syscall.go ../../../../src/libgo/go/syscall/sockcmsg_linux.go ../../../../src/libgo/go/syscall/syscall_unix.go ../../../../src/libgo/go/syscall/exec_unix.go ../../../../src/libgo/go/syscall/exec_linux.go ../../../../src/libgo/go/syscall/libcall_wait4.go ../../../../src/libgo/go/syscall/sleep_select.go ../../../../src/libgo/go/syscall/errstr_linux.go ../../../../src/libgo/go/syscall/libcall_posix_largefile.go ../../../../src/libgo/go/syscall/socket_linux.go epoll.go ../../../../src/libgo/go/syscall/libcall_uname.go ../../../../src/libgo/go/syscall/netlink_linux.go ../../../../src/libgo/go/syscall/lsf_linux.go ../../../../src/libgo/go/syscall/libcall_linux.go libcalls.go sysinfo.go syscall_arch.go runtime.gox sync.gox | sed -e 's/[^ ]*\.gox//g'`; /bin/bash ./libtool --tag GO --mode=compile /build/buildd-gcc-4.7_4.7.0~rc1-2-mipsel-ImTNtr/gcc-4.7-4.7.0~rc1/build/./gcc/gccgo -B/build/buildd-gcc-4.7_4.7.0~rc1-2-mipsel-ImTNtr/gcc-4.7-4.7.0~rc1/build/./gcc/ -B/usr/mipsel-linux-gnu/bin/ -B/usr/mipsel-linux-gnu/lib/ -isystem /usr/mipsel-linux-gnu/include -isystem /usr/mipsel-linux-gnu/sys-include -O2 -g -mabi=64 -I . -c -fgo-prefix="libgo_syscall" -o syscall/syscall.lo $files libtool: compile: "/build/buildd-gcc-4.7_4.7.0~rc1-2-mipsel-ImTNtr/gcc-4.7-4.7.0~rc1/build/./gcc/gccgo" "-B/build/buildd-gcc-4.7_4.7.0~rc1-2-mipsel-ImTNtr/gcc-4.7-4.7.0~rc1/build/./gcc/" -B/usr/mipsel-linux-gnu/bin/ -B/usr/mipsel-linux-gnu/lib/ -isystem /usr/mipsel-linux-gnu/include -isystem /usr/mipsel-linux-gnu/sys-include -O2 -g -mabi=64 -I . -c -fgo-prefix=libgo_syscall ../../../../src/libgo/go/syscall/env_unix.go ../../../../src/libgo/go/syscall/syscall_errno.go ../../../../src/libgo/go/syscall/libcall_support.go ../../../../src/libgo/go/syscall/libcall_posix.go ../../../../src/libgo/go/syscall/socket.go ../../../../src/libgo/go/syscall/sockcmsg_unix.go ../../../../src/libgo/go/syscall/str.go ../../../../src/libgo/go/syscall/syscall.go ../../../../src/libgo/go/syscall/sockcmsg_linux.go ../../../../src/libgo/go/syscall/syscall_unix.go ../../../../src/libgo/go/syscall/exec_unix.go ../../../../src/libgo/go/syscall/exec_linux.go ../../../../src/libgo/go/syscall/libcall_wait4.go ../../../../src/libgo/go/syscall/sleep_select.go ../../../../src/libgo/go/syscall/errstr_linux.go ../../../../src/libgo/go/syscall/libcall_posix_largefile.go ../../../../src/libgo/go/syscall/socket_linux.go epoll.go ../../../../src/libgo/go/syscall/libcall_uname.go ../../../../src/libgo/go/syscall/netlink_linux.go ../../../../src/libgo/go/syscall/lsf_linux.go ../../../../src/libgo/go/syscall/libcall_linux.go libcalls.go sysinfo.go syscall_arch.go -fPIC -o syscall/.libs/syscall.o ../../../../src/libgo/go/syscall/libcall_linux.go:206:26: error: reference to undefined name 'SYS_GETDENTS64' make[10]: *** [syscall/syscall.lo] Error 1 make[10]: Leaving directory `/build/buildd-gcc-4.7_4.7.0~rc1-2-mipsel-ImTNtr/gcc-4.7-4.7.0~rc1/build/mipsel-linux-gnu/64/libgo' make[9]: *** [all-recursive] Error 1
[Bug c++/52582] [4.7/4.8 Regression] g++ ICE when compiling qt-4.8.0 with -O2 on PPC (32bit)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52582 --- Comment #6 from Jakub Jelinek 2012-03-14 14:21:22 UTC --- Author: jakub Date: Wed Mar 14 14:21:12 2012 New Revision: 185383 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185383 Log: PR c++/52582 * config/rs6000/rs6000.c (call_ABI_of_interest): Return true if c_node is NULL. * g++.dg/opt/pr52582.C: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/opt/pr52582.C Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/config/rs6000/rs6000.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug c++/52582] [4.7/4.8 Regression] g++ ICE when compiling qt-4.8.0 with -O2 on PPC (32bit)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52582 --- Comment #7 from Jakub Jelinek 2012-03-14 14:24:38 UTC --- Author: jakub Date: Wed Mar 14 14:24:32 2012 New Revision: 185384 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185384 Log: PR c++/52582 * config/rs6000/rs6000.c (call_ABI_of_interest): Return true if c_node is NULL. * g++.dg/opt/pr52582.C: New test. Added: trunk/gcc/testsuite/g++.dg/opt/pr52582.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug fortran/52585] Wromg result for ASSOCIATED with dummy procedure pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52585
Tobias Burnus changed:
What|Removed |Added
Keywords||wrong-code
CC||burnus at gcc dot gnu.org
Summary|Dummy procedure pointer |Wromg result for ASSOCIATED
|loses its pointer |with dummy procedure
|association status |pointer
--- Comment #1 from Tobias Burnus 2012-03-14
14:32:59 UTC ---
Thanks for the report!
It does not loose the pointer association state - it just takes (internally)
the wrong address as -fdump-tree-original shows.
It has the correct result for the main program/caller:
void (*) (void) pp;
pp = sub2;
if (pp != sub2 || pp == 0B)
_gfortran_stop_string (&"FAIL"[1]{lb: 1 sz: 1}, 4);
But in subroutine s, it uses the wrong address:
s (void (*) (void) * ss)
{
if (ss != sub2 || ss == 0B)
_gfortran_stop_string (&"FAIL2"[1]{lb: 1 sz: 1}, 5);
The "ss != sub2 || ss = 0B" should have been a "*ss != sub2 || *ss == 0B" in
this C-like dump.
[Bug middle-end/52580] [4.8 Regression] 171.swim performance drop on x86 – vectorization doesn’t happen anymore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52580 --- Comment #2 from Richard Guenther 2012-03-14 14:32:49 UTC --- Confirmed, 4.7 does 418: LOOP VECTORIZED. 398: LOOP VECTORIZED. 335: LOOP VECTORIZED. 316: LOOP VECTORIZED. 280: LOOP VECTORIZED. 262: LOOP VECTORIZED. 213: LOOP VECTORIZED. vs. 398: LOOP VECTORIZED. 335: LOOP VECTORIZED. 213: LOOP VECTORIZED. and different amount of alias checks as well. For the loop at line 316 trunk cannot determine the dependence of some refs: 316: versioning for alias required: can't determine dependence between __BLNK__.uold[D.2769_24] and __BLNK__.vnew[D.2782_49] Reduced testcase: SUBROUTINE CALC2 IMPLICIT REAL*8 (A-H, O-Z) PARAMETER (N1=1335, N2=1335) COMMON U(N1,N2), V(N1,N2), P(N1,N2), *UNEW(N1,N2), VNEW(N1,N2), 1PNEW(N1,N2), UOLD(N1,N2), *VOLD(N1,N2), POLD(N1,N2), 2CU(N1,N2), CV(N1,N2), *Z(N1,N2), H(N1,N2), PSI(N1,N2) COMMON /CONS/ DT,TDT,DX,DY,A,ALPHA,ITMAX,MPRINT,M,N,MP1, 1 NP1,EL,PI,TPI,DI,DJ,PCF TDTS8 = TDT/8.D0 TDTSDX = TDT/DX TDTSDY = TDT/DY DO 200 J=1,N DO 200 I=1,M UNEW(I+1,J) = UOLD(I+1,J)+ 1TDTS8*(Z(I+1,J+1)+Z(I+1,J))*(CV(I+1,J+1)+CV(I,J+1)+CV(I,J) 2 +CV(I+1,J))-TDTSDX*(H(I+1,J)-H(I,J)) VNEW(I,J+1) = VOLD(I,J+1)-TDTS8*(Z(I+1,J+1)+Z(I,J+1)) 1 *(CU(I+1,J+1)+CU(I,J+1)+CU(I,J)+CU(I+1,J)) 2 -TDTSDY*(H(I,J+1)-H(I,J)) PNEW(I,J) = POLD(I,J)-TDTSDX*(CU(I+1,J)-CU(I,J)) 1 -TDTSDY*(CV(I,J+1)-CV(I,J)) 200 CONTINUE RETURN END
[Bug fortran/52585] Wromg result for ASSOCIATED with dummy procedure pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52585 --- Comment #2 from Tobias Burnus 2012-03-14 14:41:05 UTC --- I think one needs something like the following for both the first and the second argument. if (arg1->expr->symtree->n.sym->attr.proc_pointer && arg1->expr->symtree->n.sym->attr.dummy) arg1se.expr = build_fold_indirect_ref_loc (input_location, arg1se.expr);
[Bug middle-end/52580] [4.8 Regression] 171.swim performance drop on x86 – vectorization doesn’t happen anymore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52580
--- Comment #3 from Richard Guenther 2012-03-14
14:52:11 UTC ---
The issue is that with the artificial access functions added for
__BLNK__.uold and __BLK__.vnew we run the subscript dependence tester
but that fails even when only a single access function cannot be
analyzed.
The following fixes that.
Index: gcc/tree-data-ref.c
===
--- gcc/tree-data-ref.c (revision 185379)
+++ gcc/tree-data-ref.c (working copy)
@@ -3460,6 +3460,7 @@ subscript_dependence_tester_1 (struct da
unsigned int i;
tree last_conflicts;
struct subscript *subscript;
+ tree res = NULL_TREE;
for (i = 0; VEC_iterate (subscript_p, DDR_SUBSCRIPTS (ddr), i, subscript);
i++)
@@ -3471,40 +3472,43 @@ subscript_dependence_tester_1 (struct da
&overlaps_a, &overlaps_b,
&last_conflicts, loop_nest);
+ if (SUB_CONFLICTS_IN_A (subscript))
+ free_conflict_function (SUB_CONFLICTS_IN_A (subscript));
+ if (SUB_CONFLICTS_IN_B (subscript))
+ free_conflict_function (SUB_CONFLICTS_IN_B (subscript));
+
+ SUB_CONFLICTS_IN_A (subscript) = overlaps_a;
+ SUB_CONFLICTS_IN_B (subscript) = overlaps_b;
+ SUB_LAST_CONFLICT (subscript) = last_conflicts;
+
+ /* If there is any undetermined conflict function we have to
+ give a conservative answer in case we cannot prove that
+no dependence exists when analyzing another subscript. */
if (CF_NOT_KNOWN_P (overlaps_a)
|| CF_NOT_KNOWN_P (overlaps_b))
{
- finalize_ddr_dependent (ddr, chrec_dont_know);
- dependence_stats.num_dependence_undetermined++;
- free_conflict_function (overlaps_a);
- free_conflict_function (overlaps_b);
- return false;
+ res = chrec_dont_know;
+ continue;
}
+ /* When there is a subscript with no dependence we can stop. */
else if (CF_NO_DEPENDENCE_P (overlaps_a)
|| CF_NO_DEPENDENCE_P (overlaps_b))
{
- finalize_ddr_dependent (ddr, chrec_known);
- dependence_stats.num_dependence_independent++;
- free_conflict_function (overlaps_a);
- free_conflict_function (overlaps_b);
- return false;
- }
-
- else
- {
- if (SUB_CONFLICTS_IN_A (subscript))
- free_conflict_function (SUB_CONFLICTS_IN_A (subscript));
- if (SUB_CONFLICTS_IN_B (subscript))
- free_conflict_function (SUB_CONFLICTS_IN_B (subscript));
-
- SUB_CONFLICTS_IN_A (subscript) = overlaps_a;
- SUB_CONFLICTS_IN_B (subscript) = overlaps_b;
- SUB_LAST_CONFLICT (subscript) = last_conflicts;
+ res = chrec_known;
+ break;
}
}
- return true;
+ if (res == NULL_TREE)
+return true;
+
+ if (res == chrec_known)
+dependence_stats.num_dependence_independent++;
+ else
+dependence_stats.num_dependence_undetermined++;
+ finalize_ddr_dependent (ddr, res);
+ return false;
}
/* Computes the conflicting iterations in LOOP_NEST, and initialize DDR. */
[Bug middle-end/52584] Fails to constant fold vector upper/lower half BIT_FIELD_REFs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52584 --- Comment #1 from Richard Guenther 2012-03-14 14:55:16 UTC --- Author: rguenth Date: Wed Mar 14 14:55:11 2012 New Revision: 185385 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185385 Log: 2012-03-14 Richard Guenther PR middle-end/52584 * tree-vect-generic.c (type_for_widest_vector_mode): Take element type instead of mode, use build_vector_type_for_mode instead of the langhook, build a vector of proper signedness. (expand_vector_operations_1): Adjust. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-generic.c
[Bug c/52587] New: ICE: in emit_move_insn, at expr.c:3355: array with one element
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52587 Bug #: 52587 Summary: ICE: in emit_move_insn, at expr.c:3355: array with one element Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: dmagagn...@yahoo.com Created attachment 26891 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26891 Preprocessed source file Using built-in specs. COLLECT_GCC=gcc-4.6 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6.1/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.1-9ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-g3' '-O3' '-fno-strict-aliasing' '-o' 'ICE.o' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-linux-gnu/4.6.1/cc1 -E -quiet -v -imultilib . -imultiarch x86_64-linux-gnu -dD ICE.c -mtune=generic -march=x86-64 -fno-strict-aliasing -g3 -fworking-directory -O3 -fpch-preprocess -fstack-protector -o ICE.i ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../x86_64-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/x86_64-linux-gnu/4.6.1/include /usr/local/include /usr/lib/gcc/x86_64-linux-gnu/4.6.1/include-fixed /usr/include/x86_64-linux-gnu /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-g3' '-O3' '-fno-strict-aliasing' '-o' 'ICE.o' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-linux-gnu/4.6.1/cc1 -fpreprocessed ICE.i -quiet -dumpbase ICE.c -mtune=generic -march=x86-64 -auxbase-strip ICE.o -g3 -O3 -version -fno-strict-aliasing -fstack-protector -o ICE.s GNU C (Ubuntu/Linaro 4.6.1-9ubuntu3) version 4.6.1 (x86_64-linux-gnu) compiled by GNU C version 4.6.1, GMP version 5.0.1, MPFR version 3.0.1-p3, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C (Ubuntu/Linaro 4.6.1-9ubuntu3) version 4.6.1 (x86_64-linux-gnu) compiled by GNU C version 4.6.1, GMP version 5.0.1, MPFR version 3.0.1-p3, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 5dede901e38d49932d3155c3e888bca1 ICE.c: In function ‘func3’: ICE.c:36:19: internal compiler error: in emit_move_insn, at expr.c:3355 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. Preprocessed source stored into /tmp/ccbwMOGo.out file, please attach this to your bugreport. Notes: 1) No ICE with -O1. 2) Changing n_elts to 2 avoids the ICE. 3) Compiles correctly with GCC 4.4.6.
[Bug c/52588] New: false warning: array subscript is above array bounds: number of elements is 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52588 Bug #: 52588 Summary: false warning: array subscript is above array bounds: number of elements is 1 Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: dmagagn...@yahoo.com Created attachment 26892 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26892 Preprocessed source file Using built-in specs. COLLECT_GCC=gcc-4.6 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6.1/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.1-9ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-c' '-g3' '-O3' '-o' 'OOB.o' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-linux-gnu/4.6.1/cc1 -E -quiet -v -imultilib . -imultiarch x86_64-linux-gnu -dD OOB.c -mtune=generic -march=x86-64 -Wall -g3 -fworking-directory -O3 -fpch-preprocess -fstack-protector -o OOB.i ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../x86_64-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/x86_64-linux-gnu/4.6.1/include /usr/local/include /usr/lib/gcc/x86_64-linux-gnu/4.6.1/include-fixed /usr/include/x86_64-linux-gnu /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-c' '-g3' '-O3' '-o' 'OOB.o' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-linux-gnu/4.6.1/cc1 -fpreprocessed OOB.i -quiet -dumpbase OOB.c -mtune=generic -march=x86-64 -auxbase-strip OOB.o -g3 -O3 -Wall -version -fstack-protector -o OOB.s GNU C (Ubuntu/Linaro 4.6.1-9ubuntu3) version 4.6.1 (x86_64-linux-gnu) compiled by GNU C version 4.6.1, GMP version 5.0.1, MPFR version 3.0.1-p3, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C (Ubuntu/Linaro 4.6.1-9ubuntu3) version 4.6.1 (x86_64-linux-gnu) compiled by GNU C version 4.6.1, GMP version 5.0.1, MPFR version 3.0.1-p3, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 5dede901e38d49932d3155c3e888bca1 OOB.c: In function ‘func’: OOB.c:20:25: warning: array subscript is above array bounds [-Warray-bounds] COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-c' '-g3' '-O3' '-o' 'OOB.o' '-mtune=generic' '-march=x86-64' as --64 -o OOB.o OOB.s COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.6.1/:/usr/lib/gcc/x86_64-linux-gnu/4.6.1/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.6.1/:/usr/lib/gcc/x86_64-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.6.1/:/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-c' '-g3' '-O3' '-o' 'OOB.o' '-mtune=generic' '-march=x86-64' Notes: 1) Changing the second dimension to 2 avoids the warning. 2) Compiles correctly with GCC 4.4.6.
[Bug tree-optimization/52589] New: VRP missed optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52589
Bug #: 52589
Summary: VRP missed optimization
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
extern void link_error (void);
void
foo (unsigned int s)
{
if (s + 0x7000 < 0xf000U)
{
if (s >= 0x8000U && s < 0x9000U)
link_error ();
}
}
void
bar (unsigned int s)
{
if (s + 0x7000 >= 0xf000U)
{
if (s < 0x8000U || s >= 0x9000U)
link_error ();
}
}
In the above testcase, bar is optimized fine (VRP adds an ASSERT_EXPR with
range [0x8000, 0x8fff] and optimizes away the test), but in foo it
isn't - the range there is ~[0x8000, 0x8] and we don't handle the
VR_ANTI_RANGE somewhere where we should.
I've noticed this while working on PR52267 - the vrp65.c testcase that I'm
bootstrapping there right now needs to have 4 tests commented out (well,
replaced by checks of a few selected values from the range which VRP optimizes
out properly).
[Bug c++/52582] [4.7/4.8 Regression] g++ ICE when compiling qt-4.8.0 with -O2 on PPC (32bit)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52582 --- Comment #8 from Jakub Jelinek 2012-03-14 16:12:35 UTC --- Temporarily worked around for 4.7.0. We really should find out why we aren't setting DECL_EXTERNAL on this.
[Bug tree-optimization/52589] VRP missed optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52589 --- Comment #1 from Jakub Jelinek 2012-03-14 17:24:30 UTC --- The problem is in extract_range_from_binary_expr_1, we have s_7 = ASSERT_EXPR ; D.1721_3 = s_7 + 2147483648; if (D.1721_3 <= 268435455) s_7 has range ~[2147483648, 2415919103] (i.e. VR_ANTI_RANGE), the constant obviously [2147483648, 2147483648] (i.e. VR_RANGE), but as vr0.type != vr1.type, we drop it to varying, while we could combine that ~[0x8000, 0x8fff] + [0x8000, 0x8000] into ~[0, 0xfff] (at least, for TYPE_UNSIGNED addition and perhaps limited only to constants (i.e. vr1.min == vr1.max VR_RANGE).
[Bug c++/14710] Warning about useless casts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14710 --- Comment #8 from Jason Merrill 2012-03-14 18:00:33 UTC --- I wouldn't warn about a cast that changes the type or value category of an expression at all, or a cast that ends up being the same type as the result of template instantiation. But a warning for (A*)&a seems reasonable.
[Bug c++/52582] [4.7/4.8 Regression] g++ ICE when compiling qt-4.8.0 with -O2 on PPC (32bit)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52582 --- Comment #9 from Jason Merrill 2012-03-14 18:33:07 UTC --- Created attachment 26893 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26893 patch Does this fix it?
[Bug c++/52582] [4.7/4.8 Regression] g++ ICE when compiling qt-4.8.0 with -O2 on PPC (32bit)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52582 --- Comment #10 from Jakub Jelinek 2012-03-14 18:44:32 UTC --- On this testcase? Yes, it does. Haven't done bootstrap/regtest with it though.
[Bug go/52583] Several new go testsuite failues on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583 --- Comment #1 from Uros Bizjak 2012-03-14 19:27:09 UTC --- (In reply to comment #0) > --- FAIL: log.TestAll (0.02 seconds) > log_test.go:66: log output should match > "^.*/[A-Za-z0-9_\\-]+\\.go:(54|56): > hello 23 world$" is ":0: hello 23 world" > log_test.go:66: log output should match "^[A-Za-z0-9_\\-]+\\.go:(54|56): > hello 23 world$" is ":0: hello 23 world" > log_test.go:66: log output should match "^[A-Za-z0-9_\\-]+\\.go:(54|56): > hello 23 world$" is ":0: hello 23 world" > log_test.go:66: log output should match > "^XXX[0-9][0-9][0-9][0-9]/[0-9][0-9]/[0-9][0-9] > [0-9][0-9]:[0-9][0-9]:[0-9][0-9]\\.[0-9][0-9][0-9][0-9][0-9][0-9] > .*/[A-Za-z0-9_\\-]+\\.go:(54|56): hello 23 world$" is "XXX2012/03/12 > 20:22:43.453671 :0: hello 23 world" > log_test.go:66: log output should match > "^XXX[0-9][0-9][0-9][0-9]/[0-9][0-9]/[0-9][0-9] > [0-9][0-9]:[0-9][0-9]:[0-9][0-9]\\.[0-9][0-9][0-9][0-9][0-9][0-9] > [A-Za-z0-9_\\-]+\\.go:(54|56): hello 23 world$" is "XXX2012/03/12 > 20:22:43.455184 :0: hello 23 world" > FAIL > FAIL: log I also see these failures on alpha. I have debugged this issue a bit: these failures happen only when useFormat is false in function testPrint, at log_test.go:48. It looks to me that Println doesn't handle long and short file names correctly. Equivalent Printf function works without problems, outputting correct expected strings.
[Bug libstdc++/52590] New: std::thread Segmentation fault static linking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52590
Bug #: 52590
Summary: std::thread Segmentation fault static linking
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@cornsyrup.org
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.7.0~rc1-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin
--enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.0 20120302 (prerelease) (Ubuntu/Linaro 4.7.0~rc1-1ubuntu1)
$ g++ -static -pthread -std=c++0x -o thread thread.cc
$ ./thread
pthread_create works
std::thread works
Segmentation fault
$ cat thread.cc
#include
#include
void *foo1(void *) {
std::cout << "pthread_create works\n";
return 0;
}
void foo2() {
std::cout << "std::thread works\n";
}
int main() {
{
pthread_t t;
pthread_create(&t, 0, foo1, 0);
void *r;
pthread_join(t, &r);
}
{
std::thread t(foo2);
t.join();
}
return 0;
}
I was surprised to see that pthreads worked in this case while std::thread did
not. I've also heard that boost::thread works. I'm having a hard time finding
any documentation on whether static linking and std::thread should work
together. Also see
http://stackoverflow.com/questions/7090623/c0x-thread-static-linking-problem
If it is the case that pthreads and std::thread cannot work together with
static linking, then it'd be nice to fail at some point before runtime if that
is possible.
[Bug libstdc++/52590] std::thread Segmentation fault static linking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52590 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID Severity|major |normal --- Comment #1 from Andrew Pinski 2012-03-14 20:42:22 UTC --- > -static You need to make sure all of libpthread.a is included, right it does not get linked that way. This is not a GCC or glibc bug.
[Bug ada/52362] gnat.dg/lto8.adb FAILs with gas/gld
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52362 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot ||gnu.org --- Comment #2 from Eric Botcazou 2012-03-14 20:43:16 UTC --- What's different with --disable-bootstrap? Missing linker plugin support?
[Bug ada/52362] gnat.dg/lto8.adb FAILs with gas/gld
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52362 --- Comment #3 from vries at gcc dot gnu.org 2012-03-14 21:02:51 UTC --- (In reply to comment #2) > What's different with --disable-bootstrap? Missing linker plugin support? I did a reference build, bootstrap and nobootstrap, and the test passed for bootstrap and failed for nobootstrap: ... ref-last/FAIL:./gcc/testsuite/gnat/gnat.sum:PASS: gnat.dg/lto8.adb (test for excess errors) ref-last/FAIL:./gcc/testsuite/gnat/gnat.sum:PASS: gnat.dg/lto8.adb execution test ref-last/FAIL.nobootstrap:./gcc/testsuite/gnat/gnat.sum:FAIL: gnat.dg/lto8.adb (test for excess errors) ref-last/FAIL.nobootstrap:./gcc/testsuite/gnat/gnat.sum:UNRESOLVED: gnat.dg/lto8.adb compilation failed to produce executable ... After that, I tested an tail-merge (AFAIK unrelated) patch on top of the same sources, and now the test fails for both: ... test-pr51879.8.4.patch/with/FAIL:./gcc/testsuite/gnat/gnat.sum:FAIL: gnat.dg/lto8.adb (test for excess errors) test-pr51879.8.4.patch/with/FAIL:./gcc/testsuite/gnat/gnat.sum:UNRESOLVED: gnat.dg/lto8.adb compilation failed to produce executable test-pr51879.8.4.patch/with/FAIL.nobootstrap:./gcc/testsuite/gnat/gnat.sum:FAIL: gnat.dg/lto8.adb (test for excess errors) test-pr51879.8.4.patch/with/FAIL.nobootstrap:./gcc/testsuite/gnat/gnat.sum:UNRESOLVED: gnat.dg/lto8.adb compilation failed to produce executable ... So I'm not sure that the failure is linked to --nobootstrap.
[Bug libstdc++/52591] New: [C++0x] [4.7 Regression] moving std::vector relies on movable elements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52591 Bug #: 52591 Summary: [C++0x] [4.7 Regression] moving std::vector relies on movable elements Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: expipipl...@gmail.com Created attachment 26894 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26894 A simple testcase. libstdc++ has a code branch in the move assignment operator of vector which depends on the move assignment operator of the element type. I'm compiling with 'g++ -std=c++11 test.cpp' The attached code compiles with no problems using either: 'g++-4.6 -std=c++0x test.cpp' or 'clang++ -std=c++11 -stdlib=libc++ test.cpp' The wonderful template error message: In file included from /usr/local/lib/gcc/x86_64-linux-gnu/4.7.0/../../../../include/c++/4.7.0/vector:61:0, from move.cpp:1: /usr/local/lib/gcc/x86_64-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/stl_algobase.h: In instantiation of 'static _OI std::__copy_move::__copy_m(_II, _II, _OI) [with _II = C*; _OI = C*]': /usr/local/lib/gcc/x86_64-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/stl_algobase.h:384:70: required from '_OI std::__copy_move_a(_II, _II, _OI) [with bool _IsMove = true; _II = C*; _OI = C*]' /usr/local/lib/gcc/x86_64-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/stl_algobase.h:422:39: required from '_OI std::__copy_move_a2(_II, _II, _OI) [with bool _IsMove = true; _II = __gnu_cxx::__normal_iterator >; _OI = C*]' /usr/local/lib/gcc/x86_64-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/stl_algobase.h:454:18: required from '_OI std::copy(_II, _II, _OI) [with _II = std::move_iterator<__gnu_cxx::__normal_iterator > >; _OI = C*]' /usr/local/lib/gcc/x86_64-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/vector.tcc:275:4: required from 'void std::vector<_Tp, _Alloc>::_M_assign_aux(_ForwardIterator, _ForwardIterator, std::forward_iterator_tag) [with _ForwardIterator = std::move_iterator<__gnu_cxx::__normal_iterator > >; _Tp = C; _Alloc = std::allocator]' /usr/local/lib/gcc/x86_64-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/stl_vector.h:1235:4: required from 'void std::vector<_Tp, _Alloc>::_M_assign_dispatch(_InputIterator, _InputIterator, std::__false_type) [with _InputIterator = std::move_iterator<__gnu_cxx::__normal_iterator > >; _Tp = C; _Alloc = std::allocator]' /usr/local/lib/gcc/x86_64-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/stl_vector.h:506:4: required from 'void std::vector<_Tp, _Alloc>::assign(_InputIterator, _InputIterator) [with _InputIterator = std::move_iterator<__gnu_cxx::__normal_iterator > >; _Tp = C; _Alloc = std::allocator]' /usr/local/lib/gcc/x86_64-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/stl_vector.h:448:6: required from 'std::vector<_Tp, _Alloc>& std::vector<_Tp, _Alloc>::operator=(std::vector<_Tp, _Alloc>&&) [with _Tp = C; _Alloc = std::allocator; std::vector<_Tp, _Alloc> = std::vector]' move.cpp:17:38: required from here /usr/local/lib/gcc/x86_64-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/stl_algobase.h:348:8: error: use of deleted function 'C& C::operator=(const C&)' move.cpp:4:7: note: 'C& C::operator=(const C&)' is implicitly deleted because the default definition would be ill-formed: move.cpp:4:7: error: non-static reference member 'int& C::m_r', can't use default assignment operator
[Bug ada/52362] gnat.dg/lto8.adb FAILs with gas/gld
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52362 --- Comment #4 from Eric Botcazou 2012-03-14 21:10:38 UTC --- > After that, I tested an tail-merge (AFAIK unrelated) patch on top of the same > sources, and now the test fails for both: With exactly the same invocation of make -k check, in particular from the same directory?
[Bug ada/52362] gnat.dg/lto8.adb FAILs with gas/gld
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52362
--- Comment #5 from vries at gcc dot gnu.org 2012-03-14 21:28:40 UTC ---
(In reply to comment #4)
> > After that, I tested an tail-merge (AFAIK unrelated) patch on top of the
> > same
> > sources, and now the test fails for both:
>
> With exactly the same invocation of make -k check, in particular from the same
> directory?
Same invocation of make -k check:
...
make \
-k \
-j9 \
check \
> CHECKLOG 2>&1
...
Not the same dirs (4 different dirs {ref,patch}x{bootstrap,nobootstrap}).
[Bug libstdc++/52590] std::thread Segmentation fault static linking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52590 --- Comment #2 from Jason Toffaletti 2012-03-14 21:29:18 UTC --- (In reply to comment #1) > > -static > > You need to make sure all of libpthread.a is included, right it does not get > linked that way. > > This is not a GCC or glibc bug. Your comment seems to suggest there is a way, but I can't find it. g++ -Wl,--whole-archive -static -pthread -std=c++0x -o thread thread.cc Gives pages of linker errors. http://sourceware.org/bugzilla/show_bug.cgi?id=10652 suggests glibc and pthreads just don't work with static linking.
[Bug target/50797] [x32] Use 32bit Pmode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50797 --- Comment #2 from hjl at gcc dot gnu.org 2012-03-14 22:20:23 UTC --- Author: hjl Date: Wed Mar 14 22:20:17 2012 New Revision: 185396 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185396 Log: Add -maddress-mode=short|long for x86 2012-03-14 H.J. Lu PR target/50797 * config/i386/i386-opts.h (pmode): New. * config/i386/i386.c (ix86_option_override_internal): Properly check and set ix86_pmode. * config/i386/i386.h (Pmode): Check ix86_pmode instead of TARGET_64BIT. * config/i386/i386.opt (maddress-mode=): New. * doc/invoke.texi: Document -maddress-mode=short|long for x86. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386-opts.h trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.h trunk/gcc/config/i386/i386.opt trunk/gcc/doc/invoke.texi
[Bug libstdc++/52591] [C++0x] [4.7 Regression] moving std::vector relies on movable elements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52591 Paolo Carlini changed: What|Removed |Added CC||jwakely.gcc at gmail dot ||com --- Comment #1 from Paolo Carlini 2012-03-14 22:43:45 UTC --- Jon, can you have a look? I suspect it's just matter of telling apart cases in the move-assignment operator at compile time with templates instead of a normal conditional.
[Bug target/49468] SH Target: inefficient integer abs code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49468 --- Comment #10 from Oleg Endo 2012-03-14 22:58:05 UTC --- Author: olegendo Date: Wed Mar 14 22:57:58 2012 New Revision: 185397 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185397 Log: PR target/49468 * gcc.target/sh/pr49468-si.c: Make dg-skip-if not the first directive. * gcc.target/sh/pr49468-di.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/sh/pr49468-di.c trunk/gcc/testsuite/gcc.target/sh/pr49468-si.c
[Bug c++/14710] Warning about useless casts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14710 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED CC|paolo.carlini at oracle dot | |com | AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Target Milestone|--- |4.8.0 --- Comment #9 from Paolo Carlini 2012-03-14 23:10:06 UTC --- Ok, thanks. Let's see..
[Bug libstdc++/52591] [C++0x] [4.7 Regression] moving std::vector relies on movable elements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52591 Joe Hermaszewski changed: What|Removed |Added Version|4.7.0 |4.8.0 --- Comment #2 from Joe Hermaszewski 2012-03-14 23:34:32 UTC --- Nothing's changed in the move assignment operator in 4.8, the error remains the same.
[Bug libstdc++/52591] [C++0x] [4.7 Regression] moving std::vector relies on movable elements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52591 --- Comment #3 from Paolo Carlini 2012-03-14 23:46:59 UTC --- You bet it ;)
[Bug libstdc++/52591] [C++0x] [4.7 Regression] moving std::vector relies on movable elements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52591 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-03-15 CC|jwakely.gcc at gmail dot| |com | AssignedTo|unassigned at gcc dot |redi at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.1 Ever Confirmed|0 |1 --- Comment #4 from Jonathan Wakely 2012-03-15 00:29:36 UTC --- Hmm, it shouldn't be taking that branch anyway, the allocators should be equal.
[Bug libstdc++/52591] [C++0x] [4.7 Regression] moving std::vector relies on movable elements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52591 --- Comment #5 from Jonathan Wakely 2012-03-15 00:36:22 UTC --- (In reply to comment #1) > Jon, can you have a look? I suspect it's just matter of telling apart cases in > the move-assignment operator at compile time with templates instead of a > normal > conditional. Oh I see what you mean, the untaken branch is instantiated anyway. It's not possible to tell if the allocators are equal at compile-time and until we implement DR 2103 (I have a patch) propagate_on_container_move_assignment is false for std::allocator, so that branch will be taken in general. Anyway, I'll look into it...
[Bug libstdc++/52591] [C++0x] [4.7 Regression] moving std::vector relies on movable elements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52591 --- Comment #6 from Jonathan Wakely 2012-03-15 00:51:23 UTC --- The allocator-aware container requirements (table 99) state that move-assigning a vector requires that the element type be MoveAssignable
[Bug libstdc++/52591] [C++0x] [4.7 Regression] moving std::vector relies on movable elements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52591 --- Comment #7 from Jonathan Wakely 2012-03-15 00:58:15 UTC --- std::vector did not conform to the C++11 allocator-aware container requirements in 4.6, now it does, so you can't use a non-MoveAssignable type as the element type. It would be possible to dispatch to a different function for the cases when propagate_on_container_move_assignment is true or the allocators are known to always compare equal (which I suspect libc++ does) and I'll consider doing that as a conforming extension, but I think the testcase is invalid.
[Bug libstdc++/52591] [C++0x] [4.7 Regression] moving std::vector relies on movable elements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52591 --- Comment #8 from Paolo Carlini 2012-03-15 01:01:36 UTC --- I see. That conforming extension seems nice to have, anyway, I agree (together with 2103)
[Bug libstdc++/52591] [C++0x] [4.7 Regression] moving std::vector relies on movable elements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52591 --- Comment #9 from Jonathan Wakely 2012-03-15 01:20:33 UTC --- Created attachment 26895 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26895 barely tested patch that allows testcase to compile here's a prototype, I'll come back to it later
[Bug libstdc++/52591] [C++0x] [4.7 Regression] moving std::vector relies on movable elements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52591 Jonathan Wakely changed: What|Removed |Added Severity|major |enhancement --- Comment #10 from Jonathan Wakely 2012-03-15 01:25:34 UTC --- N.B. that relies on the "always equal" extension for allocators which I already implemented (and reported as DR 2108) when we implement DR 2103 it will work because POCMA will be true for std::allocator
[Bug libstdc++/52590] std::thread Segmentation fault static linking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52590 --- Comment #3 from Jason Toffaletti 2012-03-15 04:14:40 UTC --- $ g++-4.7 -Wl,-M -v -static -pthread -std=c++0x -o thread thread.cc shows all of libpthread being linked. With a bit more digging I traced the problem to /usr/include/c++/4.7.0/x86_64-linux-gnu/bits/gthr-posix.h declaring all of its symbols with __attribute__((weakref)) even when linking statically. Which caused the __gthread_* symbols to resolve to zero. I found this for some background info http://gcc.gnu.org/ml/gcc/2005-10/msg00235.html This change made my example work: $ g++ -D_GLIBCXX_GTHREAD_USE_WEAK=0 -static -pthread -std=c++0x -o thread thread.cc $ ./thread pthread_create works std::thread works However, if I change the code to call std::thread::detach instead of join, then it crashes again with std::thread::detach being resolved to zero. Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x00439785 in std::thread::detach() () #2 0x00401f52 in main ()
[Bug target/52479] SH Target: SH4A DFmode fsca tests failing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52479 --- Comment #2 from Alexandre Oliva 2012-03-15 04:47:07 UTC --- IMHO, the whole point of -ffast-math is to trade precision for speed, so the use of fsca makes sense to me, but I wouldn't mind if we no longer used it for DFmode.
[Bug go/52583] Several new go testsuite failues on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583 --- Comment #2 from Ian Lance Taylor 2012-03-15 05:27:03 UTC --- What's failing is not Printf or Println, but the filename and line number. Those are retrieved using DWARF lookup on the PC, and evidently something is going wrong in that area. It might be interesting to know if the test succeeds using GOCFLAGS=-g, rather than the default -g -O2.
[Bug c/52592] New: mplayer compilation failure with undefined reference to `__builtin_iround'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52592 Bug #: 52592 Summary: mplayer compilation failure with undefined reference to `__builtin_iround' Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: o...@ojab.ru MPlayer build fails with gcc-4.7.0rc2 (see http://bugzilla.mplayerhq.hu/show_bug.cgi?id=2047 ): gcc -o mencoder mencoder.o parser-mecmd.o … -lfribidi -lass -lz -lbz2 -lmad -lvpx -lpthread -ldl -rdynamic -lmp3lame ffmpeg/libavcodec/libavcodec.a(ffv1.o): In function `encode_init': ffv1.c:(.text.unlikely+0x16a1): undefined reference to `__builtin_iround' collect2: error: ld returned 1 exit status make: *** [mencoder] Error 1 make: *** Waiting for unfinished jobs ffmpeg/libavcodec/libavcodec.a(ffv1.o): In function `encode_init': ffv1.c:(.text.unlikely+0x16a1): undefined reference to `__builtin_iround' collect2: error: ld returned 1 exit status make: *** [mplayer] Error 1 Looks like related to http://gcc.gnu.org/ml/gcc-patches/2011-08/msg01001.html and >Please document those in doc/extend.texi and make sure they do not leak into >the global namespace as ifloor, etc., but are only available as >__builtin_ifloor, etc.. from http://gcc.gnu.org/ml/gcc-patches/2011-08/msg01003.html mplayer builds fine with CFLAGS=-ffast-math, I think that it can be gcc bug. Please tell me what additional info is needed.
[Bug target/52593] New: Builtin sqrt on x86 is not correctly rounded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52593 Bug #: 52593 Summary: Builtin sqrt on x86 is not correctly rounded Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: bug...@aerifal.cx The builtin sqrt() on x86 (i387) should be disabled except with -ffast-math because it is not correctly rounded. For example, sqrt(0x1.fp-1) yields 1 instead of 0x1.fp-1. Using -fno-builtin-sqrt will give the correct value assuming your C library/libm is correctly rounded. Unfortunately bugs like this seem endemic in gcc. I would really like to see all dubious builtins and other dubious floating point optimizations disabled except with -ffast-math until somebody takes the time to rigorously test them and prove their correctness.
[Bug c/52592] mplayer compilation failure with undefined reference to `__builtin_iround'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52592 --- Comment #1 from Andrew Pinski 2012-03-15 06:00:37 UTC --- What target is this on?
[Bug middle-end/52592] mplayer compilation failure with undefined reference to `__builtin_iround'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52592 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-03-15 Component|c |middle-end Ever Confirmed|0 |1 --- Comment #2 from Andrew Pinski 2012-03-15 06:01:53 UTC --- Can you attach the preprocessed source for ffv1.c ? Also can you give the exact command is used to compile ffv1.c ?
[Bug middle-end/52592] mplayer compilation failure with undefined reference to `__builtin_iround'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52592 --- Comment #3 from ojab 2012-03-15 06:04:02 UTC --- $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.7.0-RC-20120314/configure --prefix=/usr --libexecdir=/usr/lib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++ --disable-multilib --disable-bootstrap --with-system-zlib Thread model: posix gcc version 4.7.0 20120314 (prerelease) (GCC) Compilation string: gcc -I. -I./ -DHAVE_AV_CONFIG_H -Wundef -Wall -Wno-switch -Wno-parentheses -Wpointer-arith -Wredundant-decls -Wstrict-prototypes -Wmissing-prototypes -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement -std=gnu99 -Werror-implicit-function-declaration -O4 -march=native -mtune=native -pipe -ffast-math -fomit-frame-pointer -fno-tree-vectorize -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -Ilibdvdread4 -I. -Iffmpeg -D_REENTRANT -I/usr/include/freetype2 -MD -MP -c -o libavcodec/ffv1.o libavcodec/ffv1.c
[Bug middle-end/52592] mplayer compilation failure with undefined reference to `__builtin_iround'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52592 --- Comment #4 from ojab 2012-03-15 06:04:38 UTC --- Created attachment 26896 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26896 Preprocessed source
[Bug middle-end/52592] [4.7/4.8 Regression] compilation failure with undefined reference to `__builtin_iround'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52592 Andrew Pinski changed: What|Removed |Added Keywords||link-failure, wrong-code Target||x86_64-*-linux-gnu Status|WAITING |NEW Target Milestone|--- |4.7.0 Summary|mplayer compilation failure |[4.7/4.8 Regression] |with undefined reference to |compilation failure with |`__builtin_iround' |undefined reference to ||`__builtin_iround' Severity|normal |critical --- Comment #5 from Andrew Pinski 2012-03-15 06:13:11 UTC --- Reducing a testcase.
[Bug middle-end/52592] [4.7/4.8 Regression] compilation failure with undefined reference to `__builtin_iround'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52592 --- Comment #6 from Andrew Pinski 2012-03-15 06:13:42 UTC --- Note a simple testcase works correctly.
[Bug middle-end/52592] [4.7/4.8 Regression] compilation failure with undefined reference to `__builtin_iround'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52592
--- Comment #7 from Andrew Pinski 2012-03-15
06:43:55 UTC ---
Reduced testcase:
int best_state[256][256];
__attribute__((cold))
int encode_init(double p) {
return best_state[(int)round(p)][0];
}
--- CUT ---
(define_expand "lround2"
[(match_operand:SWI248x 0 "nonimmediate_operand" "")
(match_operand:X87MODEF 1 "register_operand" "")]
"(TARGET_USE_FANCY_MATH_387
&& (!(SSE_FLOAT_MODE_P (mode) && TARGET_SSE_MATH)
|| TARGET_MIX_SSE_I387)
&& flag_unsafe_math_optimizations)
|| (SSE_FLOAT_MODE_P (mode) && TARGET_SSE_MATH
&& mode != HImode
&& ((mode != DImode) || TARGET_64BIT)
&& !flag_trapping_math && !flag_rounding_math)"
{
if (optimize_insn_for_size_p ())
FAIL;
--- CUT ---
Looks like there is a disconnect about when choosing iround over lround.
I bet the code that handles the expanding of __builtin_iround
(expand_builtin_int_roundingfn_2) should do exactly what the expanding of iceil
does (expand_builtin_int_roundingfn).
