[Bug target/47000] [4.5 Regression] Failure to inline SSE intrinsics

[jakub at gcc dot gnu.org]

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

--- Comment #24 from Jakub Jelinek  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

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

 CC||jb at gcc dot gnu.org

--- Comment #13 from Janne Blomqvist  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

[burnus at gcc dot gnu.org]

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

--- Comment #7 from Tobias Burnus  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

[dominiq at lps dot ens.fr]

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

--- Comment #16 from Dominique d'Humieres  
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

[burnus at gcc dot gnu.org]

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

[irar at il dot ibm.com]

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

Ira Rosen  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  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

[dominiq at lps dot ens.fr]

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

--- Comment #97 from Dominique d'Humieres  
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" *

[eres at il dot ibm.com]

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

--- Comment #1 from revital eres  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)

[guanx.bac at gmail dot com]

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

Guan Xin  changed:

   What|Removed |Added

 CC||guanx.bac at gmail dot com

--- Comment #10 from Guan Xin  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" *

[eres at il dot ibm.com]

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

--- Comment #2 from revital eres  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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  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

[burnus at gcc dot gnu.org]

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

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #4 from Jonathan Wakely  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

[jon at beniston dot com]

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

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  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

[iains at gcc dot gnu.org]

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

--- Comment #2 from Iain Sandoe  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=gcc&view=rev&rev=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

[iains at gcc dot gnu.org]

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

--- Comment #4 from Iain Sandoe  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=gcc&view=rev&rev=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

[iains at gcc dot gnu.org]

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

--- Comment #98 from Iain Sandoe  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=gcc&view=rev&rev=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

[iains at gcc dot gnu.org]

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

--- Comment #99 from Iain Sandoe  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=gcc&view=rev&rev=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" *

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  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

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres  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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  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:DI<<0x2+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:DI<<0x2+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:DI<<0x2+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

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||jakub at redhat dot com

--- Comment #8 from Dominique d'Humieres  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" *

[eres at il dot ibm.com]

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

--- Comment #4 from revital eres  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" *

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  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

[burnus at gcc dot gnu.org]

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

--- Comment #6 from Tobias Burnus  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

[burnus at gcc dot gnu.org]

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

--- Comment #7 from Tobias Burnus  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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution||FIXED

--- Comment #9 from Jakub Jelinek  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

[paulius.zaleckas at gmail dot com]

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

--- Comment #7 from Paulius Zaleckas  
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

[iains at gcc dot gnu.org]

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

--- Comment #100 from Iain Sandoe  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

[David Holland]

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

[tmoschou at gmail dot com]

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
-
#include 
#include 

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);

}
--

[Bug c++/47026] invalid temporary is being assigned to a const-reference

[tmoschou at gmail dot com]

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

Terry  changed:

   What|Removed |Added

 CC||tmoschou at gmail dot com

--- Comment #1 from Terry  2010-12-20 11:33:37 UTC 
---
Whoops, forgot to say compiled on Ubuntu 10.10 x64.

Re: gcc's cpp makes ?: left-associative

[Joseph S. Myers]

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  

PR preprocessor/35313, PR preprocessor/36088:
* expr.c (optab) : Set precedence to 4.
(reduce) : 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

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #2 from Jonathan Wakely  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

[Jonathan Wakely]

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

[wd at denx dot de]

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

Wolfgang Denk  changed:

   What|Removed |Added

 CC||wd at denx dot de

--- Comment #15 from Wolfgang Denk  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

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  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

[jamborm at gcc dot gnu.org]

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

[amylaar at gcc dot gnu.org]

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

--- Comment #3 from Jorn Wolfgang Rennecke  
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

[fenixk19 at mail dot ru]

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

--- Comment #14 from Alexander Varnin  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

[zsojka at seznam dot cz]

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

--- Comment #1 from Zdenek Sojka  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 = 

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

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #15 from Steve Kargl  
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

[janus at gcc dot gnu.org]

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

[joseph at codesourcery dot com]

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

--- Comment #4 from 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

[amylaar at gcc dot gnu.org]

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

--- Comment #16 from Jorn Wolfgang Rennecke  
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=gcc&view=rev&rev=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
branches/pr46489-20101217-branch/gcc/target.h
branches/pr464

[Bug fortran/47024] [OOP] STORAGE_SIZE (for polymorphic types): Segfault at run time

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  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 ".data == NULL" or " == 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

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski  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

[amylaar at gcc dot gnu.org]

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

--- Comment #5 from Jorn Wolfgang Rennecke  
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

[rwild at gcc dot gnu.org]

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

Ralf Wildenhues  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  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

[rwild at gcc dot gnu.org]

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

--- Comment #2 from Ralf Wildenhues  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=gcc&view=rev&rev=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

[rwild at gcc dot gnu.org]

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

Ralf Wildenhues  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #3 from Ralf Wildenhues  2010-12-20 
17:38:21 UTC ---
Fixed.  Sorry again for the breakage.

[Bug other/46489] tree optimizer and frontend files use target macros

[joseph at codesourcery dot com]

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

--- Comment #6 from 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  
> 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

[zsojka at seznam dot cz]

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

--- Comment #12 from Zdenek Sojka  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

[zsojka at seznam dot cz]

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

--- Comment #13 from Zdenek Sojka  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

[gandalf at gcc dot gnu.org]

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

--- Comment #3 from 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=gcc&view=rev&rev=168092
Log:
PR libgcj/46774: Create dynamic ProtectionDomain instances which check the
system policy.

2010-12-13  Andrew John Hughes  

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

[howarth at nitro dot med.uc.edu]

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

Jack Howarth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #7 from Jack Howarth  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

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  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

[gnu_andrew at member dot fsf.org]

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

Andrew John Hughes  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  
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

[jamborm at gcc dot gnu.org]

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

--- Comment #4 from Martin Jambor  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

[mkuvyrkov at gcc dot gnu.org]

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

Maxim Kuvyrkov  changed:

   What|Removed |Added

 CC||mkuvyrkov at gcc dot
   ||gnu.org

--- Comment #4 from Maxim Kuvyrkov  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

[zsojka at seznam dot cz]

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

[gseanmcg at gmail dot com]

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

Sean McGovern  changed:

   What|Removed |Added

 CC||gseanmcg at gmail dot com

--- Comment #10 from Sean McGovern  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

[zsojka at seznam dot cz]

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

--- Comment #1 from Zdenek Sojka  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

[burnus at gcc dot gnu.org]

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

--- Comment #11 from Tobias Burnus  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=gcc&view=rev&rev=168095
Log:
2010-12-20  Tobias Burnus  

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

[mikael at gcc dot gnu.org]

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

--- Comment #7 from Mikael Morin  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

[mikael at gcc dot gnu.org]

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

--- Comment #8 from Mikael Morin  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

[jiez at gcc dot gnu.org]

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

--- Comment #31 from Jie Zhang  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.