[Bug target/43216] New: Use high registers to reduce code size and improve performance when targeting thumb2

[carrot at google dot com]

Compile the attached source code with options -march=armv7-a -mthumb -Os, gcc
generates:

foo2:
push{r4, r5, r6, r7, lr}
sub sp, sp, #20
mov r7, r2
str r0, [sp, #8]
movsr0, #64
bl  malloc
str r0, [sp, #4]//C1
cmp r0, #0  //C2
beq .L2
ldr r6, [sp, #8]
movsr5, #0
movsr4, #2
b   .L3
.L8:
add r3, r7, r4, lsl #2  // A1
str r3, [sp, #12]   // A2
ldr r3, [r7, r4, lsl #2]//B1
mov r0, r3  //B2
str r3, [sp, #0]//B3
bl  foo1
ldr r3, [sp, #0]//B4
cbnzr0, .L4
mov r0, r3  //B5
bl  bar
ldr r3, [sp, #0]//B6
cbz r0, .L5
ldr r3, [sp, #12]   // A3
.L7:
addsr4, r4, #1
cmp r4, r6
bge .L6
ldr r0, [r3, #4]!   // A4
str r3, [sp, #0]// A5
bl  foo1
ldr r3, [sp, #0]// A6
cmp r0, #0
bne .L7
.L6:
ldr r3, [r7, r4, lsl #2]//B7
mov r6, r4
.L5:
ldr r0, [r3, #0]//B8
ldr r1, [sp, #8]
bl  foo
ldr r3, [sp, #4]//   C3
str r0, [r3, r5, lsl #2]//   C4
addsr5, r5, #1
.L4:
addsr4, r4, #1
.L3:
cmp r4, r6
blt .L8
.L2:
ldr r0, [sp, #4]//   C5
add sp, sp, #20
pop {r4, r5, r6, r7, pc}

Usually instructions involved high registers are larger than those with low
registers only. But if we can use them cleverly we can improve both code size
and performance. Especially in cases we can reduce register spills and for
instruction encodings that are already 4 bytes long regardless what registers
are used.

First example is instructions marked An. They represent the live range of
register r3. Among them A2,A3,A5,A6 are register spill and reload instructions.
If we replace r3 with r8, these 4 instructions can be removed. At the same time
we keep the size of A1,A4 because they are already 4 bytes long. The cost we
must pay is save and restore high registers in function prologue and epilogue.
But it is still a win.

Now consider another live range of register r3 in instructions marked Bn. If we
replace r3 with r9, instructions B3,B4,B6 can be removed because they are spill
and reload. Code size of instruction B8 will be larger. The size of other Bn
instructions is unchanged. So it is also win.

The third example in this test case is the value in memory [sp, #4] in
instructions marked Cn. Instead we can place the value into register r10. So
instruction C1,C2 can be rewritten as "mov r10,r0". The reload in C3 can be
removed and the r3 in C4 can be replace by r10. C5 can be replaced by "mov r0,
r10".


-- 
   Summary: Use high registers to reduce code size and improve
performance when targeting thumb2
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
 GCC build triplet: i686-linux
  GCC host triplet: i686-linux
GCC target triplet: arm-eabi


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

[Bug target/43216] Use high registers to reduce code size and improve performance when targeting thumb2

[carrot at google dot com]

--- Comment #1 from carrot at google dot com  2010-03-01 08:11 ---
Created an attachment (id=19994)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19994&action=view)
test case


-- 


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

[Bug fortran/43062] NAMELIST attribute conflicts with ALLOCATABLE attribute

[burnus at gcc dot gnu dot org]

--- Comment #15 from burnus at gcc dot gnu dot org  2010-03-01 08:45 ---
See also: http://j3-fortran.org/pipermail/j3/2010-February/003401.html
where Van and Malcolm agreed that changes should be done.


-- 


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

[Bug fortran/43199] [OOP] ICE when reading module file: find_array_spec(): Component not found

[burnus at gcc dot gnu dot org]

--- Comment #5 from burnus at gcc dot gnu dot org  2010-03-01 09:24 ---
Subject: Bug 43199

Author: burnus
Date: Mon Mar  1 09:23:35 2010
New Revision: 157133

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157133
Log:
2010-03-01  Tobias Burnus  

PR fortran/43199
* resolve.c (find_array_spec): Handle REF_COMPONENT with
CLASS components.

2010-03-01  Tobias Burnus  

PR fortran/43199
* gfortran.dg/module_read_2.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/module_read_2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/43199] [OOP] ICE when reading module file: find_array_spec(): Component not found

[burnus at gcc dot gnu dot org]

--- Comment #6 from burnus at gcc dot gnu dot org  2010-03-01 09:24 ---
FIXED on the trunk (4.5). Thanks for the bugreport!


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug target/43215] x86-64: Nonstandard instruction "movd %xmm0, %rax"

[ubizjak at gmail dot com]

--- Comment #1 from ubizjak at gmail dot com  2010-03-01 09:56 ---
Indeed.

Following patch fixes the problem:

Index: i386.md
===
--- i386.md (revision 157132)
+++ i386.md (working copy)
@@ -3245,7 +3245,7 @@

 case 9:
 case 10:
-return "%vmovd\t{%1, %0|%0, %1}";
+return "%vmovq\t{%1, %0|%0, %1}";

 default:
   gcc_unreachable();


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ubizjak at gmail dot com
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-03-01 09:56:03
   date||
   Target Milestone|--- |4.3.5


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

[Bug libstdc++/43203] abi_check from libstdc++ tests fails with CFLAGS="-march=core2"

[paolo dot carlini at oracle dot com]

--- Comment #13 from paolo dot carlini at oracle dot com  2010-03-01 10:05 
---
Closing


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug fortran/43217] New: Output of Hollerith constants which are not a multiple of 4 bytes

[burnus at gcc dot gnu dot org]

I do not know whether the following program is valid Fortran 77 (with deleted
parts). The issue is that gfortran creates:

static character(kind=1) C.1534[1:9] = "HELLO YOU";

which is then passed to an default-kind integer. "HELLO YOU" consists of 9
characters, but a default-kind integer can accommodate for multiples of 4, i.e.
12 characters. Thus, printing with "FORMAT (100A4)" prints more data than
available.

gfortran:
HELLO YOUhfj
:HELLO YOUhfj:
4C4C4548 4F59204F 6A666855
where "od" shows that it prints:
  H   E   L   L   O  sp   Y   O   U   h   f   j  nl

ifort:
HELLO YOU
:HELLO YOU:
4C4C4548 4F59204F   55
   H   E   L   L   O  sp   Y   O   U nul nul nul  nl
i.e. it prints trailing NULs.

NAG f95:
HELLO YOU
:HELLO YOU:
4C4C4548 4F59204F 34280055
   H   E   L   L   O  sp   Y   O   U nul   (   4  nl

sunf95:
HELLO YOU
:HELLO YOU:
4C4C4548 4F59204F   55
  H   E   L   L   O  sp   Y   O   U nul nul nul  nl

open64:
HELLO YOU
:HELLO YOU   :
4C4C4548 4F59204F 20202055
   H   E   L   L   O  sp   Y   O   U  sp  sp  sp  nl

pathscale:
HELLO YOU
:HELLO YOU   :
4C4C4548 4F59204F 20202055
   H   E   L   L   O  sp   Y   O   U  sp  sp  sp  nl

Thus either by zero or by space padding it seems to work in the other
compilers. I wonder what happens with g77.


The program itself:

C PROGRAM HELLO2
  CALL WRTOUT (9HHELLO YOU, 9)
  STOP
  END
C
  SUBROUTINE WRTOUT (IARRAY, NCHRS)
C
  INTEGER IARRAY(1)
  INTEGER NCHRS
C
  INTEGER ICPW
  DATA ICPW/4/
  INTEGER I, NWRDS
C
  NWRDS = (NCHRS + ICPW - 1) /ICPW
  WRITE (6,100) (IARRAY(I), I=1,NWRDS)
  WRITE (6,101) (IARRAY(I), I=1,NWRDS)
  write(*,'(4(z8," "))') (IARRAY(I), I=1,NWRDS)
  RETURN
  100 FORMAT (100A4)
  101 FORMAT (':',3A4,':')
  END


-- 
   Summary: Output of Hollerith constants which are not a multiple
of 4 bytes
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug c++/42748] warnings about 'mangling of 'va_list' has changed in GCC 4.4' not suppressed in sytem headers

[dominiq at lps dot ens dot fr]

--- Comment #23 from dominiq at lps dot ens dot fr  2010-03-01 10:20 ---
*** Bug 40459 has been marked as a duplicate of this bug. ***


-- 

dominiq at lps dot ens dot fr changed:

   What|Removed |Added

 CC||dominiq at lps dot ens dot
   ||fr


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

[Bug testsuite/40459] g++.dg/abi/mangle*.C fail on darwin

[dominiq at lps dot ens dot fr]

--- Comment #14 from dominiq at lps dot ens dot fr  2010-03-01 10:20 ---
> This is a dup of c++/42748, which has now been fixed.

So marking this pr as duplicate.


*** This bug has been marked as a duplicate of 42748 ***


-- 

dominiq at lps dot ens dot fr changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug lto/43218] New: [LTO] Conflicting function types cause ICE

[d dot g dot gorbachev at gmail dot com]

#1

lto1: internal compiler error: in cgraph_estimate_size_after_inlining, at
ipa-inline.c:206
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: /usr/local/bin/i686-pc-linux-gnu-gcc-4.5.0 returned 1 exit status
collect2: lto-wrapper returned 1 exit status

#2

In file included from expand_call_inline-2.c:1:0,
 from expand_call_inline-1.c:1,
 from :0:
expand_call_inline-1.c: In function 'main':
expand_call_inline-1.c:5:11: internal compiler error: in expand_call_inline, at
tree-inline.c:3798
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: /usr/local/bin/i686-pc-linux-gnu-gcc-4.5.0 returned 1 exit status
collect2: lto-wrapper returned 1 exit status

#3

In file included from fold_convert_loc-2.c:1:0,
 from fold_convert_loc-1.c:1,
 from :0:
fold_convert_loc-1.c: In function 'main':
fold_convert_loc-1.c:5:3: internal compiler error: in fold_convert_loc, at
fold-const.c:2670
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: /usr/local/bin/i686-pc-linux-gnu-gcc-4.5.0 returned 1 exit status
collect2: lto-wrapper returned 1 exit status


-- 
   Summary: [LTO] Conflicting function types cause ICE
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: d dot g dot gorbachev at gmail dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug tree-optimization/43213] [4.5 Regression] Worse code generated with -O2

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-03-01 10:29 ---
Huh.  Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-03-01 10:29:21
   date||
   Target Milestone|--- |4.5.0


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

[Bug fortran/43217] Output of Hollerith constants which are not a multiple of 4 bytes

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2010-03-01 10:29 ---
> I wonder what happens with g77.

[ibook-dhum] f90/bug% g77 pr43217.f
[ibook-dhum] f90/bug% a.out
HELLO YOU   
:HELLO YOU  :
4C4C4548 4F59204F  955 


-- 


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

Re: [Bug tree-optimization/43213] [4.5 Regression] Worse code generated with -O2

[Andrew Pinski]

Sent from my iPhone

On Mar 1, 2010, at 2:29 AM, "rguenth at gcc dot gnu dot org" > wrote:





--- Comment #3 from rguenth at gcc dot gnu dot org  2010-03-01  
10:29 ---

Huh.  Confirmed.


Not that interesting because the aliasing sets are different and we  
made 4.5 work for c++ code dealing with dynamic types.






--

rguenth at gcc dot gnu dot org changed:

  What|Removed |Added
--- 
--- 
--

Status|UNCONFIRMED |NEW
Ever Confirmed|0   |1
  Last reconfirmed|-00-00 00:00:00 |2010-03-01 10:29:21
  date||
  Target Milestone|--- |4.5.0


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

[Bug tree-optimization/43213] [4.5 Regression] Worse code generated with -O2

[pinskia at gmail dot com]

--- Comment #4 from pinskia at gmail dot com  2010-03-01 10:38 ---
Subject: Re:  [4.5 Regression] Worse code generated with -O2



Sent from my iPhone

On Mar 1, 2010, at 2:29 AM, "rguenth at gcc dot gnu dot org"
 wrote:

>
>
> --- Comment #3 from rguenth at gcc dot gnu dot org  2010-03-01  
> 10:29 ---
> Huh.  Confirmed.

Not that interesting because the aliasing sets are different and we  
made 4.5 work for c++ code dealing with dynamic types.


>
>
> -- 
>
> rguenth at gcc dot gnu dot org changed:
>
>   What|Removed |Added
> --- 
> --- 
> --
> Status|UNCONFIRMED |NEW
> Ever Confirmed|0   |1
>   Last reconfirmed|-00-00 00:00:00 |2010-03-01 10:29:21
>   date||
>   Target Milestone|--- |4.5.0
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43213
>


-- 


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

[Bug lto/43212] [LTO] error: control flow in the middle of basic block

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-03-01 10:43 ---
Confirmed.  We do have sort-of a fixup pass to deal with this, but it doesn't
work very well.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||lto
   Last reconfirmed|-00-00 00:00:00 |2010-03-01 10:43:50
   date||


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

[Bug c/43211] [4.5 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at tree-ssa.c:1430

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-03-01 10:48 ---
Confirmed.  We leak bogus function types to the middle-end:

(gdb) call debug_tree (inner_type)
 >
QI
size  constant 8>
unit size  constant 1>
align 8 symtab 0 alias set -1 structural equality
arg-types 
chain >>
pointer_to_this >

which is void ()()

useless_type_converison_p doesn't expect this.  Called from

#7  0x00800e6d in gimplify_modify_expr (expr_p=0x75afa0b0, 
pre_p=0x7fffced8, post_p=0x7fffc558, want_value=0 '\000')
at /space/rguenther/src/svn/trunk/gcc/gimplify.c:4409
4409  STRIP_USELESS_TYPE_CONVERSION (*from_p);

A radical approach would be to not gimplify in case of errors (now that
most diagnostics we'd want to preserve have been moved pre-gimplification).


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-03-01 10:48:27
   date||
   Target Milestone|--- |4.5.0


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

[Bug tree-optimization/43213] [4.5 Regression] Worse code generated with -O2

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2010-03-01 10:48 ---
I have a patch.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-03-01 10:29:21 |2010-03-01 10:48:41
   date||


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

[Bug tree-optimization/43209] [4.5 Regression] ICE in try_improve_iv_set, at tree-ssa-loop-ivopts.c:5238

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Priority|P3  |P1


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

[Bug lto/43208] lto1: error: invalid conversion in return statement

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-03-01 10:54 ---
Confirmed.  struct X are not compatible by the notion of C99.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-03-01 10:54:53
   date||


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

[Bug c++/43206] [4.5 Regression] Revision 145440 caused ICE at cp/pt.c:9249

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-03-01 10:59 ---
Confirmed.  The testcase is invalid (apart from the missing semi-colon):

t.ii(9): error: class "Image" has no member "PixelType"
  template ::TInputImage > > >
   
  ^
  detected during processing of template argument list for "XXX" based
on template argument > at line 12

or 4.4:

t.ii:12: error: no type named 'PixelType' in 'class Image'
t.ii:12: error: template argument 2 is invalid
t.ii:12: error: invalid type in declaration before ';' token


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-invalid-code
  Known to work||4.4.3
   Last reconfirmed|-00-00 00:00:00 |2010-03-01 10:59:37
   date||


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

[Bug c++/43081] [4.3/4.4/4.5 regression] ICE with invalid in-class initializer

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.3.5


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

[Bug middle-end/42805] [4.5 Regression] FAIL: gcc.c-torture/execute/pr42248.c compilation at -O1 and above

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2010-03-01 11:48 ---
Confirmed with a cross to hppa-linux.

I believe this is again related to DECL_VALUE_EXPR.  SRA does:

@@ -122,8 +60,9 @@

 :
   x.0 = x;
+  SR.3_7 = x.a;
   y.1_6 = y_1(D);
-  D.1959_2 = x.0.a;
+  D.1959_2 = SR.3_7;
   y.2_3 = y.1_6;
   if (D.1959_2 != y.2_3)
 goto ;

but x is replaced with x.0 (callee copy).  SRA shouldn't undo this
(thus, never create replacements involving a DECL with DECL_HAS_VALUE_EXPR_P
set).

Reduced testcase:

typedef struct {
  _Complex double a;
  _Complex double b;
} Scf10;

void
check (Scf10 x, _Complex double y)
{
  if (x.a != y) __builtin_abort ();
}


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  GCC build triplet|hppa-unknown-linux-gnu  |
   GCC host triplet|hppa-unknown-linux-gnu  |
 GCC target triplet|hppa-unknown-linux-gnu  |hppa-unknown-linux-gnu,
   ||hppa2.0w-hp-hpux11.11
   Priority|P3  |P1
   Last reconfirmed|-00-00 00:00:00 |2010-03-01 11:48:54
   date||


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

[Bug c++/43081] [4.3/4.4/4.5 regression] ICE with invalid in-class initializer

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug c++/43116] [4.3/4.4/4.5 Regression] ICE when using attributes in a function alias declaration

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug c/43125] [4.5 Regression] Revision 156907 failed gcc.dg/attr-used.c

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2010-03-01 11:50 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/43141] [4.5 Regression] Wrong debug information with IPA-SRA

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


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

[Bug rtl-optimization/43156] [4.5 Regression] SPU-elf ICEs on simple programs

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-03-01 11:51 ---
spu-elf is neither a primary nor a secondary platform.  But, confirmed, as
I originally reported this.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Priority|P3  |P4
   Last reconfirmed|-00-00 00:00:00 |2010-03-01 11:51:50
   date||


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

[Bug tree-optimization/43164] [4.5 Regression] ice in completely_scalarize_record, at tree-sra.c:85

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


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

[Bug fortran/43173] Unnecessary array temporary: Passing contiguous array as actual argument

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2010-03-01 11:54 ---
Not a regression (we track regressions only against releases).  I see both
temporaries also on the 4.4 branch.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.4.3
Summary|[4.5 Regression] Unnecessary|Unnecessary array temporary:
   |array temporary: Passing|Passing contiguous array as
   |contiguous array as actual  |actual argument
   |argument|
   Target Milestone|4.5.0   |---


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

[Bug tree-optimization/43191] [4.5 Regression] ice in load_assign_lhs_subreplacements, at tree-sra.c:2459

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


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

[Bug c++/43206] [4.5 Regression] Revision 145440 caused ICE at cp/pt.c:9249

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


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

[Bug c/43211] [4.5 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at tree-ssa.c:1430

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug middle-end/42805] [4.5 Regression] FAIL: gcc.c-torture/execute/pr42248.c compilation at -O1 and above

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2010-03-01 12:11 ---
I have a patch.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-03-01 11:48:54 |2010-03-01 12:11:19
   date||


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

[Bug fortran/42900] gfortran.dg/stat_[12].f90 may fail on NFS filesystems

[ro at gcc dot gnu dot org]

--- Comment #3 from ro at gcc dot gnu dot org  2010-03-01 12:25 ---
Subject: Bug 42900

Author: ro
Date: Mon Mar  1 12:25:34 2010
New Revision: 157135

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157135
Log:
PR fortran/42900
* gfortran.dg/stat_1.f90: Accept 'testfile' gid == parent dir gid.
Explain this.
* gfortran.dg/stat_2.f90: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/stat_1.f90
trunk/gcc/testsuite/gfortran.dg/stat_2.f90


-- 


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

[Bug libgcj/38251] [4.4/4.5 Regression] tools.zip doesn't build on systems with short command lines

[ro at gcc dot gnu dot org]

--- Comment #12 from ro at gcc dot gnu dot org  2010-03-01 12:32 ---
Subject: Bug 38251

Author: ro
Date: Mon Mar  1 12:32:02 2010
New Revision: 157137

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157137
Log:
PR libgcj/38251
* tools/Makefile.am (dist-hook): Prune .svn directories in asm and
classes copies.
* tools/Makefile.in: Regenerate.

Revert:
2008-11-05  Andrew Haley  

* tools/Makefile.am (UPDATE_TOOLS_ZIP, CREATE_TOOLS_ZIP): Exclude
.svn direcories.

Modified:
trunk/libjava/classpath/ChangeLog
trunk/libjava/classpath/tools/Makefile.am
trunk/libjava/classpath/tools/Makefile.in


-- 


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

[Bug lto/43218] [LTO] Conflicting function types cause ICE

[d dot g dot gorbachev at gmail dot com]

--- Comment #1 from d dot g dot gorbachev at gmail dot com  2010-03-01 
12:43 ---
Created an attachment (id=19995)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19995&action=view)
Three testcases

Compile with `-flto -O2'


-- 


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

[Bug pch/14940] PCH largefile test fails on various platforms

[ro at gcc dot gnu dot org]

--- Comment #36 from ro at gcc dot gnu dot org  2010-03-01 12:44 ---
Subject: Bug 14940

Author: ro
Date: Mon Mar  1 12:44:33 2010
New Revision: 157141

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157141
Log:
gcc:
PR pch/14940
* config/host-solaris.c (HOST_HOOKS_GT_PCH_GET_ADDRESS): Redefine
to sol_gt_pch_get_address.
(TRY_EMPTY_VM_SPACE): Define for all combinations of 32 and
64-bit, SPARC and x86.
(sol_gt_pch_get_address): New function.

gcc/testsuite:
PR pch/14940
* gcc.dg/pch/pch.exp: Don't XFAIL largefile.c on i?86-*-solaris2.10.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/host-solaris.c
trunk/gcc/testsuite/gcc.dg/pch/pch.exp


-- 


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

[Bug lto/42451] 'warning: type of "array" does not match original declaration' with -flto/-fwhopr

[d dot g dot gorbachev at gmail dot com]

--- Comment #6 from d dot g dot gorbachev at gmail dot com  2010-03-01 
12:47 ---
Created an attachment (id=19996)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19996&action=view)
Another testcase

Compile with `gcc -flto 1.c 2.c'


-- 


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

[Bug fortran/43169] [OOP] gfortran rejects pure procedure with select type construct

[janus at gcc dot gnu dot org]

--- Comment #9 from janus at gcc dot gnu dot org  2010-03-01 12:47 ---
Even with the patch from comment #7, another thing goes wrong with BLOCK
statements:

  pure subroutine swap
implicit none
real :: r1
block
  real :: r2
  r1 = 42.
  r2 = 43.
end block
  end subroutine


  r1 = 42.
  1
Error: Cannot assign to variable 'r1' in PURE procedure at (1)

This is rejected although it is valid.


-- 


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

[Bug tree-optimization/43213] [4.5 Regression] Worse code generated with -O2

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2010-03-01 12:56 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/41250] hppa has DECL_VALUE_EXPR decls appearing in the function

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2010-03-01 12:57 ---
Mine.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-03-01 12:57:11
   date||


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

[Bug tree-optimization/43213] [4.5 Regression] Worse code generated with -O2

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2010-03-01 12:57 ---
Subject: Bug 43213

Author: rguenth
Date: Mon Mar  1 12:56:44 2010
New Revision: 157142

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157142
Log:
2010-03-01  Richard Guenther  

PR middle-end/43213
* expr.c (expand_assignment): Use the alias-oracle to tell
if the rhs aliases the result decl.

* gcc.dg/pr43213.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/pr43213.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/expr.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c/43219] New: O2, O3 and Os produce wrong code

[vierhaus at physik dot hu-berlin dot de]

LC_ALL=C gcc -v
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)


The following code
#include 
#include 

int main() {

  int i;
  double R4 = 0;
  int *activedirections;
  int nactive=0;
  int holder;
  activedirections = malloc(sizeof(int));
  activedirections[0] = 0;
  nactive = 0;

  for (i=1; i<=1; i=i+1) {
  activedirections[nactive] = i;
  nactive = nactive + 1;
  }

  holder = activedirections[0];
  printf("activedirections[0] = %i\n",activedirections[0]);
  printf("activedirections[0] = %i\n",activedirections[0]);
  printf("holder  = %i\n",holder);
  free(activedirections);
}

produces the output:

activedirections[0] = 0
activedirections[0] = 1
holder  = 0

when compiling with (gcc version 4.3.2)
gcc -O3 prog.c
gcc -O2 prog.c
gcc -Os prog.c

and the output

activedirections[0] = 1
activedirections[0] = 1
holder  = 1

when compiled with -O1 or -O0 or when compiled with gcc-4.2.4 or gcc-4.1.3 on
any optimization level. The latter is latter case is what I would expect.
There is no compiler output in all cases.

I will not paste the 1600 lines of prog.i in here and can not see how to attach
the file to the report... ?


-- 
   Summary: O2, O3 and Os produce wrong code
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vierhaus at physik dot hu-berlin dot de


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

[Bug c/43219] O2, O3 and Os produce wrong code

[vierhaus at physik dot hu-berlin dot de]

--- Comment #1 from vierhaus at physik dot hu-berlin dot de  2010-03-01 
13:01 ---
Created an attachment (id=19997)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19997&action=view)
prog.i after compilation with -Os


-- 


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

[Bug c/43219] O2, O3 and Os produce wrong code

[vierhaus at physik dot hu-berlin dot de]

--- Comment #2 from vierhaus at physik dot hu-berlin dot de  2010-03-01 
13:01 ---
Created an attachment (id=19998)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19998&action=view)
Source code


-- 


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

[Bug middle-end/42805] [4.5 Regression] FAIL: gcc.c-torture/execute/pr42248.c compilation at -O1 and above

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2010-03-01 13:14 ---


*** This bug has been marked as a duplicate of 41250 ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||DUPLICATE


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

[Bug middle-end/41250] hppa has DECL_VALUE_EXPR decls appearing in the function

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2010-03-01 13:14 ---
*** Bug 42805 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu dot
   ||org


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

[Bug target/43215] x86-64: Nonstandard instruction "movd %xmm0, %rax"

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2010-03-01 13:31 ---
This is done on purpose to provide backward compatibility
since vmovq isn't in original x86-64 spec and older assemblers
don't support it. From i386-opc.tbl in binutils:

// These really shouldn't allow for Reg64 (movq is the right mnemonic for
// copying between Reg64/Mem64 and RegXMM/RegMMX, as is mandated by Intel's
// spec). AMD's spec, having been in existence for much longer, failed to
// recognize that and specified movd for 32- and 64-bit operations.

// vmovd really shouldn't allow for 64bit operand (vmovq is the right
// mnemonic for copying between Reg64/Mem64 and RegXMM, as is mandated
// by Intel AVX spec).  To avoid extra template in gcc x86 backend and
// support assembler for AMD64, we accept 64bit operand on vmovd so
// that we can use one template for both SSE and AVX instructions.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||WONTFIX


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

[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers

[dominiq at lps dot ens dot fr]

--- Comment #46 from dominiq at lps dot ens dot fr  2010-03-01 13:34 ---
Anything else I can do for this pr?


-- 


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

[Bug other/32499] libstdc++ testsuite fails on platforms without ranlib

[ro at gcc dot gnu dot org]

--- Comment #13 from ro at gcc dot gnu dot org  2010-03-01 13:59 ---
Subject: Bug 32499

Author: ro
Date: Mon Mar  1 13:58:48 2010
New Revision: 157144

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157144
Log:
libstdc++-v3:
PR libstdc++/32499
* testsuite/Makefile.am (check-DEJAGNU
$(check_DEJAGNU_normal_targets)): Export AR, RANLIB.
* testsuite/Makefile.in: Regenerate.

toplevel:
PR libstdc++/32499
* configure.ac (RANLIB): Default to true.
(STRIP): Likewise.
(RANLIB_FOR_TARGET): Remove superfluous : argument.
* configure: Regenerate.

Modified:
trunk/ChangeLog
trunk/configure
trunk/configure.ac
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/testsuite/Makefile.am
trunk/libstdc++-v3/testsuite/Makefile.in


-- 


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

[Bug tree-optimization/43220] New: Paritially optimized __builtin_save_stack/__builtin_restore_stack causes segmentation fault

[bmei at broadcom dot com]

I encountered a segmentation fault when executing an unrolled version of
20040811-1.c (tested with -O2)

void *volatile p;

int
main (void)
{
  int n = 0;
 lab:;
  {
  int x[n % 1000 + 1];
  x[0] = 1;
  x[n % 1000] = 2;
  p = x;
  n++;
  }


  {
  int x[n % 1000 + 1];
  x[0] = 1;
  x[n % 1000] = 2;
  p = x;
  n++;
  }

  if (n < 100)
goto lab;

  return 0;
}

The problem is that the first pair of
__builtin_stack_save/__builtin_satck_restore of the unrolled loop is optimized
out in optimize_stack_restore (tree-ssa-ccp.c) of fab pass. Consequently, the
dynamic memory allocated grows bigger and bigger and causes segfault. The
following is from tst.c.139t.optimized


lab:
  saved_stack.1_3 = 0B;
  D.2723_4 = n_1 % 1000;
  D.2724_5 = D.2723_4 + 1;
  D.2728_15 = (long unsigned int) D.2724_5;
  D.2730_16 = D.2728_15 * 4;
  D.2732_17 = __builtin_alloca (D.2730_16);
  x.0_18 = (int[0:D.2727] *) D.2732_17;
  (*x.0_18)[0] = 1;
  (*x.0_18)[D.2723_4] = 2;
  p ={v} x.0_18;
  D.2770_66 = (unsigned int) n_1;
  D.2771_65 = D.2770_66 + 1;
  n_64 = (int) D.2771_65;
  GIMPLE_NOP
  saved_stack.3_21 = __builtin_stack_save ();
  D.2723_22 = n_64 % 1000;
  D.2734_23 = D.2723_22 + 1;
  D.2738_33 = (long unsigned int) D.2734_23;
  D.2740_34 = D.2738_33 * 4;
  D.2742_35 = __builtin_alloca (D.2740_34);
  x.2_36 = (int[0:D.2737] *) D.2742_35;
  (*x.2_36)[0] = 1;
  (*x.2_36)[D.2723_22] = 2;
  p ={v} x.2_36;
  D.2773_62 = D.2770_66 + 2;
  n_61 = (int) D.2773_62;
  __builtin_stack_restore (saved_stack.3_21);
  if (n_61 != 100)
goto  (lab);
  else
goto ;


-- 
   Summary: Paritially optimized
__builtin_save_stack/__builtin_restore_stack causes
segmentation fault
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bmei at broadcom dot com
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug pch/14940] PCH largefile test fails on various platforms

[ro at gcc dot gnu dot org]

--- Comment #37 from ro at gcc dot gnu dot org  2010-03-01 14:07 ---
Subject: Bug 14940

Author: ro
Date: Mon Mar  1 14:07:12 2010
New Revision: 157145

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157145
Log:
PR pch/14940
* gcc.dg/pch/pch.exp: Don't XFAIL largefile.c on i?86-*-solaris2.10.

Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/42852] gfortran -Wall warns about truncated lines when only a continuation character is truncated

[jvdelisle at gcc dot gnu dot org]

--- Comment #7 from jvdelisle at gcc dot gnu dot org  2010-03-01 14:27 
---
OK, I will make some adjustments.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jvdelisle at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-03-01 14:27:50
   date||


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

[Bug fortran/43217] Output of Hollerith constants which are not a multiple of 4 bytes

[jvdelisle at gcc dot gnu dot org]

--- Comment #2 from jvdelisle at gcc dot gnu dot org  2010-03-01 14:31 
---
You folks think of the crazy stuff :)  I will check into this.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jvdelisle at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-03-01 14:31:02
   date||


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

[Bug target/43215] x86-64: Nonstandard instruction "movd %xmm0, %rax"

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-03-01 14:55 ---
I fail to see why binutils accepting both version should be a reason to
not fix gcc.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |


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

[Bug tree-optimization/43220] [4.3/4.4/4.5 Regression] Paritially optimized __builtin_save_stack/__builtin_restore_stack causes segmentation fault

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-03-01 14:59 ---
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||wrong-code
  Known to fail||4.3.4 4.4.3 4.5.0
  Known to work||4.2.4
   Last reconfirmed|-00-00 00:00:00 |2010-03-01 14:59:56
   date||
Summary|Paritially optimized|[4.3/4.4/4.5 Regression]
   |__builtin_save_stack/__built|Paritially optimized
   |in_restore_stack causes |__builtin_save_stack/__built
   |segmentation fault  |in_restore_stack causes
   ||segmentation fault
   Target Milestone|--- |4.3.5


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

[Bug libstdc++/43183] std::unique_ptr::reset() does not conform to N3035.

[jwakely dot gcc at gmail dot com]

--- Comment #5 from jwakely dot gcc at gmail dot com  2010-03-01 15:05 
---
OK, I'm back and have had time to look at this.  I vaguely remember noticing
that the assignment and the deleter invocation happened in the wrong order in
our implementation, but I must have forgotten about it as I don't have any
uncommitted change (or even a comment) in my working copy.

The suggested change is still incorrect: the wrong condition is checked. The
deleter must be invoked when old_p != NULL, rather than when old_p != p.
Consider:

unique_ptr p1;
p1.reset(new int);

The deleter should not be invoked by the call to reset, because old_p ==
nullptr.

Another case:

  unique_ptr p(new int);
  p.reset(p.get());
  p.release();

This should not leak, but with the suggested change it will, because the
deleter will not get invoked.

A better implementation would be (untested):

  void
  reset(pointer __p = pointer())
  {
pointer __old = get();
std::get<0>(_M_t) = __p;
if (__old != 0)
  std::get<1>(_M_t)(__old);
  }


-- 


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

[Bug tree-optimization/43220] [4.3/4.4/4.5 Regression] Paritially optimized __builtin_save_stack/__builtin_restore_stack causes segmentation fault

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-03-01 15:16 ---
The code doesn't do what it says it does.  I have a patch.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-03-01 14:59:56 |2010-03-01 15:16:12
   date||


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

[Bug middle-end/43219] O2, O3 and Os produce wrong code

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-03-01 15:22 ---
It works for me. With all versions of 4.3.x.


-- 


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

[Bug lto/43218] [LTO] Conflicting function types cause ICE

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-03-01 15:27 ---
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-03-01 15:27:36
   date||


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

[Bug fortran/43217] Output of Hollerith constants which are not a multiple of 4 bytes

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2010-03-01 15:37 ---
I now check the standard.

a) Hollerith constants (not H... in FORMAT) are deleted in Fortran 77, but they
were allowed in Fortran 66. F77 "A.2 Conflicts with ANSI X3.9-1966" has:
"Hollerith constants and Hollerith data are not permitted in this standard.
ANSI X3.9-1966 permitted the use of Hollerith constants in DATA and CALL
statements"

b) They seemingly need to be space padded; F77 "C.4 Hollerith Constant" has:
"For an entity of type integer, real, or logical, the number of characters n in
the corresponding Hollerith constant must be less than or equal to g, where g
is the maximum number of characters that can be stored in a single numeric
storage unit at one time. If n is less than g, the entity is initially defined
with the n Hollerith characters extended on the right with g - n blank
characters.
Note that each Hollerith constant initially defines exactly one variable or
array element. Also note that g is processor dependent"

gfortran seemingly supports the common extension of allowing arrays (and not
just array elements) to be initialized by a single constant.

F66 has Holleriths in 4.2.6, 5.1.1.6 and some other places, though I could not
spot the padding part. (I have not tried very hard.)

c) The Hollerith constants should not be mixed up with the H edit descriptor,
which has only be deleted in Fortran 95 (cf. "B.1.5 H edit descriptor" in F95).

 * * *

> You folks think of the crazy stuff :)  I will check into this.

Well, that's the nice thing. With minimal modifications even Fortran IV
programs will run with today's compiler. Compare this with Python where you
need to modify/audit your code to go from Python 2 (released 2000) to 3
(released 2008).

If you look at the example on page 46 of "Fortran - Programmer's Reference
Manual" from 1956, you have no trouble except for the FREQUENCY statement
(estimate of likelihood that a certain branch is taken) - and also on p. 48 it
does not look to strange, though WRITE TAPE, END FILE and MORE PROGRAM do not
exist anymore. And contrary to the the H edit descriptor, Hollerith constants
wee not available; as there were no DATA nor subroutines that it not
surprising. (There were functions but they could not be written in Fortran.)

 * * *

See: http://gcc.gnu.org/wiki/GFortranStandards for the Fortran 77 and 66
standards - and the Fortran handbook of 1956.


-- 


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

[Bug target/43215] x86-64: Nonstandard instruction "movd %xmm0, %rax"

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2010-03-01 15:42 ---
(In reply to comment #3)
> I fail to see why binutils accepting both version should be a reason to
> not fix gcc.
> 

What is the minimum binutils required by gcc? Does it support movq?


-- 


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

[Bug middle-end/41250] hppa has DECL_VALUE_EXPR decls appearing in the function

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2010-03-01 15:43 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/41250] hppa has DECL_VALUE_EXPR decls appearing in the function

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2010-03-01 15:44 ---
Subject: Bug 41250

Author: rguenth
Date: Mon Mar  1 15:43:32 2010
New Revision: 157148

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157148
Log:
2010-03-01  Richard Guenther  
Martin Jambor  

PR middle-end/41250
* gimplify.c (gimplify_body): Unset DECL_HAS_VALUE_EXPR_P on
gimplified parameters.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c


-- 


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

[Bug rtl-optimization/43156] [4.5 Regression] SPU-elf ICEs on simple programs

[pinskia at gmail dot com]

--- Comment #2 from pinskia at gmail dot com  2010-03-01 15:45 ---
Subject: Re:  [4.5 Regression] SPU-elf ICEs on simple programs



Sent from my iPhone

On Mar 1, 2010, at 3:51 AM, "rguenth at gcc dot gnu dot org"
 wrote:

>
>
> --- Comment #1 from rguenth at gcc dot gnu dot org  2010-03-01  
> 11:51 ---
> spu-elf is neither a primary nor a secondary platform.  But,  
> confirmed, as
> I originally reported this.


My anaylis of this bug is that this bug is very generic and could  
cause issues on any target.



>
>
> -- 
>
> rguenth at gcc dot gnu dot org changed:
>
>   What|Removed |Added
> --- 
> --- 
> --
> Status|UNCONFIRMED |NEW
> Ever Confirmed|0   |1
>   Priority|P3  |P4
>   Last reconfirmed|-00-00 00:00:00 |2010-03-01 11:51:50
>   date||
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43156
>
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.


-- 


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

[Bug middle-end/43221] New: [LTO] ICE in get_alias_set

[d dot g dot gorbachev at gmail dot com]

In file included from :0:0:
1.c: In function 'f':
1.c:13:6: internal compiler error: in get_alias_set, at alias.c:710
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: /usr/local/bin/i686-pc-linux-gnu-gcc-4.5.0 returned 1 exit status
collect2: lto-wrapper returned 1 exit status

This seems to be different than PR41925.


-- 
   Summary: [LTO] ICE in get_alias_set
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: d dot g dot gorbachev at gmail dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug middle-end/43221] [LTO] ICE in get_alias_set

[d dot g dot gorbachev at gmail dot com]

--- Comment #1 from d dot g dot gorbachev at gmail dot com  2010-03-01 
15:54 ---
Created an attachment (id=1)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=1&action=view)
Testcase

Compile with `gcc -O2 -flto 1.c 2.c'


-- 


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

[Bug libstdc++/43183] std::unique_ptr::reset() does not conform to N3035.

[paolo dot carlini at oracle dot com]

--- Comment #6 from paolo dot carlini at oracle dot com  2010-03-01 16:08 
---
Indeed, thanks Jon. Shall we implement this for 4.5.0, or we had better wait
for nullptr / nullptr_t, what do you think?


-- 


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

[Bug libstdc++/43183] std::unique_ptr::reset() does not conform to N3035.

[jwakely dot gcc at gmail dot com]

--- Comment #7 from jwakely dot gcc at gmail dot com  2010-03-01 16:23 
---
I think it should be fixed for 4.5 and then updated when nullptr is available.
I assume that LWG 834 will be accepted in some form, so we will need an update
at some point anyway, to use nullptr in release and operator bool and in the
assertions in operator* and operator->


-- 


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

[Bug debug/43177] Handle at least simple cases of reversible insns in debug info

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2010-03-01 16:25 ---
Created an attachment (id=2)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=2&action=view)
gcc45-pr43177.patch

Untested patch I'm playing with.


-- 


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

[Bug libstdc++/43183] std::unique_ptr::reset() does not conform to N3035.

[jwakely dot gcc at gmail dot com]

--- Comment #8 from jwakely dot gcc at gmail dot com  2010-03-01 16:35 
---
Actually, we could just use pointer() everywhere, which would work today and
would be equivalent to using nullptr, assuming the current proposed resolution
of 834 or something similar.  I would be very surprised if 834 is resolved in a
way that allows different semantics for get() == nullptr and get() == pointer()

i.e.

  explicit operator bool() const
  { return get() == pointer() ? false : true; }

  // Modifiers.
  pointer
  release()
  {
pointer __p = get();
std::get<0>(_M_t) = pointer();
return __p;
  }


-- 


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

[Bug tree-optimization/43220] [4.3/4.4 Regression] Paritially optimized __builtin_save_stack/__builtin_restore_stack causes segmentation fault

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-03-01 16:57 ---
Fixed for 4.5 sofar.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail|4.3.4 4.4.3 4.5.0   |4.3.4 4.4.3
  Known to work|4.2.4   |4.2.4 4.5.0
Summary|[4.3/4.4/4.5 Regression]|[4.3/4.4 Regression]
   |Paritially optimized|Paritially optimized
   |__builtin_save_stack/__built|__builtin_save_stack/__built
   |in_restore_stack causes |in_restore_stack causes
   |segmentation fault  |segmentation fault


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

[Bug tree-optimization/43220] [4.3/4.4 Regression] Paritially optimized __builtin_save_stack/__builtin_restore_stack causes segmentation fault

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2010-03-01 16:57 ---
Subject: Bug 43220

Author: rguenth
Date: Mon Mar  1 16:57:02 2010
New Revision: 157149

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157149
Log:
2010-03-01  Richard Guenther  

PR tree-optimization/43220
* tree-ssa-ccp.c (optimize_stack_restore): Do not optimize
BUILT_IN_STACK_{SAVE,RESTORE} around alloca.

* gcc.c-torture/execute/pr43220.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr43220.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-ccp.c


-- 


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

[Bug libstdc++/43183] std::unique_ptr::reset() does not conform to N3035.

[paolo dot carlini at oracle dot com]

--- Comment #9 from paolo dot carlini at oracle dot com  2010-03-01 17:06 
---
Agreed. In two days or so I can take care of committing these changes.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-03-01 17:06:21
   date||


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

[Bug tree-optimization/43174] Teaching SCEV about ADDR_EXPR causes regression

[amonakov at gcc dot gnu dot org]

--- Comment #1 from amonakov at gcc dot gnu dot org  2010-03-01 17:43 
---
Created an attachment (id=20001)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20001&action=view)
Simplify increments in IVopts using final values of inner loop IVs

A quick & dirty attempt to implement register pressure reduction in outer loops
by using final values of inner loop IVs.  Currently, given
for (i = 0; i < N; i++)
  for (j = 0; j < N; j++)
s += a[i][j];
we generate something like

L1:
s.0 = PHI(0, s.2)
i.0 = PHI(0, i.1)
ivtmp.0 = &a[i.0][0]

L2:
s.1 = PHI(s.0, s.2)
j.0 = PHI(122, j.1)
ivtmp.1 = PHI(ivtmp.0, ivtmp.2)
s.2 = s.1 + MEM(ivtmp.1)
ivtmp.2 = ivtmp.1 + 4
j.1 = j.0 - 1
if (j.1 >= 0) goto L2

i.1 = i.0 + 1
if (i.1 <= 122) goto L1

This together with the patch mentioned in the previous comment allows to
generate:
ivtmp.0 = &a[0][0]

L1:
s.0 = PHI(0, s.2)
i.0 = PHI(122, i.1)
ivtmp.1 = PHI(ivtmp.0, ivtmp.4)

L2:
s.1 = PHI(s.0, s.2)
j.0 = PHI(122, j.1)
ivtmp.2 = PHI(ivtmp.1, ivtmp.3)
s.2 = s.1 + MEM(ivtmp.2)
ivtmp.3 = ivtmp.2 + 4
j.1 = j.0 - 1
if (j.1 >= 0) goto L2

ivtmp.4 = ivtmp.3 // would be ivtmp.4 = ivtmp.1 + stride
i.1 = i.0 - 1
if (i.1 >= 0) goto L1

The improvement is that ivtmp.1 is not live across the inner loop.

The approach is to store final values of IVs in a hashtable, mapping SSA_NAME
of initial value in the preheader to aff_tree with final value, and then try to
replace increments of new IVs with uses of IVs from inner loops (currently I
just implemented a brute force loop over all IV uses to find a useful entry in
that hashtable).
Does this make sense and sound acceptable?


-- 


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

[Bug tree-optimization/43209] [4.5 Regression] ICE in try_improve_iv_set, at tree-ssa-loop-ivopts.c:5238

[changpeng dot fang at amd dot com]

--- Comment #5 from changpeng dot fang at amd dot com  2010-03-01 18:02 
---
I have a fix for this problem. We should not decrease the cost if the cost is
infinite.

diff --git a/gcc/tree-ssa-loop-ivopts.c b/gcc/tree-ssa-loop-ivopts.c
index 74dadf7..9accda9 100644
--- a/gcc/tree-ssa-loop-ivopts.c
+++ b/gcc/tree-ssa-loop-ivopts.c
@@ -4124,7 +4124,11 @@ determine_use_iv_cost_condition (struct ivopts_data
*data,
   if (integer_zerop (*bound_cst)
   && (operand_equal_p (*control_var, cand->var_after, 0)
  || operand_equal_p (*control_var, cand->var_before, 0)))
-elim_cost.cost -= 1;
+{
+  /* Should not decrease the cost if it is infinite */
+  if (!infinite_cost_p (elim_cost))
+elim_cost.cost -= 1;
+}


-- 

changpeng dot fang at amd dot com changed:

   What|Removed |Added

 CC||changpeng dot fang at amd
   ||dot com


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

[Bug tree-optimization/43209] [4.5 Regression] ICE in try_improve_iv_set, at tree-ssa-loop-ivopts.c:5238

[sebpop at gmail dot com]

--- Comment #6 from sebpop at gmail dot com  2010-03-01 18:10 ---
Subject: Re:  [4.5 Regression] ICE in 
try_improve_iv_set, at tree-ssa-loop-ivopts.c:5238

On Mon, Mar 1, 2010 at 12:02, changpeng dot fang at amd dot com
> I have a fix for this problem. We should not decrease the cost if the cost is
> infinite.
>

Looks good.  Thanks for fixing this.  Please test with the minor
modification below, and submit a patch to gcc-patches@

> diff --git a/gcc/tree-ssa-loop-ivopts.c b/gcc/tree-ssa-loop-ivopts.c
> index 74dadf7..9accda9 100644
> --- a/gcc/tree-ssa-loop-ivopts.c
> +++ b/gcc/tree-ssa-loop-ivopts.c
> @@ -4124,7 +4124,11 @@ determine_use_iv_cost_condition (struct ivopts_data
> *data,
>   if (integer_zerop (*bound_cst)
>       && (operand_equal_p (*control_var, cand->var_after, 0)
>          || operand_equal_p (*control_var, cand->var_before, 0)))
> -    elim_cost.cost -= 1;
> +    {
> +      /* Should not decrease the cost if it is infinite */
> +      if (!infinite_cost_p (elim_cost))

You should fuse this condition into the previous condition expression
to avoid the inner if.

> +        elim_cost.cost -= 1;
> +    }


-- 


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

[Bug testsuite/32547] gnat.dg tasking tests fail on IRIX 5.3

[ro at gcc dot gnu dot org]

--- Comment #4 from ro at gcc dot gnu dot org  2010-03-01 18:13 ---
Mine.


-- 

ro at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ro at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-03-01 18:13:47
   date||


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

[Bug testsuite/32547] gnat.dg tasking tests fail on IRIX 5.3

[ro at gcc dot gnu dot org]

--- Comment #5 from ro at gcc dot gnu dot org  2010-03-01 18:14 ---
Fixed for 4.5.0:

http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00594.html


-- 

ro at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug libgcj/38251] [4.4/4.5 Regression] tools.zip doesn't build on systems with short command lines

[ro at gcc dot gnu dot org]

-- 

ro at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|aph at gcc dot gnu dot org  |ro at gcc dot gnu dot org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-03-01 18:15:00
   date||


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

[Bug libgcj/38251] [4.4/4.5 Regression] tools.zip doesn't build on systems with short command lines

[ro at gcc dot gnu dot org]

--- Comment #13 from ro at gcc dot gnu dot org  2010-03-01 18:15 ---
Fixed for 4.5.0:

http://gcc.gnu.org/ml/java-patches/2010-q1/msg00021.html


-- 

ro at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug other/32499] libstdc++ testsuite fails on platforms without ranlib

[ro at gcc dot gnu dot org]

--- Comment #14 from ro at gcc dot gnu dot org  2010-03-01 18:16 ---
Mine.


-- 

ro at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|bonzini at gnu dot org  |ro at gcc dot gnu dot org


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

[Bug other/32499] libstdc++ testsuite fails on platforms without ranlib

[ro at gcc dot gnu dot org]

--- Comment #15 from ro at gcc dot gnu dot org  2010-03-01 18:16 ---
Fixed for 4.5.0:

http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00139.html


-- 

ro at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug pch/14940] PCH largefile test fails on various platforms

[ro at gcc dot gnu dot org]

--- Comment #38 from ro at gcc dot gnu dot org  2010-03-01 18:17 ---
Fixed for Solaris 2 for 4.5.0:

http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00979.html


-- 


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

[Bug fortran/42900] gfortran.dg/stat_[12].f90 may fail on NFS filesystems

[ro at gcc dot gnu dot org]

--- Comment #4 from ro at gcc dot gnu dot org  2010-03-01 18:19 ---
Mine.


-- 

ro at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ro at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-03-01 18:19:00
   date||


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

[Bug fortran/42900] gfortran.dg/stat_[12].f90 may fail on NFS filesystems

[ro at gcc dot gnu dot org]

--- Comment #5 from ro at gcc dot gnu dot org  2010-03-01 18:19 ---
Fixed for 4.5.0:

http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00992.html


-- 

ro at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/43209] [4.5 Regression] ICE in try_improve_iv_set, at tree-ssa-loop-ivopts.c:5238

[sebpop at gmail dot com]

--- Comment #7 from sebpop at gmail dot com  2010-03-01 18:21 ---
Subject: Re:  [4.5 Regression] ICE in 
try_improve_iv_set, at tree-ssa-loop-ivopts.c:5238

> You should fuse this condition into the previous condition expression
> to avoid the inner if.

Like this:

diff --git a/gcc/tree-ssa-loop-ivopts.c b/gcc/tree-ssa-loop-ivopts.c
index 74dadf7..3b766ed 100644
--- a/gcc/tree-ssa-loop-ivopts.c
+++ b/gcc/tree-ssa-loop-ivopts.c
@@ -4121,7 +4121,8 @@ determine_use_iv_cost_condition (struct ivopts_data
*data,
  TODO: The constant that we're substracting from the cost should
  be target-dependent.  This information should be added to the
  target costs for each backend.  */
-  if (integer_zerop (*bound_cst)
+  if (!infinite_cost_p (elim_cost)
+  && integer_zerop (*bound_cst)
   && (operand_equal_p (*control_var, cand->var_after, 0)
  || operand_equal_p (*control_var, cand->var_before, 0)))
 elim_cost.cost -= 1;


-- 


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

[Bug rtl-optimization/40761] [4.4/4.5 Regression] IRA memory hog for insanely nested loops

[tkoenig at gcc dot gnu dot org]

--- Comment #4 from tkoenig at gcc dot gnu dot org  2010-03-01 19:27 ---
This now causes an ICE:

i...@linux-fd1f:/tmp> cat haha.c
#define ONE while (b())
#define TEN ONE ONE ONE ONE ONE ONE ONE ONE ONE ONE
#define HUN TEN TEN TEN TEN TEN TEN TEN TEN TEN TEN
#define THOUHUN HUN HUN HUN HUN HUN HUN HUN HUN HUN

void foo()
{
  /* 1,000 nested whiles.  */
  THOU
  a();
}
i...@linux-fd1f:/tmp> gcc -O3 haha.c
haha.c: In Funktion »foo«:
haha.c:6:6: interner Compiler-Fehler: in compute_antic, bei tree-ssa-pre.c:2557
Bitte senden Sie einen vollständigen Fehlerbericht auf Englisch ein;
bearbeiten Sie die Quellen zunächst mit einem Präprozessor, wenn es
dienlich ist.
Fehler in der deutschen Übersetzung sind an
translation-team...@lists.sourceforge.net zu melden.

Gehen Sie gemäß den Hinweisen in  vor.

Backtrace:

Breakpoint 1, fancy_abort (file=0xd791f0 "../../trunk/gcc/tree-ssa-pre.c",
line=2557,
function=0xd799ed "compute_antic") at ../../trunk/gcc/diagnostic.c:728
728 {
(gdb) up
#1  0x008ab23c in compute_antic () at
../../trunk/gcc/tree-ssa-pre.c:2557
2557  gcc_assert (num_iterations < 500);

The gcc_assert appears to be triggered for this case was introduced
by jakub:

118169dberlin   }
137036  jakub #ifdef ENABLE_CHECKING
118821dberlin   /* Theoretically possible, but *highly* unlikely.  */
137036  jakub   gcc_assert (num_iterations < 500);
137036  jakub #endif
 81764   dnovillo }


Resetting to P3 for new triage, as this is now ice-on-valid-code.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu dot
   ||org, tkoenig at gcc dot gnu
   ||dot org
   Keywords||ice-on-valid-code
   Priority|P2  |P3


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

[Bug target/43215] x86-64: Nonstandard instruction "movd %xmm0, %rax"

[ubizjak at gmail dot com]

--- Comment #5 from ubizjak at gmail dot com  2010-03-01 20:30 ---
(In reply to comment #4)

> What is the minimum binutils required by gcc? Does it support movq?

install.texi says that i?86-linux-gnu requires 2.13.1.

Since you are listed as x86 binutils maintainer, I would expect that you can
provide the information if it includes correct movq support.


-- 


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

[Bug target/43215] x86-64: Nonstandard instruction "movd %xmm0, %rax"

[ubizjak at gmail dot com]

--- Comment #6 from ubizjak at gmail dot com  2010-03-01 20:36 ---
(In reply to comment #5)

> install.texi says that i?86-linux-gnu requires 2.13.1.

binutils-2.13.1.tar.bz2   07-Nov-2002 23:45  9.5M  
binutils-2.13.1.tar.gz07-Nov-2002 23:45   12M  

IMNSHO, I really can't see the reason why we should support *eight* years old
toolchain part with a new compiler.  Does it even build with gcc-4.5?


-- 


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

[Bug libstdc++/43183] std::unique_ptr::reset() does not conform to N3035.

[redi at gcc dot gnu dot org]

-- 

redi at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |redi at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-03-01 17:06:21 |2010-03-01 20:56:36
   date||


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

[Bug libstdc++/43183] std::unique_ptr::reset() does not conform to N3035.

[tjgolubi at netins dot net]

--- Comment #10 from tjgolubi at netins dot net  2010-03-01 22:22 ---
Subject: Re:  std::unique_ptr::reset() does not conform to N3035.

I see your point.
I think it should still check for resetting to the same value to avoid 
duplicate deletes later.

terry

  void
  reset(pointer __p = pointer())
  {
pointer old_p = get();
if (__p != old_p)
  {
std::get<0>(_M_t) = __p;
if (old_p != pointer()) // < added this line
   get_deleter()(old_p);
  }
  }

- Original Message - 
From: "jwakely dot gcc at gmail dot com" 
To: 
Sent: Monday, March 01, 2010 9:05 AM
Subject: [Bug libstdc++/43183] std::unique_ptr::reset() does not conform to 
N3035.


>
>
> --- Comment #5 from jwakely dot gcc at gmail dot com  2010-03-01 
> 15:05 ---
> OK, I'm back and have had time to look at this.  I vaguely remember 
> noticing
> that the assignment and the deleter invocation happened in the wrong order 
> in
> our implementation, but I must have forgotten about it as I don't have any
> uncommitted change (or even a comment) in my working copy.
>
> The suggested change is still incorrect: the wrong condition is checked. 
> The
> deleter must be invoked when old_p != NULL, rather than when old_p != p.
> Consider:
>
> unique_ptr p1;
> p1.reset(new int);
>
> The deleter should not be invoked by the call to reset, because old_p ==
> nullptr.
>
> Another case:
>
>  unique_ptr p(new int);
>  p.reset(p.get());
>  p.release();
>
> This should not leak, but with the suggested change it will, because the
> deleter will not get invoked.
>
> A better implementation would be (untested):
>
>  void
>  reset(pointer __p = pointer())
>  {
>pointer __old = get();
>std::get<0>(_M_t) = __p;
>if (__old != 0)
>  std::get<1>(_M_t)(__old);
>  }
>
>
> -- 
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43183
>
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter. 


-- 


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

[Bug libstdc++/43183] std::unique_ptr::reset() does not conform to N3035.

[redi at gcc dot gnu dot org]

--- Comment #11 from redi at gcc dot gnu dot org  2010-03-01 22:30 ---
(In reply to comment #10)
> I think it should still check for resetting to the same value to avoid 
> duplicate deletes later.

I disagree, double delete can only happen in the case of a programming error.

Look at my second example in comment #5 - it may not be a very good idea to
write code like that, but it is technically correct (the stored pointer is
deleted when reset() is called, then released so it won't be deleted again) and
should not leak the stored pointer. If you check for the same value then you
will not call the deleter during reset and will leak.

I am testing a fix now, but I will not include your suggestion to check p!=old,
the C++0x draft requires a certain behaviour and I will implement that.


-- 


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

[Bug libstdc++/43183] std::unique_ptr::reset() does not conform to N3035.

[redi at gcc dot gnu dot org]

--- Comment #12 from redi at gcc dot gnu dot org  2010-03-01 22:38 ---
Bear in mind that a custom deleter with custom pointer type might have very
different semantics for comparing pointer values and for invoking the deleter. 
Consider a custom D::pointer which keeps a generation count, which is not used
when comparing for equality:

template
struct MyDeleter {
  struct pointer {
int generation;
T* ptr;
pointer() : generation(), ptr() { }
bool operator==(pointer rhs)
{ return ptr == rhs.ptr; }
  };
  void operator()(pointer p) const
  {
do_something(ptr.generation);
delete p.ptr;
  }
  void do_something(int gen);
};

Your suggested implementation would not update the value, because the equality
test is true, but that would be wrong i.e. you would have failed to reset the
unique_ptr as requested by the user.


-- 


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

[Bug debug/42897] [4.5 Regression] yet another ice in verify_ssa

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2010-03-01 22:53 ---
Reduced testcase:
int gif_read_lzw(int input_code_size)
{
  int i, incode;
  static short fresh = 0,  code_size, set_code_size, clear_code,
table[2][4096], *sp;
  set_code_size = input_code_size;
  clear_code = 1 << set_code_size;
  for (i = 0; i < clear_code; i ++)
table[1][i] = i;
  for (; i < 4096; i ++)
code_size ++;
}


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   GCC host triplet|x86_64-suse-linux   |
 GCC target triplet||x86_64-suse-linux


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

[Bug libfortran/32972] performance of pack/unpack

[tkoenig at gcc dot gnu dot org]

--- Comment #26 from tkoenig at gcc dot gnu dot org  2010-03-01 22:53 
---
I think pack and unpack are OK now.

Closing.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug debug/43222] New: two DEBUG i => 0 generated after loop copy header

[pinskia at gcc dot gnu dot org]

I Noticed this while looking into the testcase of 42897, sometimes we generate
a second DEBUG i => 0 when doing a loop copy header.  The second debug
statement does not even have a line number associated with it either (but that
might be because it was from the phi).

Simple testcase:
int gif_read_lzw(int input_code_size)
{
  int i, incode;
  static short fresh = 0,  code_size, set_code_size, clear_code, table[4096],
*sp;
  set_code_size = input_code_size;
  clear_code = 1 << input_code_size;
  for (i = 0; i < clear_code; i ++)
table[i] = i;
}


-- 
   Summary: two DEBUG i => 0 generated after loop copy header
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org


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

[Bug debug/43222] two DEBUG i => 0 generated after loop copy header

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-03-01 23:05 ---
And there are actually two duplicated debug statements.  One for the i => 0 and
then one for i => i_11


-- 


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

[Bug c++/43223] New: c++0x: Cannot init a R-value reference with L-value

[rodrigorivascosta at gmail dot com]

The following function fails to compile with C++0x:
int main()
{
int i = 3;
int &&x = i;
}
$ g++ -std=gnu++0x test.cpp -o test
test.cpp:4:15: error: invalid initialization of reference of type 'int&&' from
expression of type 'int'


-- 
   Summary: c++0x: Cannot init a R-value reference with L-value
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rodrigorivascosta at gmail dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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