[Bug target/47000] [4.5 Regression] Failure to inline SSE intrinsics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47000 --- Comment #24 from Jakub Jelinek jakub at gcc dot gnu.org 2010-12-20 08:32:10 UTC --- VCE is often very expensive though (often a memory store followed by memory load into a different register, etc.), so 0 unconditionally is IMHO wrong. Perhaps for some TYPE_MODE combinations at most.
[Bug fortran/47007] Values from namelist file should not depend on locale settings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added CC||jb at gcc dot gnu.org --- Comment #13 from Janne Blomqvist jb at gcc dot gnu.org 2010-12-20 08:48:18 UTC --- Also vaguely related: PR 36857 I don't think it's a good idea to call setlocale() in the library - I suspect this would (subtly?) break a lot of programs that set the locale and then at some later point call a Fortran library function.
[Bug libfortran/46720] [4.6 Regression] missing quadmath_weak.h with --enable-maintainer-mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46720 --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-20 08:52:08 UTC --- * PING * Can you still reproduce it -- with the correct version of automake installed?
[Bug lto/44334] rnflow.f90 ~27% slower with -fwhole-program -flto after revision 159852
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44334 --- Comment #16 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-12-20 08:57:32 UTC --- The patch in comment #14 fixed the problem on x86_64-apple-darwin10, but causes the following regressions: FAIL: gcc.dg/autopar/outer-2.c scan-tree-dump-times parloops parallelizing outer loop 1 FAIL: gcc.dg/autopar/outer-2.c scan-tree-dump-times optimized loopfn 5 FAIL: gcc.dg/tree-ssa/ldist-pr45948.c scan-tree-dump ldist distributed: split to 3 which disappear if I revert the patch. Note that something looks uninitialized with the patch: [macbook] f90/bug% gcc46 -O2 -ftree-loop-distribution -fdump-tree-ldist-details -c /opt/gcc/work/gcc/testsuite/gcc.dg/tree-ssa/ldist-pr45948.c [macbook] f90/bug% grep distributed ldist-pr45948.c.101t.ldist Loop -1515870811 distributed: split to 2 loops. instead of Loop 1 distributed: split to 3 loops.
[Bug fortran/47023] New: C_Sizeof: Rejects valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023 Summary: C_Sizeof: Rejects valid code Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org The following program is rejected with: print *, c_sizeof(a) 1 Error: 'x' argument of 'c_sizeof' intrinsic at (1) must be be an interoperable data entity However, a is an kind-4 INTEGER which is interoperable. It works if one uses integer(c_int) - however, the message is completely bogus. While for a BIND(C) procedure the size matters, for c_sizeof a c_int vs. c_long vs. c_signed_char are all completely valid, thus all kind numbers should be fine. use iso_c_binding implicit none integer :: a(5) print *, sizeof(a) print *, c_sizeof(a) end
[Bug tree-optimization/47001] segmentation fault in vect_mark_slp_stmts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47001
Ira Rosen irar at il dot ibm.com changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2010.12.20 09:00:13
CC||irar at il dot ibm.com
AssignedTo|unassigned at gcc dot |irar at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #1 from Ira Rosen irar at il dot ibm.com 2010-12-20 09:00:13 UTC
---
The vectorizer tries to do SLP for reduction here, but there is only one scalar
load for both reductions, which is not supported, but also is not checked. I am
testing a patch that adds such check.
Index: tree-vect-slp.c
===
--- tree-vect-slp.c (revision 167365)
+++ tree-vect-slp.c (working copy)
@@ -1002,7 +1002,35 @@ vect_supported_load_permutation_p (slp_i
if (!bad_permutation)
{
- /* This permutaion is valid for reduction. Since the order of the
+ /* Check that all the loads are different. */
+ load_index = sbitmap_alloc (group_size);
+ sbitmap_zero (load_index);
+ for (k = 0; k group_size; k++)
+{
+ first_group_load_index = VEC_index (int, load_permutation, k);
+ if (TEST_BIT (load_index, first_group_load_index))
+{
+ bad_permutation = true;
+ break;
+}
+
+ SET_BIT (load_index, first_group_load_index);
+}
+
+ if (!bad_permutation)
+for (k = 0; k group_size; k++)
+ if (!TEST_BIT (load_index, k))
+{
+ bad_permutation = true;
+ break;
+}
+
+ sbitmap_free (load_index);
+}
+
+ if (!bad_permutation)
+{
+ /* This permutation is valid for reduction. Since the order of the
statements in the nodes is not important unless they are memory
accesses, we can rearrange the statements in all the nodes
according to the order of the loads. */
Ira
[Bug middle-end/46916] gcc.dg/torture/stackalign/non-local-goto-[1,2].c ICEs compiler due to r167727
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46916 --- Comment #97 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-12-20 09:05:05 UTC --- The patch in attachment 22787 fixes also a Stage 3 ada bootstrap error on i686-apple-darwin9, see comment #3 of pr46950.
[Bug testsuite/47013] FAIL: gcc.dg/sms-*.c scan-rtl-dump-times sms SMS succeeded *
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47013 --- Comment #1 from revital eres eres at il dot ibm.com 2010-12-20 09:07:53 UTC --- In some of the testcases additional flags are needed to make SMS apply: (though it does not mean it succeeds) sms-5.c: add -mno-update -fno-auto-inc-dec sms-4.c: -funsafe-loop-optimizations -fno-auto-inc-dec (-funsafe-loop-optimizations is related to PR32283 http://gcc.gnu.org/ml/gcc/2010-07/msg00379.html) sms-7.c: add -fno-auto-inc-dec
[Bug target/45261] Doesn't indicate failure status when it doesn't support (attiny2313A)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45261 Guan Xin guanx.bac at gmail dot com changed: What|Removed |Added CC||guanx.bac at gmail dot com --- Comment #10 from Guan Xin guanx.bac at gmail dot com 2010-12-20 09:18:26 UTC --- request to add version 4.5.2
[Bug testsuite/47013] FAIL: gcc.dg/sms-*.c scan-rtl-dump-times sms SMS succeeded *
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47013 --- Comment #2 from revital eres eres at il dot ibm.com 2010-12-20 09:26:21 UTC --- The testcases fail (even when adding the flags mentioned before) due to the decision to apply SMS when stage_count greater than 1. If stage_count is 1 it means the new SMSed kernel includes instructions from a single iteration of the original loop -- in that case SMS fails and leaves the scheduling task to the scheduler. In r146278 SMS has been applied also when SC equals 1 so the testcases passed with that version.
[Bug debug/47018] ICE: in pre_and_rev_post_order_compute, at cfganal.c:1047 with -fnon-call-exceptions -fvar-tracking -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47018
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2010-12-20
09:29:41 UTC ---
The problem is that split2 pass splits:
(insn 6 3 7 2 (set (reg:DF 21 xmm0 [orig:59 D.2082 ] [59])
(float_extend:DF (reg/v:SF 21 xmm0 [orig:61 f ] [61]))) pr47018-2.C:11
136 {*extendsfdf2_sse}
(expr_list:REG_EH_REGION (const_int 1 [0x1])
(nil)))
into:
(insn 36 3 37 2 (set (reg:V4SF 21 xmm0 [orig:61 f ] [61])
(vec_select:V4SF (vec_concat:V8SF (reg:V4SF 21 xmm0 [orig:61 f ] [61])
(reg:V4SF 21 xmm0 [orig:61 f ] [61]))
(parallel [
(const_int 0 [0])
(const_int 4 [0x4])
(const_int 1 [0x1])
(const_int 5 [0x5])
]))) pr47018-2.C:11 1472 {vec_interleave_lowv4sf}
(nil))
(insn 37 36 7 2 (set (reg:V2DF 21 xmm0 [orig:59 D.2082 ] [59])
(float_extend:V2DF (vec_select:V2SF (reg:V4SF 21 xmm0 [orig:61 f ]
[61])
(parallel [
(const_int 0 [0])
(const_int 1 [0x1])
] pr47018-2.C:11 1462 {sse2_cvtps2pd}
(nil))
and the split2 pass doesn't expect it needs to clean up the cfg and purge dead
eh edges etc. With -O0 -fvar-tracking then var-tracking ICEs because there is
an unreachable bb.
With -fnon-call-exceptions float_extend in scalar float mode is considered as
may_trap_p while vector float mode is not:
default:
/* Any floating arithmetic may trap. */
if (SCALAR_FLOAT_MODE_P (GET_MODE (x))
flag_trapping_math)
return 1;
If the reason why float_extend:DF is considered as maybe trapping is sNaN, then
doesn't vector mode float_extend trap too? Either split2 needs to purge dead
eh edges and cleanup if needed, or the splitter is incorrect for
-fnon-call-exceptions, or may_trap_p is wring in only handling scalar float
modes and not vector float modes too.
[Bug fortran/47024] New: [OOP] STORAGE_SIZE (for polymorphic types): Segfault at run time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47024 Summary: [OOP] STORAGE_SIZE (for polymorphic types): Segfault at run time Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: ja...@gcc.gnu.org STORAGE_SIZE does not work for unallocated polymorphic types. However, the Fortran 2008 standard allows them: Ashall be a scalar or array of any type. If it is polymorphic it shall not be an undefined pointer. If it has any deferred type parameters it shall not be an unallocated allocatable variable or a disassociated or undefined pointer. (F2008, 13.7.160) Note: The standard allows an unallocated polymorphic variable - as long as the type does not have any deferred type parameter. Fortunately, CLASS(*) does not seem to be allowed as CLASS(*) has no type. Maybe one should cross check (e.g. at the J3 mailing list) to see whether the proper result is the declared type or something else. implicit none type t integer :: a end type t type, extends(t) :: t2 integer :: b end type t2 class(t), allocatable :: y print *, storage_size(y)/8 ! Expected: 4; in reality: segfault end
[Bug c++/33558] 'mutable' incorrectly accepted on reference members
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33558 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||patch --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2010-12-20 09:43:40 UTC --- new patch http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01469.html
[Bug target/47025] New: Dead stores in varadic functions not eliminated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47025
Summary: Dead stores in varadic functions not eliminated
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@beniston.com
If I compile a varadic function such as this:
double d;
void func(int a, ...)
{
va_list ap;
va_start(ap, a);
d = va_arg(ap, double);
va_end(ap);
}
with:
mips-elf-gcc test.c -O2 -S -mhard-float -march=m4k -mabi=eabi
The stores of register arguments on to the stack are not eliminated, even if
not used. Eg:
func:
.frame $sp,80,$31 # vars= 16, regs= 0/0, args= 0, gp= 0
.mask 0x,0
.fmask 0x,0
.setnoreorder
.setnomacro
addiu $sp,$sp,-80
addiu $2,$sp,80
sw $2,0($sp)
sw $2,4($sp)
addiu $2,$sp,48
sw $2,8($sp)
li $2,28
sb $2,12($sp)
li $2,24
sw $5,52($sp) # redundant stores
sw $6,56($sp)
sw $7,60($sp)
sw $8,64($sp)
sw $9,68($sp)
sw $10,72($sp)
sw $11,76($sp)
sdc1$f12,16($sp)
sdc1$f14,24($sp)
sdc1$f16,32($sp)
sdc1$f18,40($sp)
sb $2,13($sp)
sdc1$f12,%gp_rel(d)($28)
j $31
addiu $sp,$sp,80
[Bug fortran/47024] [OOP] STORAGE_SIZE (for polymorphic types): Segfault at run time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47024 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-20 09:47:11 UTC --- IR 10-171 (http://j3-fortran.org/doc/year/10/10-171.txt) adds the text in the bracket (which does not apply here): If it [is unlimited polymorphic or] has any deferred type parameters it shall not be ... * * * I have now asked at J3: http://j3-fortran.org/pipermail/j3/2010-December/004090.html
[Bug c++/46904] [4.6 Regression] g++.dg/tree-prof/(indir-call-prof.C|inline_mismatch_args.C) fail on powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46904 --- Comment #2 from Iain Sandoe iains at gcc dot gnu.org 2010-12-20 10:01:06 UTC --- Author: iains Date: Mon Dec 20 10:01:02 2010 New Revision: 168083 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168083 Log: PR c++/46904 PR middle-end/46916 PR target/46950 * config/darwin.c (generating_for_darwin_version): New var. (darwin_text_section): Remove. (darwin_rodata_section): Do not check function section here. (darwin_emit_unwind_label): Do not emit for Darwin = 9. Emit distinct labels for successive calls for the same decl. (darwin_override_options): Set generating_for_darwin_version. Add FIXME and disable -freorder-blocks-and-partition. Suppress automatic asynchronous unwind tables for m32. Switch off -freorder-blocks-and-partition when unwind tables will be generated. Update to use generating_for_darwin_version. (darwin_function_section): Check for cases that need to be placed in coalesced sections. * config/darwin-sections.def: Define hot, cold, startup and exit sections for both coalesced and regular code. * config/darwin.h (USE_SELECT_SECTION_FOR_FUNCTIONS): Delete. * config/darwin10.h (TARGET_ASM_EMIT_UNWIND_LABEL): Delete. Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin-sections.def trunk/gcc/config/darwin.c trunk/gcc/config/darwin.h trunk/gcc/config/darwin10.h
[Bug target/46950] Stage 3 ada bootstrap error on i686-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46950 --- Comment #4 from Iain Sandoe iains at gcc dot gnu.org 2010-12-20 10:01:07 UTC --- Author: iains Date: Mon Dec 20 10:01:02 2010 New Revision: 168083 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168083 Log: PR c++/46904 PR middle-end/46916 PR target/46950 * config/darwin.c (generating_for_darwin_version): New var. (darwin_text_section): Remove. (darwin_rodata_section): Do not check function section here. (darwin_emit_unwind_label): Do not emit for Darwin = 9. Emit distinct labels for successive calls for the same decl. (darwin_override_options): Set generating_for_darwin_version. Add FIXME and disable -freorder-blocks-and-partition. Suppress automatic asynchronous unwind tables for m32. Switch off -freorder-blocks-and-partition when unwind tables will be generated. Update to use generating_for_darwin_version. (darwin_function_section): Check for cases that need to be placed in coalesced sections. * config/darwin-sections.def: Define hot, cold, startup and exit sections for both coalesced and regular code. * config/darwin.h (USE_SELECT_SECTION_FOR_FUNCTIONS): Delete. * config/darwin10.h (TARGET_ASM_EMIT_UNWIND_LABEL): Delete. Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin-sections.def trunk/gcc/config/darwin.c trunk/gcc/config/darwin.h trunk/gcc/config/darwin10.h
[Bug middle-end/46916] gcc.dg/torture/stackalign/non-local-goto-[1,2].c ICEs compiler due to r167727
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46916 --- Comment #98 from Iain Sandoe iains at gcc dot gnu.org 2010-12-20 10:01:07 UTC --- Author: iains Date: Mon Dec 20 10:01:02 2010 New Revision: 168083 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168083 Log: PR c++/46904 PR middle-end/46916 PR target/46950 * config/darwin.c (generating_for_darwin_version): New var. (darwin_text_section): Remove. (darwin_rodata_section): Do not check function section here. (darwin_emit_unwind_label): Do not emit for Darwin = 9. Emit distinct labels for successive calls for the same decl. (darwin_override_options): Set generating_for_darwin_version. Add FIXME and disable -freorder-blocks-and-partition. Suppress automatic asynchronous unwind tables for m32. Switch off -freorder-blocks-and-partition when unwind tables will be generated. Update to use generating_for_darwin_version. (darwin_function_section): Check for cases that need to be placed in coalesced sections. * config/darwin-sections.def: Define hot, cold, startup and exit sections for both coalesced and regular code. * config/darwin.h (USE_SELECT_SECTION_FOR_FUNCTIONS): Delete. * config/darwin10.h (TARGET_ASM_EMIT_UNWIND_LABEL): Delete. Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin-sections.def trunk/gcc/config/darwin.c trunk/gcc/config/darwin.h trunk/gcc/config/darwin10.h
[Bug middle-end/46916] gcc.dg/torture/stackalign/non-local-goto-[1,2].c ICEs compiler due to r167727
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46916 --- Comment #99 from Iain Sandoe iains at gcc dot gnu.org 2010-12-20 10:14:39 UTC --- Author: iains Date: Mon Dec 20 10:14:36 2010 New Revision: 168084 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168084 Log: PR middle-end/46916 * opts.c (finish_options): Enable -freorder-functions when -freorder-blocks-and-partition is active. Modified: trunk/gcc/ChangeLog trunk/gcc/opts.c
[Bug testsuite/47013] FAIL: gcc.dg/sms-*.c scan-rtl-dump-times sms SMS succeeded *
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47013 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-12-20 10:21:37 UTC --- Thanks for looking at the problem. Do you understand why the tests pass on *86*-*-* and not on powerpc*-*-*?
[Bug tree-optimization/45965] [4.6 Regression] ICE on powerpc-apple-darwin9: gfortran.dg/subref_array_pointer_4.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45965 --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-12-20 10:25:46 UTC --- These failures have disappeared between revisions 168021 and 168044 (see http://gcc.gnu.org/ml/gcc-testresults/2010-12/msg01606.html and http://gcc.gnu.org/ml/gcc-testresults/2010-12/msg01678.html ).
[Bug rtl-optimization/47008] [4.6 Regression] gfortran.dg/extends_{23}.f03 FAIL with -Os -fschedule-insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47008
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2010-12-20
10:30:43 UTC ---
It doesn't, it looks like a RA/reload bug.
In *.sched1 we have:
17 NOTE_INSN_BASIC_BLOCK
31 [pre sp:DI+=0xfff8]=0
20 {r64:DI=frame:DI-0x30;clobber flags:CC;}
REG_UNUSED: flags:CC
23 r67:SI=0x20202020
24 r68:DI=0x6
18 [frame:DI-0x8]=r63:DI
19 [frame:DI-0x30]=0x1e23f
32 [pre sp:DI+=0xfff8]=0
21 {r65:DI=r64:DI+0x4;clobber flags:CC;}
REG_UNUSED: flags:CC
34 {r72:DI=frame:DI-0x8;clobber flags:CC;}
REG_UNUSED: flags:CC
29 r71:DI=0xa
36 r9:DI=`*.LC1'
37 r8:DI=`*.LC2'
25 {r68:DI=0;r66:DI=r68:DI0x2+r65:DI;[r65:DI]=0;use r67:SI;use r68:DI;}
REG_DEAD: r67:SI
REG_DEAD: r65:DI
REG_UNUSED: r68:DI
REG_UNUSED: r66:DI
so, the 0x1e23f store in insn 19 is to frame-48 and then there is memset
(frame-48+4, ' ', 24)
In *.ira this is:
17 NOTE_INSN_BASIC_BLOCK
31 [pre sp:DI+=0xfff8]=0
20 {si:DI=sp:DI+0x8;clobber flags:CC;}
REG_EQUIV: sp:DI+0x8
24 cx:DI=0x6
REG_EQUAL: 0x6
18 [sp:DI+0x30]=r10:DI
19 [sp:DI+0x8]=0x1e23f
32 [pre sp:DI+=0xfff8]=0
21 {dx:DI=si:DI+0x4;clobber flags:CC;}
34 {bx:DI=sp:DI+0x38;clobber flags:CC;}
REG_EQUIV: sp:DI+0x38
29 r11:DI=0xa
REG_EQUAL: 0xa
36 r9:DI=`*.LC1'
37 r8:DI=`*.LC2'
57 ax:SI=0x20202020
REG_EQUIV: 0x20202020
59 di:DI=dx:DI
25 {cx:DI=0;di:DI=cx:DI0x2+di:DI;[di:DI]=0;use ax:SI;use cx:DI;}
i.e. frame-48 is rsp+0 at the beginning of the bb, and the 0x1e234 store is to
that location and memset 4 bytes above it (as there are intervening push insns,
the store is to %rsp+8 at that point and memset is to %rsp+16+4). The
REG_EQUIV on insn 20 is wrong though, %rsi is equal to %rsp+8 only until %rsp
is changed, not always.
And in *.postreload it uses REG_EQUIV to optimize rdx = rsi + 4 into rdx = rsp
+ 12, which is wrong in that spot, it should have been rsp + 20:
31 [pre sp:DI+=0xfff8]=0
20 {si:DI=sp:DI+0x8;clobber flags:CC;}
REG_EQUIV: sp:DI+0x8
24 cx:DI=0x6
REG_EQUAL: 0x6
18 [sp:DI+0x30]=r10:DI
19 [sp:DI+0x8]=0x1e23f
32 [pre sp:DI+=0xfff8]=0
21 {dx:DI=sp:DI+0xc;clobber flags:CC;}
34 {bx:DI=sp:DI+0x38;clobber flags:CC;}
REG_EQUIV: sp:DI+0x38
29 r11:DI=0xa
REG_EQUAL: 0xa
36 r9:DI=`*.LC1'
37 r8:DI=`*.LC2'
57 ax:SI=0x20202020
REG_EQUIV: 0x20202020
59 di:DI=dx:DI
25 {cx:DI=0;di:DI=cx:DI0x2+di:DI;[di:DI]=0;use ax:SI;use cx:DI;}
[Bug tree-optimization/45965] [4.6 Regression] ICE on powerpc-apple-darwin9: gfortran.dg/subref_array_pointer_4.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45965 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||jakub at redhat dot com --- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-12-20 10:52:14 UTC --- Since the patch in comment #3 is doing changes in gcc/tree-scalar-evolution.c, revision 168027 seems to be the best candidate (although I don't know enough to rule out r168034 or even r168031): Revision 168027 Jump to revision: Author:jakub Date:Sat Dec 18 18:15:10 2010 UTC (40 hours, 30 minutes ago) Changed paths:4 Log Message: PR tree-optimization/46985 * tree-scalar-evolution.c (instantiate_scev_r): If chrec is NULL, return it immediately. * gfortran.dg/pr46985.f90: New test. Changed paths: PathDetails trunk/gcc/ChangeLogmodified , text changed trunk/gcc/testsuite/ChangeLogmodified , text changed trunk/gcc/testsuite/gfortran.dg/pr46985.f90added trunk/gcc/tree-scalar-evolution.cmodified , text changed
[Bug testsuite/47013] FAIL: gcc.dg/sms-*.c scan-rtl-dump-times sms SMS succeeded *
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47013
--- Comment #4 from revital eres eres at il dot ibm.com 2010-12-20 10:55:40
UTC ---
(In reply to comment #3)
Thanks for looking at the problem. Do you understand why the tests pass on
*86*-*-* and not on powerpc*-*-*?
Yes, the dump file is checked only for powerpc*-*-* and spu-*-*:
/* { dg-final { scan-rtl-dump-times SMS succeeded 1 sms { target
powerpc*-*-* spu-*-* } } } */
[Bug testsuite/47013] FAIL: gcc.dg/sms-*.c scan-rtl-dump-times sms SMS succeeded *
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47013
--- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-12-20
10:59:26 UTC ---
Yes, the dump file is checked only for powerpc*-*-* and spu-*-*:
/* { dg-final { scan-rtl-dump-times SMS succeeded 1 sms { target
powerpc*-*-* spu-*-* } } } */
Indeed I have seen it, but obviously I did not registered the information;-)
[Bug fortran/36437] Simplify argument to [c_]sizeof
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36437 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-20 11:02:27 UTC --- Created attachment 22829 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22829 Draft patch A different draft patch (I forgot about attachment 15721 - maybe one can move something over). This patch implements simplification for c_sizeof/sizeof and for storage_size. TODO: - The code (in target-memory.c) currently expects character literal strings or PARAMETERs and thus fails for character variables - There needs to be a return NULL for characters with only run-time known length. - Maybe some other return-early checks? - Presumably refs of the kind foo%bar(1)%blub(1:5)(1:2) are mishandled - Test cases are missing
[Bug fortran/36437] Simplify argument to [c_]sizeof
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36437 --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-20 11:05:36 UTC --- (Ignore the match.c and resolve.c part - those are for PR PR46371.)
[Bug rtl-optimization/47008] [4.6 Regression] gfortran.dg/extends_{23}.f03 FAIL with -Os -fschedule-insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47008
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||law at gcc dot gnu.org,
||vmakarov at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2010-12-20
11:10:00 UTC ---
The note is added in update_equiv_regs called from ira.
/* cse sometimes generates function invariants, but doesn't put a
REG_EQUAL note on the insn. Since this note would be redundant,
there's no point creating it earlier than here. */
if (! note ! rtx_varies_p (src, 0))
note = set_unique_reg_note (insn, REG_EQUAL, copy_rtx (src));
...
/* If this register is known to be equal to a constant, record that
it is always equivalent to the constant. */
if (DF_REG_DEF_COUNT (regno) == 1
note ! rtx_varies_p (XEXP (note, 0), 0))
{
rtx note_value = XEXP (note, 0);
remove_note (insn, note);
set_unique_reg_note (insn, REG_EQUIV, note_value);
}
This is correct at that point, because note_value is frame - 48, which really
is constant through the whole function.
But when
/* If we changed something, perform elimination in REG_NOTES. This is
needed even when REPLACE is zero because a REG_DEAD note might refer
to a register that we eliminate and could cause a different number
of spill registers to be needed in the final reload pass than in
the pre-passes. */
if (val REG_NOTES (insn) != 0)
REG_NOTES (insn)
= eliminate_regs_1 (REG_NOTES (insn), VOIDmode, REG_NOTES (insn), true,
false);
in eliminate_regs_in_insn changes the REG_EQUIV note content from frame -
something to %rsp + something, the expression is suddenly not constant anymore.
So, shouldn't eliminate_regs_1 here downgrade REG_EQUIV notes where
!rtx_varies_p before and rtx_varies_p afterwards to REG_EQUAL?
[Bug tree-optimization/45965] [4.6 Regression] ICE on powerpc-apple-darwin9: gfortran.dg/subref_array_pointer_4.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45965 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2010-12-20 11:17:00 UTC --- My patch should make the #c3 patch unnecessary, and perhaps if the problem was somewhere deeper in the ARRAY_REF argument instead the #c3 patch wouldn't fix ICE while what has been committed did. Anyway, as it is fixed now, let's say it is fixed.
[Bug target/46972] __thread storage class variable gets optimized out on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46972 --- Comment #7 from Paulius Zaleckas paulius.zaleckas at gmail dot com 2010-12-20 11:28:14 UTC --- (In reply to comment #6) I think enumtls has been fixed on the trunk with respect of fsection-anchors. Can you try the trunk? Yes, looks like this bug is fixed in trunk. Assembly output looks sane. I will see if it works on real hardware some time later today. Do you know svn revision it got fixed?
[Bug middle-end/46916] gcc.dg/torture/stackalign/non-local-goto-[1,2].c ICEs compiler due to r167727
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46916
--- Comment #100 from Iain Sandoe iains at gcc dot gnu.org 2010-12-20
11:28:44 UTC ---
(In reply to comment #39)
The patch I had in mind
http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01129.html
BTW: When the BB reordering is applied
(together with http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01553.html and
http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01554.html)
I see the code trashing reduced -- but also that there are no partition
switches created for either partition{1,2}.C on i686-darwin9.
Perhaps that is intended -- but it's a 'heads up' that the test-cases might
need adjustment to force section switches, if that is the intention.
I think this PR should be fixed now.
gcc's cpp makes ?: left-associative
The following fragment prints wrong for me: #if 2 1 ? 0 : 0 ? 1 : 1 wrong #endif when run through the preprocessor (either gcc -E or cpp). This occurs with Debian stable's gcc: Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.3.2 (Debian 4.3.2-1.1) as well as with the gcc 4.1 used by CentOS and NetBSD. The Debian one is unfortunately the latest gcc I have ready access to. However, this is obscure enough that I'm assuming nobody else is likely to have noticed it in the meantime. See http://gnats.netbsd.org/44253 for a more elaborate example. -- - David A. Holland / dholl...@eecs.harvard.edu
[Bug c++/47026] New: invalid temporary is being assigned to a const-reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47026
Summary: invalid temporary is being assigned to a
const-reference
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tmosc...@gmail.com
Created attachment 22830
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22830
Prog which demonstrates bug. returns EXIT_FAILURE for g++, EXIT_SUCCESS for
MSVC++
The following program (also attached) highlights an obvious bug in g++. When
compiled in Microsoft Visual C++, the program executes as expected: ‘ptr ==
alias’. But when compiled with g++: ‘ptr != alias’. I believe that this is
because a temporary is wrongly created in the statement,
const int* const alias(prt);
or alternatively
const int* const alias = ptr;
A ‘const int*’ temp is created from ‘ptr’ of type ‘int*’. So ‘alias’ is a
reference to the temp and not ‘ptr’. I’ve tried using a ‘const_cast’ operator
but with no luck for the desired results.
Program was compiled with the command: g++ -o prog.exe prog.cpp
program: prog.cpp
---start--
#include iostream
#include cstdlib
using namespace std;
int main() {
int a = 10;
int* ptr = a;
/* temporary is being assigned to a const-reference : BAD */
const int* const alias(ptr);
ptr = NULL; /* or ptr = 0; */
if (ptr != alias) {
/* should never execute but DOES on g++ (not on MSVC++)*/
cout ptr != alias endl;
return (EXIT_FAILURE);
}
cout ptr == alias endl;
return (EXIT_SUCCESS);
}
---end---
[Bug c++/47026] invalid temporary is being assigned to a const-reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47026 Terry tmoschou at gmail dot com changed: What|Removed |Added CC||tmoschou at gmail dot com --- Comment #1 from Terry tmoschou at gmail dot com 2010-12-20 11:33:37 UTC --- Whoops, forgot to say compiled on Ubuntu 10.10 x64.
Re: gcc's cpp makes ?: left-associative
On Mon, 20 Dec 2010, David Holland wrote: as well as with the gcc 4.1 used by CentOS and NetBSD. The Debian one is unfortunately the latest gcc I have ready access to. However, this is obscure enough that I'm assuming nobody else is likely to have noticed it in the meantime. This no longer appears and was probably fixed by: 2008-05-06 Tom Tromey tro...@redhat.com PR preprocessor/35313, PR preprocessor/36088: * expr.c (optab) QUERY, COMMA: Set precedence to 4. (reduce) case CPP_QUERY: Special case CPP_COMMA and CPP_COLON. -- Joseph S. Myers jos...@codesourcery.com
[Bug c++/47026] invalid temporary is being assigned to a const-reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47026 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2010-12-20 12:03:12 UTC --- (In reply to comment #0) /* temporary is being assigned to a const-reference : BAD */ const int* const alias(ptr); This is the correct behaviour, see 12.2 [class.temporary] paragraphs 4 and 5 in the standard: 4 There are two contexts in which temporaries are destroyed at a different point than the end of the full-expression. ... 5 The second context is when a reference is bound to a temporary. The temporary to which the reference is bound or the temporary that is the complete object to a subobject of which the temporary is bound persists for the lifetime of the reference except as specified below. The lifetime of the temporary ends on return from main, so the temporary also ends when main returns.
Re: gcc's cpp makes ?: left-associative
The correct way to report bugs is via bugzilla, as described at http://gcc.gnu.org/bugs/ The gcc-bugs list consists almost entirely of auto-generated mail from bugzilla so mails sent there can be missed and they don't get tracked in bugzilla. GCC 4.4 and later have the right result, but I don't know when it was fixed.
[Bug target/43810] [4.5 Regression] linking results in undefined references to _savegpr_* _restgpr_*_x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43810 Wolfgang Denk wd at denx dot de changed: What|Removed |Added CC||wd at denx dot de --- Comment #15 from Wolfgang Denk wd at denx dot de 2010-12-20 12:22:22 UTC --- For the record: the problem appears to be still present in 4.5.1 (at least I run into the same symptoms when trying to build poky with --enable-target-optspace enabled.
[Bug rtl-optimization/47008] [4.6 Regression] gfortran.dg/extends_{23}.f03 FAIL with -Os -fschedule-insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47008
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2010-12-20
13:03:56 UTC ---
--- reload1.c.jj 2010-11-25 18:50:45.0 +0100
+++ reload1.c 2010-12-20 12:54:34.924901692 +0100
@@ -3597,9 +3597,20 @@ eliminate_regs_in_insn (rtx insn, int re
of spill registers to be needed in the final reload pass than in
the pre-passes. */
if (val REG_NOTES (insn) != 0)
-REG_NOTES (insn)
- = eliminate_regs_1 (REG_NOTES (insn), VOIDmode, REG_NOTES (insn), true,
- false);
+{
+ rtx note;
+ REG_NOTES (insn)
+ = eliminate_regs_1 (REG_NOTES (insn), VOIDmode, REG_NOTES (insn), true,
+ false);
+ /* Register elimination might change a REG_EQUIV note expression from
+something that is constant to e.g. stack pointer based expression,
+which can't be safely moved across stack pointer adjustments.
+Downgrade such notes to REG_EQUAL. */
+ for (note = REG_NOTES (insn); note; note = XEXP (note, 1))
+ if (REG_NOTE_KIND (note) == REG_EQUIV
+rtx_varies_p (XEXP (note, 0), 0))
+ PUT_REG_NOTE_KIND (note, REG_EQUAL);
+}
return val;
}
unfortunately doesn't fix this.
--- postreload.c.jj2010-12-02 13:15:24.0 +0100
+++ postreload.c2010-12-20 14:01:23.404758077 +0100
@@ -1415,7 +1415,8 @@ reload_combine_note_store (rtx dst, cons
{
dst = XEXP (dst, 0);
if (GET_CODE (dst) == PRE_INC || GET_CODE (dst) == POST_INC
- || GET_CODE (dst) == PRE_DEC || GET_CODE (dst) == POST_DEC)
+ || GET_CODE (dst) == PRE_DEC || GET_CODE (dst) == POST_DEC
+ || GET_CODE (dst) == PRE_MODIFY || GET_CODE (dst) == POST_MODIFY)
{
regno = REGNO (XEXP (dst, 0));
mode = GET_MODE (XEXP (dst, 0));
does though. Perhaps just the latter patch would be good enough, dunno whether
something after reload ever makes a difference between REG_EQUIV and REG_EQUAL.
[Bug bootstrap/47027] New: a-stwiun.ads:441:80: (style) this line is too long
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47027 Summary: a-stwiun.ads:441:80: (style) this line is too long Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: jamb...@gcc.gnu.org Bootstrap of trunk revision 168084 with all,ada languages enabled on x86_64-suse-linux fails with: /mjambor/trunk/obj/./gcc/xgcc -B/mjambor/trunk/obj/./gcc/ -B/mjambor/inst/trunk/x86_64-unknown-linux-gnu/bin/ -B/mjambor/inst/trunk/x86_64-unknown-linux-gnu/lib/ -isystem /mjambor/inst/trunk/x86_64-unknown-linux-gnu/include -isystem /mjambor/inst/trunk/x86_64-unknown-linux-gnu/sys-include-c -g -O2 -fPIC -W -Wall -gnatpg a-stwiun.adb -o a-stwiun.o a-stwiun.ads:441:80: (style) this line is too long in directory obj/gcc/ada/rts
[Bug other/46489] tree optimizer and frontend files use target macros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46489 --- Comment #3 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org 2010-12-20 13:59:41 UTC --- When using gcc, using -dD, I can auto-generate a headerfile tm-poison.h which poisons all macros that including tm.h defines, which are not defined by frontend-premissible headers like coretypes.h / tree.h . The fallback would be to have tm-poison.h be empty. This file can be included instead of tm.h in files that are hoped / believed to been freed of target macros uses . This can safe a lot of manual checking.
[Bug fortran/47007] Values from namelist file should not depend on locale settings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007 --- Comment #14 from Alexander Varnin fenixk19 at mail dot ru 2010-12-20 14:04:08 UTC --- There is internal variants of strtof/strtod/strtold/etc functions in glibc, that allow explicitly set locale of convertion. These functions are base for user variants of strto*. If we only could access these internal functions some way, it would be solution of problem, and not workaround.
[Bug tree-optimization/46352] ICE: division by zero with -fdump-tree-tracer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46352 --- Comment #1 from Zdenek Sojka zsojka at seznam dot cz 2010-12-20 14:12:19 UTC --- Backtrace for r165699: The offending line is: fprintf (dump_file, Duplicated %i insns (%i%%)\n, nduplicated, nduplicated * 100 / ninsns); Program received signal SIGFPE, Arithmetic exception. 0x0088a835 in tail_duplicate () at /mnt/svn/gcc-trunk/gcc/tracer.c:338 338 fprintf (dump_file, Duplicated %i insns (%i%%)\n, nduplicated, (gdb) bt #0 0x0088a835 in tail_duplicate () at /mnt/svn/gcc-trunk/gcc/tracer.c:338 #1 tracer () at /mnt/svn/gcc-trunk/gcc/tracer.c:364 #2 0x0079613f in execute_one_pass (pass=0x155f000) at /mnt/svn/gcc-trunk/gcc/passes.c:1562 #3 0x007963d5 in execute_pass_list (pass=0x155f000) at /mnt/svn/gcc-trunk/gcc/passes.c:1617 #4 0x007963e7 in execute_pass_list (pass=0x155fd80) at /mnt/svn/gcc-trunk/gcc/passes.c:1618 #5 0x008e30f6 in tree_rest_of_compilation (fndecl=0x75aadf00) at /mnt/svn/gcc-trunk/gcc/tree-optimize.c:419 #6 0x00aac342 in cgraph_expand_function (node=0x75acc000) at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1494 #7 0x00aae90a in cgraph_expand_all_functions () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1553 #8 cgraph_optimize () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1809 #9 0x00aaee6a in cgraph_finalize_compilation_unit () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1016 #10 0x004ab4b4 in c_write_global_declarations () at /mnt/svn/gcc-trunk/gcc/c-decl.c:9822 #11 0x00889934 in compile_file (argc=16, argv=0x7fffdac8) at /mnt/svn/gcc-trunk/gcc/toplev.c:931 #12 do_compile (argc=16, argv=0x7fffdac8) at /mnt/svn/gcc-trunk/gcc/toplev.c:2363 #13 toplev_main (argc=16, argv=0x7fffdac8) at /mnt/svn/gcc-trunk/gcc/toplev.c:2423 #14 0x76371bbd in __libc_start_main () from /lib/libc.so.6 #15 0x004920b9 in _start () (gdb) p nduplicated $1 = 0 (gdb) p ninsns $2 = value optimized out I can't reproduce it in current trunk, but I don't know if it was fixed or just hidden.
[Bug fortran/47007] Values from namelist file should not depend on locale settings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007 --- Comment #15 from Steve Kargl sgk at troutmask dot apl.washington.edu 2010-12-20 14:48:03 UTC --- On Mon, Dec 20, 2010 at 02:04:14PM +, fenixk19 at mail dot ru wrote: There is internal variants of strtof/strtod/strtold/etc functions in glibc, that allow explicitly set locale of convertion. These functions are base for user variants of strto*. If we only could access these internal functions some way, it would be solution of problem, and not workaround. It is not a solution to the problem. gfortran runs on numerous platforms where glibc is not libc nor is glibc available. Also, note that gfortran cannot simply take the glibc code and put it into libgfortran due to licensing. Tobias is probably correct. gfortran eventually will need to implement its own set of conversion routines.
[Bug fortran/47024] [OOP] STORAGE_SIZE (for polymorphic types): Segfault at run time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47024 --- Comment #2 from janus at gcc dot gnu.org 2010-12-20 15:16:44 UTC --- (In reply to comment #0) STORAGE_SIZE does not work for unallocated polymorphic types. However, the Fortran 2008 standard allows them: Ashall be a scalar or array of any type. If it is polymorphic it shall not be an undefined pointer. If it has any deferred type parameters it shall not be an unallocated allocatable variable or a disassociated or undefined pointer. (F2008, 13.7.160) I don't really understand this. Why should one allow it for unallocated allocatables, but not for undefined pointers? Also, it's not exactly clear to me which value to expect for such a case. From the standard's description of STORAGE_SIZE: The result value is the size expressed in bits for an element of an array that has the dynamic type and type parameters of A. However, if A is unallocated, it does not have a dynamic type!
[Bug other/46489] tree optimizer and frontend files use target macros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46489 --- Comment #4 from joseph at codesourcery dot com joseph at codesourcery dot com 2010-12-20 15:43:37 UTC --- On Mon, 20 Dec 2010, amylaar at gcc dot gnu.org wrote: When using gcc, using -dD, I can auto-generate a headerfile tm-poison.h which poisons all macros that including tm.h defines, which are not defined by frontend-premissible headers like coretypes.h / tree.h . The fallback would be to have tm-poison.h be empty. This file can be included instead of tm.h in files that are hoped / believed to been freed of target macros uses . This can safe a lot of manual checking. This sounds like a nice approach for making sure it is safe to remove a tm.h include from a particular source file - if combined with generating a list of every target (every triplet with significant differences in how config.gcc / libgcc/config.host configure it, whether in the set of headers or the set of tm_defines) so you can run tests automatically for all targets - it may avoid the need to check for every macro with one of the properties I identified as meaning a target macro, that is used anywhere in that source file or any header it includes. I'd be more doubtful about actually checking in a #include of tm-poison.h on trunk (the code to generate it, however, might be useful to check in). Your approach also catches target macros such as TARGET_64BIT that are meant to be purely internal to a port but may nevertheless be used, incorrectly, in target-independent code, by treating such macros identically to those that are expected to be used in target-independent code but only in those source files allowed to include tm.h. (Which anything based on looking at documented macros in tm.texi.in, for example, would not catch.)
[Bug other/46677] frontends and tree optimizers use *_TYPE_SIZE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46677 --- Comment #16 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org 2010-12-20 16:47:50 UTC --- Author: amylaar Date: Mon Dec 20 16:47:45 2010 New Revision: 168086 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168086 Log: PR other/46677 http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00934.html gcc: * doc/tm.texi: Regenerate. * doc/tm.texi.in (BOOL_TYPE_SIZE): Delete. (TARGET_BOOL_TYPE_SIZE): New hook. * targhooks.c (legacy_integer_type_size): New function. (default_bool_type_size, legacy_float_type_size): Likewise. * targhooks.h (legacy_integer_type_size): Declare. (default_bool_type_size, legacy_float_type_size): Likewise. * target.def (bool_type_size): New hook. (integer_type_size, float_type_size): Likewise. * defaults.h (BOOL_TYPE_SIZE): Delete. * tree.c (free_lang_data): Use targetm.bool_type_size. (build_common_tree_nodes): Likewise. * tree.h (enum integer_type_kind): Move from here... * coretypes.h ... to here. * target.h (enum th_float_type): New enum. * tree-ssa-loop-ivopts.c (add_standard_iv_candidates): Use targetm.integer_type_size. * tree-data-ref.c: Include target.h (estimated_loop_iterations_tree): Use targetm.integer_type_size. * system.h (BOOL_TYPE_SIZE): Poison. * Makefile.in (tree-data-ref.o): Depend on $(TARGET_H) . * config/rs6000/darwin.h (BOOL_TYPE_SIZE): Delete. (darwin_bool_type_size): Declare. (TARGET_BOOL_TYPE_SIZE): Define. * config/darwin.c (darwin_bool_type_size): New function. gcc/c-family.c: * c-common.c (c_common_to_target_charset): Use TYPE_PRECISION (char_type_node). gcc/java: * decl.c (java_init_decl_processing): Use targetm.integer_type_size. * expr.c (expand_java_return): Likewise. gcc/ada: * gcc-interface/decl.c (gnat_to_gnu_entity): Use targetm.float_type_size and targetm.integer_type_size. (make_type_from_size): Use targetm.integer_type_size. * gcc-interface/targtyps.c: Include target.h . [!ADA_LONG_TYPE_SIZE] (ADA_LONG_TYPE_SIZE): Use targetm.integer_type_size. [!WIDEST_HARDWARE_FP_SIZE] (LONG_DOUBLE_TYPE_SIZE): Don't define. (get_target_char_size): Use targetm.integer_type_size. (get_target_wchar_t_size, get_target_short_size): Likewise. (get_target_int_size, get_target_long_long_size): Likewise. (get_target_float_size): Use targetm.float_type_size. (get_target_double_size, get_target_long_double_size): Likewise. (MALLOC_OBSERVABLE_ALIGNMENT): Use targetm.integer_type_size. * gcc-interface/trans.c: Include target.h . (gigi): Use targetm.float_type_size. (build_binary_op_trapv): Use targetm.integer_type_size. * gcc-interface/Make-lang.in (ada/targtyps.o): Depend on $(TARGET_H). (ada/trans.o): Likewise. gcc/fortran: * trans-types.c (gfc_init_kinds): Use targetm.integer_type_size. (gfc_build_int_type): Likewise. (gfc_build_uint_type): Use TYPE_PRECISION on the type nodes checked. (gfc_build_real_type): Use targetm.float_type_size. (gfc_build_logical_type): Use targetm.bool_type_size. [0] (c_size_t_size): Delete. * f95-lang.c [!CHAR_TYPE_SIZE] (CHAR_TYPE_SIZE): Don't define. [!INT_TYPE_SIZE] (INT_TYPE_SIZE): Likewise. * iso-c-binding.def (c_bool): Use targetm.bool_type_size. * types.def (BT_BOOL): Likewise. * trans-intrinsic.c (build_round_expr): Use TYPE_PRECISION on *_integer_type_node to find out these type's sizes. (gfc_conv_intrinsic_leadz, gfc_conv_intrinsic_trailz): Likewise. (gfc_conv_intrinsic_popcnt_poppar): Likewise. Modified: branches/pr46489-20101217-branch/gcc/ChangeLog.46489 branches/pr46489-20101217-branch/gcc/Makefile.in branches/pr46489-20101217-branch/gcc/ada/gcc-interface/Make-lang.in branches/pr46489-20101217-branch/gcc/ada/gcc-interface/decl.c branches/pr46489-20101217-branch/gcc/ada/gcc-interface/targtyps.c branches/pr46489-20101217-branch/gcc/ada/gcc-interface/trans.c branches/pr46489-20101217-branch/gcc/c-family/c-common.c branches/pr46489-20101217-branch/gcc/config/darwin.c branches/pr46489-20101217-branch/gcc/config/rs6000/darwin.h branches/pr46489-20101217-branch/gcc/coretypes.h branches/pr46489-20101217-branch/gcc/defaults.h branches/pr46489-20101217-branch/gcc/doc/tm.texi branches/pr46489-20101217-branch/gcc/doc/tm.texi.in branches/pr46489-20101217-branch/gcc/fortran/f95-lang.c branches/pr46489-20101217-branch/gcc/fortran/iso-c-binding.def branches/pr46489-20101217-branch/gcc/fortran/trans-intrinsic.c branches/pr46489-20101217-branch/gcc/fortran/trans-types.c branches/pr46489-20101217-branch/gcc/fortran/types.def branches/pr46489-20101217-branch/gcc/java/decl.c branches/pr46489-20101217-branch/gcc/java/expr.c branches/pr46489-20101217-branch/gcc/system.h branches/pr46489-20101217-branch/gcc/target.def
[Bug fortran/47024] [OOP] STORAGE_SIZE (for polymorphic types): Segfault at run time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47024 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-20 16:47:56 UTC --- (In reply to comment #2) I don't really understand this. Why should one allow it for unallocated allocatables, but not for undefined pointers? Well, the situation for an unassociated pointer and for an unallocated allocatable is the same: You know that it does not have a dynamic type -- and you can check for this state via array.data == NULL or scalar == NULL. In case of an undefined pointer, you cannot. Thus, not allowing undefined pointers anywhere makes sense. The initially proposed wording was did not allow for notallocated allocatables/notassociated pointers (http://www.j3-fortran.org/doc/year/06/06-166.txt) but during the meeting 176 meeting the wording of 06-166 was changed (in two revisions, r1 and r2) to what we have today; cf. http://www.j3-fortran.org/doc/meeting/176/06-166r2.txt. Unfortunately, the new version does not clearly tell what the result value should be in that case. Possible choices would be: (a) storage size of the declared type or (b) zero or the size of the class container. If (b) is the correct answer, I do not see the reason for the additional restrictions for types with deferred type parameters and for unlimited polymorphic - one could simply return the same as for an unallocated polymorphic. Thus, I assume that (a) is meant, but I do not see how one can read this from the standard (as opposed to guessing it). Let's see what the J3 members think how it should be interpreted; I think ultimately an interpretation request is required.
[Bug target/46972] __thread storage class variable gets optimized out on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46972 --- Comment #8 from Andrew Pinski pinskia at gcc dot gnu.org 2010-12-20 16:51:29 UTC --- (In reply to comment #7) (In reply to comment #6) I think enumtls has been fixed on the trunk with respect of fsection-anchors. Can you try the trunk? Yes, looks like this bug is fixed in trunk. Assembly output looks sane. I will see if it works on real hardware some time later today. Do you know svn revision it got fixed? No but the change was done by Iain Sandoe to fix enum TLS with LTO on darwin.
[Bug other/46489] tree optimizer and frontend files use target macros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46489 --- Comment #5 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org 2010-12-20 17:04:39 UTC --- (In reply to comment #4) This sounds like a nice approach for making sure it is safe to remove a tm.h include from a particular source file - if combined with generating a list of every target (every triplet with significant differences in how config.gcc / libgcc/config.host configure it, whether in the set of headers or the set of tm_defines) so you can run tests automatically for all targets - I fear our configure system is turing complete, and thus such a list is not computable. But by testing at least one configuration per target architecture, we already get a useful test coverage. I can also make a script to search for every macro that is documented with @defmac, so the remaining uncertainty would be for undocumented macros that only appear in specific configuration variants. I think a slight risk to break something where undocumented macros are involved is acceptable in phase 1/2, as long as the breakage is obvious during the gcc build - without the target macro poisoning, we could have obscure changes in behaviour that could be very hard to debug. it may avoid the need to check for every macro with one of the properties I identified as meaning a target macro, that is used anywhere in that source file or any header it includes. I'd be more doubtful about actually checking in a #include of tm-poison.h on trunk (the code to generate it, however, might be useful to check in). Yes, the idea is to auto-generate the file.
[Bug bootstrap/47027] a-stwiun.ads:441:80: (style) this line is too long
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47027 Ralf Wildenhues rwild at gcc dot gnu.org changed: What|Removed |Added CC||rwild at gcc dot gnu.org AssignedTo|unassigned at gcc dot |rwild at gcc dot gnu.org |gnu.org | --- Comment #1 from Ralf Wildenhues rwild at gcc dot gnu.org 2010-12-20 17:25:39 UTC --- I'll fix that presently.
[Bug bootstrap/47027] a-stwiun.ads:441:80: (style) this line is too long
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47027 --- Comment #2 from Ralf Wildenhues rwild at gcc dot gnu.org 2010-12-20 17:32:17 UTC --- Author: rwild Date: Mon Dec 20 17:32:06 2010 New Revision: 168089 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168089 Log: Fix PR bootstrap/47027. gcc/ada/: PR bootstrap/47027 * a-stwiun-shared.ads: Rewrap overlong comment line. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/a-stwiun-shared.ads
[Bug bootstrap/47027] a-stwiun.ads:441:80: (style) this line is too long
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47027 Ralf Wildenhues rwild at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from Ralf Wildenhues rwild at gcc dot gnu.org 2010-12-20 17:38:21 UTC --- Fixed. Sorry again for the breakage.
[Bug other/46489] tree optimizer and frontend files use target macros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46489 --- Comment #6 from joseph at codesourcery dot com joseph at codesourcery dot com 2010-12-20 17:42:46 UTC --- On Mon, 20 Dec 2010, amylaar at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46489 --- Comment #5 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org 2010-12-20 17:04:39 UTC --- (In reply to comment #4) This sounds like a nice approach for making sure it is safe to remove a tm.h include from a particular source file - if combined with generating a list of every target (every triplet with significant differences in how config.gcc / libgcc/config.host configure it, whether in the set of headers or the set of tm_defines) so you can run tests automatically for all targets - I fear our configure system is turing complete, and thus such a list is not computable. One configuration for each case in config.gcc, at least, so that you cover every header that might go in tm_file (and every object in c_target_objs etc.). The effects of different macro values (such as the computation of FBSD_MAJOR from the target triplet for *-*-freebsd*) are less important. But by testing at least one configuration per target architecture, we already get a useful test coverage. I can also make a script to search for every macro that is documented with @defmac, so the remaining uncertainty would be for undocumented macros that only appear in specific configuration variants. You could also check for every #define (note that some may have whitespace after the #) in config/*.h config/*/*.h.
[Bug tree-optimization/44776] FAIL: gcc.dg/matrix/transpose-3.c execution, -fprofile-use -fipa-matrix-reorg -fdump-ipa-matrix-reorg -O3 -fwhole-program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44776 --- Comment #12 from Zdenek Sojka zsojka at seznam dot cz 2010-12-20 18:00:15 UTC --- Created attachment 22831 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22831 simpler testcase Crashes on x86_64-linux, r168061 $ gcc -O -fipa-matrix-reorg -fwhole-program pr44776-2.c $ ./a.out Segmentation fault With valgrind: $ valgrind -q ./a.out ==16712== Invalid write of size 4 ==16712==at 0x4005BC: main (pr44776-2.c:10) ==16712== Address 0x5186050 is 0 bytes after a block of size 16 alloc'd ==16712==at 0x4C2648E: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==16712==by 0x4005A7: main (pr44776-2.c:13) ==16712== ==16712== Invalid read of size 4 ==16712==at 0x4005F9: main (pr44776-2.c:25) ==16712== Address 0x5186050 is 0 bytes after a block of size 16 alloc'd ==16712==at 0x4C2648E: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==16712==by 0x4005A7: main (pr44776-2.c:13) ==16712== ==16712== Invalid write of size 4 ==16712==at 0x400602: main (pr44776-2.c:27) ==16712== Address 0x5186050 is 0 bytes after a block of size 16 alloc'd ==16712==at 0x4C2648E: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==16712==by 0x4005A7: main (pr44776-2.c:13) ==16712== ==16712== Invalid read of size 4 ==16712==at 0x400629: main (pr44776-2.c:25) ==16712== Address 0x5286040 is not stack'd, malloc'd or (recently) free'd ==16712== ==16712== Invalid write of size 4 ==16712==at 0x40063F: main (pr44776-2.c:27) ==16712== Address 0x5286040 is not stack'd, malloc'd or (recently) free'd ==16712==
[Bug tree-optimization/44776] FAIL: gcc.dg/matrix/transpose-3.c execution, -fprofile-use -fipa-matrix-reorg -fdump-ipa-matrix-reorg -O3 -fwhole-program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44776 --- Comment #13 from Zdenek Sojka zsojka at seznam dot cz 2010-12-20 18:01:46 UTC --- It crashes with -m32 too, so it isn't specific to target x86_64-apple-darwin10, nor x86_64 in general
[Bug libgcj/46774] [gcj] Calling Policy.setPolicy with a new Policy object has no effect on the DefaultSecurityManager
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46774 --- Comment #3 from gandalf at gcc dot gnu.org gandalf at gcc dot gnu.org 2010-12-20 18:19:57 UTC --- Author: gandalf Date: Mon Dec 20 18:19:52 2010 New Revision: 168092 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168092 Log: PR libgcj/46774: Create dynamic ProtectionDomain instances which check the system policy. 2010-12-13 Andrew John Hughes ahug...@redhat.com PR libgcj/46774 * libjava/java/security/VMAccessController.java: (DEFAULT_CONTEXT): Create ProtectionDomain with four argument constructor (arguments are the same as those implied by the two argument constructor). (getContext()): Create ProtectionDomain instances with four argument constructor using a null Principal array (as before) but including the classloader, which was always null before. Modified: branches/gcc-4_5-branch/libjava/ChangeLog branches/gcc-4_5-branch/libjava/classpath/lib/java/security/VMAccessController.class branches/gcc-4_5-branch/libjava/java/security/VMAccessController.java
[Bug bootstrap/46650] r167010 breaks --enable-build-with-cxx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46650 Jack Howarth howarth at nitro dot med.uc.edu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #7 from Jack Howarth howarth at nitro dot med.uc.edu 2010-12-20 18:20:04 UTC --- Fixed at r167764.
[Bug c++/46654] [trans-mem] volatile objects must not be allowed in a safe statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46654 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED
[Bug libgcj/46774] [gcj] Calling Policy.setPolicy with a new Policy object has no effect on the DefaultSecurityManager
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46774 Andrew John Hughes gnu_andrew at member dot fsf.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Version|4.6.0 |4.5.1 Resolution||FIXED Target Milestone|--- |4.5.3 --- Comment #4 from Andrew John Hughes gnu_andrew at member dot fsf.org 2010-12-20 18:32:25 UTC --- Fixed in trunk and 4.5 branch.
[Bug tree-optimization/46987] [4.6 Regression] g++.dg/torture/covariant-1.C ICE: double free or corruption with -fno-inline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46987 --- Comment #4 from Martin Jambor jamborm at gcc dot gnu.org 2010-12-20 18:35:51 UTC --- OK, it's not later, the folding is called from within ccp which I guess is not happy that there is a new ssa name or some such nuisance. Which means that the best fix is probably to go ahead and commit http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01217.html which I wanted to wait with but this is a good reason not to. I'll re-test and do it tomorrow.
[Bug middle-end/46935] We should recognize expanded switch statement and convert 2 way switch statements into shift mask test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46935 Maxim Kuvyrkov mkuvyrkov at gcc dot gnu.org changed: What|Removed |Added CC||mkuvyrkov at gcc dot ||gnu.org --- Comment #4 from Maxim Kuvyrkov mkuvyrkov at gcc dot gnu.org 2010-12-20 18:42:45 UTC --- I know Tom de Vries is working on this problem and has a prototype patch. He'll be posting his work for 4.7.
[Bug rtl-optimization/47028] New: [4.6 Regression] gcc.dg/tree-ssa/tailrecursion-[57].c FAIL with -foptimize-sibling-calls -fno-forward-propagate -fno-tree-copy-prop -fno-tree-dominator-opts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47028 Summary: [4.6 Regression] gcc.dg/tree-ssa/tailrecursion-[57].c FAIL with -foptimize-sibling-calls -fno-forward-propagate -fno-tree-copy-prop -fno-tree-dominator-opts Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 22832 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22832 reduced testcase Output: $ gcc -O -foptimize-sibling-calls -fno-forward-propagate -fno-tree-copy-prop -fno-tree-dominator-opts pr47028.c $ ./a.out Aborted At the assembly level, fib() is reduced to return 1;: fib: moveax, 0# add_acc.0, addeax, 1# tmp73, ret it seems to first appear in the pr47028.c.179r.combine dump Tested revision: r168061 - fail r165699 - fail r161659 - OK 4.5 r168062 -OK
[Bug middle-end/40060] [4.5/4.6 Regression] casts loose alignment info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40060 Sean McGovern gseanmcg at gmail dot com changed: What|Removed |Added CC||gseanmcg at gmail dot com --- Comment #10 from Sean McGovern gseanmcg at gmail dot com 2010-12-20 19:02:02 UTC --- Any desire to reconfirm this on powerpc-darwin-*?
[Bug rtl-optimization/47028] [4.6 Regression] gcc.dg/tree-ssa/tailrecursion-[57].c FAIL with -foptimize-sibling-calls -fno-forward-propagate -fno-tree-copy-prop -fno-tree-dominator-opts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47028 --- Comment #1 from Zdenek Sojka zsojka at seznam dot cz 2010-12-20 19:20:12 UTC --- Created attachment 22833 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22833 another testcase (reduced from gcc.dg/tree-ssa/tailrecursion-7.c) I hope this is the same problem as the first testcase. $ gcc -O -foptimize-sibling-calls -fno-tree-copy-prop -fno-tree-dominator-opts pr47028-2.c $ ./a.out Aborted (it takes some time to run, the inner loop is done 2^32-1 times instead of n-1) When the assembly is changed in the following way: --- pr47028-2.s 2010-12-20 20:16:12.0 +0100 +++ pr47028-2-fixed.s 2010-12-20 20:16:26.0 +0100 @@ -41,7 +41,7 @@ foo: .LFB0: .cfi_startproc - mov edx, 0 # n, + mov edx, edi# n, mov eax, 1 # mul_tmp.4, mov esi, 0 # add_acc.1, testedi, edi# n it works fine. edx is loaded by '0' instead of 'n'.
[Bug fortran/46974] ICE with TRANSFER using a C_PTR entity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46974 --- Comment #11 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-20 21:44:02 UTC --- Author: burnus Date: Mon Dec 20 21:43:58 2010 New Revision: 168095 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168095 Log: 2010-12-20 Tobias Burnus bur...@net-b.de PR fortran/46974 * gfortran.dg/c_ptr_tests_16.f90: Fix endian issue. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/c_ptr_tests_16.f90
[Bug fortran/46978] [4.6 Regression] TRANSPOSE with RESHAPE and ALLOCATE: Segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46978 --- Comment #7 from Mikael Morin mikael at gcc dot gnu.org 2010-12-20 23:24:54 UTC --- This seems to fix it, though I find it somewhat suspicious. Index: trans-array.c === --- trans-array.c(révision 164205) +++ trans-array.c(copie de travail) @@ -851,8 +851,8 @@ gfc_trans_create_temp_array (stmtblock_t * pre, st of the descriptor fields. */ tmp = fold_build2_loc (input_location, MINUS_EXPR, gfc_array_index_type, -gfc_conv_descriptor_ubound_get (desc, gfc_rank_cst[n]), -gfc_conv_descriptor_lbound_get (desc, gfc_rank_cst[n])); +gfc_conv_descriptor_ubound_get (desc, gfc_rank_cst[dim]), +gfc_conv_descriptor_lbound_get (desc, gfc_rank_cst[dim])); loop-to[n] = tmp; continue; } I remember making this change back and forth, and indeed, it reverts part of revision 164112, but the regression is at revision 164205. Strange.
[Bug fortran/46978] [4.6 Regression] TRANSPOSE with RESHAPE and ALLOCATE: Segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46978 --- Comment #8 from Mikael Morin mikael at gcc dot gnu.org 2010-12-20 23:29:34 UTC --- (In reply to comment #6) This seems to be the problem : the front-end generates a transposed descriptor for a non-intrinsic function. If the function is an intrinsic, the descriptor is filled in the library, and it is not transposed. It may not be the problem after all.
[Bug target/44290] [4.5 regression] __naked attribute is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44290 --- Comment #31 from Jie Zhang jiez at gcc dot gnu.org 2010-12-21 04:16:19 UTC --- Patch for 4.5 was posted: http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01351.html Waiting for approval.
