[Bug target/24344] testsuite failure: gcc.c-torture/execute/frame-address.c -O2 and above

[hp at gcc dot gnu dot org]

--- Comment #4 from hp at gcc dot gnu dot org  2010-06-22 04:58 ---
FWIW, I didn't see this with r158717 (late April), so I think I'll just close
this PR. No, I don't think it's the same issue as PR44505; after all, these are
two wildly different architectures for which the test failed at very different
revisions. And, the MMIX port doesn't have sibling calls.


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24344

[Bug fortran/44582] gfortran generates wrong results due to wrong ABI in function with array return

[paul dot richard dot thomas at gmail dot com]

--- Comment #13 from paul dot richard dot thomas at gmail dot com  
2010-06-22 04:36 ---
Subject: Re:  gfortran generates wrong results due to wrong 
ABI in function with array return

Dear Tobias,

Thanks for looking through the patch.

> Does use_assoc also include host-associated variables - it should for this
> check. (I have not checked.)

No, it doesn't - I will add such a check.
>
> Additionally allowed without temporary:
>   sym->attr.dummy && sym->attr.intent == INTENT_OUT
> as
>  "If a dummy argument has INTENT (OUT), the actual argument becomes
>   undefined at the time the association is established"
> thus also any access via any method to that variable is undefined - and thus
> invalid.
>
> I think that the LHS is a dummy argument is a very common case and thus it
> makes sense to optimize for INTENT(OUT).
>

Hmmm!  I'll have to think about this business of dummies and their
intent.  Perhaps you could give me an example, where this causes
aliasing?

>
> +       && expr2->value.function.esym
> +       && !expr2->value.function.esym->attr.contained)
>
> Doesn't this not also unnecessarily prohibit
>  contains
>    subroutine a()
>      dimension :: x(4)
>      x = f()
>    end subroutine
>    function f()
> as "f" is contained (in the same namespace as "a"? Or is this not set for the
> "sym" as available in the namespace of "a"?

The check for host association of x is needed to suppress this case
from producing a temporary.

>
>
> Otherwise, the patch looks OK.
>
>> +   /* TODO a function that could correctly be declared PURE but is not
>> +      could do with returning false as well.  */
>
> (Well said, but not easily to be implemented. Actually, that could be a weaker
> check as pure routines may not do I/O (on file units) or use (ERROR) STOP and
> the argument INTENT(IN)/VALUE constraints do not matter either.)

Indeed.  I'll have a think about this, whilst I am about it.  It could
be done in resolve.c in parallel with the checks for purity.  I'll
make it a separate patch, though.

Thanks

Paul


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44582

[Bug target/43703] Unexpected floating point precision loss due to ARM NEON autovectorization

[sandra at codesourcery dot com]

--- Comment #6 from sandra at codesourcery dot com  2010-06-22 01:55 ---
Julian's patch overlapped some other NEON changes I was already preparing for
submission, so I did some refactoring before posting it for review.  Here's the
main part of the fix:

http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02102.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43703

[Bug target/24344] testsuite failure: gcc.c-torture/execute/frame-address.c -O2 and above

[hp at gcc dot gnu dot org]

--- Comment #3 from hp at gcc dot gnu dot org  2010-06-22 01:24 ---
(In reply to comment #2)
> Dupe of PR44505?

Unknown, please hold.


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |hp at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2005-10-24 00:09:16 |2010-06-22 01:24:46
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24344

[Bug fortran/44448] 32-bit gfortran.dg/atan2_1.f90 fails on Solaris 1[01]/x86 at -O0

[jvdelisle at gcc dot gnu dot org]

--- Comment #8 from jvdelisle at gcc dot gnu dot org  2010-06-22 01:24 
---
atan2_1.f90 has failed on other platforms before too.  I think we just need:

 ! { dg-options "-ffloat-store" }

or maybe this

 ! { dg-options "-O0 -ffloat-store" }

in the test file.  Can you try that and see if it clears your problem. Add it
right after the line that says ! { dg-do run }


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8

[Bug target/44392] [4.5/4.6 Regression] libgcc compile with --enable-target-optspace (-Os) causes recursion in __bswapsi2

[ramana at gcc dot gnu dot org]

--- Comment #5 from ramana at gcc dot gnu dot org  2010-06-22 00:51 ---
Khem, 

Can you check if this fixes your problem ? Feel free to submit this to
gcc-patches@ if you get around to testing this before me. 

Ramana


diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index 628bd62..9dcceea 100644
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -11296,7 +11296,7 @@
 (define_expand "bswapsi2"
   [(set (match_operand:SI 0 "s_register_operand" "=r")
(bswap:SI (match_operand:SI 1 "s_register_operand" "r")))]
-"TARGET_EITHER"
+"TARGET_EITHER && (arm_arch6 || ( !arm_arch6 && !optimize_size))"
 "
   if (!arm_arch6)
 {


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44392

[Bug target/44392] [4.5/4.6 Regression] libgcc compile with --enable-target-optspace (-Os) causes recursion in __bswapsi2

[ramana at gcc dot gnu dot org]

-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2010-06-22 00:46:00
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44392

[Bug target/44597] [4.6 Regression] FAIL: gcc.c-torture/execute/builtin-prefetch-2.c compilation, ICE

[bernds at gcc dot gnu dot org]

--- Comment #3 from bernds at gcc dot gnu dot org  2010-06-21 23:59 ---
At first glance, it looks like the tricks in the prefetch_cc simply aren't
valid.  It seems to be trying to prevent certain types of addressing modes, but
reload is allowed to change them as it sees fit.

If I read the code right, hppa64 always uses flag_pic and thus the
reg_equiv_invariant machinery has always been disabled previously?

The best solution would be to find a way to write that pattern (and others, if
there are any) in a valid way; otherwise a new target macro might be able to
prevent this optimization on PA (however I don't think there's a guarantee that
this will work reliably).

The frame-address thing appears to be PR44505.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44597

[Bug target/39690] ld: An unknown relocation type 8

[danglin at gcc dot gnu dot org]

--- Comment #5 from danglin at gcc dot gnu dot org  2010-06-21 23:54 ---
Subject: Bug 39690

Author: danglin
Date: Mon Jun 21 23:54:25 2010
New Revision: 161124

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161124
Log:
PR target/39690
config/pa/pa.c (override_options): Disable
-freorder-blocks-and-partition.


Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/config/pa/pa.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39690

[Bug target/44618] Arguments are not passed correctly to out-of-line restore functions.

[pinskia at gcc dot gnu dot org]

--- Comment #10 from pinskia at gcc dot gnu dot org  2010-06-21 23:54 
---
(In reply to comment #9)
> Hummm, I will work on your input, But now I have more questions:
> 
> 1) Why do you call this case as explicit, and function call arguments implicit
> ? The way I see it, this is a special function call (implemented with a
> jump_insn to save space). So, why r11 is not a function call argument ?

Because the insn has a register reference to r11/r1/r12 :) that is the (use
(match_operand: )) part of the rtx.  This is unlike call instructions which
don't have match_operands for function arguments.  That is what I mean explicit
vs implicit.  


> 
> 2) On other targets, and indirect calls, gcc generates a parallel but still
> uses a call_insn to represent it. Which causes build_def_use() to avoid
> register renaming of these arguments.
> So other targets would not be slowed down, because those cases have to be
> avoided.

I mixed up insn rtl codes, woops.  I thought calls was always done using
jump_insn.  Anyways I am saying you are hard coding a target specific
information inside a target generic part of the code.  This is why I think it
is the wrong approach.

> 
> 3) On the other hand, can you give me an example of a jump_insn, with a
> parallel, and a symbol reference, where a register rename would be valid ?
> Wouldn't all those registers be considered function call arguments ?
> (Perhaps I should add a test for the existence of a symbol reference in my
> patch. If the symbol reference is external or global, registers can never be
> renamed !)

>From i386/i386.md:

(define_insn "return_indirect_internal"
  [(return)
   (use (match_operand:SI 0 "register_operand" "r"))]
  "reload_completed"
  "jmp\t%A0"
  [(set_attr "type" "ibr")
   (set_attr "length_immediate" "0")])

Though it is harder to invoke that but still it can happen if I read the code
correctly (the pop needs to be greater than 64k).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44618

[Bug target/39690] ld: An unknown relocation type 8

[danglin at gcc dot gnu dot org]

--- Comment #4 from danglin at gcc dot gnu dot org  2010-06-21 23:51 ---
Subject: Bug 39690

Author: danglin
Date: Mon Jun 21 23:51:10 2010
New Revision: 161123

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161123
Log:
PR target/39690
config/pa/pa.c (override_options): Disable
-freorder-blocks-and-partition.


Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/config/pa/pa.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39690

[Bug target/39690] ld: An unknown relocation type 8

[danglin at gcc dot gnu dot org]

--- Comment #3 from danglin at gcc dot gnu dot org  2010-06-21 23:47 ---
Subject: Bug 39690

Author: danglin
Date: Mon Jun 21 23:47:46 2010
New Revision: 161122

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161122
Log:
PR target/39690
config/pa/pa.c (override_options): Disable
-freorder-blocks-and-partition.


Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/config/pa/pa.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39690

[Bug bootstrap/44621] syntax error in gcc-4.5.0/configure for ksh

[Daniel dot Davies at xerox dot com]

--- Comment #3 from Daniel dot Davies at xerox dot com  2010-06-21 23:47 
---
Yup, another mistake.  The gold build fails.  The version of g++ I'm using to
compile gold is too old (3.4.3 from the solaris distribution).  I'll go try to
make a newer one.

g++ -DHAVE_CONFIG_H -I. -I/tool/gcc/4.5.0/gcc-4.5.0/gold 
-I/tool/gcc/4.5.0/gcc-4.5.0/gold -I/tool/gcc/4.5.0/gcc-4.5.0/gold/../include
-I/tool/gcc/4.5.0/gcc-4.5.0/gold/../elfcpp
-DLOCALEDIR="\"/tool/gcc/4.5.0/i386-pc-solaris2.10/share/locale\""
-DBINDIR="\"/tool/gcc/4.5.0/i386-pc-solaris2.10/bin\""
-DTOOLBINDIR="\"/tool/gcc/4.5.0/i386-pc-solaris2.10/i686-pc-solaris2.10/bin\""
-I./../intl  -W -Wall   -Werror -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-frandom-seed=incremental.o -g -fkeep-inline-functions -MT incremental.o -MD
-MP -MF .deps/incremental.Tpo -c -o incremental.o
/tool/gcc/4.5.0/gcc-4.5.0/gold/incremental.cc
/tool/gcc/4.5.0/gcc-4.5.0/gold/incremental.cc: In function `void
gold::vexplain_no_incremental(const char*, char*)':
/tool/gcc/4.5.0/gcc-4.5.0/gold/incremental.cc:240: error: `vasprintf'
undeclared (first use this function)
/tool/gcc/4.5.0/gcc-4.5.0/gold/incremental.cc:240: error: (Each undeclared
identifier is reported only once for each function it appears in.)
make[5]: *** [incremental.o] Error 1
make[5]: Leaving directory `/tool/gcc/4.5.0/build/gold'
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory `/tool/gcc/4.5.0/build/gold'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/tool/gcc/4.5.0/build/gold'
make[2]: *** [all-stage1-gold] Error 2
make[2]: Leaving directory `/tool/gcc/4.5.0/build'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/tool/gcc/4.5.0/build'
make: *** [bootstrap] Error 2
51 ddavies-metro:/tool/gcc/4.5.0/build:> 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44621

[Bug target/39690] ld: An unknown relocation type 8

[danglin at gcc dot gnu dot org]

--- Comment #2 from danglin at gcc dot gnu dot org  2010-06-21 23:43 ---
Subject: Bug 39690

Author: danglin
Date: Mon Jun 21 23:43:42 2010
New Revision: 161121

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161121
Log:
PR target/39690
config/pa/pa.c (override_options): Disable
-freorder-blocks-and-partition.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/pa/pa.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39690

[Bug bootstrap/44621] syntax error in gcc-4.5.0/configure for ksh

[Daniel dot Davies at xerox dot com]

--- Comment #2 from Daniel dot Davies at xerox dot com  2010-06-21 23:42 
---
Excellent!  Here's where I must have gotten confused. 
http://gcc.gnu.org/install/configure.html says

--enable-gold
Enable support for using gold as the linker. If gold support is enabled
together with --enable-lto, an additional directory lto-plugin will be built.
The code in this directory is a plugin for gold that allows the link-time
optimizer to extract object files with LTO information out of library archives.
See -flto and -fwhopr for details.

Since I have object files in library archive, I assumed that gold was required.

Two other hints: attempting to apply LTO to my large 32-bit application has
absolutely no effect on performance; and attempting to link a 64-bit version of
the same large application results in an error because the linker tries to link
in the 32-bit lto-plugin.so.  I'm hoping that actually having gold available
will help, but perhaps that's just another mistake.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44621

[Bug target/44618] Arguments are not passed correctly to out-of-line restore functions.

[edmar at freescale dot com]

--- Comment #9 from edmar at freescale dot com  2010-06-21 23:36 ---
Hummm, I will work on your input, But now I have more questions:

1) Why do you call this case as explicit, and function call arguments implicit
? The way I see it, this is a special function call (implemented with a
jump_insn to save space). So, why r11 is not a function call argument ?

2) On other targets, and indirect calls, gcc generates a parallel but still
uses a call_insn to represent it. Which causes build_def_use() to avoid
register renaming of these arguments.
So other targets would not be slowed down, because those cases have to be
avoided.

3) On the other hand, can you give me an example of a jump_insn, with a
parallel, and a symbol reference, where a register rename would be valid ?
Wouldn't all those registers be considered function call arguments ?
(Perhaps I should add a test for the existence of a symbol reference in my
patch. If the symbol reference is external or global, registers can never be
renamed !)

Thanks,
Edmar


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44618

[Bug bootstrap/44621] syntax error in gcc-4.5.0/configure for ksh

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-06-21 23:30 ---
>and LTO silently does nothing.

Huh?  gold is not required for lto to work.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44621

[Bug bootstrap/44621] New: syntax error in gcc-4.5.0/configure for ksh

[Daniel dot Davies at xerox dot com]

http://gcc.gnu.org/install/specific.html#ix86-x-solaris210 says to use
/usr/bin/ksh as CONFIG_SHELL on solaris2.

When you do so, gcc-4.5.0/configure emits the following text:

> $TOOL/gcc/4.5.0/gcc-4.5.0/configure 
> --prefix=$TOOL/gcc/4.5.0/i386-pc-solaris2.10 --with-gnu-as --with-gnu-ld 
> --enable-shared --enable-lto --with-libelf=/usr/local --enable-gold 
> --enable-stage1-languages=c,c++ i686-pc-solaris2.10
configure: WARNING: you should use --build, --host, --target
checking build system type... i686-pc-solaris2.10
checking host system type... i686-pc-solaris2.10
checking target system type... i686-pc-solaris2.10
checking for a BSD-compatible install... /opt/sfw/bin/install -c
checking whether ln works... yes
checking whether ln -s works... yes
checking for a sed that does not truncate output... /opt/sfw/bin/sed
checking for gawk... gawk
/tool/gcc/4.5.0/gcc-4.5.0/configure: : cannot execute
/tool/gcc/4.5.0/gcc-4.5.0/configure: intl: not found
... and then the rest of the normal config output

The result of the "cannot execute" is that gold is not built and LTO silently
does nothing.

The problem can be fixed by converting line 3100 of configure as follows. 
Convert
configdirs="`echo " ${configdirs} " | sed -e 's/ ld / gold /'`"
into
configdirs=`echo " ${configdirs} " | sed -e 's/ ld / gold /'`


-- 
   Summary: syntax error in gcc-4.5.0/configure for ksh
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Daniel dot Davies at xerox dot com
 GCC build triplet: i386-pc-solaris2.10
  GCC host triplet: i386-pc-solaris2.10
GCC target triplet: i386-pc-solaris2.10


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44621

[Bug target/44597] [4.6 Regression] FAIL: gcc.c-torture/execute/builtin-prefetch-2.c compilation, ICE

[danglin at gcc dot gnu dot org]

--- Comment #2 from danglin at gcc dot gnu dot org  2010-06-21 23:20 ---
This change also probably introduced the following fails on
hppa-unknown-linux-gnu:

FAIL: gcc.c-torture/execute/frame-address.c execution,  -O2 
FAIL: gcc.c-torture/execute/frame-address.c execution,  -O3
-fomit-frame-pointer

FAIL: gcc.c-torture/execute/frame-address.c execution,  -O3 -g 
FAIL: gcc.c-torture/execute/frame-address.c execution,  -Os 
FAIL: gcc.c-torture/execute/frame-address.c execution,  -O2 -flto 
FAIL: gcc.c-torture/execute/frame-address.c execution,  -O2 -fwhopr 


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44597

[Bug preprocessor/38105] -Wundef -Werror -Wno-error=undef result in error, not warning

[jsm28 at gcc dot gnu dot org]

--- Comment #5 from jsm28 at gcc dot gnu dot org  2010-06-21 23:17 ---
This appears to be fixed on trunk, probably by:

2010-04-07  Simon Baldwin  

* directives.c (do_diagnostic): Add warning reason argument,
call appropriate error reporting function for code.
[...]


-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||4.6.0
 Resolution||FIXED
   Target Milestone|--- |4.6.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38105

[Bug target/44597] [4.6 Regression] FAIL: gcc.c-torture/execute/builtin-prefetch-2.c compilation, ICE

[danglin at gcc dot gnu dot org]

--- Comment #1 from danglin at gcc dot gnu dot org  2010-06-21 23:03 ---
This was introduced by the following change:

Author: bernds
Date: Thu Jun 17 21:51:55 2010
New Revision: 160947

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160947
Log:
PR rtl-optimization/39871
* reload1.c (init_eliminable_invariants): For flag_pic, disable
equivalences only for constants that aren't LEGITIMATE_PIC_OPERAND_P.
(function_invariant_p): Rule out a plus of frame or arg pointer with
a SYMBOL_REF.
* ira.c (find_reg_equiv_invariant_const): Likewise.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira.c
trunk/gcc/reload1.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44597

[Bug target/44615] -mtune=atom failed on sse2-vec-2.c and amd64-abi-3.c

[hjl at gcc dot gnu dot org]

--- Comment #8 from hjl at gcc dot gnu dot org  2010-06-21 21:59 ---
Subject: Bug 44615

Author: hjl
Date: Mon Jun 21 21:58:38 2010
New Revision: 161119

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161119
Log:
Properly handle psrldq when optimizing for Atom.

gcc/

2010-06-21  H.J. Lu  

Backport from mainline
2010-06-21  H.J. Lu  

PR target/44615
* config/i386/atom.md (atom_sseishft_2): Also check sseishft1.

* config/i386/i386.md (type): Add sseishft1

* config/i386/ppro_insn (ppro_insn): Also check sseishft1.
(ppro_insn_load): Likewise.
(ppro_insn_store): Likewise.
(ppro_insn_both): Likewise.

* config/i386/sse.md (sse2_lshrv1ti3): Add atom_unit.
(*vec_extractv2di_1_rex64_avx): Replace sseishft with sseishft1
for type.
(*vec_extractv2di_1_avx): Likewise.
(*vec_extractv2di_1_rex64): Replace sseishft with sseishft1 for
type.  Remove atom_unit.
(*vec_extractv2di_1_sse2): Likewise.

gcc/testsuite/

2010-06-21  H.J. Lu  

Backport from mainline
2010-06-21  H.J. Lu  

PR target/44615
* gcc.target/i386/sse2-vec-2a.c: New.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/sse2-vec-2a.c
Modified:
branches/gcc-4_5-branch/gcc/config/i386/atom.md
branches/gcc-4_5-branch/gcc/config/i386/i386.md
branches/gcc-4_5-branch/gcc/config/i386/ppro.md
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=44615

[Bug target/44615] -mtune=atom failed on sse2-vec-2.c and amd64-abi-3.c

[hjl at gcc dot gnu dot org]

--- Comment #7 from hjl at gcc dot gnu dot org  2010-06-21 21:57 ---
Subject: Bug 44615

Author: hjl
Date: Mon Jun 21 21:56:47 2010
New Revision: 161118

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161118
Log:
Properly handle psrldq when optimizing for Atom.

gcc/

2010-06-21  H.J. Lu  

PR target/44615
* config/i386/atom.md (atom_sseishft_2): Also check sseishft1.

* config/i386/i386.md (type): Add sseishft1

* config/i386/ppro_insn (ppro_insn): Also check sseishft1.
(ppro_insn_load): Likewise.
(ppro_insn_store): Likewise.
(ppro_insn_both): Likewise.

* config/i386/sse.md (sse2_lshrv1ti3): Add atom_unit.
(*vec_extractv2di_1_rex64_avx): Replace sseishft with sseishft1
for type.
(*vec_extractv2di_1_avx): Likewise.
(*vec_extractv2di_1_rex64): Replace sseishft with sseishft1 for
type.  Remove atom_unit.
(*vec_extractv2di_1_sse2): Likewise.

gcc/testsuite/

2010-06-21  H.J. Lu  

PR target/44615
* gcc.target/i386/sse2-vec-2a.c: New.

Added:
trunk/gcc/testsuite/gcc.target/i386/sse2-vec-2a.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/atom.md
trunk/gcc/config/i386/i386.md
trunk/gcc/config/i386/ppro.md
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44615

[Bug target/44618] Arguments are not passed correctly to out-of-line restore functions.

[pinskia at gcc dot gnu dot org]

--- Comment #8 from pinskia at gcc dot gnu dot org  2010-06-21 21:29 ---
(In reply to comment #7) 
> I mostly agree with you. But in this case, it is already a hard register (rtl
> generated in epilogue).

No the pattern accepts any registers which means register rename can rename the
register to what ever registers it feels like.  What register rename
constraints has is to do with stuff that are implicit (like hard registers for
inline-asm and function call arguments).  This case we have an explicit operand
which means we need to mark the constraint to be correct.

For an example:
(define_insn "*restore_gpregs_"
 [(match_parallel 0 "any_parallel_operand"
  [(clobber (match_operand:P 1 "register_operand" "=l"))
   (use (match_operand:P 2 "symbol_ref_operand" "s"))
   (use (match_operand:P 3 "gpc_reg_operand" "r"))
   (set (match_operand:P 4 "gpc_reg_operand" "=r")
(match_operand:P 5 "memory_operand" "m"))])]
 ""
 "bl %2"
 [(set_attr "type" "branch")
  (set_attr "length" "4")])

Should be changed to:
(define_insn "*restore_gpregs_"
 [(match_parallel 0 "any_parallel_operand"
  [(clobber (match_operand:P 1 "register_operand" "=l"))
   (use (match_operand:P 2 "symbol_ref_operand" "s"))
   (use (match_operand:P 3 "gpc_reg_operand" "d"))
   (set (match_operand:P 4 "gpc_reg_operand" "=r")
(match_operand:P 5 "memory_operand" "m"))])]
 ""
 "bl %2"
 [(set_attr "type" "branch")
  (set_attr "length" "4")])

(etc.)
Where d is a new constraint.  Though you might need more than one constraint
and patterns because of the following code:
  RTVEC_ELT (p, offset++)
= gen_rtx_USE (VOIDmode,
   gen_rtx_REG (Pmode, DEFAULT_ABI != ABI_AIX ? 11
   : gpr && !lr ? 12
   : 1));

--- CUT ---
I think you might cause other targets to slow down because of the use of
parallels inside jump instructions (mostly indirect calls).


Thanks,
Andrew Pinski


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44618

[Bug target/44618] Arguments are not passed correctly to out-of-line restore functions.

[edmar at freescale dot com]

--- Comment #7 from edmar at freescale dot com  2010-06-21 21:18 ---
(In reply to comment #6)
> I think this is the wrong fix   I think the problem is in the patterns not
> using a hard register or a constraint that says only those registers can be
> used.
> 
> Confirmed.
> 

I mostly agree with you. But in this case, it is already a hard register (rtl
generated in epilogue).

If the goal is to fix the bug changing only the powerpc end. I must use some
constraint already coded in regrename.c. But, IMHO, I did not see anything
appropriated. So I resorted to the solution I posted ...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44618

[Bug c++/44620] gcc -fvisibility-ms-compat crash when throwing const char*

[soren dot soe at gonsoe dot com]

--- Comment #1 from soren dot soe at gonsoe dot com  2010-06-21 21:13 
---
Created an attachment (id=20971)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20971&action=view)
crash.ii

Attached crash.ii


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44620

[Bug c++/44620] New: gcc -fvisibility-ms-compat crash when throwing const char*

[soren dot soe at gonsoe dot com]

This simple source file causes gcc to crash when compiled with
-fvisibility-ms-compat:

void foo()
{ 
  throw "Help!";
}

% gcc -v -save-temps -c -fvisibility-ms-compat crash.cxx 

Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../../src/lnx32/configure
--prefix=/tools/batonroot/rodin/devkits/lnx32/gcc-4.4.4
--enable-languages=c,c++
Thread model: posix
gcc version 4.4.4 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-fvisibility-ms-compat'
'-mtune=generic'

/tools/batonroot/rodin/devkits/lnx32/gcc-4.4.4/libexec/gcc/i686-pc-linux-gnu/4.4.4/cc1plus
-E -quiet -v -D_GNU_SOURCE crash.cxx -mtune=generic -fvisibility-ms-compat
-fpch-preprocess -o crash.ii
ignoring nonexistent directory
"/tools/batonroot/rodin/devkits/lnx32/gcc-4.4.4/lib/gcc/i686-pc-linux-gnu/4.4.4/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/tools/batonroot/rodin/devkits/lnx32/gcc-4.4.4/lib/gcc/i686-pc-linux-gnu/4.4.4/../../../../include/c++/4.4.4

/tools/batonroot/rodin/devkits/lnx32/gcc-4.4.4/lib/gcc/i686-pc-linux-gnu/4.4.4/../../../../include/c++/4.4.4/i686-pc-linux-gnu

/tools/batonroot/rodin/devkits/lnx32/gcc-4.4.4/lib/gcc/i686-pc-linux-gnu/4.4.4/../../../../include/c++/4.4.4/backward
 /usr/local/include
 /tools/batonroot/rodin/devkits/lnx32/gcc-4.4.4/include

/tools/batonroot/rodin/devkits/lnx32/gcc-4.4.4/lib/gcc/i686-pc-linux-gnu/4.4.4/include

/tools/batonroot/rodin/devkits/lnx32/gcc-4.4.4/lib/gcc/i686-pc-linux-gnu/4.4.4/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-fvisibility-ms-compat'
'-mtune=generic'

/tools/batonroot/rodin/devkits/lnx32/gcc-4.4.4/libexec/gcc/i686-pc-linux-gnu/4.4.4/cc1plus
-fpreprocessed crash.ii -quiet -dumpbase crash.cxx -mtune=generic -auxbase
crash -version -fvisibility-ms-compat -o crash.s
GNU C++ (GCC) version 4.4.4 (i686-pc-linux-gnu)
compiled by GNU C version 4.4.4, GMP version 5.0.1, MPFR version 2.4.2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: b301e3deb4f2be9f847ad7d75351dd84
crash.cxx:3: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

I am not sure how to attach the .ii file, but the content is pasted here:

# 1 "crash.cxx"
# 1 ""
# 1 ""
# 1 "crash.cxx"
void foo()
{
  throw "Help!";
}


-- 
   Summary: gcc -fvisibility-ms-compat crash when throwing const
char*
   Product: gcc
   Version: 4.4.4
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: soren dot soe at gonsoe dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44620

[Bug fortran/44584] [4.6 Regression] gfortran.dg/typebound_proc_15.f03 failed

[hjl dot tools at gmail dot com]

--- Comment #11 from hjl dot tools at gmail dot com  2010-06-21 21:00 
---
Revision 161061 has the same bug.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44584

[Bug fortran/44584] [4.6 Regression] gfortran.dg/typebound_proc_15.f03 failed

[hjl dot tools at gmail dot com]

--- Comment #10 from hjl dot tools at gmail dot com  2010-06-21 20:57 
---
Revision 161041 deosn't fix it on Linux/x86-64. I got

valgrind --tool=memcheck  ./f951
/export/gnu/import/rrs/161041/src/gcc/testsuite/gfortran.dg/typebound_proc_15.f03
-quiet -dumpbase typebound_proc_15.f03 -mtune=generic -march=pentium4 -auxbase
typebound_proc_15 -std=f2003 -version -o typebound_proc_15.s
-fintrinsic-modules-path finclude -m32

Error: Fortran 2008: PROCEDURE list at (1)
==7012== Invalid read of size 8
==7012==at 0x4A5935: add_proc_component (class.c:223)
==7012==by 0x4A5A97: add_proc_comps (class.c:251)
==7012==by 0x4A5CFD: add_procs_to_declared_vtab1 (class.c:296)
==7012==by 0x4A615C: add_procs_to_declared_vtab (class.c:386)
==7012==by 0x4A6BAE: gfc_find_derived_vtab (class.c:626)
==7012==by 0x4A5711: gfc_build_class_symbol (class.c:177)
==7012==by 0x4ACB46: build_sym (decl.c:1163)
==7012==by 0x4ADF75: variable_decl (decl.c:1756)
==7012==by 0x4B106E: gfc_match_data_decl (decl.c:3857)
==7012==by 0x504FD3: match_word (parse.c:65)
==7012==by 0x5057F1: decode_statement (parse.c:284)
==7012==by 0x506F99: next_free (parse.c:723)
==7012==  Address 0x7367d78 is 40 bytes inside a block of size 48 free'd
==7012==at 0x4C23D72: free (vg_replace_malloc.c:325)
==7012==by 0x4F7039: gfc_free (misc.c:51)
==7012==by 0x542D64: gfc_delete_symtree (symbol.c:2376)
==7012==by 0x54396E: gfc_undo_symbols (symbol.c:2843)
==7012==by 0x507F35: reject_statement (parse.c:1647)
==7012==by 0x504FFA: match_word (parse.c:70)
==7012==by 0x506321: decode_statement (parse.c:423)
==7012==by 0x506F99: next_free (parse.c:723)
==7012==by 0x507369: next_statement (parse.c:908)
==7012==by 0x508311: parse_derived_contains (parse.c:1870)
==7012==by 0x50876C: parse_derived (parse.c:2075)
==7012==by 0x509329: parse_spec (parse.c:2531)
==7012== 
==7012== Invalid read of size 1
==7012==at 0x527852: resolve_fl_derived (resolve.c:10831)
==7012==by 0x529649: resolve_symbol (resolve.c:11445)
==7012==by 0x5445E5: traverse_ns (symbol.c:3313)
==7012==by 0x544614: traverse_ns (symbol.c:3316)
==7012==by 0x544653: gfc_traverse_ns (symbol.c:3329)
==7012==by 0x52C83F: resolve_types (resolve.c:12909)
==7012==by 0x52CC3E: gfc_resolve (resolve.c:13005)
==7012==by 0x50BBF1: gfc_parse_file (parse.c:4371)
==7012==by 0x54C51E: gfc_be_parse_file (f95-lang.c:236)
==7012==by 0xA1E78A: compile_file (toplev.c:1012)
==7012==by 0xA20A39: do_compile (toplev.c:2377)
==7012==by 0xA20B0F: toplev_main (toplev.c:2419)
==7012==  Address 0x7367bac is 76 bytes inside a block of size 424 free'd
==7012==at 0x4C23D72: free (vg_replace_malloc.c:325)
==7012==by 0x4F7039: gfc_free (misc.c:51)
==7012==by 0x542FE0: gfc_free_symbol (symbol.c:2482)
==7012==by 0x5439C0: gfc_undo_symbols (symbol.c:2849)
==7012==by 0x507F35: reject_statement (parse.c:1647)
==7012==by 0x504FFA: match_word (parse.c:70)
==7012==by 0x506321: decode_statement (parse.c:423)
==7012==by 0x506F99: next_free (parse.c:723)
==7012==by 0x507369: next_statement (parse.c:908)
==7012==by 0x508311: parse_derived_contains (parse.c:1870)
==7012==by 0x50876C: parse_derived (parse.c:2075)
==7012==by 0x509329: parse_spec (parse.c:2531)
==7012== 
==7012== Invalid read of size 1
==7012==at 0x5278A0: resolve_fl_derived (resolve.c:10838)
==7012==by 0x529649: resolve_symbol (resolve.c:11445)
==7012==by 0x5445E5: traverse_ns (symbol.c:3313)
==7012==by 0x544614: traverse_ns (symbol.c:3316)
==7012==by 0x544653: gfc_traverse_ns (symbol.c:3329)
==7012==by 0x52C83F: resolve_types (resolve.c:12909)
==7012==by 0x52CC3E: gfc_resolve (resolve.c:13005)
==7012==by 0x50BBF1: gfc_parse_file (parse.c:4371)
==7012==by 0x54C51E: gfc_be_parse_file (f95-lang.c:236)
==7012==by 0xA1E78A: compile_file (toplev.c:1012)
==7012==by 0xA20A39: do_compile (toplev.c:2377)
==7012==by 0xA20B0F: toplev_main (toplev.c:2419)
==7012==  Address 0x7367bb1 is 81 bytes inside a block of size 424 free'd
==7012==at 0x4C23D72: free (vg_replace_malloc.c:325)
==7012==by 0x4F7039: gfc_free (misc.c:51)
==7012==by 0x542FE0: gfc_free_symbol (symbol.c:2482)
==7012==by 0x5439C0: gfc_undo_symbols (symbol.c:2849)
==7012==by 0x507F35: reject_statement (parse.c:1647)
==7012==by 0x504FFA: match_word (parse.c:70)
==7012==by 0x506321: decode_statement (parse.c:423)
==7012==by 0x506F99: next_free (parse.c:723)
==7012==by 0x507369: next_statement (parse.c:908)
==7012==by 0x508311: parse_derived_contains (parse.c:1870)
==7012==by 0x50876C: parse_derived (parse.c:2075)
==7012==by 0x509329: parse_spec (parse.c:2531)
==7012== 
==7012== Invalid read of size 1
==7012==at 0x5278B3: resolve_fl_derived (resolve.c:10838)
==7012==by 0x529649: resolve_symbol (resolve.c:11445)
==7012==by 0x5445E5: traverse_ns (symbol.

[Bug c++/44619] [4.6 Regression] Bogus set but not used warning when using pointer to member operators

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-06-21 20:54 ---
Confirmed on the trunk:
GNU C++ (GCC) version 4.6.0 20100621 (experimental) [trunk revision 161061]
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.6.0 20100621 (experimental) [trunk revision
161061], GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||diagnostic
   Last reconfirmed|-00-00 00:00:00 |2010-06-21 20:54:10
   date||
Summary|Bogus set but not used  |[4.6 Regression] Bogus set
   |warning when using pointer  |but not used warning when
   |to member operators |using pointer to member
   ||operators
   Target Milestone|--- |4.6.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44619

[Bug c++/44619] New: Bogus set but not used when using pointer to member operators

[davi dot arnaut at sun dot com]

host:~$ cat bogus.cpp 
struct S { int x, y; };

int main(int argc, char *argv[])
{
  struct S foo;
  int S::*bar = &S::x;
  foo.*bar = 5;
  return foo.*bar;
}
host:~$ g++ -o bogus bogus.cpp -Wunused
bogus.cpp: In function 'int main(int, char**)':
bogus.cpp:5:12: warning: variable 'foo' set but not used
[-Wunused-but-set-variable]
bogus.cpp:6:11: warning: variable 'bar' set but not used
[-Wunused-but-set-variable]
host:~$ g++ --version
g++ (Ubuntu 20100530-0ubuntu1) 4.6.0 20100530 (experimental) [trunk revision
160047]


-- 
   Summary: Bogus set but not used when using pointer to member
operators
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: davi dot arnaut at sun dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44619

[Bug target/44618] Arguments are not passed correctly to out-of-line restore functions.

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2010-06-21 20:34 ---
I think this is the wrong fix   I think the problem is in the patterns not
using a hard register or a constraint that says only those registers can be
used.

Confirmed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|rtl-optimization|target
 Ever Confirmed|0   |1
   GCC host triplet|powerpc-unkonw-linux-gnu|
 GCC target triplet|powerpc-unkonw-linux-gnu|powerpc-linux-gnu
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2010-06-21 20:34:41
   date||
Summary|Arguments are not passed|Arguments are not passed
   |correctly to out-of-line|correctly to out-of-line
   |restore functions.  |restore functions.
   |[4.4][4.5][4.6] |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44618

[Bug target/44615] -mtune=atom failed on sse2-vec-2.c and amd64-abi-3.c

[hjl at gcc dot gnu dot org]

--- Comment #6 from hjl at gcc dot gnu dot org  2010-06-21 20:28 ---
Subject: Bug 44615

Author: hjl
Date: Mon Jun 21 20:28:24 2010
New Revision: 161114

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161114
Log:
Add -mtune=k8 to gcc.target/i386/amd64-abi-3.c.

2010-06-21  H.J. Lu  

Backport from mainline
2010-06-21  H.J. Lu  

PR target/44615
* gcc.target/i386/amd64-abi-3.c: Add -mtune=k8.

Modified:
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/amd64-abi-3.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44615

[Bug target/44615] -mtune=atom failed on sse2-vec-2.c and amd64-abi-3.c

[hjl at gcc dot gnu dot org]

--- Comment #5 from hjl at gcc dot gnu dot org  2010-06-21 20:28 ---
Subject: Bug 44615

Author: hjl
Date: Mon Jun 21 20:28:03 2010
New Revision: 161113

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161113
Log:
Add -mtune=k8 to gcc.target/i386/amd64-abi-3.c.

2010-06-21  H.J. Lu  

Backport from mainline
2010-06-21  H.J. Lu  

PR target/44615
* gcc.target/i386/amd64-abi-3.c: Add -mtune=k8.

Modified:
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/amd64-abi-3.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44615

[Bug target/44615] -mtune=atom failed on sse2-vec-2.c and amd64-abi-3.c

[hjl at gcc dot gnu dot org]

--- Comment #4 from hjl at gcc dot gnu dot org  2010-06-21 20:26 ---
Subject: Bug 44615

Author: hjl
Date: Mon Jun 21 20:26:11 2010
New Revision: 161112

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161112
Log:
Add -mtune=k8 to gcc.target/i386/amd64-abi-3.c.

2010-06-21  H.J. Lu  

PR target/44615
* gcc.target/i386/amd64-abi-3.c: Add -mtune=k8.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/amd64-abi-3.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44615

[Bug rtl-optimization/44618] Arguments are not passed correctly to out-of-line restore functions. [4.4][4.5][4.6]

[edmar at freescale dot com]

--- Comment #5 from edmar at freescale dot com  2010-06-21 20:24 ---
(In reply to comment #0)

Sorry for the spelling, please read "unknown" through out the report.

Thanks
Edmar


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44618

[Bug rtl-optimization/44618] Arguments are not passed correctly to out-of-line restore functions. [4.4][4.5][4.6]

[edmar at freescale dot com]

--- Comment #2 from edmar at freescale dot com  2010-06-21 20:15 ---
Created an attachment (id=20968)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20968&action=view)
patch for 4.4


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44618

[Bug rtl-optimization/44618] Arguments are not passed correctly to out-of-line restore functions. [4.4][4.5][4.6]

[edmar at freescale dot com]

--- Comment #4 from edmar at freescale dot com  2010-06-21 20:17 ---
Created an attachment (id=20970)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20970&action=view)
ChangeLog for proposed test case


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44618

[Bug rtl-optimization/44618] Arguments are not passed correctly to out-of-line restore functions. [4.4][4.5][4.6]

[edmar at freescale dot com]

--- Comment #3 from edmar at freescale dot com  2010-06-21 20:17 ---
Created an attachment (id=20969)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20969&action=view)
ChangeLog for propsed patch


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44618

[Bug rtl-optimization/44618] Arguments are not passed correctly to out-of-line restore functions. [4.4][4.5][4.6]

[edmar at freescale dot com]

--- Comment #1 from edmar at freescale dot com  2010-06-21 20:14 ---
Created an attachment (id=20967)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20967&action=view)
patch for 4.5 and 4.6


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44618

[Bug rtl-optimization/44618] New: Arguments are not passed correctly to out-of-line restore functions. [4.4][4.5][4.6]

[edmar at freescale dot com]

On 32 bit powerpc targets, the family of out-of-line restore functions
(_restgpr__x), expects r11 (or something else, depending on the
ABI used) to have the new value of the stack pointer.

Gcc emits rtl that sets r11, and a jump_insn that flags the use of r11.

When compiling the test case with "-Os -frename-registers", the register
rename pass (regrename.c) may rename this r11 def-use chain.

test case:
int
calc (int j)
{
  if (j==0) return 0;
  return calc(j-1)*(j+1);
}

compiled with:
-Os -frename-registers -S

results in assembler like this:
.
.
.
.L3:
addi 4,1,16
b _restgpr_31_x

This problem exists in the 4.4 branch, the 4.5 branch, and in the main
trunk as well.

In general, the optimization avoids renaming registers involved in
argument passing, but only when a call_insn is involved. The attached
patches extends this behavior to jump_insn as well.

Is my approach to fix the problem adequate ?

In case it is, attached are a patch that can be applied to gcc-4.5 and
the trunk, and a specific one for the 4.4 branch. I have bootstraped
and regression tested each of the following:
(All of them completed with no regressions)
Note: I have no WAA privilege.


4.4 branch rev 160848 on target powerpc-unkown-linux-gnu (--with-cpu=603e, G5
hardware)
4.4 branch rev 160838 on target powerpc64-unkown-linux-gnu (--with-cpu=970, G5
hardware)
4.4 branch rev 160837 on target i686-pc-linux (--with-cpu=generic,
--with-arch=i686, Xeon hardware)
4.4 branch rev 160837 on target x86_64-pc-linux (--with-cpu=generic, Xeon
hardware)

4.5 branch rev 160890 on target powerpc-unkown-linux-gnu (--with-cpu=603e, G5
hardware)
4.5 branch rev 160869 on target powerpc64-unkown-linux-gnu (--with-cpu=970, G5
hardware)
4.5 branch rev 160869 on target i686-pc-linux (--with-cpu=generic,
--with-arch=i686, Xeon hardware)
4.5 branch rev 160857 on target x86_64-pc-linux (--with-cpu=generic, Xeon
hardware)

4.6 (trunk) rev 160955 on target powerpc-unkown-linux-gnu (--with-cpu=603e, G5
hardware)
4.6 (trunk) rev 161009 on target powerpc64-unkown-linux-gnu (--with-cpu=970, G5
hardware)
4.6 (trunk) rev 160906 on target i686-pc-linux (--with-cpu=generic,
--with-arch=i686, Xeon hardware)
4.6 (trunk) rev 160919 on target x86_64-pc-linux (--with-cpu=generic, Xeon
hardware)


-- 
   Summary: Arguments are not passed correctly to out-of-line
restore functions. [4.4][4.5][4.6]
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edmar at freescale dot com
  GCC host triplet: powerpc-unkonw-linux-gnu
GCC target triplet: powerpc-unkonw-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44618

[Bug target/44617] Serial Output on the atmega1280 does not work

[scott at perturb dot org]

--- Comment #8 from scott at perturb dot org  2010-06-21 19:03 ---
Here is the full command the arduino ide generates when it compiles code. I
just took the last command for sketch_jun21a.cpp.o (my code) and added the -v
and -save-temps.

avr-gcc -c -g -Os -w -ffunction-sections -fdata-sections -mmcu=atmega1280
-DF_CPU=1600L -DARDUINO=18
-I/home/bakers/arduino-0018/hardware/arduino/cores/arduino
/home/bakers/arduino-0018/hardware/arduino/cores/arduino/wiring.c
-o/tmp/build4637782385548929954.tmp/wiring.c.o 
avr-gcc -c -g -Os -w -ffunction-sections -fdata-sections -mmcu=atmega1280
-DF_CPU=1600L -DARDUINO=18
-I/home/bakers/arduino-0018/hardware/arduino/cores/arduino
/home/bakers/arduino-0018/hardware/arduino/cores/arduino/wiring_analog.c
-o/tmp/build4637782385548929954.tmp/wiring_analog.c.o 
avr-gcc -c -g -Os -w -ffunction-sections -fdata-sections -mmcu=atmega1280
-DF_CPU=1600L -DARDUINO=18
-I/home/bakers/arduino-0018/hardware/arduino/cores/arduino
/home/bakers/arduino-0018/hardware/arduino/cores/arduino/pins_arduino.c
-o/tmp/build4637782385548929954.tmp/pins_arduino.c.o 
avr-gcc -c -g -Os -w -ffunction-sections -fdata-sections -mmcu=atmega1280
-DF_CPU=1600L -DARDUINO=18
-I/home/bakers/arduino-0018/hardware/arduino/cores/arduino
/home/bakers/arduino-0018/hardware/arduino/cores/arduino/wiring_shift.c
-o/tmp/build4637782385548929954.tmp/wiring_shift.c.o 
avr-gcc -c -g -Os -w -ffunction-sections -fdata-sections -mmcu=atmega1280
-DF_CPU=1600L -DARDUINO=18
-I/home/bakers/arduino-0018/hardware/arduino/cores/arduino
/home/bakers/arduino-0018/hardware/arduino/cores/arduino/wiring_digital.c
-o/tmp/build4637782385548929954.tmp/wiring_digital.c.o 
avr-gcc -c -g -Os -w -ffunction-sections -fdata-sections -mmcu=atmega1280
-DF_CPU=1600L -DARDUINO=18
-I/home/bakers/arduino-0018/hardware/arduino/cores/arduino
/home/bakers/arduino-0018/hardware/arduino/cores/arduino/wiring_pulse.c
-o/tmp/build4637782385548929954.tmp/wiring_pulse.c.o 
avr-gcc -c -g -Os -w -ffunction-sections -fdata-sections -mmcu=atmega1280
-DF_CPU=1600L -DARDUINO=18
-I/home/bakers/arduino-0018/hardware/arduino/cores/arduino
/home/bakers/arduino-0018/hardware/arduino/cores/arduino/WInterrupts.c
-o/tmp/build4637782385548929954.tmp/WInterrupts.c.o 
avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections
-mmcu=atmega1280 -DF_CPU=1600L -DARDUINO=18
-I/home/bakers/arduino-0018/hardware/arduino/cores/arduino
/home/bakers/arduino-0018/hardware/arduino/cores/arduino/HardwareSerial.cpp
-o/tmp/build4637782385548929954.tmp/HardwareSerial.cpp.o 
avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections
-mmcu=atmega1280 -DF_CPU=1600L -DARDUINO=18
-I/home/bakers/arduino-0018/hardware/arduino/cores/arduino
/home/bakers/arduino-0018/hardware/arduino/cores/arduino/Print.cpp
-o/tmp/build4637782385548929954.tmp/Print.cpp.o 
avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections
-mmcu=atmega1280 -DF_CPU=1600L -DARDUINO=18
-I/home/bakers/arduino-0018/hardware/arduino/cores/arduino
/home/bakers/arduino-0018/hardware/arduino/cores/arduino/WMath.cpp
-o/tmp/build4637782385548929954.tmp/WMath.cpp.o 
avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections
-mmcu=atmega1280 -DF_CPU=1600L -DARDUINO=18
-I/home/bakers/arduino-0018/hardware/arduino/cores/arduino
/home/bakers/arduino-0018/hardware/arduino/cores/arduino/main.cpp
-o/tmp/build4637782385548929954.tmp/main.cpp.o 
avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections
-mmcu=atmega1280 -DF_CPU=1600L -DARDUINO=18
-I/home/bakers/arduino-0018/hardware/arduino/cores/arduino
/home/bakers/arduino-0018/hardware/arduino/cores/arduino/Tone.cpp
-o/tmp/build4637782385548929954.tmp/Tone.cpp.o 
avr-ar rcs /tmp/build4637782385548929954.tmp/core.a
/tmp/build4637782385548929954.tmp/wiring.c.o 
avr-ar rcs /tmp/build4637782385548929954.tmp/core.a
/tmp/build4637782385548929954.tmp/wiring_analog.c.o 
avr-ar rcs /tmp/build4637782385548929954.tmp/core.a
/tmp/build4637782385548929954.tmp/pins_arduino.c.o 
avr-ar rcs /tmp/build4637782385548929954.tmp/core.a
/tmp/build4637782385548929954.tmp/wiring_shift.c.o 
avr-ar rcs /tmp/build4637782385548929954.tmp/core.a
/tmp/build4637782385548929954.tmp/wiring_digital.c.o 
avr-ar rcs /tmp/build4637782385548929954.tmp/core.a
/tmp/build4637782385548929954.tmp/wiring_pulse.c.o 
avr-ar rcs /tmp/build4637782385548929954.tmp/core.a
/tmp/build4637782385548929954.tmp/WInterrupts.c.o 
avr-ar rcs /tmp/build4637782385548929954.tmp/core.a
/tmp/build4637782385548929954.tmp/HardwareSerial.cpp.o 
avr-ar rcs /tmp/build4637782385548929954.tmp/core.a
/tmp/build4637782385548929954.tmp/Print.cpp.o 
avr-ar rcs /tmp/build4637782385548929954.tmp/core.a
/tmp/build4637782385548929954.tmp/WMath.cpp.o 
avr-ar rcs /tmp/build4637782385548929954.tmp/core.a
/tmp/build4637782385548929954.tmp/main.cpp.o 
avr-ar rcs /tmp/build4637782385548929954.tmp/core.a
/tmp/build4637782385548929954.tmp/Tone.cpp.o 
avr-g++ 

[Bug target/44617] Serial Output on the atmega1280 does not work

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2010-06-21 18:40 ---
>*.i* 

It should have produced a file that ended in .ii .


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44617

[Bug target/44617] Serial Output on the atmega1280 does not work

[scott at perturb dot org]

--- Comment #6 from scott at perturb dot org  2010-06-21 18:39 ---
For the record, the code I'm attempting to compile is extremely simple. Might
explain why it compiles so cleanly:

---

void setup()   {
  Serial.begin(9600);   
}

void loop() {
  Serial.println("Hello world");
  delay(1000);
}


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44617

[Bug target/44617] Serial Output on the atmega1280 does not work

[scott at perturb dot org]

--- Comment #5 from scott at perturb dot org  2010-06-21 18:38 ---
* the complete command line that triggers the bug;

avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections
-mmcu=atmega1280 -DF_CPU=1600L -DARDUINO=18
-I/home/bakers/arduino-0018/hardware/arduino/cores/arduino
/tmp/build4637782385548929954.tmp/sketch_jun21a.cpp
-o/tmp/build4637782385548929954.tmp/sketch_jun21a.cpp.o

* the compiler output (error messages, warnings, etc.); and

I don't get any? Not sure if this is right, but it appears to compile 100%
clean.

* the preprocessed file (*.i*) that triggers the bug, generated by adding
-save-temps to the complete compilation command, or, in the case of a bug
report for the GNAT front end, a complete set of source files (see below).

If I add -v -save-temps I do not get any *.i* files created. Perhaps my syntax
is wrong?

avr-g++ -v -save-temps -c -g -Os -w -fno-exceptions -ffunction-sections
-fdata-sections -mmcu=atmega1280 -DF_CPU=1600L -DARDUINO=18
-I/home/bakers/arduino-0018/hardware/arduino/cores/arduino
/tmp/build4637782385548929954.tmp/sketch_jun21a.cpp
-o/tmp/build4637782385548929954.tmp/sketch_jun21a.cpp.o


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44617

[Bug target/24344] testsuite failure: gcc.c-torture/execute/frame-address.c -O2 and above

[ubizjak at gmail dot com]

--- Comment #2 from ubizjak at gmail dot com  2010-06-21 18:30 ---
Dupe of PR44505?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24344

[Bug fortran/44616] [OOP] ICE if CLASS(foo) is used before its definition

[janus at gcc dot gnu dot org]

--- Comment #1 from janus at gcc dot gnu dot org  2010-06-21 18:30 ---
Here is a fix:

Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (revision 161045)
+++ gcc/fortran/resolve.c   (working copy)
@@ -11136,6 +11136,7 @@ resolve_fl_derived (gfc_symbol *sym)
   /* If this is a non-ABSTRACT type extending an ABSTRACT one, ensure that
  all DEFERRED bindings are overridden.  */
   if (super_type && super_type->attr.abstract && !sym->attr.abstract
+  && !sym->attr.is_class
   && ensure_not_abstract (sym, super_type) == FAILURE)
 return FAILURE;



-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |janus at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-06-21 18:30:07
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44616

[Bug target/44617] Serial Output on the atmega1280 does not work

[scott at perturb dot org]

--- Comment #4 from scott at perturb dot org  2010-06-21 18:13 ---
(In reply to comment #3)
> Can you also try on a FSF released GCC rather than one that has been modified
> by the Fedora project?

That might be harder... I do see from the two forum posts that the bug persists
in GCC from Mandrake, OpenSuse, Ubuntu, and Mac OSX.

I'll see what I can come up with.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44617

[Bug target/44617] Serial Output on the atmega1280 does not work

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2010-06-21 18:10 ---
Can you also try on a FSF released GCC rather than one that has been modified
by the Fedora project?


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c++ |target
 GCC target triplet||avr-elf


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44617

[Bug middle-end/44505] [4.6 Regression] gcc.c-torture/execute/frame-address.c

[uros at gcc dot gnu dot org]

--- Comment #8 from uros at gcc dot gnu dot org  2010-06-21 18:08 ---
Subject: Bug 44505

Author: uros
Date: Mon Jun 21 18:07:59 2010
New Revision: 161105

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161105
Log:
PR testsuite/44505
* gcc.c-torture/execute/frame-address.c (check_fa): Avoid
tail call to check_fa_mid.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.c-torture/execute/frame-address.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44505

[Bug c++/44617] Serial Output on the atmega1280 does not work

[scott at perturb dot org]

--- Comment #2 from scott at perturb dot org  2010-06-21 18:07 ---
*  the exact version of GCC;

avr-gcc-c++-4.5.0-1.fc13.x86_64
avr-gcc-4.5.0-1.fc13.x86_64

* the system type;

Compiled on 2.6.33.5-112.fc13.x86_64 but the target was an atmega1280

* the options given when GCC was configured/built;

:avr-g++ -v
Using built-in specs.
COLLECT_GCC=/usr/bin/avr-g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/avr/4.5.0/lto-wrapper
Target: avr
Configured with: ../gcc-4.5.0/configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --target=avr --enable-languages=c,c++ --disable-nls
--disable-libssp --with-system-zlib --enable-version-specific-runtime-libs
--with-pkgversion='Fedora 4.5.0-1.fc13'
--with-bugurl=https://bugzilla.redhat.com/
Thread model: single
gcc version 4.5.0 (Fedora 4.5.0-1.fc13) 

* the complete command line that triggers the bug;
* the compiler output (error messages, warnings, etc.); and
* the preprocessed file (*.i*) that triggers the bug, generated by adding
-save-temps to the complete compilation command, or, in the case of a bug
report for the GNAT front end, a complete set of source files (see below).

It's on my machine at home so I'll have to get this information for you at a
later time.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44617

[Bug fortran/44614] [OOP] Wrongly importing a symbol into an interface without IMPORT

[janus at gcc dot gnu dot org]

--- Comment #2 from janus at gcc dot gnu dot org  2010-06-21 18:00 ---
Confirmed. Changing the CLASS statement into TYPE gives the correct error:

type(Connection) :: self
1
Error: the type of 'self' at (1) has not been declared within the interface


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-06-21 18:00:04
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44614

[Bug c++/44617] Serial Output on the atmega1280 does not work

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2010-06-21 17:57 
---
Did you read this, before opening the PR?

  http://gcc.gnu.org/bugs/

Please provide all the required information, otherwise nobody will be able to
look at the issue.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
Summary|Serial Output on the|Serial Output on the
   |atmega1280 does not work|atmega1280 does not work


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44617

[Bug libstdc++/44436] [C++0x] Implement insert(&&) and emplace* in associative and unordered containers

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2010-06-21 17:48 
---
I'm working on these, maybe will be ready in time for 4.6.0.


-- 

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|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-06-21 17:48:26
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44436

[Bug libstdc++/44436] [C++0x] Implement insert(&&) and emplace* in associative and unordered containers

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2010-06-21 17:47 
---
Reopening


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |
Summary|Associative containers lack |[C++0x] Implement insert(&&)
   |emplace() and emplace_hint()|and emplace* in associative
   |methods.|and unordered containers


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44436

[Bug c++/44617] New: Serial Output on the atmega1280 does not work

[scott at perturb dot org]

There appears to be some sort of regression with avr-gcc 4.5.0. When compiling
a sketch for the atmega1280 everything works except for serial output. The fix
is to revert to 4.3.x

The issue is documented here: 

http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1276727004/15
and
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1250084886

Everything else (that I've tested) works fine. This issue appears to *only*
affect the atmega1280 chip. As the atmega328 chip does not exhibit this bug
when doing serial output.


-- 
   Summary: Serial Output on the atmega1280 does not work
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: scott at perturb dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44617

[Bug target/44603] out of range branch generated in thumb code.

[raj dot khem at gmail dot com]

--- Comment #4 from raj dot khem at gmail dot com  2010-06-21 17:45 ---
(In reply to comment #3)
> Dupe of PR43961?
> 

yes seems so.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44603

[Bug fortran/41137] inefficient zeroing of an array

[jakub at gcc dot gnu dot org]

--- Comment #11 from jakub at gcc dot gnu dot org  2010-06-21 17:43 ---
What's the reason why gfc_trans_zero_assign insists that len is INTEGER_CST?
At least if it is contiguous (and not assumed size), why can't memset be used
even for non-constant sizes?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41137

[Bug target/44615] -mtune=atom failed on sse2-vec-2.c and amd64-abi-3.c

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2010-06-21 17:23 ---
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02058.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2010-
   ||06/msg02058.html


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44615

[Bug bootstrap/44426] [4.4/4.5/4.6 Regression] gcc 4.5.0 requires c9x compiler to build

[jakub at gcc dot gnu dot org]

--- Comment #17 from jakub at gcc dot gnu dot org  2010-06-21 17:20 ---
Should be fixed now.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44426

[Bug bootstrap/44426] [4.4/4.5/4.6 Regression] gcc 4.5.0 requires c9x compiler to build

[jakub at gcc dot gnu dot org]

--- Comment #16 from jakub at gcc dot gnu dot org  2010-06-21 17:11 ---
Subject: Bug 44426

Author: jakub
Date: Mon Jun 21 17:10:02 2010
New Revision: 161102

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161102
Log:
PR bootstrap/44426
* sel-sched-dump.h (sel_prepare_string_for_dot_label): Remove
prototype.
(sel_print_to_dot): Remove macro.
(sel_print): Likewise.  New prototype.
* sel-sched-dump.c (sel_prepare_string_for_dot_label): Make static.
(sel_print): New function.

Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/sel-sched-dump.c
branches/gcc-4_4-branch/gcc/sel-sched-dump.h


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44426

[Bug bootstrap/44426] [4.4/4.5/4.6 Regression] gcc 4.5.0 requires c9x compiler to build

[jakub at gcc dot gnu dot org]

--- Comment #15 from jakub at gcc dot gnu dot org  2010-06-21 17:07 ---
Subject: Bug 44426

Author: jakub
Date: Mon Jun 21 17:06:48 2010
New Revision: 161100

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161100
Log:
PR bootstrap/44426
* sel-sched-dump.h (sel_prepare_string_for_dot_label): Remove
prototype.
(sel_print_to_dot): Remove macro.
(sel_print): Likewise.  New prototype.
* sel-sched-dump.c (sel_prepare_string_for_dot_label): Make static.
(sel_print): New function.

Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/sel-sched-dump.c
branches/gcc-4_5-branch/gcc/sel-sched-dump.h


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44426

[Bug fortran/41137] inefficient zeroing of an array

[burnus at gcc dot gnu dot org]

--- Comment #10 from burnus at gcc dot gnu dot org  2010-06-21 17:00 ---
(In reply to comment #9)
> (In reply to comment #7)
> > I cannot reproduce the factor of 10 results, however. 
> Here this still is the case (so might depend on the precise architecture):

OK, I was using -fwhole-file out of habit - thus the difference is that small
(all optimization levels, including -O0). Otherwise, I also get the same
factor-of-10 difference. If one splits it in two files, one needs to use "-O3
-flto" to get a fast program.

For comparison, using two files, ifort also shows a factor of 2 to 5 difference
(and is at -O0 ten times slower than gfortran; at -O2 it is twice as fast as
gfortran).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41137

[Bug c++/44613] Declaring an array with non-constant length inside a switch corrupts stack pointer.

[manu at gcc dot gnu dot org]

--- Comment #4 from manu at gcc dot gnu dot org  2010-06-21 16:51 ---
(In reply to comment #3)
> (In reply to comment #1)
> > (In reply to comment #0)
> > > The following program compiles with g++ -O3 without errors or warnings
> > 
> > Not with warnings enabled it doesn't!
> > 
> 
> Sorry,
> 
> g++ -O3 -Wall -Wextra switch-crash.cpp gives:
> 
> switch-crash.cpp: In function ‘int f(int)’:
> switch-crash.cpp:6: warning: unused variable ‘x’
> switch-crash.cpp:10: warning: no return statement in function returning
> non-void

If you add return 0 after the printf, this warning is silenced and it still
crashes (it crashes for me even at -O0).

> switch-crash.cpp:7: warning: ‘saved_stack.1’ is used uninitialized in this
> function
> 
> The ‘saved_stack.1’ is somewhat suspicious. 

It is a bug anyway, because internal variables should never be warned.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-06-21 16:51:06
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44613

[Bug c++/44613] Declaring an array with non-constant length inside a switch corrupts stack pointer.

[mark dot haines at openmarket dot com]

--- Comment #3 from mark dot haines at openmarket dot com  2010-06-21 16:47 
---
(In reply to comment #1)
> (In reply to comment #0)
> > The following program compiles with g++ -O3 without errors or warnings
> 
> Not with warnings enabled it doesn't!
> 

Sorry,

g++ -O3 -Wall -Wextra switch-crash.cpp gives:

switch-crash.cpp: In function ‘int f(int)’:
switch-crash.cpp:6: warning: unused variable ‘x’
switch-crash.cpp:10: warning: no return statement in function returning
non-void
switch-crash.cpp:7: warning: ‘saved_stack.1’ is used uninitialized in this
function

The ‘saved_stack.1’ is somewhat suspicious. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44613

[Bug c++/44613] Declaring an array with non-constant length inside a switch corrupts stack pointer.

[manu at gcc dot gnu dot org]

--- Comment #2 from manu at gcc dot gnu dot org  2010-06-21 16:45 ---
(In reply to comment #1)
> (In reply to comment #0)
> > The following program compiles with g++ -O3 without errors or warnings
> 
> Not with warnings enabled it doesn't!
> 

???


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44613

[Bug target/44615] -mtune=atom failed on sse2-vec-2.c and amd64-abi-3.c

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2010-06-21 16:45 ---
(In reply to comment #0)
> FAIL: gcc.target/i386/sse2-vec-2.c (internal compiler error)
> FAIL: gcc.target/i386/sse2-vec-2.c (test for excess errors)

I got

/export/build/gnu/gcc-atom/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-atom/build-x86_64-linux/gcc/
/export/gnu/import/git/gcc/gcc/testsuite/gcc.target/i386/sse2-vec-2.c   -O2
-msse2 -mtune=atom
In file included from
/export/gnu/import/git/gcc/gcc/testsuite/gcc.target/i386/sse2-vec-2.c:5:0:
/export/gnu/import/git/gcc/gcc/testsuite/gcc.target/i386/sse2-check.h: In
function ‘do_test’:
/export/gnu/import/git/gcc/gcc/testsuite/gcc.target/i386/sse2-check.h:12:1:
internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

The problem is

;; if palignr or psrldq
(define_insn_reservation  "atom_sseishft_2" 1
  (and (eq_attr "cpu" "atom")
   (and (eq_attr "type" "sseishft")
(and (eq_attr "atom_unit" "sishuf")
 (match_operand 2 "immediate_operand"
  "atom-simple-0")

;; if reg/mem op
(define_insn_reservation  "atom_sseishft_3" 2
  (and (eq_attr "cpu" "atom")
   (and (eq_attr "type" "sseishft")
(not (match_operand 2 "immediate_operand"
  "atom-complex, atom-all-eu")

in atom.md. Some patterns, which generate psrldq, don't
have the 3rd operand as shift count.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44615

[Bug fortran/44614] [OOP] Wrongly importing a symbol into an interface without IMPORT

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2010-06-21 16:44 ---
Cf. also PR 44616 for the ICE reported at the mailing list.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44614

[Bug fortran/44616] New: [OOP] ICE if CLASS(foo) is used before its definition

[burnus at gcc dot gnu dot org]

Reported by bd satish at http://gcc.gnu.org/ml/fortran/2010-06/msg00210.html

For the program, gfortran ICEs with:
  f951: internal compiler error: in find_typebound_proc_uop, at
  fortran/class.c:660

The failing assert is:
  gcc_assert (derived->f2k_derived);

Note: The original test case (see link) misses an IMPORT, cf. PR 44614.

The additional derived type is required -- and for the ICE it needs to come
before the actual definition, otherwise, it works.

module factory_pattern
implicit none

type First_Factory
character(len=20) :: factory_type
class(Connection), pointer :: connection_type
contains
end type First_Factory

type, abstract :: Connection
contains
procedure(generic_desc), deferred :: description
end type Connection

abstract interface
subroutine generic_desc(self)
import  ! Required, cf. PR 44614
class(Connection) :: self
end subroutine generic_desc
end interface
end module factory_pattern


-- 
   Summary: [OOP] ICE if CLASS(foo) is used before its definition
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44616

[Bug target/44615] -mtune=atom failed on sse2-vec-2.c and amd64-abi-3.c

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2010-06-21 16:42 ---
(In reply to comment #0)
> FAIL: gcc.target/i386/amd64-abi-3.c scan-assembler subq[\\t ]*\\$88,[\\t 
> ]*%rsp

This is due to -mtune=atom generates:

leaq-88(%rsp), %rsp

instead of

subq$88, %rsp


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

Summary|-mtune=atom failed on sse2- |-mtune=atom failed on sse2-
   |vec-2.c and amd64-abi-3.c   |vec-2.c and amd64-abi-3.c


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44615

[Bug target/44615] New: -mtune=atom failed on sse2-vec-2.c and amd64-abi-3.c

[hjl dot tools at gmail dot com]

On Linux/x86-64, I got

FAIL: gcc.target/i386/amd64-abi-3.c scan-assembler subq[\\t ]*\\$88,[\\t ]*%rsp
FAIL: gcc.target/i386/sse2-vec-2.c (internal compiler error)
FAIL: gcc.target/i386/sse2-vec-2.c (test for excess errors)

with -mtune=atom.


-- 
   Summary: -mtune=atom failed on sse2-vec-2.c and amd64-abi-3.c
   Product: gcc
   Version: 4.4.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
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=44615

[Bug fortran/44614] New: [OOP] Wrongly importing a symbol into an interface without IMPORT

[burnus at gcc dot gnu dot org]

Based on a report by bd satish at
http://gcc.gnu.org/ml/fortran/2010-06/msg00210.html

The following program is invalid as IMPORT is missing, but gfortran still
compiles it:

Expected: An error such as:
  Error: line 12: SELF is of undefined derived type CONNECTION
or
  error #6457: This derived type name has not been declared.   [CONNECTION]


module factory_pattern
implicit none

type, abstract :: Connection
contains
procedure(generic_desc), deferred :: description
end type Connection

abstract interface
subroutine generic_desc(self)
!import
class(Connection) :: self
end subroutine generic_desc
end interface
end module factory_pattern


-- 
   Summary: [OOP] Wrongly importing a symbol into an interface
without IMPORT
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: accepts-invalid, diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44614

[Bug target/44575] [4.5/4.6 Regression] __builtin_va_arg overwrites into adjacent stack location

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2010-06-21 16:34 ---
Subject: Bug 44575

Author: jakub
Date: Mon Jun 21 16:33:49 2010
New Revision: 161097

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161097
Log:
PR target/44575
* config/i386/i386.c (ix86_gimplify_va_arg): When copying
va_arg from a set of register save slots into a temporary,
if the container is bigger than type size, do the copying
using smaller mode or using memcpy.

* gcc.c-torture/execute/pr44575.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr44575.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44575

[Bug c++/44611] Including and hides ::signbit function

[gnu at bluedreamer dot com]

--- Comment #13 from gnu at bluedreamer dot com  2010-06-21 16:31 ---
(In reply to comment #12)
> Is there a reason you changed the component back to c++?
> This is not a problem in the C++ compiler front-end.
> 
I didn't mean to change anything. All I did was reply (maybe browser cached
some post back values)

My apologies - please change it to whatever it should be.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44611

[Bug c++/44611] Including and hides ::signbit function

[redi at gcc dot gnu dot org]

--- Comment #12 from redi at gcc dot gnu dot org  2010-06-21 16:28 ---
Is there a reason you changed the component back to c++?
This is not a problem in the C++ compiler front-end.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44611

[Bug bootstrap/44426] [4.4/4.5/4.6 Regression] gcc 4.5.0 requires c9x compiler to build

[jakub at gcc dot gnu dot org]

--- Comment #14 from jakub at gcc dot gnu dot org  2010-06-21 16:27 ---
Subject: Bug 44426

Author: jakub
Date: Mon Jun 21 16:26:25 2010
New Revision: 161092

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161092
Log:
PR bootstrap/44426
* sel-sched-dump.h (sel_prepare_string_for_dot_label): Remove
prototype.
(sel_print_to_dot): Remove macro.
(sel_print): Likewise.  New prototype.
* sel-sched-dump.c (sel_prepare_string_for_dot_label): Make static.
(sel_print): New function.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/sel-sched-dump.c
trunk/gcc/sel-sched-dump.h


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44426

[Bug c++/44613] Declaring an array with non-constant length inside a switch corrupts stack pointer.

[redi at gcc dot gnu dot org]

--- Comment #1 from redi at gcc dot gnu dot org  2010-06-21 16:22 ---
(In reply to comment #0)
> The following program compiles with g++ -O3 without errors or warnings

Not with warnings enabled it doesn't!


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44613

[Bug c++/44611] Including and hides ::signbit function

[gnu at bluedreamer dot com]

--- Comment #11 from gnu at bluedreamer dot com  2010-06-21 16:20 ---
(In reply to comment #10)
> (In reply to comment #9)
> > Are these still relevant for c++0x? More so section 5 which says if they are
> > macros in C they must be macros in C++
> 
> see 26.8 [c.math] paragraph 11

Thanks. I should probably start using the draft rather then my dusty old 14882
copy.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44611

[Bug c++/44611] Including and hides ::signbit function

[redi at gcc dot gnu dot org]

--- Comment #10 from redi at gcc dot gnu dot org  2010-06-21 16:12 ---
(In reply to comment #9)
> Are these still relevant for c++0x? More so section 5 which says if they are
> macros in C they must be macros in C++

see 26.8 [c.math] paragraph 11


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44611

[Bug c++/44611] Including and hides ::signbit function

[gnu at bluedreamer dot com]

--- Comment #9 from gnu at bluedreamer dot com  2010-06-21 16:07 ---
> I agree the macro and template can't co-exist, but the template could be
> available as both std::signbit and ::signbit, and I think that's required by
> appendix D.

Are these still relevant for c++0x? More so section 5 which says if they are
macros in C they must be macros in C++

17.4.1.2 Headers
4. Except as noted in clauses 18 through 27, the contents of each header cname
shall be the same as that of the corresponding header name.h, as specified in
ISO/IEC 9899:1990 Programming Languages C (Clause 7), or ISO/IEC:1990
Programming Languages—C AMENDMENT 1: C Integrity, (Clause 7), as appropriate,
as if by inclusion. In the C++ Standard Library, however, the declarations and
definitions (except for names which are defined as macros in C) are within
namespace scope (3.3.5) of the namespace std.

5. Names which are defined as macros in C shall be defined as macros in the C++
Standard Library, even if C grants license for implementation as functions.
[Note: the names defined as macros in C include the following: assert, errno,
offsetof, setjmp, va_arg, va_end, and va_start. —end note]


-- 

gnu at bluedreamer dot com changed:

   What|Removed |Added

  Component|libstdc++   |c++


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44611

[Bug libstdc++/44611] Including and hides ::signbit function

[redi at gcc dot gnu dot org]

--- Comment #7 from redi at gcc dot gnu dot org  2010-06-21 15:56 ---
(In reply to comment #6)
> To be honest, I have zero doubts about nullptr_t: nowhere 18.2 hints at
> providing it in the global namespace, per se.

[depr.c.headers]/3
"The header  assuredly provides the same declarations and definitions
within the global namespace"

Note "the same declarations", not "the subset of declarations defined in the C
standard"

> About signbit, if it's a macro in C it has to be undefined in order to
> implement the  facility in c++0x, see 26.8/11. Really, I don't see how
> the macro and the template can co-exist: "The templates defined in 
> replace the C macros with the same names" and the templates are specified in
> namespace std.

I agree the macro and template can't co-exist, but the template could be
available as both std::signbit and ::signbit, and I think that's required by
appendix D.

I agree this isn't ideal, and DR456 tried to help, I don't think DR456 goes far
enough in relaxing the requirements on implementations.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44611

[Bug libstdc++/44611] Including and hides ::signbit function

[paolo dot carlini at oracle dot com]

--- Comment #8 from paolo dot carlini at oracle dot com  2010-06-21 16:02 
---
To be clear: I'm against fiddling with *.h headers, basing on DR456. If you
want to do that, for each C library we support, good luck, but I'm not going to
help, sorry.

And note that appendix D talks about *the C .h headers*, thus anything you do
in the global namespace has to happen via a C *.h header.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44611

[Bug target/44364] Wrong code with e500 double floating point

[Kyle dot D dot Moffett at boeing dot com]

--- Comment #47 from Kyle dot D dot Moffett at boeing dot com  2010-06-21 
15:55 ---
(In reply to comment #41)
> Created an attachment (id=20877)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20877&action=view) [edit]
> e500.h and caller-save.c patch
> 
> The ICE in #38 is due to a bug in caller-save.c

We've basically rebuilt everything in the PowerPCSPE Debian port now, and as
far as I can tell all of the test-cases affected by this bug are fixed by your
attachment 20877 (pr44364.diff).  Now that we've gotten further, Sebastian has
identified a new floating point bug (PR44606), but I believe we can call this
one closed.

Again, many thanks for all your help!

Cheers,
Kyle Moffett


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364

[Bug fortran/41137] inefficient zeroing of an array

[jv244 at cam dot ac dot uk]

--- Comment #9 from jv244 at cam dot ac dot uk  2010-06-21 15:49 ---
(In reply to comment #7)

> I cannot reproduce the factor of 10 results, however. 

Here this still is the case (so might depend on the precise architecture):

/data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/f951
test.f90 -march=k8-sse3 -mcx16 -msahf --param l1-cache-size=64 --param
l1-cache-line-size=64 --param l2-cache-size=1024 -mtune=k8 -quiet -dumpbase
test.f90 -auxbase test -O3 -version -fintrinsic-modules-path
/data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/finclude
-o /tmp/ccXsKXnD.s

> ./a.out
  0.10800600
   1.0520660


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41137

[Bug c++/44613] New: Declaring an array with non-constant length inside a switch corrupts stack pointer.

[mark dot haines at openmarket dot com]

The following program compiles with g++ -O3 without errors or warnings but sets
crash at the first printf. It seems to zero the stack pointer before calling
printf.

- Begin switch-crash.ii
# 1 "switch-crash.cpp"
# 1 ""
# 1 ""
# 1 "switch-crash.cpp"
extern "C" int printf (__const char *__restrict __format, ...);

int f(int len) {
switch(1) {
case 1:
char x[len];
break;
}
printf("Done\n");
}

int main() {
f(1);
printf("Done\n");
}
-- End switch-crash.ii

Output of g++ -v:

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)


-- 
   Summary:  Declaring an array with non-constant length inside a
switch corrupts stack pointer.
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mark dot haines at openmarket dot com
GCC target triplet: x86_64-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44613

[Bug libstdc++/44611] Including and hides ::signbit function

[paolo dot carlini at oracle dot com]

--- Comment #6 from paolo dot carlini at oracle dot com  2010-06-21 15:41 
---
To be honest, I have zero doubts about nullptr_t: nowhere 18.2 hints at
providing it in the global namespace, per se.

About signbit, if it's a macro in C it has to be undefined in order to
implement the  facility in c++0x, see 26.8/11. Really, I don't see how
the macro and the template can co-exist: "The templates defined in 
replace the C macros with the same names" and the templates are specified in
namespace std.

If, on the other hand, we are talking in general about the *.h headers, the
basic point of DR456, finally resolved, is that those headers very often come
together with the C library, over which many C++ library implementations have
***no control*** today (maybe back in the C++98 times people have some other
ideas about the interaction between C and C++ in typical platforms, I don't
know) Irrespective of the details of the resolution, that is the very important
gist of the resolution: implementors of the C++ library are supposed to not
have controls on the internals of the *.h C headers and for sure are not
supposed to add in facilities. If, in corner cases (*), that is still not clear
enough, maybe (other members of) the LWG can further clarify the matter, but
it's clear enough for me ;)

(*) In the past, we had one, that with memchr & co, which has been resolved by
Jakub at the C headers level because  could not be implemented
correctly otherwise. At some point I wanted to raise the issue in the LWG,
because, missing an ISO clarification, we forced in a glibc + v3 solution which
is contrary to the gist of 456.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44611

[Bug fortran/41137] inefficient zeroing of an array

[burnus at gcc dot gnu dot org]

--- Comment #8 from burnus at gcc dot gnu dot org  2010-06-21 15:22 ---
(In reply to comment #7)
> I get for the example the following values, note especially the newly added
> CONTIGUOUS result:

For the test case, see attachment 20966 at PR 44612; that PR I have filled
because GCC does not optimize away the loops, which only set but never read the
value from the variable. (Ifort does this optimization.) Additionally, if one
prints the variable, ifort is twice as fast. For curiosity: Using NAG, the
timing is 0.690 vs. 1.220, i.e. the assumed-shape version is actually
faster [though, its overall the performance is poor].


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41137

[Bug middle-end/44612] -flto -fwhole-program: Never read variable not optimized away

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2010-06-21 15:17 ---
Created an attachment (id=20966)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20966&action=view)
Test case


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44612

[Bug middle-end/44612] New: -flto -fwhole-program: Never read variable not optimized away

[burnus at gcc dot gnu dot org]

Follow up to PR 41137.

Using the Intel compiler, the following program takes 0s for the loops (real
time: 0.005s); however, with
 gfortran -fdump-tree-original -fwhole-program -flto -ffast-math -march=native
-O3 cont.f90
GCC needs 1.142s.

Expected:
* GCC also optimizes the loops away if the variable "a" is never read (but only
set)


Removing the !! comments prevents ifort from optimizing the loops away; still
the performance is with (real time) 0.650s twice as good as the one of GCC.


-- 
   Summary: -flto -fwhole-program: Never read variable not optimized
away
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44612

[Bug fortran/41137] inefficient zeroing of an array

[burnus at gcc dot gnu dot org]

--- Comment #7 from burnus at gcc dot gnu dot org  2010-06-21 15:02 ---
(In reply to comment #1)
> Just for reference, the difference in time between the two variants is truly
> impressive. About a factor of 11 with gcc 4.4 and 8 with gcc 4.5.

I get for the example the following values, note especially the newly added
CONTIGUOUS result:

  0.31601900 - assumed-shape
  0.21601403 - assumed-shape CONTIGUOUS 
  0.21601295  - explicit size (n,n,...)
  0.20801300  - explicit size (10,10,...)
  0.21601403  - explicit size (10*10*...)

Ignoring some measuring noise, assumed-shape is 46% (-O0) to 25% (-O3) slower
than explicit  size, but using the CONTIGUOUS attribute, the performance is
re-gained. I cannot reproduce the factor of 10 results, however. What surprises
me a bit is that -flto -fwhole-program does not reduce the speed penalty of
assumed-shape arrays.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41137

[Bug target/44546] [4.5/4.6 Regression] ICE in extract_insn, at recog.c:2103 with -ffast-math -Os (compiling graphviz)

[ubizjak at gmail dot com]

--- Comment #11 from ubizjak at gmail dot com  2010-06-21 14:53 ---
Fixed.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44546

[Bug target/44546] [4.5/4.6 Regression] ICE in extract_insn, at recog.c:2103 with -ffast-math -Os (compiling graphviz)

[uros at gcc dot gnu dot org]

--- Comment #10 from uros at gcc dot gnu dot org  2010-06-21 14:52 ---
Subject: Bug 44546

Author: uros
Date: Mon Jun 21 14:52:07 2010
New Revision: 161085

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161085
Log:
PR target/44546
* config/i386/predicates.md (ix86_swapped_fp_comparsion_operator):
New predicate.
* config/i386/i386.md (*fp_jcc_8_387 and splitters): Use
ix86_swapped_fp_comparsion_operator instead of
ix86_fp_comparison_operator.

(*fp_jcc_1_387): Rename from *fp_jcc_3_387.
(*fp_jcc_1r_387): Rename from *fp_jcc_4_387.
(*fp_jcc_2_387): Rename from *fp_jcc_5_387.
(*fp_jcc_2r_387): Rename from *fp_jcc_6_387.
(*fp_jcc_3_387): Rename from *fp_jcc_7_387.
(*fp_jcc_4__387): Rename from *fp_jcc_8_387.

testsuite/ChangeLog:

PR target/44546
* gcc.target/i386/pr44546.c: New test.


Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/pr44546.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/config/i386/i386.md
branches/gcc-4_5-branch/gcc/config/i386/predicates.md
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44546

[Bug libstdc++/44611] Including and hides ::signbit function

[redi at gcc dot gnu dot org]

--- Comment #5 from redi at gcc dot gnu dot org  2010-06-21 14:52 ---
But should std::signbit be available as ::signbit when  is included, at
least for c++0x mode?

[depr.c.headers]/2 says
"Every C header, each of which has a name of the form name.h, behaves as if
each name placed in the standard library namespace by the corresponding cname
header is placed within the global namespace scope."

signbit is placed in namespace std by  which says to me that it should
be placed in the global namespace by 

(I'm still unsure whether the same applies to  and std::nullptr_t)


-- 

redi at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c++ |libstdc++


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44611

[Bug fortran/40632] Support F2008's contiguous attribute

[burnus at gcc dot gnu dot org]

--- Comment #4 from burnus at gcc dot gnu dot org  2010-06-21 14:44 ---
FIXED on the trunk.  Related items: is_contiguous() intrinsic and DO CONCURRENT
construct.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40632

[Bug c++/44611] Including and hides ::signbit function

[paolo dot carlini at oracle dot com]

--- Comment #4 from paolo dot carlini at oracle dot com  2010-06-21 14:44 
---
I don't think signbit is special: including *any*  header first undefs the
names, thus if they are defined as macros in C, you don't see them anymore in
the global namespace, only in std::. If, on the other hand, your specific point
is one about the C99 classification macros, yes those are enabled by default,
can be disabled at library configure time with --disable-c99. In fact the issue
whether C99 facilities should be enabled by default in c++98 mode is a very old
one, you can find traces of it in bugzilla for sure, and now is definitely *way
too old* to change our decision, considering that all of that is standard in
c++0x, which is behind the corner.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

Summary|Including  and  |Including  and
   | hides ::signbit | hides ::signbit
   |function|function


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44611

[Bug c++/44609] Invalid template code causes infinite loop of error messages

[chris at bubblescope dot net]

--- Comment #6 from chris at bubblescope dot net  2010-06-21 14:35 ---
Of course, there is a big difference between an ICE and an infinite loop. Also,
bug which causes ICEs on one computer and not another need treating with great
care, as that suggests unpredictable memory corruption may be occurring.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44609

[Bug fortran/44584] [4.6 Regression] gfortran.dg/typebound_proc_15.f03 failed

[hjl dot tools at gmail dot com]

--- Comment #9 from hjl dot tools at gmail dot com  2010-06-21 14:32 ---
Test starts to pass between revision 161046 and revision
161055 on Linux/ia64. Does anyone know which checkin fixes
this? This that a real fix?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44584

[Bug c++/44611] Including and hides ::signbit function

[gnu at bluedreamer dot com]

--- Comment #3 from gnu at bluedreamer dot com  2010-06-21 14:32 ---
Created an attachment (id=20965)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20965&action=view)
--save-temps output .s file


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44611

[Bug c++/44611] Including and hides ::signbit function

[gnu at bluedreamer dot com]

--- Comment #2 from gnu at bluedreamer dot com  2010-06-21 14:31 ---
Created an attachment (id=20964)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20964&action=view)
--save-temps output .ii file


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44611

[Bug c++/44611] Including and hides ::signbit function

[gnu at bluedreamer dot com]

--- Comment #1 from gnu at bluedreamer dot com  2010-06-21 14:31 ---
Created an attachment (id=20963)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20963&action=view)
Source file


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44611