Re: Tree Browser
On Thu, May 13, 2010 at 11:45 PM, Diego Novillo dnovi...@google.com wrote: On 5/4/10 15:11 , Wolfgang kaifler wrote: (gdb) p browse_tree (current_function_decl) No symbol browse_tree in current context. (gdb) What i'm doing wrong? Any ideas? The tree browser code has bitrotted to the point that I think it should be removed, unfortunately. It's a great candidate to be re-implemented as a plugin. I know this does not help you much. Sorry. In this case, it is likely that since there are no calls to browse_tree anywhere in the code, the linker is removing it. Are you building cc1 with -O0? It probably also can be re-implemented as gdb python script? Richard. Diego.
Re: Machine description question
Hi Bengfeng, Changing my instruction patterns similar to the ones that you sent does get over the correctness issue. Setting the imaginary register explicitly this way and adding those extra unspec patterns does seem to work. But, performance-wise, it still doesn't give me anything. Did you decide to use these patterns (instead of the simpler unspec_volatile ones) for performance reasons? Does using these patterns give you anything? Cheers Hari Bingfeng Mei wrote: Hari, Here are some patterns similar to yours. (define_insn putbx [(set (reg:BXBC R_BX) (unspec:BXBC [(match_operand:QI 0 firepath_register vr)] UNSPEC_BXM)) (unspec:BXBC [(reg:BXBC R_BX)] UNSPEC_BX)] --- Important to avoid some wrong optimization (Maybe DCE, I couldn't remember clearly) define_insn getbx [(set (reg:BXBC R_BX) (unspec:BXBC [(reg:BXBC R_BX)] UNSPEC_BX)) Artifical dependency (set (match_operand:SI 0 register_operand =r) (unspec:SI [(reg:BXBC R_BX)]UNSPEC_BXM)) (unspec:BXBC [(reg:BXBC R_BX)] UNSPEC_BX)] Important to avoid some optimization. Our port is still porivate and not in mainline. Cheers, Bingfeng -Original Message- From: Hariharan Sandanagobalane [mailto:harihar...@picochip.com] Sent: 13 May 2010 10:17 To: Bingfeng Mei Cc: gcc@gcc.gnu.org Subject: Re: Machine description question The patterns for PUT/GET were ; Scalar Put instruction. (define_insn commsPut [(unspec_volatile [(match_operand:HI 0 const_int_operand ) (match_operand:SI 1 register_operand r)] UNSPEC_PUT)] PUT %R1,%0\t// PORT(%0) := %R1 [(set_attr type comms) (set_attr length 2)]) (define_insn commsGet [(set (match_operand:SI 0 register_operand =r) (unspec_volatile:SI [(match_operand:HI 1 immediate_operand n)] UNSPEC_GET))] GET %1,%R0\t// %R0 := PORT(%1) [(set_attr type comms) (set_attr length 2)]) I changed them to ; Scalar Put instruction. (define_insn commsPut [(unspec [(match_operand:HI 0 const_int_operand ) (match_operand:SI 1 register_operand r)] UNSPEC_PUT) (use (reg:HI DUMMY_COMMN_REGNUM)) (clobber (reg:HI DUMMY_COMMN_REGNUM))] PUT %R1,%0\t// PORT(%0) := %R1 [(set_attr type comms) (set_attr length 2)]) ; Simple scalar get. (define_insn commsGet [(set (match_operand:SI 0 register_operand =r) (unspec:SI [(match_operand:HI 1 immediate_operand n)] UNSPEC_GET)) (use (reg:HI DUMMY_COMMN_REGNUM)) (clobber (reg:HI DUMMY_COMMN_REGNUM))] GET %1,%R0\t// %R0 := PORT(%1) [(set_attr type comms) (set_attr length 2)]) As for the DUMMY_COMMN_REGNUM, I just defined this as a FIXED_REGISTER and bumped up FIRST_PSUEDO_REG. Actually, there is one more problem i faced (other than performance). The code generated using unspec's was just plain wrong. The unspec pattern that i was using for GET, which was inside a loop, was being hoisted out of the loop by the loop optimizer. I guess i should have seen this coming, since unspec is just machine-specific operation and the optimizer probably rightly assumes that multiple execution of this with same parameters would result in same value being produced. This obviously is not the case for these communication instructions. Do you have your code to do this using unspec in gcc mainline? Can you point me to that, please? Thanks Hari Bingfeng Mei wrote: How do you define your imaginary register in target.h? Can you post one example of your instruction pattern? Bingfeng -Original Message- From: Hariharan Sandanagobalane [mailto:harihar...@picochip.com] Sent: 12 May 2010 16:40 To: Bingfeng Mei Cc: gcc@gcc.gnu.org Subject: Re: Machine description question Thanks for your help BingFeng. I gave this a go and ended up with worse code (and worse memory usage) than before. I started with this experiment because of the compilers All virtual registers are assumed to be used and clobbered by unspec_volatile rule. The get/put instructions read/write to registers and the virtual register assigned for them interferes with all the virtual registers in the function. So, they were highly likely to be spilled and use stack instead. I wanted to try to avoid this by the introduction of unspec's and use of imaginary registers. But, the virtual registers that are involved in unspec patterns with these imaginary registers still seem to be marked to interfere with all the virtual registers. Is that to be expected? Am i missing something obvious here? Regards Hari Bingfeng Mei wrote: Our architecture has the similar resource, and we use the first approach by creating an imaginary register and dependency between these instructions, i.e.,
GIMPLE types merging in LTO compiler
Hi, most of the remaining warnings issued by the LTO compiler on object files compiled from Ada are caused by a small flaw in the GIMPLE types merging process: it is done before symbols are merged so compatible types (typically domain types of arrays) whose distinguishing features depend on symbols (variable bounds for domain types of arrays) aren't recognized as such if the first type references one instance of the symbol (e.g. the prevailing one) and the second type references another instance of the same symbol. What's the best approach to addressing this? Thanks in advance. -- Eric Botcazou
RE: Machine description question
Yes, we use this instead of unspec_volatile out of performance concern. Our target is a VLIW processor, so there is more opportunities to move instructions around. Did you observe any instruction that should be moved but not? Cheers, Bingfeng -Original Message- From: Hariharan Sandanagobalane [mailto:harihar...@picochip.com] Sent: 14 May 2010 12:26 To: Bingfeng Mei Cc: gcc@gcc.gnu.org Subject: Re: Machine description question Hi Bengfeng, Changing my instruction patterns similar to the ones that you sent does get over the correctness issue. Setting the imaginary register explicitly this way and adding those extra unspec patterns does seem to work. But, performance-wise, it still doesn't give me anything. Did you decide to use these patterns (instead of the simpler unspec_volatile ones) for performance reasons? Does using these patterns give you anything? Cheers Hari Bingfeng Mei wrote: Hari, Here are some patterns similar to yours. (define_insn putbx [(set (reg:BXBC R_BX) (unspec:BXBC [(match_operand:QI 0 firepath_register vr)] UNSPEC_BXM)) (unspec:BXBC [(reg:BXBC R_BX)] UNSPEC_BX)] --- Important to avoid some wrong optimization (Maybe DCE, I couldn't remember clearly) define_insn getbx [(set (reg:BXBC R_BX) (unspec:BXBC [(reg:BXBC R_BX)] UNSPEC_BX)) Artifical dependency (set (match_operand:SI 0 register_operand =r) (unspec:SI [(reg:BXBC R_BX)]UNSPEC_BXM)) (unspec:BXBC [(reg:BXBC R_BX)] UNSPEC_BX)] Important to avoid some optimization. Our port is still porivate and not in mainline. Cheers, Bingfeng -Original Message- From: Hariharan Sandanagobalane [mailto:harihar...@picochip.com] Sent: 13 May 2010 10:17 To: Bingfeng Mei Cc: gcc@gcc.gnu.org Subject: Re: Machine description question The patterns for PUT/GET were ; Scalar Put instruction. (define_insn commsPut [(unspec_volatile [(match_operand:HI 0 const_int_operand ) (match_operand:SI 1 register_operand r)] UNSPEC_PUT)] PUT %R1,%0\t// PORT(%0) := %R1 [(set_attr type comms) (set_attr length 2)]) (define_insn commsGet [(set (match_operand:SI 0 register_operand =r) (unspec_volatile:SI [(match_operand:HI 1 immediate_operand n)] UNSPEC_GET))] GET %1,%R0\t// %R0 := PORT(%1) [(set_attr type comms) (set_attr length 2)]) I changed them to ; Scalar Put instruction. (define_insn commsPut [(unspec [(match_operand:HI 0 const_int_operand ) (match_operand:SI 1 register_operand r)] UNSPEC_PUT) (use (reg:HI DUMMY_COMMN_REGNUM)) (clobber (reg:HI DUMMY_COMMN_REGNUM))] PUT %R1,%0\t// PORT(%0) := %R1 [(set_attr type comms) (set_attr length 2)]) ; Simple scalar get. (define_insn commsGet [(set (match_operand:SI 0 register_operand =r) (unspec:SI [(match_operand:HI 1 immediate_operand n)] UNSPEC_GET)) (use (reg:HI DUMMY_COMMN_REGNUM)) (clobber (reg:HI DUMMY_COMMN_REGNUM))] GET %1,%R0\t// %R0 := PORT(%1) [(set_attr type comms) (set_attr length 2)]) As for the DUMMY_COMMN_REGNUM, I just defined this as a FIXED_REGISTER and bumped up FIRST_PSUEDO_REG. Actually, there is one more problem i faced (other than performance). The code generated using unspec's was just plain wrong. The unspec pattern that i was using for GET, which was inside a loop, was being hoisted out of the loop by the loop optimizer. I guess i should have seen this coming, since unspec is just machine-specific operation and the optimizer probably rightly assumes that multiple execution of this with same parameters would result in same value being produced. This obviously is not the case for these communication instructions. Do you have your code to do this using unspec in gcc mainline? Can you point me to that, please? Thanks Hari Bingfeng Mei wrote: How do you define your imaginary register in target.h? Can you post one example of your instruction pattern? Bingfeng -Original Message- From: Hariharan Sandanagobalane [mailto:harihar...@picochip.com] Sent: 12 May 2010 16:40 To: Bingfeng Mei Cc: gcc@gcc.gnu.org Subject: Re: Machine description question Thanks for your help BingFeng. I gave this a go and ended up with worse code (and worse memory usage) than before. I started with this experiment because of the compilers All virtual registers are assumed to be used and clobbered by unspec_volatile rule. The get/put instructions read/write to registers and the virtual register assigned for them interferes with all the virtual registers in the function. So, they were
Re: Machine description question
Ours is a vliw processor too, but my focus was on register allocation. Unfortunately, the instruction with unspec is still marked to interfere with all virtual registers and hence gets spilled. I was hoping the one with unspecs might do better there, but no change there. So, i end up with similar performance to the unspec_volatile version. Thanks for your help Cheers Hari Bingfeng Mei wrote: Yes, we use this instead of unspec_volatile out of performance concern. Our target is a VLIW processor, so there is more opportunities to move instructions around. Did you observe any instruction that should be moved but not? Cheers, Bingfeng -Original Message- From: Hariharan Sandanagobalane [mailto:harihar...@picochip.com] Sent: 14 May 2010 12:26 To: Bingfeng Mei Cc: gcc@gcc.gnu.org Subject: Re: Machine description question Hi Bengfeng, Changing my instruction patterns similar to the ones that you sent does get over the correctness issue. Setting the imaginary register explicitly this way and adding those extra unspec patterns does seem to work. But, performance-wise, it still doesn't give me anything. Did you decide to use these patterns (instead of the simpler unspec_volatile ones) for performance reasons? Does using these patterns give you anything? Cheers Hari Bingfeng Mei wrote: Hari, Here are some patterns similar to yours. (define_insn putbx [(set (reg:BXBC R_BX) (unspec:BXBC [(match_operand:QI 0 firepath_register vr)] UNSPEC_BXM)) (unspec:BXBC [(reg:BXBC R_BX)] UNSPEC_BX)] --- Important to avoid some wrong optimization (Maybe DCE, I couldn't remember clearly) define_insn getbx [(set (reg:BXBC R_BX) (unspec:BXBC [(reg:BXBC R_BX)] UNSPEC_BX)) Artifical dependency (set (match_operand:SI 0 register_operand =r) (unspec:SI [(reg:BXBC R_BX)]UNSPEC_BXM)) (unspec:BXBC [(reg:BXBC R_BX)] UNSPEC_BX)] Important to avoid some optimization. Our port is still porivate and not in mainline. Cheers, Bingfeng -Original Message- From: Hariharan Sandanagobalane [mailto:harihar...@picochip.com] Sent: 13 May 2010 10:17 To: Bingfeng Mei Cc: gcc@gcc.gnu.org Subject: Re: Machine description question The patterns for PUT/GET were ; Scalar Put instruction. (define_insn commsPut [(unspec_volatile [(match_operand:HI 0 const_int_operand ) (match_operand:SI 1 register_operand r)] UNSPEC_PUT)] PUT %R1,%0\t// PORT(%0) := %R1 [(set_attr type comms) (set_attr length 2)]) (define_insn commsGet [(set (match_operand:SI 0 register_operand =r) (unspec_volatile:SI [(match_operand:HI 1 immediate_operand n)] UNSPEC_GET))] GET %1,%R0\t// %R0 := PORT(%1) [(set_attr type comms) (set_attr length 2)]) I changed them to ; Scalar Put instruction. (define_insn commsPut [(unspec [(match_operand:HI 0 const_int_operand ) (match_operand:SI 1 register_operand r)] UNSPEC_PUT) (use (reg:HI DUMMY_COMMN_REGNUM)) (clobber (reg:HI DUMMY_COMMN_REGNUM))] PUT %R1,%0\t// PORT(%0) := %R1 [(set_attr type comms) (set_attr length 2)]) ; Simple scalar get. (define_insn commsGet [(set (match_operand:SI 0 register_operand =r) (unspec:SI [(match_operand:HI 1 immediate_operand n)] UNSPEC_GET)) (use (reg:HI DUMMY_COMMN_REGNUM)) (clobber (reg:HI DUMMY_COMMN_REGNUM))] GET %1,%R0\t// %R0 := PORT(%1) [(set_attr type comms) (set_attr length 2)]) As for the DUMMY_COMMN_REGNUM, I just defined this as a FIXED_REGISTER and bumped up FIRST_PSUEDO_REG. Actually, there is one more problem i faced (other than performance). The code generated using unspec's was just plain wrong. The unspec pattern that i was using for GET, which was inside a loop, was being hoisted out of the loop by the loop optimizer. I guess i should have seen this coming, since unspec is just machine-specific operation and the optimizer probably rightly assumes that multiple execution of this with same parameters would result in same value being produced. This obviously is not the case for these communication instructions. Do you have your code to do this using unspec in gcc mainline? Can you point me to that, please? Thanks Hari Bingfeng Mei wrote: How do you define your imaginary register in target.h? Can you post one example of your instruction pattern? Bingfeng -Original Message- From: Hariharan Sandanagobalane [mailto:harihar...@picochip.com] Sent: 12 May 2010 16:40 To: Bingfeng Mei Cc: gcc@gcc.gnu.org Subject: Re: Machine description question Thanks for your help BingFeng. I gave this a go and ended up with worse code (and worse memory usage) than before. I started with this
Re: GIMPLE types merging in LTO compiler
On Fri, May 14, 2010 at 1:24 PM, Eric Botcazou ebotca...@adacore.com wrote: Hi, most of the remaining warnings issued by the LTO compiler on object files compiled from Ada are caused by a small flaw in the GIMPLE types merging process: it is done before symbols are merged so compatible types (typically domain types of arrays) whose distinguishing features depend on symbols (variable bounds for domain types of arrays) aren't recognized as such if the first type references one instance of the symbol (e.g. the prevailing one) and the second type references another instance of the same symbol. What's the best approach to addressing this? Thanks in advance. Ugh. This presents a chicken-and-egg problem to symbol resolution and type-merging. To be clear, the issue is sth like unit1 - int size; int a[size]; unit2 -- extern int size; extern a[size]; ? And you get the a's merged but a diagnostic about mismatched types? One way to fix this would be to simply detect the situation and never issue a diagnostic. Another way would be to delay the diagnostics until after all types and symbols are merged. The natural place for this would be lto_symtab_merge_cgraph_nodes () which already is after type merging and still has all candidates available. Richard. -- Eric Botcazou
Re: Tree Browser
On Fri, May 14, 2010 at 07:18, Richard Guenther richard.guent...@gmail.com wrote: It probably also can be re-implemented as gdb python script? Really? Wicked. I like that. Diego.
GCC seem output error messages in UTF8.Dev-cpp cant show it.Can this change in target declaration ?
Hi I compile the GCC4.5.0 on cygwin and when i use it in cygwin shell, all is ok. But when i use it on dev-cpp the output contain some crap chars, because GCC output utf8 error messages Is there a way to avoid that GCC output text in utf8 ? Here is dev-cpp source.Its since long time not fortherdevelop.I think it cant output UTF8 text and nobody enhance it.but its a good IDE that can easy use for crosscompile and use diffrent compiler sets. http://sourceforge.net/projects/dev-cpp/ older GCC compiler have no problems. Or maybe somebody can suggest a better IDE for windows that let easy choose in GUI a Target Compiler Bye
GCC 4.3.5 Status Report (2010-05-14)
Status == The 4.3 branch is now frozen for the preparation of a 4.3.5 release. The branch is ageing and changes to it should be limited to obviously correct changes. In the past month I have skimmed through the bugs that were fixed for 4.4 and backported a bunch of obvious regression fixes. At the same time I closed a bunch of regressions as not going to be fixed on the 4.3 branch. Quality Data Priority # Change from Last Report --- --- P10 P2 104 - 28 P30 - 1 --- --- Total 104 + 19 Previous Report === http://gcc.gnu.org/ml/gcc/2009-08/msg00066.html I will continue to send status reports for the 4.3 branch where applicable.
Re: GCC 4.3.5 Status Report (2010-05-14)
On Fri, May 14, 2010 at 3:04 PM, Richard Guenther rguent...@suse.de wrote: Priority # Change from Last Report --- --- P1 0 P2 104 - 28 P3 0 - 1 --- --- Total 104 + 19 Interesting math... :-) Ciao! Steven
Re: GCC 4.3.5 Status Report (2010-05-14)
On Fri, 14 May 2010, Steven Bosscher wrote: On Fri, May 14, 2010 at 3:04 PM, Richard Guenther rguent...@suse.de wrote: Priority # Change from Last Report --- --- P1 0 P2 104 - 28 P3 0 - 1 --- --- Total 104 + 19 Interesting math... :-) Whoops ;) Obviously a non-updated column from a cutpaste template. Should be -29 in the bottommost right. Richard.
Re: lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:549
On 04/25/2010 01:24 PM, Toon Moene wrote:
Richard Guenther wrote:
[ Concerning this assert ]
It is checking that for one symbol we only have one definition.
You are using -fuse-linker-plugin?
Indeed, I do (all of our code ends up in libraries - .a files - so I
have to, to make -flto -fwhole-program be meaningful).
Is it a problem with COMMON ? Those typically have umpteen definitions,
which all have to match ...
I decided to change the following in lto-symtab.c to help me pinpoint
this culprit:
Index: lto-symtab.c
===
--- lto-symtab.c(revision 159389)
+++ lto-symtab.c(working copy)
@@ -603,8 +603,15 @@
/* Assert it's the only one. */
if (prevailing)
for (e = prevailing-next; e; e = e-next)
- gcc_assert (e-resolution != LDPR_PREVAILING_DEF_IRONLY
- e-resolution != LDPR_PREVAILING_DEF);
+ {
+ if (!(e-resolution != LDPR_PREVAILING_DEF_IRONLY
+ e-resolution != LDPR_PREVAILING_DEF))
+{
+ debug_tree(prevailing-decl);
+ debug_tree(e-decl);
+ gcc_assert(0);
+}
+ }
/* If there's not a prevailing symbol yet it's an external reference.
Happens a lot during ltrans. Choose the first symbol with a
That resulted in the following messages in my compile log:
function_decl 0x2b9d3a4af900 convect_satmixratio
type function_type 0x2b9d3a471000
type void_type 0x2b9d3548dd20 VOID
align 8 symtab 0 alias set -1 canonical type 0x2b9d3548dd20
pointer_to_this pointer_type 0x2b9d3548ddc8
QI
size integer_cst 0x2b9d3547e758 constant 8
unit size integer_cst 0x2b9d3547e780 constant 1
align 8 symtab 0 alias set -1 canonical type 0x2b9d3a471000
public external QI file bkfconv.f90 line 7712 col 0 align 8
function_decl 0x2b9d3a4af200 convect_satmixratio
type function_type 0x2b9d3a471000
type void_type 0x2b9d3548dd20 VOID
align 8 symtab 0 alias set -1 canonical type 0x2b9d3548dd20
pointer_to_this pointer_type 0x2b9d3548ddc8
QI
size integer_cst 0x2b9d3547e758 constant 8
unit size integer_cst 0x2b9d3547e780 constant 1
align 8 symtab 0 alias set -1 canonical type 0x2b9d3a471000
public external QI file bkfconv.f90 line 6525 col 0 align 8
lto1: internal compiler error: in lto_symtab_merge_decls_1, at
lto-symtab.c:612
bkconv.f90:7712:
7711 !
7712CALL CONVECT_SATMIXRATIO( KLON, ZWORK1, ZTELCL, ZWORK3,
ZLV, ZLS, ZCPH )
bkfconv.f90:6525:
6524 !
6525 CALL CONVECT_SATMIXRATIO( KLON, ZPLCL, ZTLCL, ZWORK1, ZLV,
ZWORK2, ZCPH )
The only thing I can see is that CONVECT_SATMIXRATIO is called from two
different routines in one file (bkfconv.f90:6260 CONVECT_TRIGGER_SHAL
and bkfconv.f90:7258 CONVECT_CLOSURE_SHAL)
Any suggestions how I can further chase this down ? Are the arguments
to the subroutine an issue (kind, array size, etc.) ?
Thanks in advance,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html#Fortran
Re: lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:549
On Fri, May 14, 2010 at 3:34 PM, Toon Moene t...@moene.org wrote:
On 04/25/2010 01:24 PM, Toon Moene wrote:
Richard Guenther wrote:
[ Concerning this assert ]
It is checking that for one symbol we only have one definition.
You are using -fuse-linker-plugin?
Indeed, I do (all of our code ends up in libraries - .a files - so I
have to, to make -flto -fwhole-program be meaningful).
Is it a problem with COMMON ? Those typically have umpteen definitions,
which all have to match ...
I decided to change the following in lto-symtab.c to help me pinpoint this
culprit:
Index: lto-symtab.c
===
--- lto-symtab.c (revision 159389)
+++ lto-symtab.c (working copy)
@@ -603,8 +603,15 @@
/* Assert it's the only one. */
if (prevailing)
for (e = prevailing-next; e; e = e-next)
- gcc_assert (e-resolution != LDPR_PREVAILING_DEF_IRONLY
- e-resolution != LDPR_PREVAILING_DEF);
+ {
+ if (!(e-resolution != LDPR_PREVAILING_DEF_IRONLY
+ e-resolution != LDPR_PREVAILING_DEF))
+ {
+ debug_tree(prevailing-decl);
+ debug_tree(e-decl);
+ gcc_assert(0);
+ }
+ }
/* If there's not a prevailing symbol yet it's an external reference.
Happens a lot during ltrans. Choose the first symbol with a
That resulted in the following messages in my compile log:
function_decl 0x2b9d3a4af900 convect_satmixratio
type function_type 0x2b9d3a471000
type void_type 0x2b9d3548dd20 VOID
align 8 symtab 0 alias set -1 canonical type 0x2b9d3548dd20
pointer_to_this pointer_type 0x2b9d3548ddc8
QI
size integer_cst 0x2b9d3547e758 constant 8
unit size integer_cst 0x2b9d3547e780 constant 1
align 8 symtab 0 alias set -1 canonical type 0x2b9d3a471000
public external QI file bkfconv.f90 line 7712 col 0 align 8
function_decl 0x2b9d3a4af200 convect_satmixratio
type function_type 0x2b9d3a471000
type void_type 0x2b9d3548dd20 VOID
align 8 symtab 0 alias set -1 canonical type 0x2b9d3548dd20
pointer_to_this pointer_type 0x2b9d3548ddc8
QI
size integer_cst 0x2b9d3547e758 constant 8
unit size integer_cst 0x2b9d3547e780 constant 1
align 8 symtab 0 alias set -1 canonical type 0x2b9d3a471000
public external QI file bkfconv.f90 line 6525 col 0 align 8
lto1: internal compiler error: in lto_symtab_merge_decls_1, at
lto-symtab.c:612
bkconv.f90:7712:
7711 !
7712 CALL CONVECT_SATMIXRATIO( KLON, ZWORK1, ZTELCL, ZWORK3, ZLV,
ZLS, ZCPH )
bkfconv.f90:6525:
6524 !
6525 CALL CONVECT_SATMIXRATIO( KLON, ZPLCL, ZTLCL, ZWORK1, ZLV,
ZWORK2, ZCPH )
The only thing I can see is that CONVECT_SATMIXRATIO is called from two
different routines in one file (bkfconv.f90:6260 CONVECT_TRIGGER_SHAL and
bkfconv.f90:7258 CONVECT_CLOSURE_SHAL)
Any suggestions how I can further chase this down ? Are the arguments to
the subroutine an issue (kind, array size, etc.) ?
No, the lto-plugin or gold provides you with broken symbol resolution.
Try 1) update gold, 2) file a bugreport and CC Ian and Cary.
Richard.
Thanks in advance,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html#Fortran
GCC 4.3.5 Release Candidate available from gcc.gnu.org
A release canidate for GCC 4.3.5 is available from ftp://gcc.gnu.org/pub/gcc/snapshots/4.3.5-RC-20100514 and shortly its mirrors. It has been generated from SVN revision 159394. I have sofar bootstrapped and tested the release candidate on x86_64-unknown-linux-gnu. Please test it and report any issues to bugzilla. The branch remains frozen and all checkins until after the final release of GCC 4.3.5 require explicit RM approval. If all goes well, I'd like to release 4.3.5 next week. Richard. -- Richard Guenther rguent...@suse.de Novell / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex
Re: arm-elf float-abi defaults...
I am strongly of the opinion that the right way to do this is to have the compiler generate appropriate directives in the assembly files it generates -- and to have users do the same. Relying on the defaults is just too dangerous. So... where should this go?
Re: arm-elf float-abi defaults...
DJ Delorie wrote: I am strongly of the opinion that the right way to do this is to have the compiler generate appropriate directives in the assembly files it generates -- and to have users do the same. Relying on the defaults is just too dangerous. So... where should this go? The compiler should generate a pseudo-op that is processed by the assembler. If the right pseudo-op doesn't already exist, it needs to be added to both the assembler and compiler. I thought this stuff already existed in arm-eabi toolchains. If it doesn't exist in arm-elf, then you should be able to use it there too. But, of course, arm-elf is really a dead ABI at this point... -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: GCC seem output error messages in UTF8.Dev-cpp cant show it.Can this change in target declaration ?
On 14 May 2010 13:01, Bernd Roesch wrote: Hi I compile the GCC4.5.0 on cygwin and when i use it in cygwin shell, all is ok. But when i use it on dev-cpp the output contain some crap chars, because GCC output utf8 error messages Is there a way to avoid that GCC output text in utf8 ? This message is inappropriate on this list, it would have been more relevant on the gcc-help mailing list. GCC uses the LC_MESSAGES environment variable to determine the language for diagnostics, and Cygwin behaves as described at http://www.cygwin.com/cygwin-ug-net/setup-locale.html so modifying LC_ALL or LANG should allow you to disable utf-8 in diagnostics.
Re: GIMPLE types merging in LTO compiler
Ugh. This presents a chicken-and-egg problem to symbol resolution and type-merging. To be clear, the issue is sth like unit1 - int size; int a[size]; unit2 -- extern int size; extern a[size]; ? And you get the a's merged but a diagnostic about mismatched types? Yes, exactly. One way to fix this would be to simply detect the situation and never issue a diagnostic. Another way would be to delay the diagnostics until after all types and symbols are merged. The natural place for this would be lto_symtab_merge_cgraph_nodes () which already is after type merging and still has all candidates available. Is suppressing the diagnostic sufficient? Will the two types be merged after the symbols are unified, or does that not matter at all? -- Eric Botcazou
Re: GIMPLE types merging in LTO compiler
On Fri, May 14, 2010 at 9:33 PM, Eric Botcazou ebotca...@adacore.com wrote: Ugh. This presents a chicken-and-egg problem to symbol resolution and type-merging. To be clear, the issue is sth like unit1 - int size; int a[size]; unit2 -- extern int size; extern a[size]; ? And you get the a's merged but a diagnostic about mismatched types? Yes, exactly. One way to fix this would be to simply detect the situation and never issue a diagnostic. Another way would be to delay the diagnostics until after all types and symbols are merged. The natural place for this would be lto_symtab_merge_cgraph_nodes () which already is after type merging and still has all candidates available. Is suppressing the diagnostic sufficient? Will the two types be merged after the symbols are unified, or does that not matter at all? The types will not be unified. We are currently inserting VIEW_CONVERT_EXPRs to make the IL type verification happy, but in the end it will cause broken type-based alias info and thus may trigger miscompiles. I am in the process of fixing both pieces (avoid the V_C_E by using MEM_REF and avoid the miscompile by separating TBAA types from the IL types). Richard. -- Eric Botcazou
Re: arm-elf float-abi defaults...
The compiler should generate a pseudo-op that is processed by the assembler. If the right pseudo-op doesn't already exist, it needs to be added to both the assembler and compiler. The assembler has pseudo-s for .fpu which says what kind of FPU it has, but the generic hard/soft choice is only via command line option. I thought this stuff already existed in arm-eabi toolchains. If it doesn't exist in arm-elf, then you should be able to use it there too. The EABI toolchains use eabi-specific pseudos to set the .fpu. But, of course, arm-elf is really a dead ABI at this point... hmmm... if it's dead enough, it becomes a moot point, doesn't it?
data type 'struct loop' in MELT
Hi, I am just working on integrating the struct loop as a boxed type in MELT. I had a short discussion with Basile on the basic definitions and changes to be made in melt-runtime.*. One problem was the garbage collection of the loop structure but it turned out to that I misjudged this garbage collection stuff. I recently managed to get this to work. Up to now I have basic support up and running. The hash map to the loop is missing and I have not figured out yet what I need it for, but Basile mentioned it to be necessary to reliably attach data to the loop data type. So help with this hash map stuff would be welcome. I will send the patch as soon as I have completed the that point. Regards, Michael
Re: arm-elf float-abi defaults...
DJ Delorie wrote: I thought this stuff already existed in arm-eabi toolchains. If it doesn't exist in arm-elf, then you should be able to use it there too. The EABI toolchains use eabi-specific pseudos to set the .fpu. Yes, but presumably you could make those pseudo-ops ARM-specific, rather than EABI specific? But, of course, arm-elf is really a dead ABI at this point... hmmm... if it's dead enough, it becomes a moot point, doesn't it? It's pretty dead. Richard Earnshaw recently suggested deprecating arm-elf in GCC 4.6. I think that's reasonable; most of the major operating systems (not just GNU/Linux, but embedded operating systems too) have switched to the EABI, not just for compatibility with one another, but because it's technically superior. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: arm-elf float-abi defaults...
Yes, but presumably you could make those pseudo-ops ARM-specific, rather than EABI specific? Could, but gcc doesn't always know the specific .fpu. I imagine version-sync nightmares too, so IMHO we should either do a command-line thing from gcc, or just forget it if EABI works.
Re: arm-elf float-abi defaults...
DJ Delorie wrote: Yes, but presumably you could make those pseudo-ops ARM-specific, rather than EABI specific? Could, but gcc doesn't always know the specific .fpu. I imagine version-sync nightmares too, so IMHO we should either do a command-line thing from gcc, or just forget it if EABI works. DJ, I don't have intimate knowledge of these bits, but I don't see how GCC's knowledge of FPU is, or should be, EABI-specific. I think you should start by looking at the EABI behavior, and seeing if you think it's problematic. If it isn't, then you can either punt on arm-elf, or enable some EABI functionality there. If, on the other hand, you think there's a problem when using the EABI, then we should talk about how to solve it. Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: arm-elf float-abi defaults...
If it isn't, then you can either punt on arm-elf, or enable some EABI functionality there. If, on the other hand, you think there's a problem when using the EABI, then we should talk about how to solve it. EABI works fine, we're just working through our array of things-to-be-tested and arm-elf was failing due to multilib mismatches.
Re: GIMPLE types merging in LTO compiler
On Fri, May 14, 2010 at 9:33 PM, Eric Botcazou ebotca...@adacore.com wrote: Ugh. This presents a chicken-and-egg problem to symbol resolution and type-merging. To be clear, the issue is sth like unit1 - int size; int a[size]; unit2 -- extern int size; extern a[size]; ? And you get the a's merged but a diagnostic about mismatched types? Yes, exactly. One way to fix this would be to simply detect the situation and never issue a diagnostic. Another way would be to delay the diagnostics until after all types and symbols are merged. The natural place for this would be lto_symtab_merge_cgraph_nodes () which already is after type merging and still has all candidates available. Is suppressing the diagnostic sufficient? Will the two types be merged after the symbols are unified, or does that not matter at all? The types will not be unified. We are currently inserting VIEW_CONVERT_EXPRs to make the IL type verification happy, but in the end it will cause broken type-based alias info and thus may trigger miscompiles. I am in the process of fixing both pieces (avoid the V_C_E by using MEM_REF and avoid the miscompile by separating TBAA types from the IL types). Also while working on this, please keep in mind that for data layout optimization we desperately need to have all accesses to the same memory object to have same type so we can rewrite it. ipa-struct-reorg is currently doing some pretty lame type combining based on type names for --combine, but we need sane framework for this. Honza
Re: arm-elf float-abi defaults...
On Fri, 14 May 2010, Mark Mitchell wrote: But, of course, arm-elf is really a dead ABI at this point... hmmm... if it's dead enough, it becomes a moot point, doesn't it? It's pretty dead. Richard Earnshaw recently suggested deprecating arm-elf in GCC 4.6. I think that's reasonable; most of the major operating systems (not just GNU/Linux, but embedded operating systems too) have switched to the EABI, not just for compatibility with one another, but because it's technically superior. I don't think VxWorks has yet switched to EABI. In previous discussions on the gcc list I've suggested that the RTEMS configuration ought to switch, but it hasn't yet. If the BSDs are using EABI, their configurations in FSF GCC haven't been updated accordingly. (All the many RTOSes without special configurations in GCC may have switched from arm-elf to arm-eabi, of course.) -- Joseph S. Myers jos...@codesourcery.com
Re: data type 'struct loop' in MELT
On 05/14/2010 10:27 PM, Michael Raitza wrote:
Up to now I have basic support up and running. The hash map to the loop
is missing and I have not figured out yet what I need it for, but Basile
mentioned it to be necessary to reliably attach data to the loop data
type.
Actually, this is not really MELT specific but also concerns any plugin.
As a general case, most ( probably all) GCC data structures cannot be
extended by plugins. So, for instance, a plugin cannot add its own field
to the loop data. Likewise, another plugin cannot add a field to any
gimple data structure. (More generally, most GCC data are not object
oriented and cannot be extended by plugins).
So plugins ( MELT extensions) have to associate information to existing
GCC data elsewhere. In MELT, there is some mechanism to build hash
tables associating some main GCC data (gimple, tree, edge...) to
arbitary MELT values.
Thanks for your interest in MELT.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
[Bug objc++/43689] [4.6 Regression] const-str-5/6 fails
--- Comment #1 from iains at gcc dot gnu dot org 2010-05-14 06:22 --- see: http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01030.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43689
[Bug inline-asm/43998] inline assembler: can't set clobbering for input register
--- Comment #11 from socketpair at gmail dot com 2010-05-14 06:31 --- Suppose this: volatile int x; asm(something::a (1)) x=1; the compiler may think that something do not modify eax. So next assignment may use eax ( mov eax, x ). So, it does not make sense to have it as a clobber is not correct. does not it ? - And the second, Because the way the constraints are implemented inside GCC, an input constraint cannot overlap with a clobber. - It definitely the bug. -- socketpair at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43998
[Bug objc/44125] [4.6 Regression] const-str-9 fails.
--- Comment #1 from iains at gcc dot gnu dot org 2010-05-14 06:39 --- r159321 caused this. I think this is a case where we are generating initialization of a class - maybe we're not marking something the way that is expected? ccing Jan. -- iains at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at ucw dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44125
[Bug debug/44126] wrong location description for DW_AT_vtable_elem_location
--- Comment #3 from dodji at gcc dot gnu dot org 2010-05-14 06:41 --- Subject: Re: wrong location description for DW_AT_vtable_elem_location Dodji, want to look at this? Sure. Like, Jakub said, we need to synchronize with GDB. I'll test Jakub's patch ASAP and push the change when GDB is ready to consume it then. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44126
[Bug c++/44108] [4.6 Regression] -Wunused-but-set-variable does not consider array sizing use of a const variable
-- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-14 06:42:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44108
[Bug objc/44125] [4.6 Regression] const-str-9 fails.
--- Comment #2 from iains at gcc dot gnu dot org 2010-05-14 06:42 --- the working output (const-str-9.s) is: .lazy_reference .objc_class_name_NSConstantString .comm __NSConstantStringClassReference,4,2 .const .align 2 LC0: .ascii MyApp\0 .objc_cat_cls_meth .objc_cat_inst_meth .objc_string_object .section __OBJC, __cstring_object, regular, no_dead_strip .objc_message_refs .section __OBJC, __sel_fixup, regular, no_dead_strip .objc_cls_refs .objc_class .objc_meta_class .objc_cls_meth .objc_inst_meth .objc_protocol .objc_class_names .objc_meth_var_types .objc_meth_var_names .objc_category .objc_class_vars .objc_instance_vars .objc_module_info .objc_symbols .section __OBJC, __cstring_object, regular, no_dead_strip .align 2 LC1: .long __NSConstantStringClassReference .long LC0 .long 5 .data .align 2 _appKey: .long LC1 .subsections_via_symbols -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44125
[Bug other/44116] 64bit inodes for source code causes Value too large for defined data type (XFS,inode64)
--- Comment #3 from kasparek at fit dot vutbr dot cz 2010-05-14 06:50 --- (In reply to comment #1) to get the cc1 command line. Then use gdb --args cc1 cmdline to debug the compiler. Getting a backtrace before the abort would be nice. (gdb) bt #0 open_file (file=0x8a64148) at /usr/local/lib/gcc/i686-pc-linux-gnu/4.3.4/include-fixed/sys/stat.h:510 #1 0x0866d707 in _cpp_find_file (pfile=0x8a5bb80, fname=0xff8d636f test-10356.c, start_dir=0x8a5bbf4, fake=0 '\0', angle_brackets=0) at ../../libcpp/files.c:378 #2 0x0866e2cc in cpp_read_main_file (pfile=0x8a5bb80, fname=0xff8d636f test-10356.c) at ../../libcpp/init.c:561 #3 0x080f94a1 in c_common_post_options (pfilename=0x8945fdc) at ../../gcc/c-opts.c:1197 #4 0x08339410 in toplev_main (argc=11, argv=0xff8d4874) at ../../gcc/toplev.c:1810 #5 0x08118cb2 in main (argc=Cannot access memory at address 0x100 ) at ../../gcc/main.c:35 I belive the problematic stat is gcc/files.c:232 (gcc-4.5.0). Would it be possible to add config option to enable LFS that may be disabled by default? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44116
[Bug target/44132] New: [4.6 Regression] emutls is broken under a range of circumstances.
wide-ranging fails: === libgomp Summary for unix/-m32 === # of expected passes2466 # of unexpected failures24 # of unsupported tests 2 === libgomp Summary for unix/-m64 === # of expected passes2365 # of unexpected failures73 # of unsupported tests 2 OBJC TLS fails -O0 @m64 (all undefined symbols) (Ditto Obj-C++ although I've not posted the tests yet) execution fails in libgomp/fortran. plus fails like: -lm -m64 -o ./ctor-5.exe(timeout = 60) Undefined symbols: ___emutls_v._ZL3thr, referenced from: __Z3foov.omp_fn.0 in ccPMFIjo.o foo()in ccPMFIjo.o foo()in ccPMFIjo.o ld: symbol(s) not found (possibly a manifestation of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44121 but I suspect additional to it) -- Summary: [4.6 Regression] emutls is broken under a range of circumstances. Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: iains at gcc dot gnu dot org GCC target triplet: *-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44132
[Bug inline-asm/43998] inline assembler: can't set clobbering for input register
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2010-05-14 07:10 --- the compiler may think that something do not modify eax. So next assignment may use eax ( mov eax, x ). So, it does not make sense to have it as a clobber is not correct. does not it ? Andrew was saying that it doesn't make sense to consider input operands as clobbered by an inline asm, generically. And the second, Because the way the constraints are implemented inside GCC, an input constraint cannot overlap with a clobber. - It definitely the bug. No, it isn't, it's clearly stated in the manual: You may not write a clobber description in a way that overlaps with an input or output operand. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43998
[Bug c++/44108] [4.6 Regression] -Wunused-but-set-variable does not consider array sizing use of a const variable
--- Comment #2 from jakub at gcc dot gnu dot org 2010-05-14 07:25 --- Perhaps we just shouldn't ever warn for TREE_CONSTANT decls with -Wunused-but-set-* ? Such variables can't be ever set (the set is just the definition), therefore all sets of TREE_USED for them are reads. That said, it would be good to find out why we don't warn in that case; for [M_CONST + 6] we do warn. Or for DECL_INTEGRAL_CONSTANT_VAR_P decls, or for decls for which integral_constant_value (decl) != decl not sure what is best. In any case, compute_array_index_type (and probably many other spots) calls integral_constant_value and thus doesn't see the passed in decl anymore afterwards. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44108
[Bug target/20049] __builtin_ia32_loadsss is still documented
--- Comment #6 from ubizjak at gmail dot com 2010-05-14 07:36 --- Missing/wrong documentation is covered by PR25519. *** This bug has been marked as a duplicate of 25519 *** -- ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20049
[Bug target/25519] Intel (SSE/MMX) intrinsics should only be mentioned instead of the builtins
--- Comment #10 from ubizjak at gmail dot com 2010-05-14 07:36 --- *** Bug 20049 has been marked as a duplicate of this bug. *** -- ubizjak at gmail dot com changed: What|Removed |Added CC||kirk_korver at hotmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25519
[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.
--- Comment #1 from iains at gcc dot gnu dot org 2010-05-14 08:17 --- this was caused by r159370, 72 or 72. (CC ing Jan Hubika). in case it's relevant, the emutls control vars are not finalized . I have a patch to do this (http://gcc.gnu.org/ml/gcc-patches/2010-05/msg00824.html) ... ... however, it doesn't solve this problem as applied there. I mention because the symptoms are similar -- variables 'optimized away'. -- iains at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44132
[Bug middle-end/44133] New: [4.5/4.6 Regression] Uninit warning regression with new SRA
struct S { int i, j; };
int foo (int l)
{
struct S s;
s.j = l - 22;
return s.i + s.j;
}
with -O2 -W -Wall in 4.4 this used to warn:
v.c: In function 'foo':
v.c:6: warning: 's.i' is used uninitialized in this function
but with 4.5+ it warns:
v.c: In function 'foo':
v.c:6:11: warning: '({anonymous})' is used uninitialized in this function
[-Wuninitialized]
For:
struct S { int i, j; };
int foo (int l)
{
struct S s;
if (l 126)
{
s.j = l - 22;
return s.i + s.j;
}
s.i = 12;
s.j = l + 40;
return s.i + s.j;
}
the warning is ok in both 4.4 and 4.5+.
I'd say that SRA should add the D. = s$i; stmts, perhaps right before
D. uses.
--
Summary: [4.5/4.6 Regression] Uninit warning regression with new
SRA
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44133
[Bug middle-end/44133] [4.5/4.6 Regression] Uninit warning regression with new SRA
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44133
[Bug fortran/37131] inline matmul for small matrix sizes
--- Comment #8 from tkoenig at gcc dot gnu dot org 2010-05-14 09:15 --- New timings, on x86_64-unknown-linux-gnu. I split off the invalidate subroutine to make sure the optimizers don't optimize this out: i...@linux-fd1f:/tmp gfortran -O3 matmul.f90 invalidate.f90 i...@linux-fd1f:/tmp time ./a.out matmul =11.100311 s subroutine with explicit interface:2.0216932 s unrolled subroutine with explicit interface:1.9317064 s inline with sum 1.9087105 s real0m16.971s user0m16.959s sys 0m0.005s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37131
[Bug middle-end/44134] New: Unneeded +0.0 for c = 0.0 ; c = c+ a*b
This code leads to the adding of 0.0, which is a nop. Any
signalling should have been done previously.
i...@linux-fd1f:/tmp cat mult.f90
subroutine foo(a,b,c)
real, intent(in) :: a,b
real, intent(out) :: c
c = 0.0
c = c + a*b
end subroutine foo
i...@linux-fd1f:/tmp gfortran -O3 -fdump-tree-optimized -S mult.f90
i...@linux-fd1f:/tmp cat mult.f90.142t.optimized
;; Function foo (foo_)
foo (real(kind=4) restrict a, real(kind=4) restrict b, real(kind=4)
restrict c)
{
real(kind=4) D.1542;
real(kind=4) D.1541;
real(kind=4) D.1540;
real(kind=4) D.1539;
bb 2:
D.1539_4 = *a_3(D);
D.1540_6 = *b_5(D);
D.1541_7 = D.1539_4 * D.1540_6;
D.1542_8 = D.1541_7 + 0.0;
*c_1(D) = D.1542_8;
return;
}
i...@linux-fd1f:/tmp cat mult.s
.file mult.f90
.text
.p2align 4,,15
.globl foo_
.type foo_, @function
foo_:
.LFB0:
movss (%rdi), %xmm0
mulss (%rsi), %xmm0
addss .LC0(%rip), %xmm0
movss %xmm0, (%rdx)
ret
.LFE0:
.size foo_, .-foo_
.section.rodata.cst4,aM,@progbits,4
.align 4
.LC0:
.long 0
.section.eh_frame,a,@progbits
.Lframe1:
.long .LECIE1-.LSCIE1
.LSCIE1:
.long 0
.byte 0x1
.string zR
.uleb128 0x1
.sleb128 -8
.byte 0x10
.uleb128 0x1
.byte 0x3
.byte 0xc
.uleb128 0x7
.uleb128 0x8
.byte 0x90
.uleb128 0x1
.align 8
.LECIE1:
.LSFDE1:
.long .LEFDE1-.LASFDE1
.LASFDE1:
.long .LASFDE1-.Lframe1
.long .LFB0
.long .LFE0-.LFB0
.uleb128 0
.align 8
.LEFDE1:
.ident GCC: (GNU) 4.6.0 20100513 (experimental)
.section.note.GNU-stack,,@progbits
--
Summary: Unneeded +0.0 for c = 0.0 ; c = c+ a*b
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44134
[Bug fortran/44135] New: Negative array bounds lead to spurious warning
The declaration of arrays with negative bounds leads to a warning message, probably caused by an integer overflow. The program below leads to the message gprogram.f90:6.19: call fill_array(my_arr) 1 Warning: Actual argument contains too few elements for dummy argument 'arr' (3/4294967295) at (1) program gprogram implicit none double precision, dimension(-2:0) :: my_arr call fill_array(my_arr) print*, my_arr(-2) print*, my_arr(-1) print*, my_arr( 0) contains subroutine fill_array(arr) implicit none double precision, dimension(-2:0), intent(out) :: arr arr(-2) = 1.0d0 arr(-1) = 3.1d0 arr( 0) = 9.2d0 end subroutine fill_array end program gprogram -- Summary: Negative array bounds lead to spurious warning Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: thomasr at nikhef dot nl GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44135
[Bug fortran/44135] Negative array bounds lead to spurious warning
--- Comment #1 from thomasr at nikhef dot nl 2010-05-14 09:24 --- Created an attachment (id=20660) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20660action=view) Test program that reproduces the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44135
[Bug middle-end/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3
--- Comment #49 from dominiq at lps dot ens dot fr 2010-05-14 09:28 --- Any news on this? Still there at revision 159329. Ira Rosen has devoted a fair amount of time to trace the problem, but nobody cared to pursue. Presently this PR has nothing to do with -g nor -ma64, so I updated the summary. Note that bootstrapping gcc on powerpc-apple-darwin9 is broken since revision 159339!-(each time a fix is posted an other breakage follows). -- dominiq at lps dot ens dot fr changed: What|Removed |Added Summary|[4.5/4.6 Regression] FAIL: |[4.5/4.6 Regression] FAIL: |gfortran.fortran- |gfortran.fortran- |torture/execute/where_2.f90 |torture/execute/where_2.f90 |execution, -O3 -g with -m64|execution, -O3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082
[Bug c++/30298] [4.3/4.4/4.5/4.6 regression] ICE with duplicate broken inheritance
--- Comment #10 from paolo dot carlini at oracle dot com 2010-05-14 09:42
---
This is another, slightly different testcase, both must added to the testsuite:
==
struct A {};
struct B : A, A {};
struct B : A, A {};
==
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30298
[Bug c++/30566] -Wshadow warns about clashes between nested function parameters in C++
--- Comment #4 from paolo dot carlini at oracle dot com 2010-05-14 09:43 --- Fixed for 4.6.0. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30566
[Bug middle-end/44133] [4.5/4.6 Regression] Uninit warning regression with new SRA
--- Comment #1 from jamborm at gcc dot gnu dot org 2010-05-14 09:47 --- Mine. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jamborm at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-14 09:47:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44133
[Bug c++/44092] Undefined Symbol: std::basic_string
--- Comment #3 from stefanwin at gmx dot net 2010-05-14 10:04 ---
My sample program:
// g++ 4.0.0-1
// compile: g++ -c -Wall progname.c - ist ok
// link (AIX linker ld): g++ -o progname progname.o
// ERROR: Undefined symbol: .std::basic_stringchar, std::char_traits
// char, std::allocatorchar ::basic_string()
// ERROR: Undefined symbol: .std::basic_stringchar, std::char_traits
// char, std::allocatorchar ::~basic_string()
//
#include stdio.h
#include string
using namespace std;
// main
//
int main (int argc,char **argv)
{
string test;
return(0);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44092
[Bug c++/44092] Undefined Symbol: std::basic_string
--- Comment #4 from paolo dot carlini at oracle dot com 2010-05-14 10:27 --- Yes. Note that gcc-4.0.x, 4.1.x, and 4.2.x are *not maintained anymore* and bugs affecting only those release series are simply closed. Thus, before anything else, try a current release, preferably gcc-4.4.x. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44092
[Bug debug/44136] New: [4.5/4.6 Regression] ICE in expand_debug_expr with -mno-sse
/* { dg-do compile } */
/* { dg-options -w -O2 -g } */
/* { dg-options -w -O2 -g -mno-sse { target { { i?86-*-* x86_64-*-* ilp32
} } } */
#define vector __attribute((vector_size(16)))
vector float a;
float
foo (float b)
{
vector float c = {0, 0, 0, 0 };
vector float d = {0, 0, 0, 0 };
d += c;
return ((float *)c)[2];
}
float
bar (vector float a, int b, vector float c)
{
vector float e = c * a;
a = (vector float) {0, 0, 0, 0 };
c = (vector float) {0, 0, 0, 0 };
float d = ((float *)a)[0];
float f = ((float *)c)[0];
return d * f;
}
(from vector-2.c and vector-3.c testcases) ICEs in expand_debug_expr on i?86.
op0 has BLKmode, which the code asserts it does not.
--
Summary: [4.5/4.6 Regression] ICE in expand_debug_expr with -mno-
sse
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44136
[Bug libstdc++/43259] ext/profile/all.cc fails on Solaris
--- Comment #27 from paolo at gcc dot gnu dot org 2010-05-14 11:40 --- Subject: Bug 43259 Author: paolo Date: Fri May 14 11:40:05 2010 New Revision: 159389 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159389 Log: 2010-05-14 Silvius Rus silvius@gmail.com PR libstdc++/43259 * include/profile/impl/profiler.h (_GLIBCXX_PROFILE_DEFINE_UNINIT_DATA): Add. * include/profile/impl/profiler_trace.h (__mutex_t, __lock, __unlock): Remove. (__lock_object_table, __lock_stack_table): Remove. Replace uses with calls to __gnu_cxx::__mutex::lock. (__unlock_object_table, __unlock_stack_table): Remove. Replace uses with calls to __gnu_cxx::__mutex::unlock. Modified: branches/gcc-4_5-branch/libstdc++-v3/ChangeLog branches/gcc-4_5-branch/libstdc++-v3/include/profile/impl/profiler.h branches/gcc-4_5-branch/libstdc++-v3/include/profile/impl/profiler_trace.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43259
[Bug libstdc++/43259] ext/profile/all.cc fails on Solaris
--- Comment #28 from paolo dot carlini at oracle dot com 2010-05-14 11:41 --- Fixed for 4.5.1. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43259
[Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
--- Comment #23 from janus at gcc dot gnu dot org 2010-05-14 11:53 --- (In reply to comment #22) Janus, is there something left to do here? Yes, sure. The ICE has not been fixed yet. With 4.6 trunk (r159368) I still get the same ICE on comment #8/#14: internal compiler error: in resolve_typebound_procedure, at fortran/resolve.c:10304 -- janus at gcc dot gnu dot org changed: What|Removed |Added Summary|ICE in |[OOP] ICE in |resolve_typebound_procedure |resolve_typebound_procedure Target Milestone|4.5.1 |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769
[Bug c++/44092] Undefined Symbol: std::basic_string
--- Comment #5 from stefanwin at gmx dot net 2010-05-14 11:55 --- If I want to install the gcc-4.4.0, I get the error libgmp.a and libmpfr.a not found. It seems I have to rebuild something. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44092
[Bug fortran/44131] [OOP] Using polymorphism in modules unware of derived types fails at run-time
--- Comment #2 from janus at gcc dot gnu dot org 2010-05-14 12:04 --- (In reply to comment #1) Copying your code into uh.f90 gives laptop:kargl[204] gfc4x -o z uh.f90 laptop:kargl[205] ./z Derived DoIt with i686-*-freebsd and x86_64-*-freebsd on trunk. Yes, the failure is only seen in release 4.5 (where the OOP support is highly experimental). The problem is fixed on 4.6 trunk. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Summary|Using polymorfism in modules|[OOP] Using polymorphism in |unware of derived types |modules unware of derived |fails at run-time |types fails at run-time http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44131
[Bug c++/44092] Undefined Symbol: std::basic_string
--- Comment #6 from redi at gcc dot gnu dot org 2010-05-14 12:05 --- You might want to read http://gcc.gnu.org/install/ starting with Prerequisites -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44092
[Bug debug/44136] [4.5/4.6 Regression] ICE in expand_debug_expr with -mno-sse
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44136
[Bug middle-end/44134] Unneeded +0.0 for c = 0.0 ; c = c+ a*b
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-05-14 12:19 --- But -0.0 + 0.0 is 0.0, so the transformation is only valid for -fno-signed-zeros. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44134
[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44132
[Bug c++/44127] [4.3/4.4/4.5/4.6 Regression] G++ emits unnecessary EH code
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Target Milestone|--- |4.3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44127
[Bug tree-optimization/44124] valgrind reports invalid read while compiling compile/pr34091.c
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-05-14 12:33 --- Confirmed and mine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-14 12:33:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44124
[Bug target/44129] Building linux kernel with gcc-4.5.0 and CONFIG_CC_OPTIMIZE_FOR_SIZE segfaults
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-05-14 12:26 --- Waiting for a testcase. And for the reporter to try the tip of the 4.5 branch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44129
[Bug tree-optimization/44124] valgrind reports invalid read while compiling compile/pr34091.c
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-05-14 12:36 --- Subject: Bug 44124 Author: rguenth Date: Fri May 14 12:36:28 2010 New Revision: 159390 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159390 Log: 2010-05-14 Richard Guenther rguent...@suse.de PR tree-optimization/44124 * tree-ssa-sccvn.c (vn_nary_may_trap): Fix invalid memory access. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-sccvn.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44124
[Bug tree-optimization/44124] valgrind reports invalid read while compiling compile/pr34091.c
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-05-14 12:40 --- Subject: Bug 44124 Author: rguenth Date: Fri May 14 12:40:18 2010 New Revision: 159391 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159391 Log: 2010-05-14 Richard Guenther rguent...@suse.de PR tree-optimization/44124 * tree-ssa-sccvn.c (vn_nary_may_trap): Fix invalid memory access. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/tree-ssa-sccvn.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44124
[Bug tree-optimization/44124] valgrind reports invalid read while compiling compile/pr34091.c
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-05-14 12:40 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44124
[Bug bootstrap/38591] [4.3 regression] erratic comparison failures on very fast machines
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-05-14 12:51 --- Fixed (hopefully). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38591
[Bug bootstrap/38591] [4.3 regression] erratic comparison failures on very fast machines
--- Comment #12 from rguenth at gcc dot gnu dot org 2010-05-14 12:51 --- Subject: Bug 38591 Author: rguenth Date: Fri May 14 12:51:31 2010 New Revision: 159392 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159392 Log: 2010-05-15 Richard Guenther rguent...@suse.de PR bootstrap/38591 * Makefile.in (graph.o): Add missing $(CONFIG_H) dependency. (sparseset.o): Likewise. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38591
[Bug middle-end/42255] [4.3 Regression] broken generated code when using -fprofile-arcs and -O2
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42255
[Bug debug/43190] [4.3/4.4 Regression] Used pointer typedefs eliminated from debug info
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43190
[Bug middle-end/43866] [4.3/4.4/4.5/4.6 Regression] wrong code with -fbounds-check -funswitch-loops
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43866
[Bug tree-optimization/43949] [4.3/4.4/4.5 Regression] bogus warning: array subscript is above array bounds
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43949
[Bug c++/44127] [4.3/4.4/4.5/4.6 Regression] G++ emits unnecessary EH code
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44127
[Bug tree-optimization/44137] New: [4.6 Regression]: objc.dg/torture/tls/thr-init-2.m and thr-init.m
With revision 159369 these tests passed. From revision 159376 and on, including at least 159388, these tests have failed as follows: Running /tmp/hpautotest-gcc1/gcc/gcc/testsuite/objc.dg/torture/tls/tls.exp ... FAIL: objc.dg/torture/tls/thr-init-2.m -O1 (test for excess errors) WARNING: objc.dg/torture/tls/thr-init-2.m -O1 compilation failed to produce executable FAIL: objc.dg/torture/tls/thr-init-2.m -O2 (test for excess errors) WARNING: objc.dg/torture/tls/thr-init-2.m -O2 compilation failed to produce executable FAIL: objc.dg/torture/tls/thr-init-2.m -O3 -fomit-frame-pointer (test for excess errors) WARNING: objc.dg/torture/tls/thr-init-2.m -O3 -fomit-frame-pointer compilation failed to produce executable FAIL: objc.dg/torture/tls/thr-init-2.m -O3 -g (test for excess errors) WARNING: objc.dg/torture/tls/thr-init-2.m -O3 -g compilation failed to produce executable FAIL: objc.dg/torture/tls/thr-init-2.m -Os (test for excess errors) WARNING: objc.dg/torture/tls/thr-init-2.m -Os compilation failed to produce executable FAIL: objc.dg/torture/tls/thr-init-2.m -O2 -flto (test for excess errors) WARNING: objc.dg/torture/tls/thr-init-2.m -O2 -flto compilation failed to produce executable FAIL: objc.dg/torture/tls/thr-init-2.m -O2 -fwhopr (test for excess errors) WARNING: objc.dg/torture/tls/thr-init-2.m -O2 -fwhopr compilation failed to produce executable FAIL: objc.dg/torture/tls/thr-init-3.m -O1 (test for excess errors) WARNING: objc.dg/torture/tls/thr-init-3.m -O1 compilation failed to produce executable FAIL: objc.dg/torture/tls/thr-init-3.m -O2 (test for excess errors) WARNING: objc.dg/torture/tls/thr-init-3.m -O2 compilation failed to produce executable FAIL: objc.dg/torture/tls/thr-init-3.m -O3 -fomit-frame-pointer (test for excess errors) WARNING: objc.dg/torture/tls/thr-init-3.m -O3 -fomit-frame-pointer compilation failed to produce executable FAIL: objc.dg/torture/tls/thr-init-3.m -O3 -g (test for excess errors) WARNING: objc.dg/torture/tls/thr-init-3.m -O3 -g compilation failed to produce executable FAIL: objc.dg/torture/tls/thr-init-3.m -Os (test for excess errors) WARNING: objc.dg/torture/tls/thr-init-3.m -Os compilation failed to produce executable FAIL: objc.dg/torture/tls/thr-init-3.m -O2 -flto (test for excess errors) WARNING: objc.dg/torture/tls/thr-init-3.m -O2 -flto compilation failed to produce executable FAIL: objc.dg/torture/tls/thr-init-3.m -O2 -fwhopr (test for excess errors) WARNING: objc.dg/torture/tls/thr-init-3.m -O2 -fwhopr compilation failed to produce executable FAIL: objc.dg/torture/tls/thr-init.m -O1 (test for excess errors) WARNING: objc.dg/torture/tls/thr-init.m -O1 compilation failed to produce executable FAIL: objc.dg/torture/tls/thr-init.m -O2 (test for excess errors) WARNING: objc.dg/torture/tls/thr-init.m -O2 compilation failed to produce executable FAIL: objc.dg/torture/tls/thr-init.m -O3 -fomit-frame-pointer (test for excess errors) WARNING: objc.dg/torture/tls/thr-init.m -O3 -fomit-frame-pointer compilation failed to produce executable FAIL: objc.dg/torture/tls/thr-init.m -O3 -g (test for excess errors) WARNING: objc.dg/torture/tls/thr-init.m -O3 -g compilation failed to produce executable FAIL: objc.dg/torture/tls/thr-init.m -Os (test for excess errors) WARNING: objc.dg/torture/tls/thr-init.m -Os compilation failed to produce executable FAIL: objc.dg/torture/tls/thr-init.m -O2 -flto (test for excess errors) WARNING: objc.dg/torture/tls/thr-init.m -O2 -flto compilation failed to produce executable FAIL: objc.dg/torture/tls/thr-init.m -O2 -fwhopr (test for excess errors) WARNING: objc.dg/torture/tls/thr-init.m -O2 -fwhopr compilation failed to produce executable The message in objc.log for r159388 is: Executing on host: /tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/xgcc -B/tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/ /tmp/hpautotest-gcc1/gcc/gcc/testsuite/objc.dg/torture/tls/thr-init-2.m -O1 -fgnu-runtime -I/tmp/hpautotest-gcc1/gcc/gcc/testsuite/../../libobjc -B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./libobjc/.libs -L/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./libobjc/.libs-isystem /tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./newlib/targ-include -isystem /tmp/hpautotest-gcc1/gcc/newlib/libc/include -B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./libgloss/cris/ -L/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./libgloss/cris -L/tmp/hpautotest-gcc1/gcc/libgloss/cris -B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./newlib/ -L/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./newlib -sim3 -lobjc -lm -o ./thr-init-2.exe(timeout = 300) /tmp/ccyWCWTq.o: In function `_fa': thr-init-2.m:(.text+0x12): undefined reference to `___emutls_v.as.1281' /tmp/ccyWCWTq.o: In function `_fb': thr-init-2.m:(.text+0x44): undefined reference to `___emutls_v.bs.1285' collect2: ld returned 1 exit status compiler exited with status 1 output is: /tmp/ccyWCWTq.o: In function `_fa':
Re: [Bug middle-end/44134] New: Unneeded +0.0 for c = 0.0 ; c = c+ a*b
Sent from my iPhone
On May 14, 2010, at 2:18 AM, tkoenig at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org
wrote:
This code leads to the adding of 0.0, which is a nop. Any
signalling should have been done previously.
It is not signalling that matters here but signed zero. 0.0 + -0.0 ==
0.0. So without the 0.0 +, you can get a negative zero.
i...@linux-fd1f:/tmp cat mult.f90
subroutine foo(a,b,c)
real, intent(in) :: a,b
real, intent(out) :: c
c = 0.0
c = c + a*b
end subroutine foo
i...@linux-fd1f:/tmp gfortran -O3 -fdump-tree-optimized -S mult.f90
i...@linux-fd1f:/tmp cat mult.f90.142t.optimized
;; Function foo (foo_)
foo (real(kind=4) restrict a, real(kind=4) restrict b, real
(kind=4)
restrict c)
{
real(kind=4) D.1542;
real(kind=4) D.1541;
real(kind=4) D.1540;
real(kind=4) D.1539;
bb 2:
D.1539_4 = *a_3(D);
D.1540_6 = *b_5(D);
D.1541_7 = D.1539_4 * D.1540_6;
D.1542_8 = D.1541_7 + 0.0;
*c_1(D) = D.1542_8;
return;
}
i...@linux-fd1f:/tmp cat mult.s
.file mult.f90
.text
.p2align 4,,15
.globl foo_
.type foo_, @function
foo_:
.LFB0:
movss (%rdi), %xmm0
mulss (%rsi), %xmm0
addss .LC0(%rip), %xmm0
movss %xmm0, (%rdx)
ret
.LFE0:
.size foo_, .-foo_
.section.rodata.cst4,aM,@progbits,4
.align 4
.LC0:
.long 0
.section.eh_frame,a,@progbits
.Lframe1:
.long .LECIE1-.LSCIE1
.LSCIE1:
.long 0
.byte 0x1
.string zR
.uleb128 0x1
.sleb128 -8
.byte 0x10
.uleb128 0x1
.byte 0x3
.byte 0xc
.uleb128 0x7
.uleb128 0x8
.byte 0x90
.uleb128 0x1
.align 8
.LECIE1:
.LSFDE1:
.long .LEFDE1-.LASFDE1
.LASFDE1:
.long .LASFDE1-.Lframe1
.long .LFB0
.long .LFE0-.LFB0
.uleb128 0
.align 8
.LEFDE1:
.ident GCC: (GNU) 4.6.0 20100513 (experimental)
.section.note.GNU-stack,,@progbits
--
Summary: Unneeded +0.0 for c = 0.0 ; c = c+ a*b
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44134
[Bug middle-end/44134] Unneeded +0.0 for c = 0.0 ; c = c+ a*b
--- Comment #2 from pinskia at gmail dot com 2010-05-14 13:10 ---
Subject: Re: New: Unneeded +0.0 for c = 0.0 ; c = c+ a*b
Sent from my iPhone
On May 14, 2010, at 2:18 AM, tkoenig at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org
wrote:
This code leads to the adding of 0.0, which is a nop. Any
signalling should have been done previously.
It is not signalling that matters here but signed zero. 0.0 + -0.0 ==
0.0. So without the 0.0 +, you can get a negative zero.
i...@linux-fd1f:/tmp cat mult.f90
subroutine foo(a,b,c)
real, intent(in) :: a,b
real, intent(out) :: c
c = 0.0
c = c + a*b
end subroutine foo
i...@linux-fd1f:/tmp gfortran -O3 -fdump-tree-optimized -S mult.f90
i...@linux-fd1f:/tmp cat mult.f90.142t.optimized
;; Function foo (foo_)
foo (real(kind=4) restrict a, real(kind=4) restrict b, real
(kind=4)
restrict c)
{
real(kind=4) D.1542;
real(kind=4) D.1541;
real(kind=4) D.1540;
real(kind=4) D.1539;
bb 2:
D.1539_4 = *a_3(D);
D.1540_6 = *b_5(D);
D.1541_7 = D.1539_4 * D.1540_6;
D.1542_8 = D.1541_7 + 0.0;
*c_1(D) = D.1542_8;
return;
}
i...@linux-fd1f:/tmp cat mult.s
.file mult.f90
.text
.p2align 4,,15
.globl foo_
.type foo_, @function
foo_:
.LFB0:
movss (%rdi), %xmm0
mulss (%rsi), %xmm0
addss .LC0(%rip), %xmm0
movss %xmm0, (%rdx)
ret
.LFE0:
.size foo_, .-foo_
.section.rodata.cst4,aM,@progbits,4
.align 4
.LC0:
.long 0
.section.eh_frame,a,@progbits
.Lframe1:
.long .LECIE1-.LSCIE1
.LSCIE1:
.long 0
.byte 0x1
.string zR
.uleb128 0x1
.sleb128 -8
.byte 0x10
.uleb128 0x1
.byte 0x3
.byte 0xc
.uleb128 0x7
.uleb128 0x8
.byte 0x90
.uleb128 0x1
.align 8
.LECIE1:
.LSFDE1:
.long .LEFDE1-.LASFDE1
.LASFDE1:
.long .LASFDE1-.Lframe1
.long .LFB0
.long .LFE0-.LFB0
.uleb128 0
.align 8
.LEFDE1:
.ident GCC: (GNU) 4.6.0 20100513 (experimental)
.section.note.GNU-stack,,@progbits
--
Summary: Unneeded +0.0 for c = 0.0 ; c = c+ a*b
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44134
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44134
[Bug c++/43915] Compiler flags error: error: invalid initialization of reference of type 'boost::thread' from expression of type 'boost::thread'
--- Comment #11 from mlrus at mac dot com 2010-05-14 13:25 --- The following shows how to patch, compile and use boost 1.43.0 with g++ -std=c++0x. At issue are the rvalue references and typecasts in the boost threading libraries. Simply tell Boost not to use its rvalue reference code when it gets compiled, even with option std=c++0x is set. Here's how: 1. Modify operatingSystem.jam, to compile with the -std=c+0x option. Also, remove the -no-cpp-precomp option if it is not supported by your compiler. For OS X I changed tools/build/v2/tools/darwin.jam at line 483 like this # Misc options. #flags darwin.compile OPTIONS : -no-cpp-precomp -gdwarf-2 ; flags darwin.compile OPTIONS : -std=c++0x -gdwarf-2 ; 2. Modify gcc.hpp to disable the conditional compilation of rvalue references (temporarily, until that part of the code works with g++) diff gcc.hpp.orig gcc.hpp 124c124,125 # define BOOST_HAS_RVALUE_REFS // # define BOOST_HAS_RVALUE_REFS # define BOOST_NO_RVALUE_REFERENCES In this manner you can compile and use Boost 1.43 fine gcc 4.5 or earlier, and still build your software to use the c++0x features supported by the gnu copmiler option -std=c++0x. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43915
[Bug c++/44138] New: Cannot call template method from derived template class
If a template class whose parent is a template class tries to call a template
method using the normal this-methodnameT() syntax, g++ fails to parse the
source file (details below).
-- begin test case file bug.cpp --
#define BUG_HERE
class T1;
//class A declares a template method
class A
{
public:
template class X
void test()
{
}
};
//class B is derived from class A
templateclass Y
class B : public A
{
public:
void works()
{
//class B can still call the template method from class A
this-testT1();
}
};
templateclass Y
class C : public BY
{
public:
void does_not_work()
{
#ifdef BUG_HERE
this-testT1();
//unlike for class B, for class C, this does not work
// with g++ (Ubuntu 4.4.3-4ubuntu5) 4.4.3
#endif
A::testT1(); //this seems to compile
}
};
-- end --
$ g++ -v -save-temps -c bug.cpp
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.3-4ubuntu5'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc
--disable-werror --with-arch-32=i486 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-shared-libgcc' '-mtune=generic'
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/cc1plus -E -quiet -v -D_GNU_SOURCE bug.cpp
-D_FORTIFY_SOURCE=2 -mtune=generic -fpch-preprocess -fstack-protector -o bug.ii
ignoring nonexistent directory /usr/local/include/x86_64-linux-gnu
ignoring nonexistent directory
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../x86_64-linux-gnu/include
ignoring nonexistent directory /usr/include/x86_64-linux-gnu
#include ... search starts here:
#include ... search starts here:
/usr/include/c++/4.4
/usr/include/c++/4.4/x86_64-linux-gnu
/usr/include/c++/4.4/backward
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/include
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-shared-libgcc' '-mtune=generic'
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/cc1plus -fpreprocessed bug.ii -quiet
-dumpbase bug.cpp -mtune=generic -auxbase bug -version -fstack-protector -o
bug.s
GNU C++ (Ubuntu 4.4.3-4ubuntu5) version 4.4.3 (x86_64-linux-gnu)
compiled by GNU C version 4.4.3, GMP version 4.3.2, MPFR version
2.4.2-p1.
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128001
GNU C++ (Ubuntu 4.4.3-4ubuntu5) version 4.4.3 (x86_64-linux-gnu)
compiled by GNU C version 4.4.3, GMP version 4.3.2, MPFR version
2.4.2-p1.
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128001
Compiler executable checksum: 88858f45841827736473e527a4e9ab10
bug.cpp: In member function void CY::does_not_work():
bug.cpp:34: error: expected primary-expression before token
bug.cpp:34: error: expected primary-expression before ) token
While there are workarounds for this bug, it is certainly unexpected behavior.
Note that this bug does not occur for class B or for cases where class C is not
a template class.
--
Summary: Cannot call template method from derived template class
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: klenze at mpp dot mpg dot de
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44138
[Bug c++/44138] Cannot call template method from derived template class
--- Comment #1 from paolo dot carlini at oracle dot com 2010-05-14 14:22 --- You want: this-template testT1(); -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44138
[Bug target/44139] New: Exporting emutls symbols from a DLL broken on w32 targets
Windows targets that use emutls add a . character as a separator from the
_emutls_{t,v} and the true symbol name. However, exporting these symbol names
from a DLL is problematic (i.e. a thread local data variable), because the .
in the symbol name tells the Windows loader to treat the symbol as a forwarding
RVA to a second DLL (in this case, it will look for the symbol varname in
__emutls_v.dll, the symbol exported is __emutls_v.varname). Note that this is
a runtime issue, not a compile/link issue.
This can be worked around by
#define TARGET_EMUTLS_VAR_PREFIX __emutls_v_
#define TARGET_EMUTLS_TMPL_PREFIX __emutls_t_
in the config header (e.g. config/i386/cygming.h or config/i386/mingw-w64.h,
etc).
However, this breaks backward compatibility with object files that were built
with previous versions of the compiler (e.g libold.a would have a global name
of __emutls_v.varname, while the patch would cause gcc to look for
__emutls_v_varname, which would cause linker errors).
--
Summary: Exporting emutls symbols from a DLL broken on w32
targets
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dougsemler at gmail dot com
GCC target triplet: i686-pc-mingw32 x86_64-*-mingw32 i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
[Bug lto/44140] New: objc.dg/torture/tls/thr-init-3.m failure
On Linux/ia32, I got Executing on host: /export/build/gnu/gcc/build-i686-linux/gcc/xgcc -B/export/build/gnu/gcc/build-i686-linux/gcc/ /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/objc.dg/torture/tls/thr-init-3.m -O2 -flto -fgnu-runtime -I/net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/../../libobjc -B/export/build/gnu/gcc/build-i686-linux/i686-pc-linux-gnu/./libobjc/.libs -L/export/build/gnu/gcc/build-i686-linux/i686-pc-linux-gnu/./libobjc/.libs /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/objc.dg/torture/tls/../../../objc-obj-c++-shared/Object1.m -lobjc -lm -o ./thr-init-3.exe(timeout = 300) /tmp/cc0nTyTC.lto.o:(.data+0xa0): undefined reference to `_OBJC_METACLASS_tsObj.2114'^M /tmp/cc0nTyTC.lto.o:(.data+0xfc): undefined reference to `_OBJC_CLASS_tsObj.2110'^M /tmp/cc0nTyTC.lto.o:(.data+0x104): undefined reference to `__objc_class_name_tsObj'^M collect2: ld returned 1 exit status^M -- Summary: objc.dg/torture/tls/thr-init-3.m failure Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44140
[Bug target/44088] -mavx doesn't generate always AVX instructions
--- Comment #3 from hjl at gcc dot gnu dot org 2010-05-14 14:43 --- Subject: Bug 44088 Author: hjl Date: Fri May 14 14:43:32 2010 New Revision: 159395 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159395 Log: Support AVX for cmpss/cmpsd. gcc/ 2010-05-14 H.J. Lu hongjiu...@intel.com Backport from mainline 2010-05-12 H.J. Lu hongjiu...@intel.com PR target/44088 * config/i386/sse.md (*avx_vmmaskcmpmode3): New. gcc/testsuite/ 2010-05-14 H.J. Lu hongjiu...@intel.com Backport from mainline 2010-05-12 H.J. Lu hongjiu...@intel.com PR target/44088 * gcc.target/i386/avx-cmpsd-1.c: New. * gcc.target/i386/avx-cmpsd-2.c: Likewise. * gcc.target/i386/avx-cmpss-1.c: Likewise. * gcc.target/i386/avx-cmpss-2.c: Likewise. * gcc.target/i386/sse-cmpss-1.c: Likewise. * gcc.target/i386/sse2-cmpsd-1.c: Likewise. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/avx-cmpsd-1.c branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/avx-cmpsd-2.c branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/avx-cmpss-1.c branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/avx-cmpss-2.c branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/sse-cmpss-1.c branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/sse2-cmpsd-1.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/config/i386/sse.md branches/gcc-4_5-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44088
[Bug target/44088] -mavx doesn't generate always AVX instructions
--- Comment #4 from hjl dot tools at gmail dot com 2010-05-14 14:44 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44088
[Bug c++/30298] [4.3/4.4/4.5/4.6 regression] ICE with duplicate broken inheritance
--- Comment #11 from paolo dot carlini at oracle dot com 2010-05-14 15:04 --- On it, after all ;) -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|NEW |ASSIGNED Last reconfirmed|2006-12-26 22:33:06 |2010-05-14 15:04:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30298
[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared
--- Comment #26 from armin76 at gentoo dot org 2010-05-14 15:07 --- Why hasn't that patch have been applied? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974
[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared
--- Comment #27 from paolo dot carlini at oracle dot com 2010-05-14 15:11 --- You mean the patch in Comment # 20? Because it seems an hack to me. Maybe Ralf is willing to explain why is the only possible fix. In the meanwhile just disabling the generation of the PCHs works around the problem pretty well and doesn't seem a big deal to me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974
[Bug target/44141] New: Redundant loads and stores generated for AMD bdver1 target
Redundant loads and stores created with the new -mtune=bdver1 target. BDVER1 is
optimized to generate packed single moves instead packed double/integer moves
to save 1 byte of space.
Here is the excerpt from the asm dump for ac.f90 benchmark in the Polyhedron
testsuite. Complete asm dump generated with -dP also attached.
vmovaps %xmm15, 304(%rsp) # 4985 *avx_movv4sf_internal/3 [length = 9]
#(insn 4987 4985 2838 ac.f90:503 (set (reg:V2DF 52 xmm15)
#(mem/c:V2DF (plus:DI (reg/f:DI 7 sp)
#(const_int 304 [0x130])) [16 %sfp+-37872 S16 A128])) 1031
{*avx_movv2df_internal} (nil))
vmovaps 304(%rsp), %xmm15 # 4987 *avx_movv2df_internal/2 [length
= 9]
#(insn 2838 4987 4986 ac.f90:503 (set (reg:V2DF 52 xmm15)
#(div:V2DF (reg:V2DF 52 xmm15)
#(mem:V2DF (plus:DI (reg/f:DI 7 sp)
#(const_int 32432 [0x7eb0])) [2 *vect_pdclroo.541_5123+0
S16 A128]))) 1100 {avx_divv2df3} (nil))
Comments from Uros:
You are changing V4SFmode to V2DF mode. Since this combination is not
allowed by MODES_TIEABLE_P (and/or CANNOT_CHANGE_MODE_CLASS), value
gets reloaded through the memory. You can perhaps experiment with
these two macros a bit.
--
Summary: Redundant loads and stores generated for AMD bdver1
target
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: harsha dot jagasia at amd dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44141
[Bug objc/44140] objc.dg/torture/tls/thr-init-3.m failure
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-05-14 15:25 --- That's obviously a objc bug, not a lto bug. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|lto |objc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44140
[Bug target/44142] New: Redundant loads and stores generated for AMD bdver1 target
Redundant loads and stores created with the new -mtune=bdver1 target. BDVER1 is
optimized to generate packed single moves instead packed double/integer moves
to save 1 byte of space.
Here is the excerpt from the asm dump for ac.f90 benchmark in the Polyhedron
testsuite. Complete asm dump generated with -dP also attached.
vmovaps %xmm15, 304(%rsp) # 4985 *avx_movv4sf_internal/3 [length = 9]
#(insn 4987 4985 2838 ac.f90:503 (set (reg:V2DF 52 xmm15)
#(mem/c:V2DF (plus:DI (reg/f:DI 7 sp)
#(const_int 304 [0x130])) [16 %sfp+-37872 S16 A128])) 1031
{*avx_movv2df_internal} (nil))
vmovaps 304(%rsp), %xmm15 # 4987 *avx_movv2df_internal/2 [length
= 9]
#(insn 2838 4987 4986 ac.f90:503 (set (reg:V2DF 52 xmm15)
#(div:V2DF (reg:V2DF 52 xmm15)
#(mem:V2DF (plus:DI (reg/f:DI 7 sp)
#(const_int 32432 [0x7eb0])) [2 *vect_pdclroo.541_5123+0
S16 A128]))) 1100 {avx_divv2df3} (nil))
Comments from Uros:
You are changing V4SFmode to V2DF mode. Since this combination is not
allowed by MODES_TIEABLE_P (and/or CANNOT_CHANGE_MODE_CLASS), value
gets reloaded through the memory. You can perhaps experiment with
these two macros a bit.
--
Summary: Redundant loads and stores generated for AMD bdver1
target
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: harsha dot jagasia at amd dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44142
[Bug target/44142] Redundant loads and stores generated for AMD bdver1 target
--- Comment #1 from hjl dot tools at gmail dot com 2010-05-14 15:31 --- *** This bug has been marked as a duplicate of 44141 *** -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44142
[Bug target/44141] Redundant loads and stores generated for AMD bdver1 target
--- Comment #1 from hjl dot tools at gmail dot com 2010-05-14 15:31 --- *** Bug 44142 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44141
[Bug c++/43915] Compiler flags error: error: invalid initialization of reference of type 'boost::thread' from expression of type 'boost::thread'
--- Comment #12 from redi at gcc dot gnu dot org 2010-05-14 15:36 --- (In reply to comment #11) 2. Modify gcc.hpp to disable the conditional compilation of rvalue references (temporarily, until that part of the code works with g++) diff gcc.hpp.orig gcc.hpp 124c124,125 # define BOOST_HAS_RVALUE_REFS // # define BOOST_HAS_RVALUE_REFS # define BOOST_NO_RVALUE_REFERENCES Or you can do it without editing the boost headers by defining BOOST_COMPILER_CONFIG to refer to a modified version ofthe gcc.hpp header -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43915
[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared
--- Comment #28 from dougsemler at gmail dot com 2010-05-14 15:49 --- I tried adding -nostdinc++ via --enable-cxx-flags configure option, but those aren't passed through to the pch compilation...and I'm not sure that it's appropriate to pass all the --enable-cxx-flags to the pch generation Makefile anyway. Seems to me that -nostdinc++ would be the correct thing to do (are the cross compiler's header set appropriate for inclusion into the pch??), but it won't necessarily work if the cross-target compiler isn't g++, right? -- dougsemler at gmail dot com changed: What|Removed |Added CC||dougsemler at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974
[Bug lto/44143] New: -fdump-tree-all for lto does not work as expected
PR 41564 came back. -- Summary: -fdump-tree-all for lto does not work as expected Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44143
[Bug lto/44143] -fdump-tree-all for lto does not work as expected
-- hjl dot tools at gmail dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44143
[Bug fortran/44135] Negative array bounds lead to spurious warning
--- Comment #2 from kargl at gcc dot gnu dot org 2010-05-14 16:23 --- The problem seems to be triggered by the upper bound value of 0. If I change it to 1 or -1 in both the main program and the subroutine, then the warning is not triggered. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.3.5 4.4.3 4.5.1 4.6.0 Last reconfirmed|-00-00 00:00:00 |2010-05-14 16:23:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44135
[Bug lto/44143] [4.6 Regression] -fdump-tree-all for lto does not work as expected
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-05-14 16:26 --- Did it? ./xgcc -B. -o t 1.c 2.c -flto -fdump-tree-optimized ls t.142t.optimized 1.c.142t.optimized 2.c.142t.optimized 1.c.142t.optimized 2.c.142t.optimized t.142t.optimized or do you mean with -fwhopr? Yes, there it might have been - but I'd like to change 4.5 behavior there anyway. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|-fdump-tree-all for lto does|[4.6 Regression] -fdump- |not work as expected|tree-all for lto does not ||work as expected http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44143
