RE: postreload problem using reload_inm and SECONDARY_RELOAD macros
further hints :
The immediate which gcc wants to move in R_REGS is a (const_int 8) as described
in the error message below :
arithmetic.c:197: error: insn does not satisfy its constraints:
(insn 1505 903 1506 0 (set (reg:SI 25 $R9)
(const_int 8 [0x8])) 0 {movsi_internal} (nil)
(nil))
arithmetic.c:197: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:391
So I added some debug trace in function 'my_secondary_input_reload_class' to
understand why (const_int 8) is not reloaded to C_REGS.
'my_secondary_input_reload_class' is called several times but never with rtl
expression (const_int 8).
I also checked 'my_preferred_reload_class' function and I don't see expression
(const_int 8).
Selim
Are there plans to maintain the CFG througout the compilation?
I would like to analyse code using the GCC CFG, however, some steps invalidate it notably delay slot scheduling. Are there plans to move toward how it ought to work as outlined in : http://gcc.gnu.org/wiki/basic_block_graph Peter.
CCmode size
Hi, genmodes.c has the following comment: /* Again, nothing more need be said. For historical reasons, the size of a CC mode is four units. */ validate_mode (m, UNSET, UNSET, UNSET, UNSET, UNSET); m-bytesize = 4; Now, this is probably ok for _most_ archs but for my arch where a word == byte == 16 bits, this causes a lot of pain. Is there a way (macro?) to change this to m-bytesize = 1; in the backend without hardcoding it into genmodes.c? Cheers, -- PMatos
RE: CCmode size
genmodes.c has the following comment: /* Again, nothing more need be said. For historical reasons, the size of a CC mode is four units. */ validate_mode (m, UNSET, UNSET, UNSET, UNSET, UNSET); m-bytesize = 4; Now, this is probably ok for _most_ archs but for my arch where a word == byte == 16 bits, this causes a lot of pain. Is there a way (macro?) to change this to m-bytesize = 1; in the backend without hardcoding it into genmodes.c? It would seem that making it equal to word size (whatever that is on the platform) or size of the int type would be a way to make this better. Would that have any bad consequences for other platforms? paul
RE: CCmode size
Quoting paul_kon...@dell.com:
It would seem that making it equal to word size (whatever that is on
the platform) or size of the int type would be a way to make this
better. Would that have any bad consequences for other platforms?
For MXP (16-bit word addressed, with 128 bit vector registers) I had this:
2008-04-25 Jorn Rennecke joern.renne...@arc.com
* genmodes.c (vector_class):
(complete_mode): Allow bytesize to have been set for MODE_CC.
case MODE_CC:
/* Again, nothing more need be said. For historical reasons,
-the size of a CC mode is four units. */
- validate_mode (m, UNSET, UNSET, UNSET, UNSET, UNSET);
+the size of a CC mode defaults to four units. */
+ if (m-bytesize != blank_mode.bytesize)
+ validate_mode (m, UNSET, SET, UNSET, UNSET, UNSET);
+ else
+ {
+ validate_mode (m, UNSET, UNSET, UNSET, UNSET, UNSET);
+ m-bytesize = 4;
+ }
- m-bytesize = 4;
m-ncomponents = 1;
m-component = 0;
break;
Then there was also:
ChangeLog.ARC: (SIZED_CC_MODE): New macro.
genmodes.c:#define SIZED_CC_MODE(N, Y) (CC_MODE (N)-bytesize = (Y))
Of course, MXP needed a few more patches to support MODE_VECTOR_PARTIAL_INT
and MODE_VECTOR_CC modes.
In mxp-modes.def, I had then:
VECTOR_MODES (INT, 4); /* V4QI V2HI */
VECTOR_MODES (INT, 8); /* V8QI V4HI V2SI */
VECTOR_MODES (INT, 16); /* V16QI V8HI V4SI V2DI */
PARTIAL_INT_MODE (SI); /* Needed to make V2PSI / V4PSI. */
VECTOR_MODE (PARTIAL_INT, PSI, 2); /* V2PSI, flags for DImode arithmetic. */
VECTOR_MODE (PARTIAL_INT, PSI, 4); /* V4PSI, flags for V2DImode
arithmetic. */
VECTOR_MODES (FLOAT, 8); /* V2SF */
VECTOR_MODES (FLOAT, 16); /* V4SF V2DF */
#define CC_MODES(N) SIZED_CC_MODE (N, 2); \
VECTOR_MODE (CC, N, 2); VECTOR_MODE (CC, N, 4); VECTOR_MODE (CC, N, 8)
CC_MODES (CCI); /* Ordinary integer flags. */
CC_MODES (CCZN); /* Only zero / negative flag relevant. */
CC_MODES (CCZ); /* Only zero flag relevant. */
VECTOR_MODE (CC, CC, 2); /* V2CCmode - flag clobber for DI arithmetic. */
VECTOR_MODE (CC, CC, 4); /* V4CCmode - flag clobber for V2DI arithmetic. */
IRA misses register range overlap
In the msp430 back end, hard registers 4 through 15 are HImode, with
adjacent register sequences used for SImode and DImode. In preparation for
a library call, I'm emitting RTL that assigns values directly to reg:SI 4.
Despite that, in gcc 4.5.x IRA choses reg:HI 4 as the destination
for a pseudo-register for a preceding assignment, and does nothing to
preserve the value over the span where the register is part of an SI value.
The subsequence:
(insn 2 4 3 2 (set (reg/v:HI 38 [ x ])
(reg:HI 15 r15 [ x ])) test.c:28 21 {*movhi2}
(expr_list:REG_DEAD (reg:HI 15 r15 [ x ])
(nil)))
(note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
(note 6 3 10 2 NOTE_INSN_DELETED)
(insn 10 6 11 2 (set (reg:SI 8 r8)
(mem/c/i:SI (symbol_ref:HI (seed) [flags 0x2] var_decl
0x7f032064f960 seed) [2 seed+0 S4 A16])) test.c:14 24 {*movsi2}
(nil))
(insn 11 10 12 2 (set (reg:SI 4 r4)
(const_int 33614 [0x834e])) test.c:14 24 {*movsi2}
(nil))
with:
insn=2, live_throughout: 1, dead_or_set: 15, 38
insn=10, live_throughout: 1, 38, dead_or_set: 8, 9
insn=11, live_throughout: 1, 8, 9, 38, dead_or_set: 4, 5
insn=12, live_throughout: 1, 38, dead_or_set: 4, 5, 6, 7, 8, 9, 10,
11, 12, 13, 14, 15
becomes:
(insn 2 4 3 2 (set (reg/v:HI 4 r4 [orig:38 x ] [38])
(reg:HI 15 r15 [ x ])) test.c:28 21 {*movhi2}
(nil))
(note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
(note 6 3 10 2 NOTE_INSN_DELETED)
(insn 10 6 11 2 (set (reg:SI 8 r8)
(mem/c/i:SI (symbol_ref:HI (seed) [flags 0x2] var_decl
0x7f032064f960 seed) [2 seed+0 S4 A16])) test.c:14 24 {*movsi2}
(nil))
(insn 11 10 12 2 (set (reg:SI 4 r4)
(const_int 33614 [0x834e])) test.c:14 24 {*movsi2}
(nil))
and the subsequent reference to reg:HI 4 (formerly reg/v:HI 38) has value
33614 instead of the user's parameter.
Could somebody suggest where should I look to understand why this is
happening and how should it be fixed?
Thanks.
Peter
Re: IRA misses register range overlap
On 09/15/2011 11:16 AM, Peter Bigot wrote:
In the msp430 back end, hard registers 4 through 15 are HImode, with
adjacent register sequences used for SImode and DImode. In preparation for
a library call, I'm emitting RTL that assigns values directly to reg:SI 4.
Despite that, in gcc 4.5.x IRA choses reg:HI 4 as the destination
for a pseudo-register for a preceding assignment, and does nothing to
preserve the value over the span where the register is part of an SI value.
The subsequence:
(insn 2 4 3 2 (set (reg/v:HI 38 [ x ])
(reg:HI 15 r15 [ x ])) test.c:28 21 {*movhi2}
(expr_list:REG_DEAD (reg:HI 15 r15 [ x ])
(nil)))
(note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
(note 6 3 10 2 NOTE_INSN_DELETED)
(insn 10 6 11 2 (set (reg:SI 8 r8)
(mem/c/i:SI (symbol_ref:HI (seed) [flags 0x2]var_decl
0x7f032064f960 seed) [2 seed+0 S4 A16])) test.c:14 24 {*movsi2}
(nil))
(insn 11 10 12 2 (set (reg:SI 4 r4)
(const_int 33614 [0x834e])) test.c:14 24 {*movsi2}
(nil))
with:
insn=2, live_throughout: 1, dead_or_set: 15, 38
insn=10, live_throughout: 1, 38, dead_or_set: 8, 9
insn=11, live_throughout: 1, 8, 9, 38, dead_or_set: 4, 5
insn=12, live_throughout: 1, 38, dead_or_set: 4, 5, 6, 7, 8, 9, 10,
11, 12, 13, 14, 15
becomes:
(insn 2 4 3 2 (set (reg/v:HI 4 r4 [orig:38 x ] [38])
(reg:HI 15 r15 [ x ])) test.c:28 21 {*movhi2}
(nil))
(note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
(note 6 3 10 2 NOTE_INSN_DELETED)
(insn 10 6 11 2 (set (reg:SI 8 r8)
(mem/c/i:SI (symbol_ref:HI (seed) [flags 0x2]var_decl
0x7f032064f960 seed) [2 seed+0 S4 A16])) test.c:14 24 {*movsi2}
(nil))
(insn 11 10 12 2 (set (reg:SI 4 r4)
(const_int 33614 [0x834e])) test.c:14 24 {*movsi2}
(nil))
and the subsequent reference to reg:HI 4 (formerly reg/v:HI 38) has value
33614 instead of the user's parameter.
Could somebody suggest where should I look to understand why this is
happening and how should it be fixed?
The best way is to file a bug to http://gcc.gnu.org/bugzilla/. You
should submit the test (the smaller the test, the better) and how to
reproduce it: how to build gcc (configure options) and how to call the
built gcc to reproduce results.
I think you could look at ira dump file and check that allocno for p38
conflicting with hard reg 4 *and* 5. If it is not, the problem is in
conflict calculation. Otherwise, it might be IRA hard register
assignment or in reload (the worst case).
But having only info you provided it is very hard to say what is wrong.
Re: [google] Merge trunk into google/integration
LGTM Ollie On Wed, Sep 14, 2011 at 3:29 PM, Diego Novillo dnovi...@google.com wrote: This merge brings google/integration up to rev 178783. I also merged rev 178833 to get the testsuite validation script I committed to trunk yesterday. Simon, Ollie, I expect our internal builder to fail until I incorporate validate_failures.py into it. It's a catch-22, but it is easier to keep the local changes to the builder than the whole merge. I have reverted all the xfail/skip markers we used to have. I moved the ones that still fail to the new xfail manifest file in contrib/testsuite-management (we'll likely need manifests for other platforms as well). Tested on x86_64. Committed to google/integration. 2011-09-14 Diego Novillo dnovi...@google.com Mainline merge rev 178783. Cherry pick mainline rev 178833. 2011-09-14 Diego Novillo dnovi...@google.com contrib/ChangeLog.google-integration * testsuite-management/x86_64-unknown-linux-gnu.xfail: New. gcc/testsuite/ChangeLog.google-integration * g++.dg/tree-prof/partition2.C: Revert to mainline variant. * g++.dg/tree-ssa/pr41186.C: Likewise. * gcc.dg/cproj-fails-with-broken-glibc.c: Likewise. * gcc.dg/guality/sra-1.c: Likewise. * gcc.dg/guality/vla-1.c: Likewise. * gcc.dg/guality/vla-2.c: Likewise. * gcc.dg/inline_3.c: Likewise. * gcc.dg/inline_4.c: Likewise. * gcc.dg/tree-ssa/vrp47.c: Likewise. * gcc.dg/uninit-B.c: Likewise. * gcc.dg/uninit-pr19430.c: Likewise. * gcc.dg/unroll_2.c: Likewise. * gcc.dg/unroll_3.c: Likewise. * gcc.dg/unroll_4.c: Likewise. * gcc.target/i386/pr27827.c: Likewise. * gcc.target/i386/sse4_1-blendps-2.c: Likewise. * gcc.target/i386/sse4_1-blendps.c: Likewise. libmudflap/ChangeLog.google-integration * testsuite/libmudflap.c++/pass55-frag.cxx: Revert to mainline variant. libstdc++-v3/ChangeLog.google-integration: * testsuite/23_containers/vector/requirements/dr438/assign_neg.cc: Revert to mainline variant. * testsuite/23_containers/vector/requirements/dr438/constructor_1_neg.cc: Likewise. * testsuite/23_containers/vector/requirements/dr438/constructor_2_neg.cc: Likewise. * testsuite/23_containers/vector/requirements/dr438/insert_neg.cc: Likewise. diff --git a/svnclient/contrib/testsuite-management/x86_64-unknown-linux-gnu.xfail b/svnclient/contrib/testsuite-management/x86_64-unknown-linux-gnu.xfail new file mode 100644 index 000..b3e86a5 --- /dev/null +++ b/svnclient/contrib/testsuite-management/x86_64-unknown-linux-gnu.xfail @@ -0,0 +1,59 @@ +# These tests fail in trunk in all configurations. +FAIL: 23_containers/vector/requirements/dr438/assign_neg.cc (test for errors, line 1222) +FAIL: 23_containers/vector/requirements/dr438/assign_neg.cc (test for excess errors) +FAIL: 23_containers/vector/requirements/dr438/constructor_1_neg.cc (test for excess errors) +FAIL: 23_containers/vector/requirements/dr438/constructor_1_neg.cc (test for errors, line 1152) +FAIL: 23_containers/vector/requirements/dr438/constructor_2_neg.cc (test for excess errors) +FAIL: 23_containers/vector/requirements/dr438/constructor_2_neg.cc (test for errors, line 1152) +FAIL: 23_containers/vector/requirements/dr438/insert_neg.cc (test for excess errors) +FAIL: 23_containers/vector/requirements/dr438/insert_neg.cc (test for errors, line 1263) +FAIL: gcc.dg/cproj-fails-with-broken-glibc.c execution test +XPASS: gcc.dg/inline_3.c (test for excess errors) +XPASS: gcc.dg/inline_4.c (test for excess errors) +FAIL: gcc.dg/tree-ssa/vrp47.c scan-tree-dump-times dom1 x[^ ]* y 1 +XPASS: gcc.dg/uninit-B.c uninit i warning (test for warnings, line 12) +XPASS: gcc.dg/uninit-pr19430.c uninitialized (test for warnings, line 41) +XPASS: gcc.dg/uninit-pr19430.c (test for warnings, line 32) +XPASS: gcc.dg/unroll_2.c (test for excess errors) +XPASS: gcc.dg/unroll_3.c (test for excess errors) +XPASS: gcc.dg/unroll_4.c (test for excess errors) +FAIL: libmudflap.c++/pass55-frag.cxx ( -O) execution test + +# The following tests are failing with gold. The LTO plugin is not resolving +# names properly. Only builds configured to use gold will show these. +UNRESOLVED: gcc.c-torture/execute/20010209-1.c execution, -O2 -flto -flto-partition=none +UNRESOLVED: gcc.c-torture/execute/20010209-1.c execution, -O2 -flto +FAIL: gcc.c-torture/execute/20010209-1.c compilation, -O2 -flto (internal compiler error) +FAIL: gcc.c-torture/execute/20010209-1.c compilation, -O2 -flto -flto-partition=none (internal compiler error) + +# These tests fail in trunk when compiled with -m32. +FAIL: boehm-gc.c/thread_leak_test.c -O2 (test for excess errors) +FAIL: gcc.target/i386/pr27827.c scan-assembler fmul[ \t]*%st +FAIL: gfortran.dg/actual_array_constructor_1.f90 -O1 (internal compiler
Re: should sync builtins be full optimization barriers?
I'd say they should be optimization barriers too (and at the tree level they I think work that way, being represented as function calls), so if they don't act as memory barriers in RTL, the *.md patterns should be fixed. The only exception should be IMHO the __SYNC_MEM_RELAXED variants - if the CPU can reorder memory accesses across them at will, why shouldn't the compiler be able to do the same as well? Agreed, so we have a bug in all released versions of GCC. :( I wouldn't go that far. They *used* to be compiler barriers, but clearly something broke at some point without anyone noticing. We don't know how many versions are affected until we debug it. For all we know it broke in 4.5 and 4.4 is fine. There's no reference to a GCC bug report about this in the thread. Did the folks over at the libdispatch project never think to file one? Or does a bug report exist and my search skills are weak? r~
Re: should sync builtins be full optimization barriers?
On 09/15/2011 06:19 PM, Richard Henderson wrote: I wouldn't go that far. They *used* to be compiler barriers, but clearly something broke at some point without anyone noticing. We don't know how many versions are affected until we debug it. For all we know it broke in 4.5 and 4.4 is fine. 4.4 is not necessarily fine, it may also be that an unrelated 4.5 change exposed a latent bug. But indeed Richard Sandiford mentioned offlist that perhaps ALIAS_SET_MEMORY_BARRIER machinery broke. Fixing the bug in 4.5/4.6/4.7 will definitely shed more light. There's no reference to a GCC bug report about this in the thread. Did the folks over at the libdispatch project never think to file one? I asked them to attach a preprocessed testcase somewhere, but they haven't done so yet. :( Paolo
[google] Merged gcc-4_6-branch - google/gcc-4_6
This merge adds the testsuite validation script to google/gcc-4_6. Merged up to rev 178854. Validated on x86_64. Diego.
Re: IRA misses register range overlap
On Thu, Sep 15, 2011 at 10:34 AM, Vladimir Makarov vmaka...@redhat.com wrote:
On 09/15/2011 11:16 AM, Peter Bigot wrote:
In the msp430 back end, hard registers 4 through 15 are HImode, with
adjacent register sequences used for SImode and DImode. In preparation
for
a library call, I'm emitting RTL that assigns values directly to reg:SI 4.
Despite that, in gcc 4.5.x IRA choses reg:HI 4 as the destination
for a pseudo-register for a preceding assignment, and does nothing to
preserve the value over the span where the register is part of an SI
value.
The subsequence:
(insn 2 4 3 2 (set (reg/v:HI 38 [ x ])
(reg:HI 15 r15 [ x ])) test.c:28 21 {*movhi2}
(expr_list:REG_DEAD (reg:HI 15 r15 [ x ])
(nil)))
(note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
(note 6 3 10 2 NOTE_INSN_DELETED)
(insn 10 6 11 2 (set (reg:SI 8 r8)
(mem/c/i:SI (symbol_ref:HI (seed) [flags 0x2]var_decl
0x7f032064f960 seed) [2 seed+0 S4 A16])) test.c:14 24 {*movsi2}
(nil))
(insn 11 10 12 2 (set (reg:SI 4 r4)
(const_int 33614 [0x834e])) test.c:14 24 {*movsi2}
(nil))
with:
insn=2, live_throughout: 1, dead_or_set: 15, 38
insn=10, live_throughout: 1, 38, dead_or_set: 8, 9
insn=11, live_throughout: 1, 8, 9, 38, dead_or_set: 4, 5
insn=12, live_throughout: 1, 38, dead_or_set: 4, 5, 6, 7, 8, 9, 10,
11, 12, 13, 14, 15
becomes:
(insn 2 4 3 2 (set (reg/v:HI 4 r4 [orig:38 x ] [38])
(reg:HI 15 r15 [ x ])) test.c:28 21 {*movhi2}
(nil))
(note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
(note 6 3 10 2 NOTE_INSN_DELETED)
(insn 10 6 11 2 (set (reg:SI 8 r8)
(mem/c/i:SI (symbol_ref:HI (seed) [flags 0x2]var_decl
0x7f032064f960 seed) [2 seed+0 S4 A16])) test.c:14 24 {*movsi2}
(nil))
(insn 11 10 12 2 (set (reg:SI 4 r4)
(const_int 33614 [0x834e])) test.c:14 24 {*movsi2}
(nil))
and the subsequent reference to reg:HI 4 (formerly reg/v:HI 38) has value
33614 instead of the user's parameter.
Could somebody suggest where should I look to understand why this is
happening and how should it be fixed?
The best way is to file a bug to http://gcc.gnu.org/bugzilla/. You should
submit the test (the smaller the test, the better) and how to reproduce it:
how to build gcc (configure options) and how to call the built gcc to
reproduce results.
Unfortunately, the former msp430 maintainers never pushed the back-end
upstream, so filing a bug on a target that isn't part of gcc is
unlikely to get much attention. It's also pretty specific to the
machine description, so I doubt it could be reproduced on another
target.
I was hoping for more of a yes, that happens if you don't [missed
back-end requirement here], or even a no, that shouldn't be
happening.
It looks almost like the fact that I'm generating RTL that references
the hard registers directly is ignored by IRA for conflict resolution,
which seems to only occur among the registers that it's responsible
for assigning. I'll look again through the docs to see if there's
some hints that I'm missing a step.
If anybody else has further suggestions or insights I'd appreciate
them. Thanks.
Peter
I think you could look at ira dump file and check that allocno for p38
conflicting with hard reg 4 *and* 5. If it is not, the problem is in
conflict calculation. Otherwise, it might be IRA hard register assignment
or in reload (the worst case).
But having only info you provided it is very hard to say what is wrong.
Re: Are there plans to maintain the CFG througout the compilation?
Thanks Ian. Any idea what the size of the problem would be , perhaps first for backends that don't chose to vandalise things themselves 1st?
Re: IRA misses register range overlap
On 09/15/2011 03:06 PM, Peter Bigot wrote:
On Thu, Sep 15, 2011 at 10:34 AM, Vladimir Makarovvmaka...@redhat.com wrote:
On 09/15/2011 11:16 AM, Peter Bigot wrote:
In the msp430 back end, hard registers 4 through 15 are HImode, with
adjacent register sequences used for SImode and DImode. In preparation
for
a library call, I'm emitting RTL that assigns values directly to reg:SI 4.
Despite that, in gcc 4.5.x IRA choses reg:HI 4 as the destination
for a pseudo-register for a preceding assignment, and does nothing to
preserve the value over the span where the register is part of an SI
value.
The subsequence:
(insn 2 4 3 2 (set (reg/v:HI 38 [ x ])
(reg:HI 15 r15 [ x ])) test.c:28 21 {*movhi2}
(expr_list:REG_DEAD (reg:HI 15 r15 [ x ])
(nil)))
(note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
(note 6 3 10 2 NOTE_INSN_DELETED)
(insn 10 6 11 2 (set (reg:SI 8 r8)
(mem/c/i:SI (symbol_ref:HI (seed) [flags 0x2]var_decl
0x7f032064f960 seed) [2 seed+0 S4 A16])) test.c:14 24 {*movsi2}
(nil))
(insn 11 10 12 2 (set (reg:SI 4 r4)
(const_int 33614 [0x834e])) test.c:14 24 {*movsi2}
(nil))
with:
insn=2, live_throughout: 1, dead_or_set: 15, 38
insn=10, live_throughout: 1, 38, dead_or_set: 8, 9
insn=11, live_throughout: 1, 8, 9, 38, dead_or_set: 4, 5
insn=12, live_throughout: 1, 38, dead_or_set: 4, 5, 6, 7, 8, 9, 10,
11, 12, 13, 14, 15
becomes:
(insn 2 4 3 2 (set (reg/v:HI 4 r4 [orig:38 x ] [38])
(reg:HI 15 r15 [ x ])) test.c:28 21 {*movhi2}
(nil))
(note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
(note 6 3 10 2 NOTE_INSN_DELETED)
(insn 10 6 11 2 (set (reg:SI 8 r8)
(mem/c/i:SI (symbol_ref:HI (seed) [flags 0x2]var_decl
0x7f032064f960 seed) [2 seed+0 S4 A16])) test.c:14 24 {*movsi2}
(nil))
(insn 11 10 12 2 (set (reg:SI 4 r4)
(const_int 33614 [0x834e])) test.c:14 24 {*movsi2}
(nil))
and the subsequent reference to reg:HI 4 (formerly reg/v:HI 38) has value
33614 instead of the user's parameter.
Could somebody suggest where should I look to understand why this is
happening and how should it be fixed?
The best way is to file a bug to http://gcc.gnu.org/bugzilla/. You should
submit the test (the smaller the test, the better) and how to reproduce it:
how to build gcc (configure options) and how to call the built gcc to
reproduce results.
Unfortunately, the former msp430 maintainers never pushed the back-end
upstream, so filing a bug on a target that isn't part of gcc is
unlikely to get much attention. It's also pretty specific to the
machine description, so I doubt it could be reproduced on another
target.
I was hoping for more of a yes, that happens if you don't [missed
back-end requirement here], or even a no, that shouldn't be
happening.
It should not be happening. It is a bug. It should be fixed in RA (IRA
or reload). IRA/reload works for many targets where the same situation
occurs. So it is hard to say what is wrong without more info.
Although RA is directed by many machine-dependent macros and one macro
might return a wrong value (e.g. number registers needed to hold value
of a mode). But it is less probable.
Re: IRA misses register range overlap
On Thu, Sep 15, 2011 at 4:09 PM, Vladimir Makarov vmaka...@redhat.com wrote:
On 09/15/2011 03:06 PM, Peter Bigot wrote:
On Thu, Sep 15, 2011 at 10:34 AM, Vladimir Makarovvmaka...@redhat.com
wrote:
On 09/15/2011 11:16 AM, Peter Bigot wrote:
In the msp430 back end, hard registers 4 through 15 are HImode, with
adjacent register sequences used for SImode and DImode. In preparation
for
a library call, I'm emitting RTL that assigns values directly to reg:SI
4.
Despite that, in gcc 4.5.x IRA choses reg:HI 4 as the destination
for a pseudo-register for a preceding assignment, and does nothing to
preserve the value over the span where the register is part of an SI
value.
The subsequence:
(insn 2 4 3 2 (set (reg/v:HI 38 [ x ])
(reg:HI 15 r15 [ x ])) test.c:28 21 {*movhi2}
(expr_list:REG_DEAD (reg:HI 15 r15 [ x ])
(nil)))
(note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
(note 6 3 10 2 NOTE_INSN_DELETED)
(insn 10 6 11 2 (set (reg:SI 8 r8)
(mem/c/i:SI (symbol_ref:HI (seed) [flags 0x2]var_decl
0x7f032064f960 seed) [2 seed+0 S4 A16])) test.c:14 24 {*movsi2}
(nil))
(insn 11 10 12 2 (set (reg:SI 4 r4)
(const_int 33614 [0x834e])) test.c:14 24 {*movsi2}
(nil))
with:
insn=2, live_throughout: 1, dead_or_set: 15, 38
insn=10, live_throughout: 1, 38, dead_or_set: 8, 9
insn=11, live_throughout: 1, 8, 9, 38, dead_or_set: 4, 5
insn=12, live_throughout: 1, 38, dead_or_set: 4, 5, 6, 7, 8, 9, 10,
11, 12, 13, 14, 15
becomes:
(insn 2 4 3 2 (set (reg/v:HI 4 r4 [orig:38 x ] [38])
(reg:HI 15 r15 [ x ])) test.c:28 21 {*movhi2}
(nil))
(note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
(note 6 3 10 2 NOTE_INSN_DELETED)
(insn 10 6 11 2 (set (reg:SI 8 r8)
(mem/c/i:SI (symbol_ref:HI (seed) [flags 0x2]var_decl
0x7f032064f960 seed) [2 seed+0 S4 A16])) test.c:14 24 {*movsi2}
(nil))
(insn 11 10 12 2 (set (reg:SI 4 r4)
(const_int 33614 [0x834e])) test.c:14 24 {*movsi2}
(nil))
and the subsequent reference to reg:HI 4 (formerly reg/v:HI 38) has
value
33614 instead of the user's parameter.
Could somebody suggest where should I look to understand why this is
happening and how should it be fixed?
The best way is to file a bug to http://gcc.gnu.org/bugzilla/. You
should
submit the test (the smaller the test, the better) and how to reproduce
it:
how to build gcc (configure options) and how to call the built gcc to
reproduce results.
Unfortunately, the former msp430 maintainers never pushed the back-end
upstream, so filing a bug on a target that isn't part of gcc is
unlikely to get much attention. It's also pretty specific to the
machine description, so I doubt it could be reproduced on another
target.
I was hoping for more of a yes, that happens if you don't [missed
back-end requirement here], or even a no, that shouldn't be
happening.
It should not be happening. It is a bug. It should be fixed in RA (IRA or
reload). IRA/reload works for many targets where the same situation occurs.
So it is hard to say what is wrong without more info.
Based on what you've said I've provided source and the before/after
IRA dump files in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50427.
I'll continue to dig into this; suggestions welcome.
Peter
Although RA is directed by many machine-dependent macros and one macro might
return a wrong value (e.g. number registers needed to hold value of a
mode). But it is less probable.
gcc-4.5-20110915 is now available
Snapshot gcc-4.5-20110915 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20110915/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch revision 178897 You'll find: gcc-4.5-20110915.tar.bz2 Complete GCC MD5=92277bf6896948d5ede50ad1210aa9c8 SHA1=baf856ececfd00d192d330f1d1f56687f4a928cf Diffs from 4.5-20110908 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
RE: A case that PRE optimization hurts performance
Hi Richard,
I slightly changed the case to be like below,
int f(char *t) {
int s=0;
while (*t s != 1) {
switch (s) {
case 0: /* path 1 */
s = 2;
break;
case 2: /* path 2 */
s = 3; /* changed */
break;
default: /* path 3 */
if (*t == '-')
s = 2;
break;
}
t++;
}
return s;
}
-O2 is still worse than -O2 -fno-tree-pre.
-O2 -fno-tree-pre result is
f:
pushl %ebp
xorl%eax, %eax
movl%esp, %ebp
movl8(%ebp), %edx
movzbl (%edx), %ecx
jmp .L14
.p2align 4,,7
.p2align 3
.L5:
movl$2, %eax
.L7:
addl$1, %edx
cmpl$1, %eax
movzbl (%edx), %ecx
je .L3
.L14:
testb %cl, %cl
je .L3
testl %eax, %eax
je .L5
cmpl$2, %eax
.p2align 4,,5
je .L17
cmpb$45, %cl
.p2align 4,,5
je .L5
addl$1, %edx
cmpl$1, %eax
movzbl (%edx), %ecx
jne .L14
.p2align 4,,7
.p2align 3
.L3:
popl%ebp
.p2align 4,,2
ret
.p2align 4,,7
.p2align 3
.L17:
movb$3, %al
.p2align 4,,3
jmp .L7
While -O2 result is
f:
pushl %ebp
xorl%eax, %eax
movl%esp, %ebp
movl8(%ebp), %edx
pushl %ebx
movzbl (%edx), %ecx
jmp .L14
.p2align 4,,7
.p2align 3
.L5:
movl$1, %ebx
movl$2, %eax
.L7:
addl$1, %edx
testb %bl, %bl
movzbl (%edx), %ecx
je .L3
.L14:
testb %cl, %cl
je .L3
testl %eax, %eax
je .L5
cmpl$2, %eax
.p2align 4,,5
je .L16
cmpb$45, %cl
.p2align 4,,5
je .L5
cmpl$1, %eax
setne %bl
addl$1, %edx
testb %bl, %bl
movzbl (%edx), %ecx
jne .L14
.p2align 4,,7
.p2align 3
.L3:
popl%ebx
popl%ebp
ret
.p2align 4,,7
.p2align 3
.L16:
movl$1, %ebx
movb$3, %al
jmp .L7
You may notice that register ebx is introduced, and some more instructions
around ebx are generated as well. i.e.
setne %bl
testb %bl, %bl
I agree with you that in theory PRE does the right thing to minimize the
computation cost on gimple level. However, the problem is the cost of
converting comparison result to a bool value is not considered, so it
actually makes binary code worse. For this case, as I summarized below, to
complete the same functionality With PRE is worse than Without PRE for
all three paths,
* Without PRE,
Path1:
movl$2, %eax
cmpl$1, %eax
je .L3
Path2:
movb$3, %al
cmpl$1, %eax
je .L3
Path3:
cmpl$1, %eax
jne .L14
* With PRE,
Path1:
movl$1, %ebx
movl$2, %eax
testb %bl, %bl
je .L3
Path2:
movl$1, %ebx
movb$3, %al
testb %bl, %bl
je .L3
Path3:
cmpl$1, %eax
setne %bl
testb %bl, %bl
jne .L14
Do you have any more thoughts?
Thanks,
-Jiangning
-Original Message-
From: Richard Guenther [mailto:richard.guent...@gmail.com]
Sent: Tuesday, August 02, 2011 5:23 PM
To: Jiangning Liu
Cc: gcc@gcc.gnu.org
Subject: Re: A case that PRE optimization hurts performance
On Tue, Aug 2, 2011 at 4:37 AM, Jiangning Liu jiangning@arm.com
wrote:
Hi,
For the following simple test case, PRE optimization hoists
computation
(s!=1) into the default branch of the switch statement, and finally
causes
very poor code generation. This problem occurs in both X86 and ARM,
and I
believe it is also a problem for other targets.
int f(char *t) {
int s=0;
while (*t s != 1) {
switch (s) {
case 0:
s = 2;
break;
case 2:
s = 1;
break;
default:
if (*t == '-')
s = 1;
break;
}
t++;
}
return s;
}
Taking X86 as an example, with option -O2 you may find 52
instructions
generated like below,
f:
0: 55 push %ebp
1: 31 c0 xor %eax,%eax
3: 89 e5 mov %esp,%ebp
5: 57 push %edi
6: 56 push %esi
7: 53 push %ebx
8: 8b 55 08 mov 0x8(%ebp),%edx
b: 0f b6 0a movzbl (%edx),%ecx
e: 84 c9
[Bug c++/50303] [C++0x] Segfault with variadic template template parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50303 Markus Trippelsdorf markus at trippelsdorf dot de changed: What|Removed |Added CC||markus at trippelsdorf dot ||de --- Comment #5 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-09-15 07:06:19 UTC --- Program received signal SIGSEGV, Segmentation fault. [Switching to process 30771] tsubst_template_parms (parms=0x0, args=0x777a6d98, complain=3) at ../../gcc/gcc/cp/pt.c:9507 9507 TMPL_PARMS_DEPTH (parms) TMPL_ARGS_DEPTH (args); (gdb) bt #0 tsubst_template_parms (parms=0x0, args=0x777a6d98, complain=3) at ../../gcc/gcc/cp/pt.c:9507 #1 0x004c6d9a in tsubst_decl (t=0x777a7e60, args=0x777a6d98, complain=3) at ../../gcc/gcc/cp/pt.c:9789 #2 0x004c3ce5 in tsubst (in_decl=optimized out, complain=3, args=0x777a6d98, t=0x777a7e60) at ../../gcc/gcc/cp/pt.c:10851 #3 tsubst (t=0x777a7e60, args=0x777a6d98, complain=3, in_decl=optimized out) at ../../gcc/gcc/cp/pt.c:10836 #4 0x004c821f in tsubst_pack_expansion (t=0x777afe70, args=0x777a6f78, complain=3, in_decl=0x777a7f18) at ../../gcc/gcc/cp/pt.c:9298 #5 0x004c656b in tsubst_template_args (t=0x777a6ac8, args=0x777a6d98, complain=3, in_decl=0x777a7f18) at ../../gcc/gcc/cp/pt.c:9400 #6 0x004c1e46 in tsubst_copy_and_build (t=0x77fd9a50, args=0x777a6d98, complain=3, in_decl=0x777a7f18, function_p=1 '\001', integral_constant_expression_p=optimized out) at ../../gcc/gcc/cp/pt.c:13035 #7 0x004c1c9e in tsubst_copy_and_build (t=0x777bd038, args=0x777a6d98, complain=3, in_decl=0x777a7f18, function_p=0 '\000', integral_constant_expression_p=0 '\000') at ../../gcc/gcc/cp/pt.c:13390 #8 0x004bd239 in tsubst_expr (t=0x777bd038, args=0x777a6d98, complain=3, in_decl=0x777a7f18, integral_constant_expression_p=0 '\000') at ../../gcc/gcc/cp/pt.c:12935 #9 0x004bdc70 in tsubst_expr (t=0x777a6b40, args=0x777a6d98, complain=3, in_decl=0x777a7f18, integral_constant_expression_p=0 '\000') at ../../gcc/gcc/cp/pt.c:12467 #10 0x004bd2b1 in tsubst_expr (t=0x777bd000, args=0x777a6d98, complain=3, in_decl=0x777a7f18, integral_constant_expression_p=0 '\000') at ../../gcc/gcc/cp/pt.c:12632 #11 0x004d0ccc in instantiate_decl (d=0x777aee00, defer_ok=optimized out, expl_inst_class_mem_p=optimized out) at ../../gcc/gcc/cp/pt.c:18305 #12 0x004d34dc in instantiate_pending_templates (retries=optimized out) at ../../gcc/gcc/cp/pt.c:18402 #13 0x004e8a4d in cp_write_global_declarations () at ../../gcc/gcc/cp/decl2.c:3713 #14 0x007f11c2 in compile_file () at ../../gcc/gcc/toplev.c:564 #15 do_compile () at ../../gcc/gcc/toplev.c:1886 #16 toplev_main (argc=13, argv=0x7fffdf28) at ../../gcc/gcc/toplev.c:1962 #17 0x77b81f82 in __libc_start_main (main=0x5a11b0 main, argc=13, ubp_av=0x7fffdf28, init=optimized out, fini=optimized out, rtld_fini=optimized out, stack_end=0x7fffdf18) at libc-start.c:226 #18 0x0048cf89 in _start () at ../sysdeps/x86_64/elf/start.S:113 (gdb)
[Bug c++/50400] New: compiler accepts invalid X::Impl::Impl::Impl::.....::foo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50400
Bug #: 50400
Summary: compiler accepts invalid
X::Impl::Impl::Impl::.::foo
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pl...@agmk.net
struct X { struct Impl; };
struct X::Impl {
Impl();
void foo();
};
X::Impl::Impl() {
void ( X::Impl::* ptr )() = X::Impl::Impl::Impl::Impl::Impl::foo;
}
gcc-4.6-20110908 and clang++ accept this code while e.g. MSVC reports
an error: C3083: '{ctor}': the symbol to the left of a '::' must be a type
[Bug fortran/50401] New: SIGSEGV in resolve_transfer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50401 Bug #: 50401 Summary: SIGSEGV in resolve_transfer Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25277 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25277 just compile it SIGSEGV in resolve_transfer
[Bug fortran/50402] New: ICE in gfc_conv_expr_descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50402 Bug #: 50402 Summary: ICE in gfc_conv_expr_descriptor Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25278 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25278 just compile it ICE in gfc_conv_expr_descriptor
[Bug fortran/50403] New: SIGSEGV in gfc_use_derived
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50403 Bug #: 50403 Summary: SIGSEGV in gfc_use_derived Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25279 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25279 just compile it SIGSEGV in gfc_use_derived
[Bug fortran/50404] New: SIGSEGV in gfc_resolve_close
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50404 Bug #: 50404 Summary: SIGSEGV in gfc_resolve_close Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25280 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25280 just compile it SIGSEGV in gfc_resolve_close
[Bug fortran/50405] New: allocation LOOP or SIGSEGV
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50405 Bug #: 50405 Summary: allocation LOOP or SIGSEGV Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25281 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25281 just compile it allocation LOOP or SIGSEGV
[Bug fortran/50406] New: ld undefined reference to __MOD_str
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50406 Bug #: 50406 Summary: ld undefined reference to __MOD_str Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25282 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25282 just compile and link ld undefined reference to __MOD_str
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 vladimir penev vovata at gmail dot com changed: What|Removed |Added CC||vovata at gmail dot com --- Comment #32 from vladimir penev vovata at gmail dot com 2011-09-15 08:30:55 UTC --- An update on this subject at my side. After some interactions with IBM AIX support there is a fix https://www-304.ibm.com/support/docview.wss?uid=isg1IV06344 and after that the assembler doesn't crash any more and works as well in the same time. It has been validated on AIX 6.1 with GCC 4.5.2
[Bug fortran/50407] New: compiler confused by .operator.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50407 Bug #: 50407 Summary: compiler confused by .operator. Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25283 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25283 just compile it compiler confused by .operator.
[Bug fortran/50408] New: ICE in transfer_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50408 Bug #: 50408 Summary: ICE in transfer_expr Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25284 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25284 just compile it ICE in transfer_expr
[Bug fortran/50409] New: SIGSEGV in gfc_simplify_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50409 Bug #: 50409 Summary: SIGSEGV in gfc_simplify_expr Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25285 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25285 just compile it SIGSEGV in gfc_simplify_expr
[Bug fortran/50410] New: ICE in record_reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410 Bug #: 50410 Summary: ICE in record_reference Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25286 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25286 just compile it ICE in record_reference
[Bug fortran/50411] New: gfortran -Ofast SIGSEGV in vect_recog_dot_prod_pattern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50411 Bug #: 50411 Summary: gfortran -Ofast SIGSEGV in vect_recog_dot_prod_pattern Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25287 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25287 please compile it with -Ofast gfortran -Ofast SIGSEGV in vect_recog_dot_prod_pattern
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #33 from vladimir penev vovata at gmail dot com 2011-09-15 08:44:04 UTC --- An update on this subject at my side. After some interactions with IBM AIX support there is a fix https://www-304.ibm.com/support/docview.wss?uid=isg1IV06344 and after that the assembler doesn't crash any more and works as well in the same time. It has been validated on AIX 6.1 TL6 with GCC 4.5.2
[Bug fortran/50412] New: gfortran -Ofast ICE in vect_do_peeling_for_loop_bound
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50412 Bug #: 50412 Summary: gfortran -Ofast ICE in vect_do_peeling_for_loop_bound Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25288 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25288 please compile it with -Ofast gfortran -Ofast ICE in vect_do_peeling_for_loop_bound
[Bug tree-optimization/50413] Incorrect instruction is used to shift value of 128 bit xmm0 registrer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50413 --- Comment #1 from Anatoly aries.nah at gmail dot com 2011-09-15 08:44:57 UTC --- Created attachment 25289 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25289 C++ source code
[Bug fortran/50415] New: gfortran -Ofast SIGSEGV in find_uses_to_rename_use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50415 Bug #: 50415 Summary: gfortran -Ofast SIGSEGV in find_uses_to_rename_use Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25291 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25291 please compile it with -Ofast gfortran -Ofast SIGSEGV in find_uses_to_rename_use
[Bug tree-optimization/50413] New: Incorrect instruction is used to shift value of 128 bit xmm0 registrer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50413 Bug #: 50413 Summary: Incorrect instruction is used to shift value of 128 bit xmm0 registrer Classification: Unclassified Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: aries@gmail.com After compilation an attached code with -O2 and -ftree-vectorize flags, it doesn't work properly. Assembler code shows that G++ tries to replace the following code V.uint128.uint64_lower = (V.uint128.uint64_lower 1); V.bitmap.b63 = V.bitmap.b64; V.uint128.uint64_upper = (V.uint128.uint64_upper 1); with SSE instructions: 400a10: movdqa 0x103d8(%rip),%xmm0# 410df0 V 400a17: and$0x1,%edi 400a1b: psrlq $0x1,%xmm0 400a20: movdqa %xmm0,0x103c8(%rip)# 410df0 V But psrlq shifts 64 bit value, it's necessary to use psrldq here
[Bug fortran/50414] New: gfortran -Ofast SIGSEGV in store_constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50414 Bug #: 50414 Summary: gfortran -Ofast SIGSEGV in store_constructor Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25290 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25290 please compile it with -Ofast gfortran -Ofast SIGSEGV in store_constructor
[Bug fortran/50416] New: gfortran -O1 ICE MPFR assertion failed: 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50416 Bug #: 50416 Summary: gfortran -O1 ICE MPFR assertion failed: 0 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25292 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25292 please compile it with -O1 gfortran -O1 ICE MPFR assertion failed: 0 I have mpfr 2.4.2-1
[Bug tree-optimization/50417] New: regression: memcpy with known alignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50417
Bug #: 50417
Summary: regression: memcpy with known alignment
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: wouter.vermae...@scarlet.be
Consider these functions:
void copy1(char* d, const char* s) {
memcpy(d, s, 256);
}
void copy2(short* d, const short* s) {
memcpy(d, s, 256);
}
void copy3(int* d, const int* s) {
memcpy(d, s, 256);
}
void copy4(long* d, const long* s) {
memcpy(d, s, 256);
}
g++-4.5.2 is able to generate better code for the later functions. But when I
test with a recent snapshot (SVN revision 178875 on linux x86_64) it generates
the same code for all versions (same as copy1()).
[Bug c++/50418] New: nested class typedef with same name and pointing to parent class typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50418
Bug #: 50418
Summary: nested class typedef with same name and pointing to
parent class typedef
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: frrr...@gmail.com
struct A
{
typedef int T;
struct B
{
typedef T T;
};
};
test.cpp:6:19: error: declaration of ‘typedef A::T A::B::T’
test.cpp:3:17: error: changes meaning of ‘T’ from ‘typedef int A::T’
It works with Comeau, Clang and VC++, gcc workaround is the following:
struct A
{
typedef int T;
struct B
{
typedef A::T T;
};
};
[Bug tree-optimization/50413] Incorrect instruction is used to shift value of 128 bit xmm0 registrer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50413 --- Comment #2 from Anatoly aries.nah at gmail dot com 2011-09-15 09:05:03 UTC --- Forgot to mention: Intel(R) Core(TM) i5 CPU 760 @ 2.80GHz LGA1156 And there's no such bug in GCC 4.3.4
[Bug libstdc++/41816] ldconfig warnings vs. libstdc++.so.6.0.14-gdb.py
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41816
Markus Trippelsdorf markus at trippelsdorf dot de changed:
What|Removed |Added
CC||markus at trippelsdorf dot
||de
--- Comment #6 from Markus Trippelsdorf markus at trippelsdorf dot de
2011-09-15 09:06:16 UTC ---
Why don't we just install this file in
/usr/share/gdb/auto-load/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.0/ instead of
$(DESTDIR)$(toolexeclibdir)/ by default?
BTW Gentoo does this by default:
# Move pretty-printers to gdb datadir to shut ldconfig up
gdbdir=/usr/share/gdb/auto-load${LIBPATH/\/lib\//\/$(get_libdir)\/}
for i in ${D}${LIBPATH}{,/32}/*-gdb.py; do
if [[ -e ${i} ]]; then
basedir=$(dirname ${i/${D}${LIBPATH}/})
sed -i -e s:^\(libdir = \).*:\1'${LIBPATH}${basedir}': ${i}
#348128
insinto ${gdbdir}${basedir}
doins ${i}
rm ${i}
fi
done
[Bug c++/50399] [c++11] Lookup error w/ enums
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50399 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-15 09:21:30 UTC --- I think G++ is correct, see [basic.lookup.qual] In C++03 a nested-name-specifier can only refer to a class or namespace, in C++11 it can also refer to an enumeration.
[Bug c++/50399] [c++11] Lookup error w/ enums
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50399 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-15 09:26:38 UTC --- C++03 says During the lookup for a name preceding the :: scope resolution operator, object, function, and enumerator names are ignored. So in -std=c++98 mode G++ is correct to ignore A::C::B and so finds B::F (Clang gets this wrong) In C++11 the enumeration is not ignored (because a nested-name-specifier could refer to a scoped enumeration) so name lookup finds B in the enclosing namespace, i.e. A::C::B
[Bug c++/50400] compiler accepts invalid X::Impl::Impl::Impl::.....::foo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50400 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-15 09:34:52 UTC --- EDG accepts it too, are you suggesting MSVC is right and all the others wrong? That would be a first ;) See http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#318 Because the constructor Impl::Impl is not an acceptable lookup result in the expression X::Impl::Impl::foo the second Impl names the class itself, and so the code is valid and G++ is correct
[Bug tree-optimization/50414] gfortran -Ofast SIGSEGV in store_constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50414
Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed:
What|Removed |Added
Component|fortran |tree-optimization
--- Comment #1 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch
2011-09-15 09:59:37 UTC ---
Breakpoint 2, internal_error (gmsgid=0xf3ffe8 gimple check: expected %s(%s),
have %s(%s) in %s, at %s:%d) at ../../gcc/gcc/diagnostic.c:833
833 {
(gdb) bt
#0 internal_error (gmsgid=0xf3ffe8 gimple check: expected %s(%s), have %s(%s)
in %s, at %s:%d) at ../../gcc/gcc/diagnostic.c:833
#1 0x0079a306 in gimple_check_failed (gs=0x75b58580,
file=Unhandled dwarf expression opcode 0xf3
) at ../../gcc/gcc/gimple.c:1156
#2 0x00aa8f9f in gimple_phi_arg (op=value optimized out,
vec_oprnds=0x7fffd5e8, op_num=0, number_of_vectors=1, reduc_index=2,
slp_node=Unhandled dwarf expression opcode 0xfa
)
at ../../gcc/gcc/gimple.h:3369
#3 gimple_phi_arg_imm_use_ptr (op=value optimized out,
vec_oprnds=0x7fffd5e8, op_num=0, number_of_vectors=1, reduc_index=2,
slp_node=Unhandled dwarf expression opcode 0xfa
)
at ../../gcc/gcc/tree-flow-inline.h:452
#4 vect_get_constant_vectors (op=value optimized out,
vec_oprnds=0x7fffd5e8, op_num=0, number_of_vectors=1, reduc_index=2,
slp_node=Unhandled dwarf expression opcode 0xfa
)
at ../../gcc/gcc/tree-vect-slp.c:2013
#5 0x00aab177 in vect_get_slp_defs (op0=0x75b55910, op1=0x0,
slp_node=0x16d5d70, vec_oprnds0=0x7fffd5e8, vec_oprnds1=0x0, reduc_index=2)
at ../../gcc/gcc/tree-vect-slp.c:2145
#6 0x00a983cb in vect_create_epilog_for_reduction
(vect_defs=0x16d6260, stmt=0x75b58580, ncopies=1,
reduc_code=REDUC_MAX_EXPR,
reduction_phis=0x16d66c0, reduc_index=2, double_reduc=false,
slp_node=0x16d5d70) at ../../gcc/gcc/tree-vect-loop.c:3541
#7 0x00a9cf8d in vectorizable_reduction (stmt=0x7fff0001,
gsi=0x7fffd900, vec_stmt=0x7fffd878, slp_node=0x16d5d70)
at ../../gcc/gcc/tree-vect-loop.c:4902
#8 0x00a91805 in vect_transform_stmt (stmt=0x75b58580,
gsi=0x7fffd900, strided_store=0x7fffd8ff, slp_node=0x16d5d70,
slp_node_instance=Unhandled dwarf expression opcode 0xf3
)
at ../../gcc/gcc/tree-vect-stmts.c:5218
#9 0x00aa7b40 in vect_schedule_slp_instance (node=0x16d5d70,
instance=0x16d5ed0, vectorization_factor=Unhandled dwarf expression opcode 0xf3
) at ../../gcc/gcc/tree-vect-slp.c:2574
#10 0x00aadbc8 in vect_schedule_slp (loop_vinfo=Unhandled dwarf
expression opcode 0xf3
) at ../../gcc/gcc/tree-vect-slp.c:2604
#11 0x00aa1a5c in vect_transform_loop (loop_vinfo=0x16ff380) at
../../gcc/gcc/tree-vect-loop.c:5317
#12 0x00aae7e3 in vectorize_loops () at
../../gcc/gcc/tree-vectorizer.c:214
#13 0x00876d37 in execute_one_pass (pass=0x1498f00) at
../../gcc/gcc/passes.c:2063
[Bug tree-optimization/50415] gfortran -Ofast SIGSEGV in find_uses_to_rename_use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50415 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-15 Component|fortran |tree-optimization Ever Confirmed|0 |1 --- Comment #1 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-09-15 10:03:10 UTC --- #0 find_uses_to_rename_use (bb=0x77eae7b8, use=0x75b56910, use_blocks=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/tree-ssa-loop-manip.c:1267 #1 find_uses_to_rename_use (bb=0x77eae7b8, use=0x75b56910, use_blocks=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/tree-ssa-loop-manip.c:232 #2 0x00a06d10 in find_uses_to_rename_bb (bb=0x77eae7b8, use_blocks=0x16d83c0, need_phis=0x16dfcd0) at ../../gcc/gcc/tree-ssa-loop-manip.c:302 #3 0x00a07506 in find_uses_to_rename (changed_bbs=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/tree-ssa-loop-manip.c:331 #4 rewrite_into_loop_closed_ssa (changed_bbs=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/tree-ssa-loop-manip.c:391 #5 0x0096bad4 in ldist_gen (loop=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/tree-loop-distribution.c:1134 #6 distribute_loop (loop=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/tree-loop-distribution.c:1216 #7 distribute_loop (loop=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/tree-loop-distribution.c:1158 #8 0x0096c895 in tree_loop_distribution () at ../../gcc/gcc/tree-loop-distribution.c:1272 #9 0x00876d37 in execute_one_pass (pass=0x1497f40) at ../../gcc/gcc/passes.c:2063 #10 0x008770a5 in execute_pass_list (pass=0x1497f40) at ../../gcc/gcc/passes.c:2118 #11 0x008770b7 in execute_pass_list (pass=0x14990e0) at ../../gcc/gcc/passes.c:2119
[Bug tree-optimization/50414] gfortran -Ofast SIGSEGV in store_constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50414 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-15 Ever Confirmed|0 |1
[Bug libstdc++/41816] ldconfig warnings vs. libstdc++.so.6.0.14-gdb.py
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41816 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-15 10:04:18 UTC --- (In reply to comment #6) Why don't we just install this file in /usr/share/gdb/auto-load/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.0/ instead of $(DESTDIR)$(toolexeclibdir)/ by default? Who's we? I have several versions of GDB and GCC installed, which GDB data dir should I put the printers in, all of them? That would need root access in some cases. BTW Gentoo does this by default: Gentoo is a distro and can decide to put the system compiler's files in the system debugger's data dir, not everyone who installs GCC can do that.
[Bug tree-optimization/50412] gfortran -Ofast ICE in vect_do_peeling_for_loop_bound
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50412 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-15 Component|fortran |tree-optimization Ever Confirmed|0 |1 --- Comment #1 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-09-15 10:05:27 UTC --- #0 internal_error (gmsgid=0x117c39a in %s, at %s:%d) at ../../gcc/gcc/diagnostic.c:833 #1 0x00e3f394 in fancy_abort (file=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/diagnostic.c:893 #2 0x00aa5fce in vect_do_peeling_for_loop_bound (loop_vinfo=0x16e3870, ratio=0x7fffda58, cond_expr=0x0, cond_expr_stmt_list=0x0) at ../../gcc/gcc/tree-vect-loop-manip.c:1931 #3 0x00aa1c7c in vect_transform_loop (loop_vinfo=0x16e3870) at ../../gcc/gcc/tree-vect-loop.c:5161 #4 0x00aae7e3 in vectorize_loops () at ../../gcc/gcc/tree-vectorizer.c:214 #5 0x00876d37 in execute_one_pass (pass=0x1498f00) at ../../gcc/gcc/passes.c:2063
[Bug c++/50344] friend declaration confused by const qualifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50344 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-15 10:06:31 UTC --- Thanks Paolo - I forgot to add a follow-up comment to say I'd tested it
[Bug tree-optimization/50414] [4.7 Regression] gfortran -Ofast SIGSEGV in store_constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50414 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Summary|gfortran -Ofast SIGSEGV in |[4.7 Regression] gfortran |store_constructor |-Ofast SIGSEGV in ||store_constructor --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-09-15 10:27:53 UTC --- This is a regression that occurred between revisions 173852 (OK) and 175707 (ICE). If needed, I'll be able to narrow the range later today.
[Bug tree-optimization/50415] [4.7 Regression] gfortran -Ofast SIGSEGV in find_uses_to_rename_use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50415 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Summary|gfortran -Ofast SIGSEGV in |[4.7 Regression] gfortran |find_uses_to_rename_use |-Ofast SIGSEGV in ||find_uses_to_rename_use --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-09-15 10:33:01 UTC --- This is a regression that occurred in the same range as pr50414 (between revisions 173852 (OK) and 175707 (ICE)).
[Bug fortran/50416] gfortran -O1 ICE MPFR assertion failed: 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50416 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-09-15 10:39:12 UTC --- It works for me with -O1, -Ofast, and -m32 -Ofast. I used x86_64-apple-darwin10 with GMP version 5.0.2, MPFR version 3.0.1, MPC version 0.9 Likely a MPFR (or its use) bug. I suggest to close this pr as invalid.
[Bug libstdc++/41816] ldconfig warnings vs. libstdc++.so.6.0.14-gdb.py
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41816 --- Comment #8 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-09-15 10:50:37 UTC --- (In reply to comment #7) (In reply to comment #6) Why don't we just install this file in /usr/share/gdb/auto-load/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.0/ instead of $(DESTDIR)$(toolexeclibdir)/ by default? Who's we? The big other :-) I have several versions of GDB and GCC installed, which GDB data dir should I put the printers in, all of them? That would need root access in some cases. All versions of GDB would look into the same directory structure. And there would be one subdirectory for each different GCC version. And of course you'll need root access in this case, but *we* could fall back to the current location for a installation without root access.
[Bug fortran/50411] gfortran -Ofast SIGSEGV in vect_recog_dot_prod_pattern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50411 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-09-15 10:55:19 UTC --- Likely a duplicate of pr50343 fixed by revision 178775. I use this pr for some general comments: (1) follow the Mikael Morin's advice in pr50375 comment #4: Please paste the code content directly instead of attaching for small (say, less than around 10-20 lines) files. (2) try to give the revision of the gfortran against which your report the bug. (3) use the free form for the code (i.e. ! instead of c).
[Bug fortran/50409] SIGSEGV in gfc_simplify_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50409 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-15 Ever Confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-09-15 11:04:05 UTC --- On x86_64-apple-darwin10 from gfortran 4.4 to 4.7 I had to interrupt the compilation after several minutes. Sampling the compilation yielded: Sampling process 55479 for 3 seconds with 1 millisecond of run time between samples Sampling completed, processing symbols... Analysis of sampling f951 (pid 55479) every 1 millisecond Process: f951 [55479] Path: /opt/gcc/gcc4.7w/libexec/gcc/x86_64-apple-darwin10.8.0/4.7.0/f951 Load Address:0x1 Identifier: f951 Version: ??? (???) Code Type: X86-64 (Native) Parent Process: gfortran [55477] Date/Time: 2011-09-15 11:05:43.420 +0200 OS Version: Mac OS X 10.6.8 (10K549) Report Version: 6 Call graph: 2366 Thread_2859011 DispatchQueue_1: com.apple.main-thread (serial) 2366 gfc_simplify_expr(gfc_expr*, int) 2366 __memcpy 2366 _sigtramp 2366 crash_signal(int) 2366 internal_error(char const*, ...) 2366 diagnostic_set_info(diagnostic_info*, char const*, __va_list_tag (*) [1], unsigned int, diagnostic_t) 2366 libintl_dcigettext 2366 strcmp Total number in stack (recursive counted multiple, when =5): Sort by top of stack, same collapsed (when = 5): strcmp2366 Binary Images: 0x1 -0x100d5bfef +f951 ??? (???) 69BA1A11-FFE8-2BE9-0157-915E87E95F7C /opt/gcc/gcc4.7w/libexec/gcc/x86_64-apple-darwin10.8.0/4.7.0/f951 0x14145b000 -0x141462fff +libintl.8.dylib 9.2.0 (compatibility 9.0.0) 77764503-B558-C86F-5C9D-0896504B2BA5 /sw64/lib/libintl.8.dylib 0x141467000 -0x141562fe7 +libiconv.2.dylib 7.0.0 (compatibility 7.0.0) 2F723465-84E7-77FB-F9FD-572D6A0DBBCC /sw64/lib/libiconv.2.dylib 0x14157e000 -0x14159aff7 +libcloog-isl.2.dylib 3.0.0 (compatibility 3.0.0) E60A7BC6-03C5-DD6E-A6EF-27B85411B2A4 /opt/sw64/lib/libcloog-isl.2.dylib 0x1415a5000 -0x141646ff7 +libisl.7.dylib 8.0.0 (compatibility 8.0.0) B502B39E-85E7-4346-20F6-AE72BC5E44D9 /opt/sw64/lib/libisl.7.dylib 0x141668000 -0x141ac1ff7 +libppl_c.4.dylib 5.0.0 (compatibility 5.0.0) E05D2529-6FEB-6511-7B01-474FF91FD359 /opt/sw64/lib/libppl_c.4.dylib 0x141c45000 -0x141d1fff7 +libppl.9.dylib 10.0.0 (compatibility 10.0.0) A5F94C60-C0C2-B343-F8C3-5C04EA05A356 /opt/sw64/lib/libppl.9.dylib 0x141d92000 -0x141d94fff +libgmpxx.4.dylib 7.2.0 (compatibility 7.0.0) 0AAF15CD-F0FC-E622-38E0-06C422E3ED95 /opt/sw64/lib/libgmpxx.4.dylib 0x141d98000 -0x141da8fff +libmpc.2.dylib 3.0.0 (compatibility 3.0.0) 306CC750-3595-7C0D-5FAE-286A1A7BA40E /opt/sw64/lib/libmpc.2.dylib 0x141dad000 -0x141df9ff7 +libmpfr.4.dylib 5.1.0 (compatibility 5.0.0) 99C678CB-35EA-1551-2921-8FAA54300718 /opt/sw64/lib/libmpfr.4.dylib 0x141e04000 -0x141e62ff7 +libgmp.10.dylib 11.2.0 (compatibility 11.0.0) B66ADC3C-CB23-AA46-1E5D-38009780079D /opt/sw64/lib/libgmp.10.dylib 0x141e73000 -0x141e74fff +libpwl.5.dylib 6.0.0 (compatibility 6.0.0) 6A4D7AF5-89E9-6E5E-1062-2DDA1628C121 /opt/sw64/lib/libpwl.5.dylib 0x7fff5fc0 - 0x7fff5fc3bdef dyld 132.1 (???) B536F2F1-9DF1-3B6C-1C2C-9075EA219A06 /usr/lib/dyld 0x7fff802f4000 - 0x7fff802f8ff7 libmathCommon.A.dylib 315.0.0 (compatibility 1.0.0) 95718673-FEEE-B6ED-B127-BCDBDB60D4E5 /usr/lib/system/libmathCommon.A.dylib 0x7fff82201000 - 0x7fff8224dfff libauto.dylib ??? (???) F7221B46-DC4F-3153-CE61-7F52C8C293CF /usr/lib/libauto.dylib 0x7fff83667000 - 0x7fff83828fef libSystem.B.dylib 125.2.11 (compatibility 1.0.0) 9AB4F1D1-89DC-0E8A-DC8E-A4FE4D69DB69 /usr/lib/libSystem.B.dylib 0x7fff8387e000 - 0x7fff83934ff7 libobjc.A.dylib 227.0.0 (compatibility 1.0.0) 03140531-3B2D-1EBA-DA7F-E12CC8F63969 /usr/lib/libobjc.A.dylib 0x7fff85fd5000 - 0x7fff86052fef libstdc++.6.dylib 7.9.0 (compatibility 7.0.0) 35ECA411-2C08-FD7D-11B1-1B7A04921A5C /usr/lib/libstdc++.6.dylib 0x7fff87636000 - 0x7fff877adfe7 com.apple.CoreFoundation 6.6.5 (550.43) 31A1C118-AD96-0A11-8BDF-BD55B9940EDC /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 0x7fff87c6f000 - 0x7fff87e2dfff libicucore.A.dylib 40.0.0 (compatibility 1.0.0) 4274FC73-A257-3A56-4293-5968F3428854 /usr/lib/libicucore.A.dylib 0x7fff899ad000 - 0x7fff899beff7 libz.1.dylib 1.2.3 (compatibility 1.0.0) FB5EE53A-0534-0FFA-B2ED-486609433717 /usr/lib/libz.1.dylib
[Bug fortran/50410] [4.6/4.7 Regression] ICE in record_reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-15 Summary|ICE in record_reference |[4.6/4.7 Regression] ICE in ||record_reference Ever Confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-09-15 11:08:55 UTC --- Confirmed on 4.6.1 and trunk: pr50410.f90:7:0: internal compiler error: in record_reference, at cgraphbuild.c:67 no ICE on 4.4.6 and 4.5.3 (no error). g95 gives the following error: In file pr50410.f90:6 data u%g /1/ 1 Error: Can't dereference POINTER in DATA statement at (1)
[Bug testsuite/50076] FAIL: c-c++-common/cxxbitfields-3.c scan-assembler movl.*, var on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50076 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-09-15 11:16:14 UTC --- Could someone look at this pr and decide if the code movq_var@GOTPCREL(%rip), %rdx movl(%rdx), %eax is buggy (in this case I cannot help) or if the dg-final has to be adjusted for darwin (then I can try to find a suitable regexp).
[Bug fortran/50401] SIGSEGV in resolve_transfer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50401
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Keywords||ice-on-invalid-code
Last reconfirmed||2011-09-15
CC||janus at gcc dot gnu.org
AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #1 from janus at gcc dot gnu.org 2011-09-15 11:17:16 UTC ---
The obvious fix:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 178876)
+++ gcc/fortran/resolve.c (working copy)
@@ -8222,7 +8222,7 @@
}
}
- if (sym-as != NULL sym-as-type == AS_ASSUMED_SIZE
+ if (sym-as != NULL sym-as-type == AS_ASSUMED_SIZE exp-ref
exp-ref-type == REF_ARRAY exp-ref-u.ar.type == AR_FULL)
{
gfc_error (Data transfer element at %L cannot be a full reference to
[Bug middle-end/50315] Regression on Atom after fix #49958
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50315 --- Comment #7 from Sergey Ostanevich sergos.gnu at gmail dot com 2011-09-15 11:24:27 UTC --- Richard, I believe your test should be reading as So you can go from (a +no b) +no c to a + no (b + c), dropping overflow knowledge on re-association. And let me re-phrase what's Joseph said (just to be sure I got the idea): we have to preserve the overflow semantics at GIMPLE level to avoid possible problems during translation into RTL. Consider we have situation without overflow in 32-bit with particular calculation order and can use either 32-bit or 64-bit operations to perform that. But after reassociation in GIMPLE we can introduce overflow for 32-bit, that will lead to wrong result in case we use 64-bit operations. Being aware of such situation during traslation we can evade error, but it requires too much effort (or even impossible) to provide this data to the translator. Is it right?
[Bug tree-optimization/50414] [4.7 Regression] gfortran -Ofast SIGSEGV in store_constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50414 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-09-15 11:27:35 UTC --- This is a regression that occurred between revisions 173852 (OK) and 175707 (ICE). If needed, I'll be able to narrow the range later today. 173817 is OK 173917 gives the ICE
[Bug tree-optimization/50415] [4.7 Regression] gfortran -Ofast SIGSEGV in find_uses_to_rename_use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50415 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-09-15 11:30:14 UTC --- This is a regression that occurred in the same range as pr50414 (between revisions 173852 (OK) and 175707 (ICE)). r174030 is OK r174283 gives the ICE.
[Bug tree-optimization/50415] [4.7 Regression] gfortran -Ofast SIGSEGV in find_uses_to_rename_use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50415 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-09-15 11:33:16 UTC --- '-O2 -ftree-vectorize' is OK, '-O3' gives the ICE.
[Bug libstdc++/41816] ldconfig warnings vs. libstdc++.so.6.0.14-gdb.py
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41816 --- Comment #9 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-15 11:33:50 UTC --- Hmm yes, this is only really an issue for people who install libstdc++ into a directory that ldconfig searches, which for most people means it only affects the system compiler, which means distros can fix it for their users as Gentoo does. For everyone who installs GCC themselves without root access, they probably don't get the ldconfig warnings anyway, so don't care. A config option allowing that to be automated would make things a little easier for those who do want to move the file.
[Bug tree-optimization/50412] gfortran -Ofast ICE in vect_do_peeling_for_loop_bound
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50412
Ira Rosen irar at il dot ibm.com changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC||irar at il dot ibm.com
AssignedTo|unassigned at gcc dot |irar at il dot ibm.com
|gnu.org |
--- Comment #2 from Ira Rosen irar at il dot ibm.com 2011-09-15 11:40:59 UTC
---
The problem is that we don't support loop peeling for outer loops, but we
support single element interleaving that may require peeling. I'll test this
patch:
Index: tree-vect-data-refs.c
===
--- tree-vect-data-refs.c (revision 178780)
+++ tree-vect-data-refs.c (working copy)
@@ -2055,6 +2059,10 @@ vect_analyze_group_access (struct data_r
HOST_WIDE_INT dr_step = TREE_INT_CST_LOW (step);
HOST_WIDE_INT stride, last_accessed_element = 1;
bool slp_impossible = false;
+ struct loop *loop = NULL;
+
+ if (loop_vinfo)
+loop = LOOP_VINFO_LOOP (loop_vinfo);
/* For interleaving, STRIDE is STEP counted in elements, i.e., the size of
the
interleaving group (including gaps). */
@@ -2085,11 +2093,17 @@ vect_analyze_group_access (struct data_r
if (loop_vinfo)
{
- LOOP_VINFO_PEELING_FOR_GAPS (loop_vinfo) = true;
-
if (vect_print_dump_info (REPORT_DETAILS))
fprintf (vect_dump, Data access with gaps requires scalar
epilogue loop);
+ if (loop-inner)
+{
+ if (vect_print_dump_info (REPORT_DETAILS))
+fprintf (vect_dump, Peeling for outer loop is not
supported);
+ return false;
+}
+
+ LOOP_VINFO_PEELING_FOR_GAPS (loop_vinfo) = true;
}
return true;
@@ -2272,10 +2286,17 @@ vect_analyze_group_access (struct data_r
/* There is a gap in the end of the group. */
if (stride - last_accessed_element 0 loop_vinfo)
{
- LOOP_VINFO_PEELING_FOR_GAPS (loop_vinfo) = true;
if (vect_print_dump_info (REPORT_DETAILS))
fprintf (vect_dump, Data access with gaps requires scalar
epilogue loop);
+ if (loop-inner)
+{
+ if (vect_print_dump_info (REPORT_DETAILS))
+fprintf (vect_dump, Peeling for outer loop is not
supported);
+ return false;
+}
+
+ LOOP_VINFO_PEELING_FOR_GAPS (loop_vinfo) = true;
}
}
[Bug fortran/50403] SIGSEGV in gfc_use_derived
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50403 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Keywords||ice-on-invalid-code Last reconfirmed||2011-09-15 CC||janus at gcc dot gnu.org AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org 2011-09-15 11:41:06 UTC --- This one is also obvious: Index: gcc/fortran/symbol.c === --- gcc/fortran/symbol.c(revision 178876) +++ gcc/fortran/symbol.c(working copy) @@ -1945,6 +1945,8 @@ gfc_symtree *st; int i; + if (!sym) return NULL; + if (sym-components != NULL || sym-attr.zero_comp) return sym; /* Already defined. */ Btw: Where do you get this enormous amount of invalid Fortran code?
[Bug c++/50418] nested class typedef with same name and pointing to parent class typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50418 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-15 12:17:48 UTC --- [basic.scope.class] A name N used in a class S shall refer to the same declaration in its context and when re-evaluated in the completed scope of S. No diagnostic is required for a violation of this rule. Which implies the program is ill-formed.
[Bug c++/50418] nested class typedef with same name and pointing to parent class typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50418 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-15 12:29:38 UTC --- you can use -fpermissive to make G++ accept the code
[Bug tree-optimization/50414] [4.7 Regression] gfortran -Ofast SIGSEGV in store_constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50414 Ira Rosen irar at il dot ibm.com changed: What|Removed |Added Status|NEW |ASSIGNED CC||irar at il dot ibm.com AssignedTo|unassigned at gcc dot |irar at il dot ibm.com |gnu.org | --- Comment #4 from Ira Rosen irar at il dot ibm.com 2011-09-15 12:36:04 UTC --- Looks like a mix up in the order of stmts in reduction SLP node. I'll take a better look next week.
[Bug tree-optimization/50413] Incorrect instruction is used to shift value of 128 bit xmm0 registrer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50413 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Uros Bizjak ubizjak at gmail dot com 2011-09-15 13:29:23 UTC --- (In reply to comment #0) After compilation an attached code with -O2 and -ftree-vectorize flags, it doesn't work properly. Assembler code shows that G++ tries to replace the following code V.uint128.uint64_lower = (V.uint128.uint64_lower 1); V.bitmap.b63 = V.bitmap.b64; V.uint128.uint64_upper = (V.uint128.uint64_upper 1); with SSE instructions: 400a10: movdqa 0x103d8(%rip),%xmm0# 410df0 V 400a17: and$0x1,%edi 400a1b: psrlq $0x1,%xmm0 400a20: movdqa %xmm0,0x103c8(%rip)# 410df0 V But psrlq shifts 64 bit value, it's necessary to use psrldq here You are wrong. The code above describes shift of two 64bit elements, each by one, so psrlq [1] is correct. [1] http://www.rz.uni-karlsruhe.de/rz/docs/VTune/reference/vc259.htm
[Bug fortran/50411] gfortran -Ofast SIGSEGV in vect_recog_dot_prod_pattern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50411 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-09-15 13:37:54 UTC --- dup fixed *** This bug has been marked as a duplicate of bug 50343 ***
[Bug middle-end/50343] [4.7 Regression] FAIL: gfortran.dg/graphite/id-22.f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50343 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added CC||zeccav at gmail dot com --- Comment #10 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-09-15 13:37:54 UTC --- *** Bug 50411 has been marked as a duplicate of this bug. ***
[Bug fortran/50408] ICE in transfer_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50408 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-15 Ever Confirmed|0 |1 --- Comment #1 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-09-15 13:40:45 UTC --- a beauty :-) #0 internal_error (gmsgid=0x117c39a in %s, at %s:%d) at ../../gcc/gcc/diagnostic.c:833 #1 0x00e3f394 in fancy_abort (file=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/diagnostic.c:893 #2 0x005db4ce in transfer_expr (se=0x7fffd400, ts=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/fortran/trans-io.c:2156 #3 0x005dfe31 in gfc_trans_transfer (code=0x16cf1e0) at ../../gcc/gcc/fortran/trans-io.c:2305 #4 0x005956b8 in trans_code (code=0x16cf1e0, cond=0x77fef6f0) at ../../gcc/gcc/fortran/trans.c:1397 #5 0x005dd90b in build_dt (function=0x75b4d200, code=0x16cf450) at ../../gcc/gcc/fortran/trans-io.c:1832 #6 0x005dfbfd in gfc_trans_write (code=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/fortran/trans-io.c:1871 #7 0x005956d8 in trans_code (code=0x16cf450, cond=0x0) at ../../gcc/gcc/fortran/trans.c:1369 #8 0x005b999c in gfc_generate_function_code (ns=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/fortran/trans-decl.c:5211 #9 0x005578c7 in translate_all_program_units () at ../../gcc/gcc/fortran/parse.c:4404 #10 gfc_parse_file () at ../../gcc/gcc/fortran/parse.c:4617 #11 0x00590ac6 in gfc_be_parse_file () at ../../gcc/gcc/fortran/f95-lang.c:250
[Bug tree-optimization/50413] Incorrect instruction is used to shift value of 128 bit xmm0 registrer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50413 Anatoly aries.nah at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | --- Comment #4 from Anatoly aries.nah at gmail dot com 2011-09-15 13:42:05 UTC --- It's not serious. Yes, I'm not an expert in SSE instructions (and in ASM at all), and it seems you're right about shifting. But, the bug is a real. GCC losts lower bit of upper quadword during shifting by psrlq. Try to compile my code and check it out. We have V.bitmap.b63 = V.bitmap.b64; to shift a lower bit of the upper quadword but GCC has decided not to do this.
[Bug fortran/50406] ld undefined reference to __MOD_str
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50406 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-15 Ever Confirmed|0 |1
[Bug fortran/50405] allocation LOOP or SIGSEGV
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50405 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-15 Ever Confirmed|0 |1
[Bug fortran/50404] SIGSEGV in gfc_resolve_close
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50404 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-15 Ever Confirmed|0 |1
[Bug fortran/50402] ICE in gfc_conv_expr_descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50402 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-15 Ever Confirmed|0 |1
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #34 from Daniel Richard G. skunk at iskunk dot org 2011-09-15 14:01:36 UTC --- (In reply to comment #33) Vladimir, this [GCC] bug report has nothing to do with the assembler segfaulting. The problem is that the linker can't link what the assembler is producing (ld: 0711-593 SEVERE ERROR).
[Bug c++/50418] nested class typedef with same name and pointing to parent class typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50418 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2011-09-15 14:07:04 UTC --- Invalid as noted in comment #1 .
[Bug c++/50365] [4.7 Regression] non-static data member error on valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50365 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug tree-optimization/50419] New: Bad interaction between data-ref and disambiguation with restrict pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50419
Bug #: 50419
Summary: Bad interaction between data-ref and disambiguation
with restrict pointers
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@gcc.gnu.org
% cat predcom-fail.c
#define INFTY 987654321
#define Ra /*__restrict*/
#define Rv __restrict
void
P7Viterbi(int * Ra _dc, int * Ra _mc, int * Ra _tpdd, int * Ra _tpmd, int M)
{
int i,k;
int sc;
int * Rv dc = _dc;
int * Rv mc = _mc;
int * Rv tpdd = _tpdd;
int * Rv tpmd = _tpmd;
dc[0] = -INFTY;
for (k = 1; k M; k++) {
dc[k] = dc[k-1] + tpdd[k-1];
if ((sc = mc[k-1] + tpmd[k-1]) dc[k]) dc[k] = sc;
if (dc[k] -INFTY) dc[k] = -INFTY;
}
}
./cc1 -Ofast predcom-fail.c should be able to predcom the loop. It doesn't
because it doesn't see that the (first) dc[] write doesn't conflict with the
mc/tpmd[] reads. It should be able to see that because all the int pointers
are created with new restrict sets. If you defined Ra as also __restrict
(making the arguments already restrict qualified) you get the transformation.
The problem is an interaction between creating the datarefs and the
disambiguator. The data-ref base objects contain the casted inputs:
#(Data Ref:
# bb: 4
# stmt: D.2741_19 = *D.2740_18;
# ref: *D.2740_18;
# base_object: *(int * restrict) _dc_2(D);
# Access function 0: {0B, +, 4}_1
#)
vs
#(Data Ref:
# bb: 4
# stmt: D.2743_24 = *D.2742_23;
# ref: *D.2742_23;
# base_object: *(int * restrict) _tpdd_6(D);
# Access function 0: {0B, +, 4}_1
#)
The disambiguator used is ptr_derefs_may_alias_p on those two (casted)
pointers. But the first thing it does is to remove all conversions.
Remembering the original type wouldn't help as we need to look into the
points-to info of the restrict qualified object (i.e. the LHS of that
conversion).
Hence when creating the data-ref we shouldn't look through such casts, that
introduce useful information. I have a patch.
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #35 from vladimir penev vovata at gmail dot com 2011-09-15 14:14:16 UTC --- Yes, it's true. And using the mentioned efix for AIX the problem doesn't exist any more, the assembler generates correct code and the linker links it as well. Nothing to do at GCC side. I just inform the affected people about the existing of a fix.
[Bug tree-optimization/50419] Bad interaction between data-ref and disambiguation with restrict pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50419 --- Comment #1 from Michael Matz matz at gcc dot gnu.org 2011-09-15 14:16:54 UTC --- Created attachment 25293 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25293 (untested) patch Potential fix for this. As yet untested.
[Bug tree-optimization/50413] Incorrect instruction is used to shift value of 128 bit xmm0 registrer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50413 --- Comment #5 from Uros Bizjak ubizjak at gmail dot com 2011-09-15 14:17:34 UTC --- (In reply to comment #4) We have V.bitmap.b63 = V.bitmap.b64; to shift a lower bit of the upper quadword but GCC has decided not to do this. Ah, I didn't see the purpose of this assignment. I will investigate this a bit more.
[Bug tree-optimization/50413] [4.6/4.7 Regression] Incorrect instruction is used to shift value of 128 bit xmm0 registrer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50413 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-15 CC||irar at il dot ibm.com Target Milestone|--- |4.6.2 Summary|Incorrect instruction is|[4.6/4.7 Regression] |used to shift value of 128 |Incorrect instruction is |bit xmm0 registrer |used to shift value of 128 ||bit xmm0 registrer Ever Confirmed|0 |1 --- Comment #6 from Uros Bizjak ubizjak at gmail dot com 2011-09-15 14:29:42 UTC --- SLP pass fails to notice one-bit assignment.
[Bug c++/50361] [C++0x] [4.7 Regression] ICE with std::initializer_list and nullptr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50361 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org 2011-09-15 14:33:29 UTC --- Author: jason Date: Thu Sep 15 14:33:24 2011 New Revision: 178882 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178882 Log: PR c++/50361 * expr.c (count_type_elements): Handle NULLPTR_TYPE. Added: trunk/gcc/testsuite/g++.dg/cpp0x/nullptr23.C Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c trunk/gcc/testsuite/ChangeLog
[Bug c++/50365] [4.7 Regression] non-static data member error on valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50365 --- Comment #8 from Jason Merrill jason at gcc dot gnu.org 2011-09-15 14:33:42 UTC --- Author: jason Date: Thu Sep 15 14:33:37 2011 New Revision: 178883 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178883 Log: PR c++/50365 * parser.c (cp_parser_late_return_type_opt): Check quals parameter for clearing current_class_ptr, too. Added: trunk/gcc/testsuite/g++.dg/cpp0x/trailing7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug c++/50365] [4.7 Regression] non-static data member error on valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50365 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #9 from Jason Merrill jason at gcc dot gnu.org 2011-09-15 14:34:06 UTC --- Fixed.
[Bug c++/50361] [C++0x] [4.7 Regression] ICE with std::initializer_list and nullptr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50361 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #7 from Jason Merrill jason at gcc dot gnu.org 2011-09-15 14:34:21 UTC --- Fixed.
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 --- Comment #3 from Jan Hubicka hubicka at gcc dot gnu.org 2011-09-15 15:39:18 UTC --- Thanks a lot! is there any chance to get those fixes into official git so we don't need to cummulate local patches? :)
[Bug fortran/50404] SIGSEGV in gfc_resolve_close
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50404
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #1 from kargl at gcc dot gnu.org 2011-09-15 15:47:33 UTC ---
Program received signal SIGSEGV, Segmentation fault.
0x004d17e9 in gfc_resolve_close (close=0x202007220)
at ../../gcc4x/gcc/fortran/io.c:2298
2298 if (close-unit-expr_type == EXPR_CONSTANT
(gdb) bt
#0 0x004d17e9 in gfc_resolve_close (close=0x202007220)
at ../../gcc4x/gcc/fortran/io.c:2298
#1 0x00501bbf in resolve_code (code=0x2020a6300, ns=0x2021bb200)
at ../../gcc4x/gcc/fortran/resolve.c:9382
#2 0x005028f9 in resolve_codes (ns=0x2021bb200)
at ../../gcc4x/gcc/fortran/resolve.c:13665
#3 0x00502a24 in gfc_resolve (ns=0x2021bb200)
at ../../gcc4x/gcc/fortran/resolve.c:13692
#4 0x004f5d04 in resolve_all_program_units ()
at ../../gcc4x/gcc/fortran/parse.c:4336
#5 gfc_parse_file () at ../../gcc4x/gcc/fortran/parse.c:4602
#6 0x0052cdce in gfc_be_parse_file ()
at ../../gcc4x/gcc/fortran/f95-lang.c:250
#7 0x008c806b in compile_file () at ../../gcc4x/gcc/toplev.c:548
#8 do_compile () at ../../gcc4x/gcc/toplev.c:1886
#9 0x008c8c95 in toplev_main (argc=2, argv=0x7fffd508)
at ../../gcc4x/gcc/toplev.c:1962
#10 0x004900dc in _start ()
(gdb) print close
$1 = (gfc_close *) 0x202007220
(gdb) print *close
$2 = {unit = 0x0, status = 0x0, iostat = 0x2020a6180, iomsg = 0x0, err = 0x0}
From f2003
C907 (R909) A file-unit-number shall be specified; if the optional
characters UNIT= are omitted, the file-unit-number shall be the
first item in the close-spec-list.
troutmask:sgk[256] gfc4x -c a.f
a.f:5.72:
close(iostat=i)
1
Error: CLOSE statement at (1) requires a UNIT number
Index: io.c
===
--- io.c(revision 178782)
+++ io.c(working copy)
@@ -2295,6 +2295,12 @@ gfc_resolve_close (gfc_close *close)
if (gfc_reference_st_label (close-err, ST_LABEL_TARGET) == FAILURE)
return FAILURE;
+ if (close-unit == NULL)
+{
+ gfc_error (CLOSE statement at %C requires a UNIT number);
+ return FAILURE;
+}
+
if (close-unit-expr_type == EXPR_CONSTANT
close-unit-ts.type == BT_INTEGER
mpz_sgn (close-unit-value.integer) 0)
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 --- Comment #4 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-09-15 16:48:37 UTC --- (In reply to comment #3) Thanks a lot! is there any chance to get those fixes into official git so we don't need to cummulate local patches? :) It looks like some libreoffice developers are monitoring this meta-bug. Issue 2) is already fixed: http://cgit.freedesktop.org/libreoffice/core/commit/?id=87891c1c8bb82904fd68c523cb1aa11ddcfaaa3d
[Bug target/50182] Performance degradation from gcc 4.1 (x86_64)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50182 --- Comment #13 from oleg at smolsky dot net 2011-09-15 16:53:26 UTC --- David, it looks like we are seeing different things with v4.7... See my comment 11 - I am still observing the slowdown. Do you have access to v4.1 and v4.6? Could you try reproducing my test please?
[Bug fortran/50407] compiler confused by .operator.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50407 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org 2011-09-15 16:55:12 UTC --- I believe the code is invalid due to the recursive IO. Don't have time now to verify this. gfortran is looking for a comma because it sees 2 in 2.ip.8 as a statement label. I think gfortran may be correct in its behavior.
[Bug c++/2316] g++ fails to overload on language linkage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316 --- Comment #34 from Marc Glisse marc.glisse at normalesup dot org 2011-09-15 16:53:33 UTC --- I posted a related demangler patch on gcc-patches a couple weeks ago, let me just link it from here so it doesn't get lost: http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00231.html
[Bug fortran/50420] New: [Coarray] lcobound doesn't accept coarray subcomponents
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50420 Bug #: 50420 Summary: [Coarray] lcobound doesn't accept coarray subcomponents Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: mik...@gcc.gnu.org This code is modified from coarray/alloc_comp_1.f90: type t integer :: i end type t type(t), allocatable :: a[:] allocate(a[3:*]) a%i = 7 if (a%i /= 7) call abort print *, lcobound(a%i) end With (patched) trunk, I get: f951: internal compiler error: in simplify_cobound, at fortran/simplify.c:3552
[Bug libgcj/50421] New: [4.7 Regression] GC Warning: Out of Memory! Returning NIL!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50421 Bug #: 50421 Summary: [4.7 Regression] GC Warning: Out of Memory! Returning NIL! Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org Host: hppa2.0w-hp-hpux11.11 Target: hppa2.0w-hp-hpux11.11 Build: hppa2.0w-hp-hpux11.11 Executing on host: /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/testsuite/ ../libtool --silent --tag=GCJ --mode=link /test/gnu/gcc/objdir/./gcc/gcj -B/test /gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/ -B/test/gnu/gcc/objdir/./gcc/ -B/ opt/gnu/gcc/gcc-4.7/hppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-4.7/hppa2.0w-h p-hpux11.11/lib/ -isystem /opt/gnu/gcc/gcc-4.7/hppa2.0w-hp-hpux11.11/include -is ystem /opt/gnu/gcc/gcc-4.7/hppa2.0w-hp-hpux11.11/sys-include --encoding=UTF-8 -B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/testsuite/../ /test/gnu/gc c/gcc/libjava/testsuite/libjava.lang/FileHandleGcTest.jar -w -no-install --mai n=FileHandleGcTest -O3 -g -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libjav a/.libs -lm -o /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/testsuite/Fi leHandleGcTest.exe(timeout = 300) PASS: FileHandleGcTest -O3 compilation from source set_ld_library_path_env_vars: ld_library_path=.:/test/gnu/gcc/objdir/hppa2.0w-hp -hpux11.11/./libjava/.libs invoke: /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/testsuite/FileHandleG cTest.exe Setting LD_LIBRARY_PATH to .:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libjav a/.libs:.:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libjava/.libs PASS: FileHandleGcTest -O3 execution - source compiled test PASS: FileHandleGcTest -O3 output - source compiled test set_ld_library_path_env_vars: ld_library_path=.:/test/gnu/gcc/objdir/hppa2.0w-hp -hpux11.11/./libjava/.libs Executing on host: /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/testsuite/ ../libtool --silent --tag=GCJ --mode=link /test/gnu/gcc/objdir/./gcc/gcj -B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/ -B/test/gnu/gcc/objdir/./gcc/ -B/opt/gnu/gcc/gcc-4.7/hppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-4.7/hppa2.0w-hp-hpux11.11/lib/ -isystem /opt/gnu/gcc/gcc-4.7/hppa2.0w-hp-hpux11.11/include -isystem /opt/gnu/gcc/gcc-4.7/hppa2.0w-hp-hpux11.11/sys-include--encoding=UTF-8 -B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/testsuite/../ /test/gnu/gcc/gcc/libjava/testsuite/libjava.lang/FileHandleGcTest.jar -w -no-install --main=FileHandleGcTest -O3 -findirect-dispatch -g -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libjava/.libs -lm -o /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/testsuite/FileHandleGcTest.exe (timeout = 300) PASS: FileHandleGcTest -O3 -findirect-dispatch compilation from source set_ld_library_path_env_vars: ld_library_path=.:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libjava/.libs invoke: /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/testsuite/FileHandleGcTest.exe Setting LD_LIBRARY_PATH to .:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libjava/.libs:.:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libjava/.libs GC Warning: Out of Memory! Returning NIL! GC Warning: Out of Memory! Returning NIL! WARNING: program timed out. FAIL: FileHandleGcTest -O3 -findirect-dispatch execution - source compiled test UNTESTED: FileHandleGcTest -O3 -findirect-dispatch output - source compiled test Similar fails: FAIL: PR19870_2 -O3 -findirect-dispatch execution - source compiled test FAIL: PR19921 -O3 -findirect-dispatch execution - source compiled test FAIL: PR29013 -O3 -findirect-dispatch execution - source compiled test FAIL: PR31264 -O3 -findirect-dispatch execution - source compiled test FAIL: PR7482 -O3 -findirect-dispatch execution - source compiled test FAIL: bclink -O3 execution - source compiled test FAIL: bclink -O3 -findirect-dispatch execution - source compiled test FAIL: initexc -O3 -findirect-dispatch execution - source compiled test FAIL: pr13107_2 -O3 -findirect-dispatch output - source compiled test FAIL: verify -O3 -findirect-dispatch execution - source compiled test
[Bug target/50182] Performance degradation from gcc 4.1 (x86_64)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50182 --- Comment #14 from davidxl xinliangli at gmail dot com 2011-09-15 17:28:10 UTC --- (In reply to comment #13) David, it looks like we are seeing different things with v4.7... See my comment 11 - I am still observing the slowdown. Do you have access to v4.1 and v4.6? Could you try reproducing my test please? Sorry for the delay -- I am pretty swamped these days (till mid October). I will try to look at the problem more then. David
