[Bug fortran/55935] [OOP] Fortran fronted has ADDR_EXPRs of FUNCTION_DECLs with bogus BLOCK
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55935
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org
|gnu.org |
--- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-11
09:18:41 UTC ---
Created attachment 29142
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29142
gcc48-pr55935.patch
Untested fix. Although the FE perhaps could unshare_expr_without_location so
that ADDR_EXPRs in the ctor don't have location, IMHO gimple-fold.c still has
to at least unshare_expr those expressions it copies from the constructors,
otherwise we'll end up with invalid sharing of ADDR_EXPRs etc. between
different functions (or within the same function).
This can be reproduced even with C:
void foo (void);
struct S { int i; void (*fn) (); };
const struct S s = { 5, foo };
void *fn1 (int x) { if (x 0) return s.fn; if (x) return 0; return s.fn; }
void *fn2 (int x) { if (x 0) return s.fn; if (x) return 0; return s.fn; }
void *fn3 (void) { return s.fn; }
void *fn4 (void) { return s.fn; }
at -O2, in *.copyrename1 pass all 6 ADDR_EXPRs in the IL are still shared.
ccp1 for whatever reason unshares them all (surprisingly).
[Bug fortran/55935] [OOP] Fortran fronted has ADDR_EXPRs of FUNCTION_DECLs with bogus BLOCK
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55935 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-11 10:03:09 UTC --- Created attachment 29143 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29143 gcc48-pr55935.patch Or alternative patch that ensures in the FE there are no locations in the ctor expressions, and just unshare_expr in the middle-end. But I tend to prefer the other patch.
[Bug tree-optimization/44061] [4.6/4.7/4.8 Regression] Warns about out-of-bounds array access inside __builtin_constant_p guarded section
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44061 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org 2013-01-11 10:20:13 UTC --- Author: rguenth Date: Fri Jan 11 10:20:02 2013 New Revision: 195103 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195103 Log: 2012-01-11 Richard Guenther rguent...@suse.de PR tree-optimization/44061 * tree-vrp.c (extract_range_basic): Compute zero as value-range for __builtin_constant_p of function parameters. * gcc.dg/pr44061.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr44061.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug c++/55898] Can't obtain stack trace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55898 --- Comment #4 from Jonathan Liu net147 at gmail dot com 2013-01-11 10:20:15 UTC --- It works if I compile the test case with -fno-exceptions.
[Bug tree-optimization/44061] [4.6/4.7 Regression] Warns about out-of-bounds array access inside __builtin_constant_p guarded section
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44061 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.8.0 Summary|[4.6/4.7/4.8 Regression]|[4.6/4.7 Regression] Warns |Warns about out-of-bounds |about out-of-bounds array |array access inside |access inside |__builtin_constant_p|__builtin_constant_p |guarded section |guarded section Known to fail|4.8.0 |4.7.2 --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org 2013-01-11 10:21:04 UTC --- Fixed on trunk sofar.
[Bug lto/55937] lto hides possible link issues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55937 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2013-01-11 10:36:46 UTC --- Yes, this is not a bug. Generally configure tests should not use optimization.
[Bug target/54300] [4.7 Regression] Erroneous optimization causes wrong Neon data management
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54300 --- Comment #6 from Eric Batut eric.batut at allegorithmic dot com 2013-01-11 10:42:04 UTC --- The patch by Christophe Lyon in the linked email was applied on trunk by Ramana at rev 188951 (June 25th 2012), but gcc-trunk still fails as of today (rev 195102). The vswp instruction that causes d19 to be 0 before being used afterwards is still generated. Don't know about 4.7.x, though. So unless my test is wrong (same command line and same test case as in the original bug report), 4.8.0 should not be in the Known to work field. Did you try with trunk ? (In reply to comment #5) I could not reproduce this in a modified 4.7.0 which has patches from the trunk. I think it was fixed by http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01732.html .
[Bug rtl-optimization/55672] [4.8 Regression] -fstack-check=generic ICEs in print_reg, at config/i386/i386.c:13868
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55672 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-11 10:44:34 UTC --- Assuming fixed.
[Bug tree-optimization/55936] Missed VRP optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55936
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2013-01-11
AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
Known to fail||4.6.4, 4.7.2, 4.8.0
--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2013-01-11
10:48:08 UTC ---
Confirmed. We should see that i = baz () is not executed.
Visiting conditional with predicate: if (i_22 0)
With known ranges
i_22: [j_12(D), j_12(D)] EQUIVALENCES: { i_9(D) j_12(D) i_24 i_26 } (4
elements)
Predicate evaluates to: DON'T KNOW
that result happens because i_22 was computed as
Visiting statement:
i_22 = ASSERT_EXPR i_24, i_24 == j_12(D);
Intersecting
[j_12(D), j_12(D)] EQUIVALENCES: { i_9(D) j_12(D) i_24 i_26 } (4 elements)
and
[10, 30] EQUIVALENCES: { i_9(D) i_26 } (2 elements)
to
[j_12(D), j_12(D)] EQUIVALENCES: { i_9(D) j_12(D) i_24 i_26 } (4 elements)
Found new range for i_22: [j_12(D), j_12(D)]
that's correct (equivalences have the [10, 30] range but they are not
checked during predicate evaluation it seems, we could also have
arbitrarily chosen [10, 30] instead of [j_12(D), j_12(D)] here)
This means we compute i as VARYING.
[Bug tree-optimization/55936] [4.6/4.7/4.8 Regression] Missed VRP optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55936 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Known to work||4.1.2 Target Milestone|--- |4.6.4 Summary|Missed VRP optimization |[4.6/4.7/4.8 Regression] ||Missed VRP optimization --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2013-01-11 10:55:19 UTC --- Worked with at least 4.1.2, thus a regression for which I have a patch.
[Bug target/55939] New: [4.6/4.7/4.8 regression] gcc miscompiles gmp-5.0.5 on m68k-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55939 Bug #: 55939 Summary: [4.6/4.7/4.8 regression] gcc miscompiles gmp-5.0.5 on m68k-linux Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: mi...@it.uu.se Building gmp-5.0.5 for m68k (configure for --host=m68020-unknown-linux), with gcc 4.6, 4.7, or 4.8, and then running gmp's test suite results in: make[4]: Entering directory `/home/mikpe/objdir-gmp/tests/mpq' ... ERROR (check_random test 1): bad mpq_set_d results 3.098073531878046e-120 3.098073531878046e-120 ... 1 of 11 tests failed The failure is 100% repeatable. Building with gcc-4.5.4 instead eliminates the failure, so this is a regression. I don't have a reduced test case yet. I'm going to start a bisection on gcc trunk to hopefully identify when this regression started.
[Bug target/55939] [4.6/4.7/4.8 regression] gcc miscompiles gmp-5.0.5 on m68k-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55939 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.4
[Bug target/55940] New: Incorrect code for accessing parameters with 32-bit Intel hosts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55940
Bug #: 55940
Summary: Incorrect code for accessing parameters with 32-bit
Intel hosts
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: f...@os.inf.tu-dresden.de
There are some reports about incorrect compiled Linux kernel modules for
VirtualBox. I've debugged one report (see here:
https://www.virtualbox.org/ticket/11035) and saw that the compiler generated
invalid code for accessing parameters inside a function. When it should read
the parameter from the stack it reads the parameter from a register.
I don't know exactly under which circumstance this happens but this seems to be
related to 32-bit x86 targets. The function VBoxHost_RTR0MemObjGetPagePhysAddr
is marked as __attribute__((cdelc, regparm(0))). The pre-processed
memobj-r0drv.i file is attached to that ticket. The generated code is part of
the vboxdrv.ko file which is also attached to the ticket.
The following code is generated to access the first function parameter (keep
cdecl in mind!):
VBoxHost_RTR0MemObjGetPagePhysAddr():
/usr/src/virtualbox-bin-4.2.4_81684/vboxhost/vboxdrv/r0drv/memobj-r0drv.c:268
955e: 8b 0f mov(%edi),%ecx
9560: 8b 47 04mov0x4(%edi),%eax
/usr/src/virtualbox-bin-4.2.4_81684/vboxhost/vboxdrv/r0drv/memobj-r0drv.c:272
9563: 8d 91 00 10 00 00 lea0x1000(%ecx),%edx
So the function is using the EDI register to access the parameter while it
should read the parameter from the stack.
The C code of this function looks (see memobj-r0drv.i) is:
RTHCPHYS __attribute__((cdecl,regparm(0)))
VBoxHost_RTR0MemObjGetPagePhysAddr(RTR0MEMOBJ MemObj, size_t iPage)
{
PRTR0MEMOBJINTERNAL pMem;
size_t cPages;
do { if (__builtin_expect(!!(!(( (uintptr_t)(MemObj) + 0x1000U = 0x2000U
))), 0)) return ((~(RTHCPHYS)0)); } while (0);
...
(Explanation of the code: This is actually a sanity check if the pointer is
valid; the value must be either less than 0xF000U or greater than
0x0FFFU).
Unfortunately I cannot reproduce this problem myself (gcc 4.7.2 on my Linux
distribution creates correct code). The gcc compiler the user is using is
gcc version 4.7.2 (Exherbo gcc-4.7.2-r2)
(see comment 18 in the above ticket).
[Bug target/55940] Incorrect code for accessing parameters with 32-bit Intel hosts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55940
--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2013-01-11
11:23:02 UTC ---
Your assumptions are wrong according to documentation:
@item cdecl
@cindex functions that do pop the argument stack on the 386
@opindex mrtd
On the Intel 386, the @code{cdecl} attribute causes the compiler to
assume that the calling function pops off the stack space used to
pass arguments. This is
useful to override the effects of the @option{-mrtd} switch.
which doesn't say that all arguments will be passed on the stack.
[Bug target/55940] Incorrect code for accessing parameters with 32-bit Intel hosts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55940 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-01-11 Ever Confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2013-01-11 11:26:44 UTC --- Please provide preprocessed source and compiler command-line. I suppose VBoxHost_RTR0MemObjGetPagePhysAddr is static so the compiler is free to choose a more optimal calling convention. If you want to avoid this mark it with the used attribute, I don't think an explicit regparm(0) will prevent this. Just guessing, without a testcase.
[Bug target/55940] Incorrect code for accessing parameters with 32-bit Intel hosts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55940 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||i?86-*-* --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2013-01-11 11:36:36 UTC --- Btw, I can't reproduce it with the testcase from the virtualbox ticket. I also cannot reproduce that regparm(0) does not correctly cancel -mregparm=3.
[Bug fortran/55932] DDT's default structure constructor does not work with having allocatable member variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55932 --- Comment #2 from stefan.mauerberger at gmail dot com 2013-01-11 11:50:19 UTC --- Indeed, it is a F2003 feature. Does that matter? I searched for duplicates without finding a similar one. Anyways ... Thanks for the suggested workaround. It seems to work just fine for my pursues.
[Bug tree-optimization/53342] [4.8 Regression] rnflow.f90 is ~5% slower after revision 187340
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53342 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-11 11:52:59 UTC --- Created attachment 29144 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29144 hackish attempt
[Bug fortran/49213] [OOP] gfortran rejects structure constructor expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49213 --- Comment #11 from janus at gcc dot gnu.org 2013-01-11 12:04:26 UTC --- Note: Neither of the patches in comment 8 and 10 shows any testsuite regressions.
[Bug inline-asm/55934] [4.8 Regression] LRA inline asm error recovery
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55934 --- Comment #2 from Steven Bosscher steven at gcc dot gnu.org 2013-01-11 12:49:16 UTC --- This is trivially fixed with the following patch: Index: lra-assigns.c === --- lra-assigns.c (revision 195104) +++ lra-assigns.c (working copy) @@ -1240,6 +1240,9 @@ assign_by_spills (void) asm_p = true; error_for_asm (insn, %asm% operand has impossible constraints); + /* Avoid further trouble with this insn. */ + PATTERN (insn) = gen_rtx_USE (VOIDmode, const0_rtx); + lra_set_insn_deleted (insn); } } lra_assert (asm_p);
[Bug inline-asm/55934] [4.8 Regression] LRA inline asm error recovery
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55934 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||steven at gcc dot gnu.org AssignedTo|unassigned at gcc dot |steven at gcc dot gnu.org |gnu.org | --- Comment #3 from Steven Bosscher steven at gcc dot gnu.org 2013-01-11 12:50:57 UTC --- (In reply to comment #2) This is trivially fixed with the following patch: Correction: should be fixed by that patch, but actually is not... Investigating.
[Bug inline-asm/55934] [4.8 Regression] LRA inline asm error recovery
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55934
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-11
12:59:33 UTC ---
Please also consider asm goto like:
void bar (int);
void
foo (_Complex float x)
{
asm volatile goto ( : : x (x) : : foo); /* { dg-error impossible
constraint } */
bar (1);
foo:
bar (2);
}
Turning a JUMP_INSN pattern into (use (const_int 0)) might not work well,
though apparently reload.c does that too. Perhaps it is lucky enough with it,
as if reload results in errors, following passes are skipped.
[Bug target/55941] New: [4.8 Regression] Strange copy of double (in struct) to stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55941
Bug #: 55941
Summary: [4.8 Regression] Strange copy of double (in struct) to
stack
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gli...@gcc.gnu.org
Target: x86_64-linux-gnu
typedef struct A { double a, b; } A;
double f(A x,double y){return x.a+y;}
generates with gcc -Ofast -S:
addsd%xmm0, %xmm2
movsd%xmm0, -8(%rsp)
movapd%xmm2, %xmm0
ret
I don't understand what that movsd is doing there?
Note that gcc-4.7 generates the expected:
addsd%xmm2, %xmm0
ret
[Bug c++/55931] [C++11] Constexpr member function inside a static member is not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55931 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #2 from Daniel Krügler daniel.kruegler at googlemail dot com 2013-01-11 13:22:13 UTC --- When using gcc 4.8.0 20130106 (experimental) with flags -Wall -std=c++11 -pedantic I get an internal compiler error for the line: static constexpr Testint x(42); 12|internal compiler error: tree check: expected target_expr, have cast_expr in check_initializer, at cp/decl.c:5699 Should this be reported separately?
[Bug c++/55931] [C++11] Constexpr member function inside a static member is not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55931 --- Comment #3 from Daniel Krügler daniel.kruegler at googlemail dot com 2013-01-11 13:26:46 UTC --- (In reply to comment #1) Most likely because Testint is not complete at the time of parsing. But this should be considered as a compiler defect, right?
[Bug fortran/55935] [OOP] Fortran fronted has ADDR_EXPRs of FUNCTION_DECLs with bogus BLOCK
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55935 --- Comment #9 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-01-11 13:35:30 UTC --- Apparently Ada does not like the patch at http://gcc.gnu.org/bugzilla/attachment.cgi?id=29142 When applied on top of r195103 bootstrap (last successful bootstrap was r195098) fails with /opt/gcc/build_w/./prev-gcc/xgcc -B/opt/gcc/build_w/./prev-gcc/ -B/opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/bin/ -B/opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/bin/ -B/opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/lib/ -isystem /opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/include -isystem /opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/sys-include-c -g -O2 -mdynamic-no-pic -gtoggle -gnatpg -gnata -W -Wall -nostdinc -I- -I. -Iada -I../../work/gcc/ada -I../../work/gcc/ada/gcc-interface ../../work/gcc/ada/osint-c.adb -o ada/osint-c.o /var/tmp//ccKGjE41.s:619:FATAL:Symbol LC0 already defined. When I'll have finished a bootstrap without the patch, I'll try the patch for gcc/fortran/trans-expr.c.
[Bug tree-optimization/55936] [4.6/4.7/4.8 Regression] Missed VRP optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55936
--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2013-01-11
13:36:29 UTC ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00592.html even though
it produces way more useful ranges regresses
FAIL: g++.dg/tree-ssa/pr18178.C -std=gnu++98 scan-tree-dump-times vrp1 if 1
FAIL: g++.dg/tree-ssa/pr18178.C -std=gnu++11 scan-tree-dump-times vrp1 if 1
because for asserts:
Visiting statement:
i_18 = ASSERT_EXPR i_1, i_1 _5;
Intersecting
[-INF, _5 + -1] EQUIVALENCES: { i_1 } (1 elements)
and
[0, 1]
to
[0, 1] EQUIVALENCES: { i_1 } (1 elements)
Found new range for i_18: [0, 1]
when we do not choose the range 0 as fallback we lose it completely
(there is no equivalence SSA name we can add to the set of equivalences).
Later this causes
i_19: [0, +INF] EQUIVALENCES: { i_1 i_18 } (2 elements)
...
-_21: [i_18 + 1, +INF] EQUIVALENCES: { _5 } (1 elements)
+_21: [1, +INF] EQUIVALENCES: { _5 } (1 elements)
...
Folding statement: if (i_19 = _21)
-Folding predicate i_19 = _21 to 0
-Folded into: if (0 != 0)
-
+Not folded
as we can fold i_18 = i_18 + 1 orginally.
Leaving for 4.9, as fixing this requires equivalence reorg or use of
one of the equivalences when propagating (which is problematic as
the comment in vrp_visit_cond_stmt suggests).
[Bug fortran/55935] [OOP] Fortran fronted has ADDR_EXPRs of FUNCTION_DECLs with bogus BLOCK
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55935
--- Comment #10 from Richard Biener rguenth at gcc dot gnu.org 2013-01-11
13:43:50 UTC ---
(In reply to comment #7)
Created attachment 29142 [details]
gcc48-pr55935.patch
Untested fix. Although the FE perhaps could unshare_expr_without_location so
that ADDR_EXPRs in the ctor don't have location, IMHO gimple-fold.c still has
to at least unshare_expr those expressions it copies from the constructors,
otherwise we'll end up with invalid sharing of ADDR_EXPRs etc. between
different functions (or within the same function).
This can be reproduced even with C:
void foo (void);
struct S { int i; void (*fn) (); };
const struct S s = { 5, foo };
void *fn1 (int x) { if (x 0) return s.fn; if (x) return 0; return s.fn; }
void *fn2 (int x) { if (x 0) return s.fn; if (x) return 0; return s.fn; }
void *fn3 (void) { return s.fn; }
void *fn4 (void) { return s.fn; }
at -O2, in *.copyrename1 pass all 6 ADDR_EXPRs in the IL are still shared.
ccp1 for whatever reason unshares them all (surprisingly).
We allow those to pass verification in verify_node_sharing because:
/* Return true when the T can be shared. */
bool
tree_node_can_be_shared (tree t)
{
if (IS_TYPE_OR_DECL_P (t)
|| TREE_CODE (t) == SSA_NAME
|| is_gimple_min_invariant (t)
|| t == error_mark_node
|| TREE_CODE (t) == IDENTIFIER_NODE)
return true;
is_gimple_min_invariant is bogus here IMHO. But I guess fixing that
might have quite some fallout ...
Btw, get_symbol_constant_value also unshares the result from
canonicalize_constructor_val (if it's is_gimple_min_invariant).
I suppose we should try fixing tree_node_can_be_shared ...
[Bug bootstrap/55556] gcc/exec-tool.in isn't parallel build safe in combined tree
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2013-01-11 13:49:33 UTC --- Fixed by: http://gcc.gnu.org/ml/gcc-cvs/2013-01/msg00282.html
[Bug fortran/55935] [OOP] Fortran fronted has ADDR_EXPRs of FUNCTION_DECLs with bogus BLOCK
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55935 --- Comment #11 from Richard Biener rguenth at gcc dot gnu.org 2013-01-11 14:05:14 UTC --- Created attachment 29145 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29145 alternative canonicalize_constructor_val fix Should be less expensive.
[Bug fortran/54195] [4.8 Regression][OOP] IMPORT fails with GENERIC TBP: is already present in the interface
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54195 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #11 from Mikael Morin mikael at gcc dot gnu.org 2013-01-11 14:07:22 UTC --- (In reply to comment #10) For comment #8, resolve_typebound_intrinsic_op is called twice: Once for the base type 'nc', and once for the extended type 'ncb'. The `gfc_namespace' struct has a `resolved' attribute. Maybe we can use it?
[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889 Andrey Belevantsev abel at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |abel at gcc dot gnu.org |gnu.org | --- Comment #6 from Andrey Belevantsev abel at gcc dot gnu.org 2013-01-11 14:23:41 UTC --- Created attachment 29146 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29146 Restore debug printing David, could you apply the above patch and send to me the output of the compile command with the -fsched-verbose=6 option? The archive of the -fdump-rtl-all-all files will help as well. I couldn't get access to AIX so this is the only option for me now. (The patch is needed because the debug printing in sel-sched is currently broken, possibly after the sched-vis cleanups. I will apply it as obvious to trunk soon.)
[Bug fortran/54195] [4.8 Regression][OOP] IMPORT fails with GENERIC TBP: is already present in the interface
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54195 --- Comment #12 from janus at gcc dot gnu.org 2013-01-11 14:29:41 UTC --- (In reply to comment #11) (In reply to comment #10) For comment #8, resolve_typebound_intrinsic_op is called twice: Once for the base type 'nc', and once for the extended type 'ncb'. The `gfc_namespace' struct has a `resolved' attribute. Maybe we can use it? Not sure. I was thinking that we may need such an attribute for each type symbol (gfc_symbol.resolved?). See e.g. PR 44978 for a related problem.
[Bug fortran/55935] [OOP] Fortran fronted has ADDR_EXPRs of FUNCTION_DECLs with bogus BLOCK
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55935
--- Comment #12 from Richard Biener rguenth at gcc dot gnu.org 2013-01-11
14:30:29 UTC ---
Index: gcc/tree-cfgcleanup.c
===
--- gcc/tree-cfgcleanup.c (revision 195103)
+++ gcc/tree-cfgcleanup.c (working copy)
@@ -412,7 +412,8 @@ remove_forwarder_block (basic_block bb)
{
gimple phi = gsi_stmt (gsi);
source_location l = gimple_phi_arg_location_from_edge (phi,
succ);
- add_phi_arg (phi, gimple_phi_arg_def (phi, succ-dest_idx), s,
l);
+ tree def = gimple_phi_arg_def (phi, succ-dest_idx);
+ add_phi_arg (phi, unshare_expr (def), s, l);
}
}
}
is the only other that triggers in tree-ssa.exp with
Index: gcc/tree-cfg.c
===
--- gcc/tree-cfg.c (revision 195103)
+++ gcc/tree-cfg.c (working copy)
@@ -4440,8 +4460,8 @@ bool
tree_node_can_be_shared (tree t)
{
if (IS_TYPE_OR_DECL_P (t)
- || is_gimple_min_invariant (t)
|| TREE_CODE (t) == SSA_NAME
+ || CONSTANT_CLASS_P (t)
|| t == error_mark_node
|| TREE_CODE (t) == IDENTIFIER_NODE)
return true;
execute.exp has more issue it seems.
removal of the handled_component_p block from tree_node_can_be_shared
has bootstrapped all languages ok, testing is still in progress.
[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889 --- Comment #7 from David Edelsohn dje at gcc dot gnu.org 2013-01-11 14:37:21 UTC --- Created attachment 29147 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29147 sched-verbose=6 dump output for failing testcase
[Bug c++/55931] [C++11] Constexpr member function inside a static member is not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55931 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-11 Ever Confirmed|0 |1 Severity|major |normal --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-11 14:37:36 UTC --- (In reply to comment #2) Should this be reported separately? Yes please, but note this PR in the comments and vice versa, in case they turn out to be fixed by the same change. (In reply to comment #3) But this should be considered as a compiler defect, right? Right.
[Bug fortran/55935] [OOP] Fortran fronted has ADDR_EXPRs of FUNCTION_DECLs with bogus BLOCK
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55935 --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-11 14:40:45 UTC --- Created attachment 29148 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29148 gimple-fold Alternative to alternative canonicalize_constructor_val fix which I'm afraid could sometimes unshare up to 3 times. Or we could just tree orig_cval = cval = unshare_expr (cval); as the first thing in the function (and drop the unshare_expr in fold_gimple_assign of course).
[Bug c++/55942] New: [C++11] sorry, unimplemented: calling a member function of the object being constructed in a constant expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55942
Bug #: 55942
Summary: [C++11] sorry, unimplemented: calling a member
function of the object being constructed in a constant
expression
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: FIXME
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
struct A
{
constexpr explicit A(bool b) : o{flip(b)} { }
constexpr bool flip(bool b) { return !b; }
bool o;
};
ce.cc: In constructor 'constexpr A::A(bool)':
ce.cc:3:49: sorry, unimplemented: calling a member function of the object being
constructed in a constant expression
constexpr explicit A(bool b) : o{flip(b)} { }
^
I found this by accident because I meant to define A::flip as a static member
function, which would have worked. Omitting the static gives the sorry above.
[Bug target/55941] [4.8 Regression] Strange copy of double (in struct) to stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55941 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-11 CC||jakub at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-11 14:44:23 UTC --- This first regressed with: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190492 into: movsd %xmm0, -8(%rsp) addsd %xmm2, %xmm0 and then we regress again with: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190847 into: addsd %xmm0, %xmm2 movsd %xmm0, -8(%rsp) movapd %xmm2, %xmm0
[Bug middle-end/37722] destructors not called on computed goto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37722
Timo Kreuzer timo.kreuzer at reactos dot org changed:
What|Removed |Added
CC||timo.kreuzer at reactos dot
||org
--- Comment #3 from Timo Kreuzer timo.kreuzer at reactos dot org 2013-01-11
14:52:03 UTC ---
(In reply to comment #2)
int bar(int idx) {
static void* const gotos[] = {RETRY, INSIDE, OUTSIDE, EVIL};
bool first = true;
{
RETRY:
foo1 f1;
if(first) {
first = false;
Well usually you cannot declare a variable after a label. That's a gcc
extension. So you should either add curly braces between RETRY and INSIDE, or
move RETRY above the preceeding brace. But that is just syntax, since it would
be desired that it behaved like it would with a normal goto, even if that was
placed like that. (I assume normal gotos will handle this properly)
To theoretically solve the proplem, you could replace every indirect goto with
code like this:
{
static void* const local_gotos[] = {label1, label2, label3,
label4};
goto *local_gotos[idx];
label1: goto RETRY;
label2: goto INSIDE;
label3: goto OUTSIDE;
label4: goto EVIL;
}
And now have the compiler optimize the pathes.
This way, there are no more crazy jumps, just a very simple indirect jump and a
number of normal jumps that the compiler should be able to handle anyway.
The problem is now, that there might be multiple indirect jumps that use the
same static data, which is just a bunch of void pointers.
So depending on the origin of the jump different pathes would need to be
generated for each target. This is incompatible with an indirect jump
instruction though, which only utilizes some arbitrary address.
One possible solution for this is to always invoke all destructors and
constructors, even for local indirect gotos. So you would need to consider an
indirect jump to always leave all scope blocks, up to the top level of the
function and reenter from there. This would allow to generate labels/codepathes
that are consistent for multiple indirect gotos.
Another solution, is to use multiple jump tables. One table for each indirect
goto containing one entry for each possibly referenced label in the function.
The trick is that the original label addresses, that are produced with the
operator will all point to an array of direct jmp instructions. all of the
same size. Now the first indirect goto would emit an indirect jump instruction
to the address itself. The second one would substract the address of the first
label, divide by the size of the jmp stub code and use the result as an index
into it's own private jump table. Alternatively a static offset could be added
to the actual address and multiple direct jump stubs would be generated in a
row.
table:
.long label1, label2, label3, label4;
table2:
.long label1_from_2, label2_from_2, label3_from_2, label4_from_2;
// first indirect goto
mov eax, table[ecx * 4] // get the address from the table
jmp eax // jump there
// Second indirect goto
mov ecx, table[ecx * 4] // get the address from the table
sub ecx, label1 // substract the address of the first label
shr ecx, 3 // divide by 8 (assuming each stub is 8 bytes)
mov eax, table[ecx * 4] // get the address from the 2nd table
jmp eax // jump there
// Alternative: using multiple stub arrays
mov eax, table[ecx * 4] // get the address from the table
add eax, label5 - label1 // add the offset to the second jmp array
jmp eax // jump there
label1: jmp label1_from_1
label2: jmp label2_from_1
label3: jmp label3_from_1
label4: jmp label4_from_1
label5: jmp label1_from_2
label6: jmp label2_from_2
label7: jmp label3_from_2
label8: jmp label4_from_2
This mechanism would only be needed as soon as multiple indirect jumps could
reference the same labels and different code pathes would need to be
constructed for the targets depending on the origin of the goto.
As an optimization it should be considered that labels, of which the address
has been put in a table, which is now out of scope are not actually available
anymore. Other optimizations might be using 2 different tables directly, if
they are only used for 2 indirect jumps (someone might (mis)use it for
different things like non-local gotos, exception handling, saving the address
of code that is being executed for debugging purposes, etc)
[Bug fortran/55935] [OOP] Fortran fronted has ADDR_EXPRs of FUNCTION_DECLs with bogus BLOCK
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55935
--- Comment #14 from Richard Biener rguenth at gcc dot gnu.org 2013-01-11
14:53:20 UTC ---
(In reply to comment #13)
Created attachment 29148 [details]
gimple-fold
Alternative to alternative canonicalize_constructor_val fix which I'm afraid
could sometimes unshare up to 3 times.
Or we could just tree orig_cval = cval = unshare_expr (cval); as the first
thing in the function (and drop the unshare_expr in fold_gimple_assign of
course).
I think I prefer the latter.
Another one, hits gcc.c-torture/execute/2910-1.c at -O3 -g
Index: tree-ssa.c
===
--- tree-ssa.c (revision 195103)
+++ tree-ssa.c (working copy)
@@ -427,7 +427,7 @@ insert_debug_temp_for_var_def (gimple_st
(!gimple_assign_single_p (def_stmt)
|| is_gimple_min_invariant (value)))
|| is_gimple_reg (value))
- value = unshare_expr (value);
+ ;
else
{
gimple def_temp;
@@ -469,7 +469,7 @@ insert_debug_temp_for_var_def (gimple_st
that was unshared when we found it had a single debug
use, or a DEBUG_EXPR_DECL, that can be safely
shared. */
- SET_USE (use_p, value);
+ SET_USE (use_p, unshare_expr (value));
/* If we didn't replace uses with a debug decl fold the
resulting expression. Otherwise we end up with invalid IL. */
if (TREE_CODE (value) != DEBUG_EXPR_DECL)
[Bug c/52381] asm goto output operands diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52381 --- Comment #5 from Timo Kreuzer timo.kreuzer at reactos dot org 2013-01-11 14:55:15 UTC --- (In reply to comment #4) Like __atomic_compare_exchange_n? Oh, didn't know of this one, thanks. But I'm sure there are other similar things you could solve with the output of asm goto ;-)
[Bug fortran/55935] [OOP] Fortran fronted has ADDR_EXPRs of FUNCTION_DECLs with bogus BLOCK
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55935 --- Comment #15 from Richard Biener rguenth at gcc dot gnu.org 2013-01-11 14:55:55 UTC --- Index: tree-ssa-pre.c === --- tree-ssa-pre.c (revision 195103) +++ tree-ssa-pre.c (working copy) @@ -3246,7 +3246,8 @@ insert_into_preds_of_block (basic_block gcc_assert (get_expr_type (ae) == type || useless_type_conversion_p (type, get_expr_type (ae))); if (ae-kind == CONSTANT) - add_phi_arg (phi, PRE_EXPR_CONSTANT (ae), pred, UNKNOWN_LOCATION); + add_phi_arg (phi, unshare_expr (PRE_EXPR_CONSTANT (ae)), +pred, UNKNOWN_LOCATION); else add_phi_arg (phi, PRE_EXPR_NAME (ae), pred, UNKNOWN_LOCATION); }
[Bug target/55941] [4.8 Regression] Strange copy of double (in struct) to stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55941
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||rth at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-11
15:01:18 UTC ---
I'd hope that the subreg pass could be able to figure out something out of:
(insn 4 3 5 2 (set (reg:TI 63 [ x ])
(const_int 0 [0])) pr55941.c:2 85 {*movti_internal_rex64}
(nil))
(insn 5 4 6 2 (set (subreg:DF (reg:TI 63 [ x ]) 0)
(reg:DF 64 [ x ])) pr55941.c:2 131 {*movdf_internal_rex64}
(expr_list:REG_DEAD (reg:DF 64 [ x ])
(nil)))
(insn 6 5 8 2 (set (subreg:DF (reg:TI 63 [ x ]) 8)
(reg:DF 22 xmm1 [ x+8 ])) pr55941.c:2 131 {*movdf_internal_rex64}
(expr_list:REG_DEAD (reg:DF 22 xmm1 [ x+8 ])
(nil)))
(insn 8 6 9 2 (set (reg:DF 67 [ D.1730 ])
(reg:DF 23 xmm2 [ y ])) pr55941.c:2 131 {*movdf_internal_rex64}
(expr_list:REG_DEAD (reg:DF 23 xmm2 [ y ])
(nil)))
(note 9 8 12 2 NOTE_INSN_FUNCTION_BEG)
(insn 12 9 17 2 (set (reg:DF 67 [ D.1730 ])
(plus:DF (reg:DF 67 [ D.1730 ])
(subreg:DF (reg:TI 63 [ x ]) 0))) pr55941.c:2 785
{*fop_df_comm_sse}
(expr_list:REG_DEAD (reg:TI 63 [ x ])
(nil)))
(all accesses to pseudo 63 in the listed insns), but it only drops the insn 6,
but doesn't figure out the only user uses the low part and thus propagate the
setter. Or perhaps should forwprop propagate something like that?
[Bug debug/55608] [4.6/4.7/4.8/4.9 Regression] Debug info quality regressions with file scope vars
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55608 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Target Milestone|4.6.4 |4.9.0 Summary|[4.6/4.7/4.8 Regression]|[4.6/4.7/4.8/4.9 |Debug info quality |Regression] Debug info |regressions with file scope |quality regressions with |vars|file scope vars --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-11 15:55:17 UTC --- Cary said on gcc-patches this is a stage1 material, so let's defer it for 4.9 then.
[Bug libstdc++/54392] [4.6/4.7/4.8 Regression] std::string::assign() fails to update length
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #16 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-11 15:57:40 UTC --- So, what are we going to do with this? Defer for 4.9, or fix for 4.8?
[Bug libstdc++/54392] [4.6/4.7/4.8 Regression] std::string::assign() fails to update length
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392 --- Comment #17 from Paolo Carlini paolo.carlini at oracle dot com 2013-01-11 16:01:28 UTC --- In my opinion, this isn't really fixable in a generic and decently neat way in the current implementation, that is in std::string. I still mean to fix it in __versa_string for 4.8 too if you like, when I'm back from my 1-week vacations. There a fix is pretty simple.
[Bug middle-end/50199] [4.7/4.8 Regression] wrong code with -flto -fno-merge-constants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50199 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-11 16:02:24 UTC --- I guess it is again too late to really fix this for 4.8, can we at least error out on -fno-merge-constants used together with -flto ? We'll still fail for targets that don't support mergeable string sections, but generally, it makes no sense to use -fno-merge-constants together with -flto.
[Bug libstdc++/54392] [4.6/4.7/4.8 Regression] std::string::assign() fails to update length
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392 --- Comment #18 from Paolo Carlini paolo.carlini at oracle dot com 2013-01-11 16:03:23 UTC --- PS: for 4.9, I think we essentially agree that we want to roll in anyway __versa_string, break the ABI, etc. We also exchanged some ideas about that with Jason, off lists.
[Bug inline-asm/55934] [4.8 Regression] LRA inline asm error recovery
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55934 --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org 2013-01-11 16:09:46 UTC --- I should mention that Investigated this a little before and found the instruction which was causing the ICE was not the inline-asm but a clobber of the pseduregister which was in the complex mode.
[Bug rtl-optimization/55719] [4.8 Regression] ICE: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55719 --- Comment #8 from Andreas Krebbel krebbel at gcc dot gnu.org 2013-01-11 16:43:56 UTC --- Author: krebbel Date: Fri Jan 11 16:43:49 2013 New Revision: 195109 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195109 Log: 2013-01-11 Andreas Krebbel andreas.kreb...@de.ibm.com PR target/55719 * config/s390/s390.c (s390_preferred_reload_class): Do not return NO_REGS for larl operands. (s390_reload_larl_operand): Use s390_load_address instead of emit_move_insn. 2013-01-11 Andreas Krebbel andreas.kreb...@de.ibm.com PR target/55719 * gcc.target/s390/pr55719.c: New testcase. Modified: trunk/gcc/ChangeLog trunk/gcc/config/s390/s390.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/55719] [4.8 Regression] ICE: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55719 Andreas Krebbel krebbel at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #9 from Andreas Krebbel krebbel at gcc dot gnu.org 2013-01-11 16:45:15 UTC --- Fixed with commit above.
[Bug tree-optimization/55920] [4.8 Regression] ICE in expand_debug_locations, at cfgexpand.c:3753
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55920
Martin Jambor jamborm at gcc dot gnu.org changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment #3 from Martin Jambor jamborm at gcc dot gnu.org 2013-01-11
16:53:08 UTC ---
As far as the ICE is concerned, I think that if we want to fix it by
reverting patches, we need to revert both the patch for PR 55579 and
PR 54971 (which introduced the generation of the debug statement in
question).
Alternatively, we can punt and put NULL on the right side of the debug
statement when types do not match. I looked at all places where SRA
generates them and only in sra_modify_assign we can have this problem.
Yes, in 4.9 we can even create a well-typed MEM_REF. Meanwhile, the
minimal patch (that I am about to bootstrap and test) would be:
2013-01-11 Martin Jambor mjam...@suse.cz
PR tree-optimization/55920
* tree-sra.c (sra_modify_assign): Put NULL RHS into debug statement if
it would have incompatible types.
Index: src/gcc/tree-sra.c
===
--- src.orig/gcc/tree-sra.c
+++ src/gcc/tree-sra.c
@@ -3108,8 +3108,15 @@ sra_modify_assign (gimple *stmt, gimple_
if (lacc lacc-grp_to_be_debug_replaced)
{
- gimple ds = gimple_build_debug_bind (get_access_replacement (lacc),
- unshare_expr (rhs), *stmt);
+ tree dbg_rhs;
+ gimple ds;
+
+ if (useless_type_conversion_p (lacc-type, TREE_TYPE (rhs)))
+dbg_rhs = unshare_expr (rhs);
+ else
+dbg_rhs = NULL_TREE;
+ ds = gimple_build_debug_bind (get_access_replacement (lacc), dbg_rhs,
+*stmt);
gsi_insert_before (gsi, ds, GSI_SAME_STMT);
}
[Bug tree-optimization/55920] [4.8 Regression] ICE in expand_debug_locations, at cfgexpand.c:3753
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55920
--- Comment #4 from Martin Jambor jamborm at gcc dot gnu.org 2013-01-11
16:55:54 UTC ---
The debug statements for non-DCEable variables can be easily disabled
by the following (also, yet untested) patch:
2013-01-11 Martin Jambor mjam...@suse.cz
* tree-sra.c (analyze_access_subtree): Do not mark non-removable
accesses as grp_to_be_debug_replaced.
Index: src/gcc/tree-sra.c
===
--- src.orig/gcc/tree-sra.c
+++ src/gcc/tree-sra.c
@@ -2199,7 +2199,9 @@ analyze_access_subtree (struct access *r
{
if (allow_replacements
scalar !root-first_child
- (root-grp_scalar_write || root-grp_assignment_write))
+ (root-grp_scalar_write || root-grp_assignment_write)
+ !bitmap_bit_p (cannot_scalarize_away_bitmap,
+DECL_UID (root-base)))
{
gcc_checking_assert (!root-grp_scalar_read
!root-grp_assignment_read);
[Bug tree-optimization/55920] [4.8 Regression] ICE in expand_debug_locations, at cfgexpand.c:3753
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55920 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-11 17:04:45 UTC --- I'd very much prefer to keep PR54971 fix in. As for #c3, I believe it would be enough to test the mode, so perhaps tree repl = get_access_replacement (lacc); enum machine_mode mode = DECL_MODE (repl); and compare that to TYPE_MODE (TREE_TYPE (rhs)). At least that would match what cfgexpand.c is actually checking, otherwise it looks reasonable. And if #c4 works, that would be even better.
[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55909
--- Comment #35 from philip.copeland at oracle dot com 2013-01-11 17:19:06 UTC
---
(Sorry for the delay in getting back to you)
I've multipass recompiled all the affected packages associated with gcc/glibc
over the last day which has taken quite some time, to try and be sure that none
of the support packages are deficient.
Paolo directed me to wade through the test-suites to look for anything odd
about the TLS results,.. and nothing seemed to be untoward until he mentioned
that he didn't see any thread_local tests
A bit of headscratching, initially the thought was that
// { dg-require-effective-target tls } was false,
however { dg-require-effective-target tls } can't be just false, because the
diag-1.C etc tests from the TLS testsuite were run (successfully). I need to
understand what triggers the tls support. It can't be that tls isn't supported
because the base compiler I used
gcc-4.4.6-3
glibc-2.12
can compile up the test program with tls and complete successfully.
The only immediate code difference I see which probably has no impact is that
the older 4.4.6 code uses
61 extern C __cxa_eh_globals*
62 __cxxabiv1::__cxa_get_globals() throw()
63 { return get_global(); }
whereas the newer 4.7.2 codebase uses
62 __cxxabiv1::__cxa_get_globals() _GLIBCXX_NOTHROW
(can't immediately tell what _GLIBCXX_NOTHROW expands to or comes from, but
I'll work it out)
This is the test program disassembled at the same point when compiled with
older gcc 4.4.6
(gdb) disassemble
Dump of assembler code for function __cxxabiv1::__cxa_get_globals():
0xf801001ee760 +0: save %sp, -176, %sp
0xf801001ee764 +4: sethi %hi(0xc00), %o0
0xf801001ee768 +8: sethi %hi(0), %i0
0xf801001ee76c +12:sethi %hi(0x12d800), %l7
0xf801001ee770 +16:call 0xf801001ee700
0xf801001ee774 +20:add %l7, 0x90, %l7 ! 0x12d890
= 0xf801001ee778 +24:add %o0, 0x80, %o0
0xf801001ee77c +28:xor %i0, 0x10, %i0
0xf801001ee780 +32:call 0xf8010031fce0 __tls_get_addr@plt
0xf801001ee784 +36:add %l7, %o0, %o0
0xf801001ee788 +40:add %o0, %i0, %i0
0xf801001ee78c +44:rett %i7 + 8
0xf801001ee790 +48:nop
End of assembler dump.
So tls DID exist and was being used. I think I can assume that tls support
didn't go away for sparc64 in later gcc releases. (I also threw the binary
against readelf -S
[root@localhost ~]# readelf -S /tmp/test | egrep init|fini|array
[11] .init PROGBITS 00100608 0608
[13] .fini PROGBITS 00100980 0980
so the older fedora 4.4.6 gcc didn't use initfini-array (if it was even an
available option back then)
So this leaves me in the situation of not understanding what nudges gcc into
supporting tls thread_local etc.It's like it's only partially implemented.
(adding testcase snippet attachment)
[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55909 --- Comment #36 from philip.copeland at oracle dot com 2013-01-11 17:20:35 UTC --- Created attachment 29149 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29149 g++/gcc testsuite results g++/gcc testsuite results
[Bug middle-end/55943] New: ICE in gen_reg_rtx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55943 Bug #: 55943 Summary: ICE in gen_reg_rtx Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: sch...@linux-m68k.org Target: ia64-*-* Created attachment 29150 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29150 Testcase $ gcc-20130111/Build/gcc/xgcc -B gcc-20130111/Build/gcc/ -S gcc/gcc/testsuite/gcc.c-torture/compile/pr55921.c gcc/gcc/testsuite/gcc.c-torture/compile/pr55921.c: In function ‘foo’: gcc/gcc/testsuite/gcc.c-torture/compile/pr55921.c:21:1: internal compiler error: in gen_reg_rtx, at emit-rtl.c:866 } ^ 0x4040012f gen_reg_rtx(machine_mode) ../../gcc/emit-rtl.c:866 0x40432f1f store_bit_field_1 ../../gcc/expmed.c:776 0x40433b9f store_bit_field(rtx_def*, unsigned long, unsigned long, unsigned long, unsigned long, machine_mode, rtx_def*) ../../gcc/expmed.c:897 0x4045f40f write_complex_part ../../gcc/expr.c:2960 0x4045f6bf emit_move_complex_parts(rtx_def*, rtx_def*) ../../gcc/expr.c:3216 0x40718dff gen_move_insn(rtx_def*, rtx_def*) ../../gcc/optabs.c:4783 0x407f752f gen_reload ../../gcc/reload1.c:8705 0x408077af emit_input_reload_insns ../../gcc/reload1.c:7591 0x408077af do_input_reload ../../gcc/reload1.c:7877 0x408077af emit_reload_insns ../../gcc/reload1.c:8069 0x408077af reload_as_needed ../../gcc/reload1.c:4645 0x40811f2f reload(rtx_def*, int) ../../gcc/reload1.c:1051 0x40604caf do_reload ../../gcc/ira.c:4635 0x40604caf rest_of_handle_reload ../../gcc/ira.c:4736 Note that this is the original version of pr55921.c with the matching constraints.
[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792 --- Comment #33 from Jan Hubicka hubicka at ucw dot cz 2013-01-11 17:36:48 UTC --- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792 --- Comment #32 from H.J. Lu hjl.tools at gmail dot com 2013-01-10 19:36:08 UTC --- (In reply to comment #30) LTO profiled-bootstrap revals: /space/rguenther/src/svn/trunk/gcc/reginfo.c: In function 'reg_scan': /space/rguenther/src/svn/trunk/gcc/reginfo.c:1015:0: error: location references block not in block tree reg_scan (rtx f, unsigned int nregs ATTRIBUTE_UNUSED) ^ ee fmt_351 = ee; /space/rguenther/src/svn/trunk/gcc/reginfo.c:1015:0: internal compiler error: verify_gimple failed this is a STRING_CST node. Needs to be tracked down ... more IPA stuff needs to use copy_tree_without_location. I think this BLOCK comes from LTO streamer. I guess we could add assert to lto streamer to not read any local blocks during WPA. I will try that. Honza -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55909 --- Comment #37 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-01-11 17:55:38 UTC --- So tls DID exist and was being used. I think I can assume that tls support didn't go away for sparc64 in later gcc releases. (I also threw the binary against readelf -S [root@localhost ~]# readelf -S /tmp/test | egrep init|fini|array [11] .init PROGBITS 00100608 0608 [13] .fini PROGBITS 00100980 0980 so the older fedora 4.4.6 gcc didn't use initfini-array (if it was even an available option back then) My gut feeling is that --enable-initfini-array is completely broken. You need to find out where the .init_array section comes from for your recompiled libstdc++. This could be from the glibc, in which case you need to replace it.
[Bug testsuite/54139] [4.8 regression] some ARM Thumb-2 tests appear to be run on ARMv5TE hardware causing unhandled exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54139 --- Comment #2 from Aldy Hernandez aldyh at gcc dot gnu.org 2013-01-11 18:01:57 UTC --- I have built a cross cc1/cc1plus with: blah/configure --enable-languages=c,c++ --target=armv5tel-unknown-linux-gnueabi but I get a totally different error on testsuite/gcc.target/arm/mmx-2.c, not the unrecognized __builtin_arm* errors reported. I get an IRA ice: cp /source_dir/gcc/testsuite/gcc.target/arm/mmx-2.c a.c ./cc1 -quiet -mcpu=iwmmxt -flax-vector-conversions -std=gnu99 a.c -I /tmp a.c: In function 'foo': a.c:166:1: internal compiler error: in find_costs_and_classes, at ira-costs.c:1710 } ^ 0x7a7fdf find_costs_and_classes /source/gcc/gcc/ira-costs.c:1709 0x7a8147 ira_costs() /source/gcc/gcc/ira-costs.c:2043 0x7a321c ira_build() /source/gcc/gcc/ira-build.c:3195 0x79bc0b ira /source/gcc/gcc/ira.c:4475 0x79bc0b rest_of_handle_ira /source/gcc/gcc/ira.c:4709 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. Unrecognized __builtin* sound like -mcpu=iwmmxt is not being passed to the compiler command line. Can you try make check-gcc RUNTESTFLAGS=arm.exp in your build/gcc directory and attach the the entire gcc/testsuite/gcc/gcc.log file? And just for kicks, could you include the result from: /build_directory$ grep 'with options' config.status and /build_directory$ grep 'with options' gcc/config.status This would help enormously, as I don't have an armv5tel machine to test on. Thanks.
[Bug gcov-profile/55674] [4.8 Regression] 20% size increase of lto/pgo binaries since r193747
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55674 --- Comment #22 from Teresa Johnson tejohnson at google dot com 2013-01-11 18:18:48 UTC --- Hi Honza, I ran a number of experiments at different thresholds, and found that performance starts dropping pretty quickly as the working set threshold is dropped, even to 98.5% (2 working sets lower than the 99.9% threshold). This appears to be due to a reduction in key inlines. If I use your divide by 32 heuristic, the performance is recovered for most of the apps I looked at (with the 98.5% threshold), but is still reduced for others. When I looked at the ratio of the min counter values between the 98.28% bucket (selected when I use the 98.5% threshold) and the 99.9% bucket, I can see that the apps that still degrade with 98.5% + your divide by 32 heuristic are those with the largest ratio (100-300). For the apps that no longer degrade from the 98.5% thresholds when dividing by 32, the ratio is small and often less than 32 (so in effect the resulting min counter is even smaller than with the current 99.9% threshold). What threshold were you thinking of changing it to, based on your experiments? For the google branches, based on the data I collected, we plan to leave it at 99.9%. Thanks, Teresa On Sat, Dec 22, 2012 at 3:20 PM, hubicka at ucw dot cz gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55674 --- Comment #21 from Jan Hubicka hubicka at ucw dot cz 2012-12-22 23:20:37 UTC --- I'll give this patch a try and let you know how it affects the performance I see. But unrolling shouldn't affect inlining, since all unrolling is after inlining, right? Well, it is, but we do other transformations that affect profile prior inlining + we use hot/cold code all across compilation, not just to drive inlining. Honza -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug c++/55944] New: [C++11] static local member with constexpr c'tor causes ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55944
Bug #: 55944
Summary: [C++11] static local member with constexpr c'tor
causes ICE
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
While testing bug 55931 on gcc 4.8.0 20130106 (experimental) using the compiler
flags
-Wall -std=c++11 -pedantic
the following program causes an ICE:
//---
templateclass T
struct Test
{
constexpr Test(T val) : value(val) {}
static void test()
{
static constexpr Testint x(42); // ICE
}
T value;
};
int main()
{
static constexpr Testint x(42); // OK
Testdouble::test();
}
//---
7|internal compiler error: tree check: expected target_expr, have cast_expr in
check_initializer, at cp/decl.c:5699
This program should be accepted.
[Bug c++/55931] [C++11] Constexpr member function inside a static member is not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55931 --- Comment #5 from Daniel Krügler daniel.kruegler at googlemail dot com 2013-01-11 18:32:13 UTC --- The ICE bug of 4.8.0 has been submitted as bug 55944
[Bug libstdc++/54392] [4.6/4.7/4.8 Regression] std::string::assign() fails to update length
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392 --- Comment #19 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-11 18:58:53 UTC --- Agreed. I don't think we'll ever fix this in the current std::string code TBH
[Bug target/55945] New: alloca aligns aligned pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55945
Bug #: 55945
Summary: alloca aligns aligned pointers
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nel...@seznam.cz
Alloca returns 16 byte aligned pointers on x64. However it does unnecessary
instructions.
Consider following example.
int foo(){
char *a=alloca(64),*b=alloca(64),*c=alloca(64);
bar(a,b,c);
}
Resulting assembly does not use that rsp is already 16 byte aligned nor that
intermediate results are 16 byte aligned.
pushq %rbp
xorl %eax, %eax
movq %rsp, %rbp
subq $80, %rsp
leaq 15(%rsp), %rdi
subq $80, %rsp
leaq 15(%rsp), %rsi
subq $80, %rsp
leaq 15(%rsp), %rdx
andq $-16, %rdi
andq $-16, %rsi
andq $-16, %rdx
call bar
leave
Moreover it is suboptimal for stacks growing down as
subq cnt, %rsp
andq $-16, %rsp
is more effective way.
[Bug sanitizer/55488] Implement cold calls in tsan run-time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55488 Dmitry Vyukov dvyukov at google dot com changed: What|Removed |Added CC||dvyukov at google dot com --- Comment #2 from Dmitry Vyukov dvyukov at google dot com 2013-01-11 19:52:55 UTC --- Great, thanks! I guess we need to close this bug now.
[Bug ada/55946] New: Wrong GNAT tools used on build of gnattools [native-cross]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55946 Bug #: 55946 Summary: Wrong GNAT tools used on build of gnattools [native-cross] Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: gregniet...@gmail.com Created attachment 29151 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29151 Workaround patch sutible for my needs First time ive added GNAT/ADA to the chain i bootstraped 4.8.0 20130107 from ada core i then rebuilt all the cross chains i have for ARM/MIPS/PPC this went fine building native i686 from x86-64 works fine trying to build a native aarch64 failed [i did have a native cross compiler in place with aarch64-linux-gnu-gnat and did test they work] please note that this is not a solution but a workaround im happy with it requires 1)gnatmake in the path 2)HOST-gnatmake/link/bind/tls [symlinks added to native to allow normal cross] the solution will require changes to autotools IMHO problems ... 1)building xgnatugn is done with aarch64-linux-gnu-gnatmake this is not correct as it needs to use gnatmake on the build system as it executes this program to generate docs the following hunk solves this but is not portable possibly adding BUILD_GNATMAKE is better gcc/ada/gcc-interface/Make-lang.in @@ -621,7 +619,7 @@ ada/doctools/xgnatugn$(build_exeext): ada/xgnatugn.adb -$(MKDIR) ada/doctools $(CP) $^ ada/doctools - cd ada/doctools $(GNATMAKE) -q xgnatugn + cd ada/doctools gnatmake -q xgnatugn 2)Wrong libs [native build] are used to build gnattools and the native tools are used setting host = @host_cpu@-@host_os@ prefixing gnat tools with $(host)- -RTS_DIR:=$(strip $(subst \,/,$(shell gnatls -v | grep adalib ))) +RTS_DIR:=$(strip $(subst \,/,$(shell $(host)-gnatls -v | grep adalib ))) this seems to work till it bombs out complaining about 3)system.ads pragma Restrictions (No_Implicit_Dynamic_Code); causes failure as others dont honor it removing this allows complteion and succesfull build
[Bug target/55939] [4.6/4.7/4.8 regression] gcc miscompiles gmp-5.0.5 on m68k-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55939 --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2013-01-11 20:06:03 UTC --- I cut out one line too many in the build log, it's tests/mpq/t-get_d that fails. On the surface the problem started with Jan Hubicka's Inline heuristic 4/4 patch in r166657: http://gcc.gnu.org/ml/gcc-patches/2010-11/msg01305.html http://gcc.gnu.org/ml/gcc-cvs/2010-11/msg00546.html However, all that did was to bump the default value of early-inlining-insns from 8 to 10. Compiling gmp with gcc-4.5.4 --param early-inlining-insns=10 also causes tests/mpq/t-get_d to fail, so the real problem is older.
[Bug target/55947] New: non constant memory models lose HLE qualifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55947 Bug #: 55947 Summary: non constant memory models lose HLE qualifiers Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: andi-...@firstfloor.org get_memmodel does this /* If the parameter is not a constant, it's a run time value so we'll just convert it to MEMMODEL_SEQ_CST to avoid annoying runtime checking. */ if (TREE_CODE (exp) != INTEGER_CST) return MEMMODEL_SEQ_CST; This implies that if __ATOMIC_HLE_ACQUIRE, __ATOMIC_HLE_RELEASE are passed in as non constant they will get lost.
[Bug target/55948] New: __atomic_clear / __atomic_store_n ignore HLE_RELEASE flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55948 Bug #: 55948 Summary: __atomic_clear / __atomic_store_n ignore HLE_RELEASE flags Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: andi-...@firstfloor.org Passing __ATOMIC_HLE_RELEASE to __atomic_clear or __atomic_store_n does nothing. But it's valid to do a HLE release on a store.
[Bug tree-optimization/55949] New: __builtin_object_size size passed to memcpy_chk is incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55949 Bug #: 55949 Summary: __builtin_object_size size passed to memcpy_chk is incorrect Classification: Unclassified Product: gcc Version: 4.6.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: rmansfi...@qnx.com float m[3][3]; float im[3][3]; memcpy( im, m, sizeof( im ) ); $ ./xgcc -B. ~/r.i -O2 -S In function 'memcpy', inlined from 'foo' at /home/ryan/r.i:35:8: /home/ryan/r.i:7:3: warning: call to __builtin___memcpy_chk will always overflow destination buffer [enabled by default] generates: mov r2, #36 mov r3, #12 bl __memcpy_chk This happens on the 4.6 branch, but not in 4.7/4.8. It stopped happening on trunk after this change: http://gcc.gnu.org/viewcvs?view=revisionrevision=179620 but then it becomes a direct call to memcpy instead of __memcpy_chk
[Bug target/55947] non constant memory models lose HLE qualifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55947 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-11 21:23:11 UTC --- Yeah, that is intentional. If you want HLE acquire/release, you really should pass it as constant. What do you think we should emit instead? Runtime switch based on the memory model?
[Bug tree-optimization/55949] __builtin_object_size size passed to memcpy_chk is incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55949 --- Comment #1 from Ryan Mansfield rmansfield at qnx dot com 2013-01-11 21:30:21 UTC --- Created attachment 29152 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29152 reduced testcase Attached testcase using: gcc version 4.6.4 20130111 (prerelease) [gcc-4_6-branch revision 195115] (GCC)
[Bug target/55947] non constant memory models lose HLE qualifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55947 --- Comment #2 from Andi Kleen andi-gcc at firstfloor dot org 2013-01-11 22:01:49 UTC --- I would probably add at least a warning. The whole concept of a runtime switched memory barrier is imho ill-defined.
[Bug rtl-optimization/55950] New: Invalid sqrt constant propagation with -frounding-mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55950 Bug #: 55950 Summary: Invalid sqrt constant propagation with -frounding-mode Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: gli...@gcc.gnu.org simplify_const_unary_operation (in simplify-rtx.c) does constant propagation for SQRT protected only by: if (HONOR_SNANS (mode) real_isnan (d)) return 0; With -frounding-math, it should check whether sqrt was exact and only propagate in that case (sqrt(1)=1, sqrt(.25)=.5, but sqrt(2) should wait for execution). (note that this doesn't happen on a trivial sqrt(2.) example, but I've already seen it happen)
[Bug tree-optimization/55949] __builtin_object_size size passed to memcpy_chk is incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55949
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-11
22:14:09 UTC ---
Looks like a bug in whatever string.h headers you are using.
The second parameter for __builtin_object_size for memcpy should be always 0,
not __USE_FORTIFY_LEVEL 1 (that is used for functions like strcpy and has the
additional restriction that the copying isn't allowed to cross array/field
boundaries).
In glibc there is
#define __bos(ptr) __builtin_object_size (ptr, __USE_FORTIFY_LEVEL 1)
#define __bos0(ptr) __builtin_object_size (ptr, 0)
and
__extern_always_inline void *
__NTH (memcpy (void *__restrict __dest, __const void *__restrict __src,
size_t __len))
{
return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
}
[Bug c++/55951] New: ICE in check_array_designated_initializer, at cp/decl.c:4785
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55951
Bug #: 55951
Summary: ICE in check_array_designated_initializer, at
cp/decl.c:4785
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com
Google ref: b/7991668
GCC-4.7 and current trunk ICE on this source:
enum { A };
static const char *a[] = {
[A] = a
};
g++ -c t.cc
t.cc:5:1: internal compiler error: in check_array_designated_initializer, at
cp/decl.c:4785
};
^
0x516a63 check_array_designated_initializer
../../gcc/cp/decl.c:4785
0x528429 reshape_init_array_1
../../gcc/cp/decl.c:5084
0x5274d9 reshape_init(tree_node*, tree_node*, int)
../../gcc/cp/decl.c:5470
0x529479 check_initializer
../../gcc/cp/decl.c:5642
0x53bc45 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/cp/decl.c:6320
0x6133db cp_parser_init_declarator
../../gcc/cp/parser.c:16030
0x613c4e cp_parser_simple_declaration
../../gcc/cp/parser.c:10561
0x615a20 cp_parser_block_declaration
../../gcc/cp/parser.c:10442
0x61e60b cp_parser_declaration
../../gcc/cp/parser.c:10339
0x61d2dd cp_parser_declaration_seq_opt
../../gcc/cp/parser.c:10225
0x61eb82 cp_parser_translation_unit
../../gcc/cp/parser.c:3807
0x61eb82 c_parse_file()
../../gcc/cp/parser.c:28175
0x725a94 c_common_parse_file()
../../gcc/c-family/c-opts.c:1022
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug rtl-optimization/55952] New: x86 FPU, unnecessary fxch instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55952
Bug #: 55952
Summary: x86 FPU, unnecessary fxch instruction
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vhais...@gmail.com
I am wondering if there are not some improvements that could be made in
generation of x86 FPU code. Here is a simple sign function:
float signf4(float x)
{
return x 0.0f
? -1.0f
: 1.0f;
}
It generates the following assembler code (GCC 4.7.2, g++ -m32 -O3
-fverbose-asm -save-temps -g3 -ggdb -march=native):
_Z6signf4f:
.LFB84:
.loc 1 27 0
.cfi_startproc
.LVL4:
.loc 1 30 0
fld1
fldz
flds4(%esp)# x
fxch%st(1)# ??? Why?
fucomip%st(1), %st#,
ffreep%st(0)#
fld1
fchs
fcmovbe%st(1), %st#,,
fstp%st(1)#
.loc 1 31 0
ret
I am wondering why is the fxch instruction necessary and why is the code
not instead like this?
_Z6signf4f:
.LFB84:
.loc 1 27 0
.cfi_startproc
.LVL4:
.loc 1 30 0
fld1
flds4(%esp)# ??? Load the parameter before the zero.
fldz# ??? to avoid the fxch instruction.
fucomip%st(1), %st#,
[...]
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 torvald at gcc dot gnu.org changed: What|Removed |Added CC||torvald at gcc dot gnu.org --- Comment #7 from torvald at gcc dot gnu.org 2013-01-11 22:54:04 UTC --- The gdb trace looks alright to me. My guess is that this is a bug in the uninstrumented code path, not in libitm. Could you try again after adding the following to the top of GTM::gtm_thread::begin_transaction in beginend.cc, please: prop = ~pr_uninstrumentedCode; Then, libitm shouldn't take the uninstrumented code path anymore. If it works with this change, this likely is a bug on the compiler side.
[Bug c/55953] New: hand loop faster then builtin memset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55953
Bug #: 55953
Summary: hand loop faster then builtin memset
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dushis...@mail.ru
variant 1:
char c[100];
void f(void)
{
for(int i=0; i 100; ++i)
c[i] = '0';
}
assembly:
push %rbp
vmovdqa 0x117(%rip),%ymm0# 0x400960
mov%rsp,%rbp
pop%rbp
movb $0x30,0x20086c(%rip)# 0x6010c0 c+96
vmovdqa %ymm0,0x200804(%rip)# 0x601060 c
vmovdqa %ymm0,0x20081c(%rip)# 0x601080 c+32
vmovdqa %ymm0,0x200834(%rip)# 0x6010a0 c+64
movb $0x30,0x20084e(%rip)# 0x6010c1 c+97
movb $0x30,0x200848(%rip)# 0x6010c2 c+98
movb $0x30,0x200842(%rip)# 0x6010c3 c+99
vzeroupper
retq
variant 2:
char c[100];
void f(void)
{
memset(c, '0', 100);
}
assembly:
movabs $0x3030303030303030,%rax
movl $0x30303030,0x20086c(%rip)# 0x6010c0 c+96
mov%rax,0x200805(%rip)# 0x601060 c
mov%rax,0x200806(%rip)# 0x601068 c+8
mov%rax,0x200807(%rip)# 0x601070 c+16
mov%rax,0x200808(%rip)# 0x601078 c+24
mov%rax,0x200809(%rip)# 0x601080 c+32
mov%rax,0x20080a(%rip)# 0x601088 c+40
mov%rax,0x20080b(%rip)# 0x601090 c+48
mov%rax,0x20080c(%rip)# 0x601098 c+56
mov%rax,0x20080d(%rip)# 0x6010a0 c+64
mov%rax,0x20080e(%rip)# 0x6010a8 c+72
mov%rax,0x20080f(%rip)# 0x6010b0 c+80
mov%rax,0x200810(%rip)# 0x6010b8 c+88
retq
The first variants take (for (size_t i = 0; i 1000; ++i) f();):
0.15 secs, abs 0.150255
The second variants take:
0.17 secs, abs 0.175502
CPU Intel i7,
gcc --version
gcc (Gentoo 4.7.2 p1.3, pie-0.5.5) 4.7.2
compile options: -Ofast -march=native
Expected behaviour:
assembly code should be the same, and it should be variant 1, or faster.
[Bug target/55953] hand loop faster then builtin memset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55953 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-*-* Component|c |target --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2013-01-11 23:35:53 UTC --- This is a target issue. The first function uses the AVX/SSE registers while the second only uses the integer registers. So the target decides not to vectorize memset but only use the integer registers.
[Bug tree-optimization/55890] [4.7 Regression] calling a builtin func through a cast triggers an ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55890 --- Comment #8 from vries at gcc dot gnu.org 2013-01-11 23:39:30 UTC --- Author: vries Date: Fri Jan 11 23:39:18 2013 New Revision: 195119 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195119 Log: 2013-01-12 Tom de Vries t...@codesourcery.com PR middle-end/55890 * calls.c (expand_call): Check if arg_nr is valid. Modified: trunk/gcc/ChangeLog trunk/gcc/calls.c
[Bug target/55953] hand loop faster then builtin memset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55953 --- Comment #2 from Evgeniy Dushistov dushistov at mail dot ru 2013-01-12 00:05:15 UTC --- Actually it is not only CPU 64bit related issue, for example the same CPU (i7), 32 bit mode: variant one: push %ebp vmovdqa 0x80488e0,%ymm0 mov%esp,%ebp pop%ebp movb $0x30,0x804a0a0 vmovdqa %ymm0,0x804a040 vmovdqa %ymm0,0x804a060 vmovdqa %ymm0,0x804a080 movb $0x30,0x804a0a1 movb $0x30,0x804a0a2 movb $0x30,0x804a0a3 vzeroupper ret variant two: mov$0x804a040,%edx push %edi mov$0x30303030,%eax mov%edx,%edi mov$0x19,%ecx rep stos %eax,%es:(%edi) pop%edi ret The variant one win.
[Bug target/55953] hand loop faster then builtin memset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55953
--- Comment #3 from Evgeniy Dushistov dushistov at mail dot ru 2013-01-12
00:13:09 UTC ---
Cross compiling for arm, g++ have almost the same version:
arm-angstrom-linux-gnueabi-g++ (Linaro GCC 4.7-2012.10) 4.7.3 20121001:
variant one (for):
movwr3, #2280 ; 0x8e8
movtr3, #1
vmov.i8 q8, #48 ; 0x30
mov r2, #48 ; 0x30
vst1.64 {d16-d17}, [r3 :64]
vstrd16, [r3, #16]
vstrd17, [r3, #24]
vstrd16, [r3, #32]
vstrd17, [r3, #40] ; 0x28
vstrd16, [r3, #48] ; 0x30
vstrd17, [r3, #56] ; 0x38
vstrd16, [r3, #64] ; 0x40
vstrd17, [r3, #72] ; 0x48
vstrd16, [r3, #80] ; 0x50
vstrd17, [r3, #88] ; 0x58
strbr2, [r3, #96] ; 0x60
strbr2, [r3, #97] ; 0x61
strbr2, [r3, #98] ; 0x62
strbr2, [r3, #99] ; 0x63
bx lr
variant two(memset):
movwr0, #2272 ; 0x8e0
mov r1, #48 ; 0x30
movtr0, #1
mov r2, #100; 0x64
b 0x8494 memset
The time difference near 5%, the first variant win,
command line options:
-march=armv7-a -mtune=cortex-a8 -mcpu=cortex-a8 -mfpu=neon -mfloat-abi=hard
-Ofast
[Bug tree-optimization/55949] __builtin_object_size size passed to memcpy_chk is incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55949
--- Comment #3 from Ryan Mansfield rmansfield at qnx dot com 2013-01-12
01:03:03 UTC ---
(In reply to comment #2)
Looks like a bug in whatever string.h headers you are using.
The second parameter for __builtin_object_size for memcpy should be always 0,
not __USE_FORTIFY_LEVEL 1 (that is used for functions like strcpy and has
the
additional restriction that the copying isn't allowed to cross array/field
boundaries).
In glibc there is
#define __bos(ptr) __builtin_object_size (ptr, __USE_FORTIFY_LEVEL 1)
#define __bos0(ptr) __builtin_object_size (ptr, 0)
and
__extern_always_inline void *
__NTH (memcpy (void *__restrict __dest, __const void *__restrict __src,
size_t __len))
{
return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
}
OK, thanks. I misread the object size checking docs then.
[Bug tree-optimization/55949] __builtin_object_size size passed to memcpy_chk is incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55949 Ryan Mansfield rmansfield at qnx dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #4 from Ryan Mansfield rmansfield at qnx dot com 2013-01-12 01:06:15 UTC --- invalid
[Bug middle-end/55921] [4.6/4.7 Regression] Crash in verify_ssa for asm to side-steps complex pessimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55921 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #8 from John David Anglin danglin at gcc dot gnu.org 2013-01-12 02:03:05 UTC --- Testsuite fails on hppa64-hp-hpux11.11: spawn /test/gnu/gcc/objdir64/gcc/xgcc -B/test/gnu/gcc/objdir64/gcc/ -fno-diagnostics-show-caret -O0 -w -c -o pr55921.o /test/gnu/gcc/gcc/gcc/testsuite/gcc.c-tor ture/compile/pr55921.c /test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr55921.c: In function 'fo o':/test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr55921.c:21:1: internal compiler error: in gen_reg_rtx, at emit-rtl.c:866 With i686-apple-darwin9 cross, I see: Breakpoint 1, gen_reg_rtx (mode=SFmode) at ../../gcc/gcc/emit-rtl.c:866 866 gcc_assert (can_create_pseudo_p ()); (gdb) bt #0 gen_reg_rtx (mode=SFmode) at ../../gcc/gcc/emit-rtl.c:866 #1 0x002cda1a in extract_bit_field_using_extv (extv=0xbfffe8e8, op0=0x4209e2d0, bitsize=32, bitnum=4294967264, unsignedp=1, target=0x0, mode=SFmode, tmode=SFmode) at ../../gcc/gcc/expmed.c:1254 #2 0x002d1d63 in extract_bit_field_1 (str_rtx=0x420994b0, bitsize=32, bitnum=0, unsignedp=1, packedp=false, target=0x0, mode=SFmode, tmode=SFmode, fallback_p=true) at ../../gcc/gcc/expmed.c:1577 #3 0x002d21d9 in extract_bit_field (str_rtx=0x420994b0, bitsize=32, bitnum=0, unsignedp=1, packedp=value temporarily unavailable, due to optimizations, target=0x0, mode=SFmode, tmode=SFmode) at ../../gcc/gcc/expmed.c:1658 #4 0x002ec8a1 in read_complex_part (cplx=0x420994b0, imag_p=false) at ../../gcc/gcc/expr.c:3023 #5 0x002f01b2 in emit_move_complex_parts (x=0x1c, y=0x420994b0) at ../../gcc/gcc/expr.c:3216 #6 0x00553138 in get_insns [inlined] () at emit-rtl.h:4783 #7 0x00553138 in gen_move_insn (x=0x420990e0, y=0x420994b0) at ../../gcc/gcc/optabs.c:4784 #8 0x005c4167 in gen_reload (out=0x420990e0, in=0x420994b0, opnum=0, type=RELOAD_OTHER) at ../../gcc/gcc/reload1.c:8705 #9 0x005c5d07 in emit_output_reload_insns (chain=0x41815268, rl=0xbd0cc0, j=0) at ../../gcc/gcc/reload1.c:7731 #10 0x005ce813 in emit_reload_insns (chain=0x41815268) at ../../gcc/gcc/reload1.c:8070 #11 0x005d010f in reload_as_needed (live_known=0) at ../../gcc/gcc/reload1.c:4645 #12 0x005d3833 in reload (first=0x4200fa20, global=0) at ../../gcc/gcc/reload1.c:1051 #13 0x004a0461 in rest_of_handle_reload () at ../../gcc/gcc/ira.c:4635 #14 0x00571c33 in execute_one_pass (pass=0xbc7300) at ../../gcc/gcc/passes.c:2333 #15 0x0057215d in execute_pass_list (pass=0xbc7300) at ../../gcc/gcc/passes.c:2381 #16 0x00572170 in execute_pass_list (pass=0xbc93a0) at ../../gcc/gcc/passes.c:2382 #17 0x001e2ba5 in invoke_plugin_callbacks [inlined] () at plugin.h:1640 #18 expand_function (node=0x42095000) at ../../gcc/gcc/cgraphunit.c:1643 #19 0x001e35b3 in output_in_order () at ../../gcc/gcc/cgraphunit.c:1833 #20 0x001e4952 in compile () at ../../gcc/gcc/cgraphunit.c:2037 #21 0x001e4e11 in timevar_pop [inlined] () at timevar.h:2119 #22 0x001e4e11 in finalize_compilation_unit () at ../../gcc/gcc/cgraphunit.c:2121 #23 0x00016c97 in c_write_global_declarations () at ../../gcc/gcc/c/c-decl.c:10118 #24 0x00658495 in compile_file () at ../../gcc/gcc/toplev.c:557 #25 0x0065993c in toplev_main (argc=14, argv=0xb3c4) at ../../gcc/gcc/toplev.c:1876 #26 0x009c8e18 in main (argc=14, argv=0xb3c4) at ../../gcc/gcc/main.c:36 Current language: auto; currently c++ (gdb) p reload_in_progress $1 = 1
[Bug target/55953] hand loop faster then builtin memset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55953 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2013-01-12 02:10:33 UTC --- Can you try memset in glibc instead of builtin memset?
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #8 from Jack Howarth howarth at nitro dot med.uc.edu 2013-01-12 03:24:55 UTC --- (In reply to comment #7) The gdb trace looks alright to me. My guess is that this is a bug in the uninstrumented code path, not in libitm. Could you try again after adding the following to the top of GTM::gtm_thread::begin_transaction in beginend.cc, please: prop = ~pr_uninstrumentedCode; Then, libitm shouldn't take the uninstrumented code path anymore. If it works with this change, this likely is a bug on the compiler side. Adding this line eliminates the testsuite failure on x86_64-apple-darwin12.
[Bug web/55954] New: Bugzilla breaks mail threading
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55954 Bug #: 55954 Summary: Bugzilla breaks mail threading Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: web AssignedTo: unassig...@gcc.gnu.org ReportedBy: mkuvyr...@gcc.gnu.org GCC bugzilla prepends New: to subject lines which causes popular mail clients (Gmail, Apple Mail, Sparrow, likely others) to use different mail threads for the original bug email and for followups. This is annoying. Mail clients usually put messages in the same thread if (1) subjects are the same modulo Re: and (2) In-Reply-To header is set to a message from the thread. Using New: for the first message, but not followups, breaks this model. There ought to be a switch to disable this. Thanks.
[Bug web/55954] Bugzilla breaks mail threading
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55954 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2013-01-12 04:59:12 UTC --- I think it is really a bug in the mail clients if they don't just use In-Reply-To instead.
[Bug web/55954] Bugzilla breaks mail threading
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55954 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2013-01-12 05:06:43 UTC --- (In reply to comment #1) I think it is really a bug in the mail clients if they don't just use In-Reply-To instead. The reason why I say that is because some mail clients other things than just Re:. Some use the native language version instead like AW or SV. So again the mail client is broken and we really should not be working around broken mail clients if they cannot handle the case new is added to the subject.
