[Bug debug/42234] [4.5 Regression] internal compiler error: verify_ssa failed

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2009-12-01 08:19 ---
Simplified testcase without the undefined signed underflow:
void
foo (int x)
{
  struct S { int s; } d = { 1 };
  unsigned int e = 1;
  if (x)
e = x && d.s;
  else
for (e = 0; e <= 3; e--)
  ;
  e++;
}

The problem starts in *.cddce1, before that we have:
  # e_2 = PHI 
  # DEBUG e => e_2
  # DEBUG e => e_2 + 1
but after that only:
:
  # DEBUG e => e_1
  # DEBUG e => e_1 + 1
where e_1 is defined only in one of the predecessors of bb 6.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-12-01 08:19:33
   date||


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

[Bug target/42235] New: redundant memory move from parameter space to spill space

[carrot at google dot com]

Compile the attached source code with options -Os -fpic -mthumb, gcc generates
following code for the constructor:

push{r4, r5, r6, r7, lr}
.LCFI2:
.pad #12
sub sp, sp, #12
.LCFI3:
str r3, [sp]
add r3, sp, #32//A,  B
ldrbr3, [r3]   //A,  B
ldr r5, .L14
mov r4, r0
mov r7, r2
mov r6, r1
str r3, [sp, #4]   //A
bl  _ZN1AC2Ev
ldr r3, .L14+4
.LPIC2:
add r5, pc
ldr r3, [r5, r3]
add r3, r3, #8
mov r1, sp//A
str r3, [r4]
add r2, r1, #4//A, C
mov r3, r4
add r3, r3, #42
ldrbr1, [r2]  //A, C
strbr7, [r3]
add r3, r3, #1//   C
strbr1, [r3]  //A, C
cmp r6, #0
beq .L9
ldr r2, [sp]
mov r3, #2
cmp r2, #0
bne .L12
mov r3, #1
.L12:
strhr3, [r4, #40]
b   .L11
.L9:
strhr6, [r4, #40]
.L11:
add sp, sp, #12
mov r0, r4
@ sp needed for prologue
pop {r4, r5, r6, r7}
pop {r1}
bx  r1

1. The instructions marked A move a byte from parameter to the object body, but
it first moves that parameter to stack [sp, 4], then move the value from [sp,4]
to the target object. The move to [sp, 4] is redundant.

2. The Instructions marked B load a byte from the stack, then store the whole
word into another place on the stack. Since later instructions load a byte from
the new space, we can simply move the whole word at the first place, so
instructions marked as B can be reduced to one instruction "ldr r3, [sp, 32]"

3. Instructions marked C can be simplified to
 ldrb r1, [r1, 4]
 strb r1, [r3, 1]

4. Why not use "pop {r4, r5, r6, r7, pc}" as the epilogue?


-- 
   Summary: redundant memory move from parameter space to spill
space
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  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=42235

[Bug target/42235] redundant memory move from parameter space to spill space

[carrot at google dot com]

--- Comment #1 from carrot at google dot com  2009-12-01 09:01 ---
Created an attachment (id=19194)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19194&action=view)
test case


-- 


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

[Bug fortran/42144] [OOP] deferred TBPs do not work

[janus at gcc dot gnu dot org]

--- Comment #3 from janus at gcc dot gnu dot org  2009-12-01 09:11 ---
This simple patch fixes comment #0 (but not comment #1):

Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c(revision 154840)
+++ gcc/fortran/trans-expr.c(working copy)
@@ -1555,6 +1555,10 @@ select_class_proc (gfc_se *se, gfc_class_esym_list
   /* This case has already been added.  */
   if (elist->derived == NULL)
goto free_elist;
+
+  /* Skip abstract base types.  */
+  if (elist->derived->attr.abstract)
+   goto free_elist;

   /* Run through the chain picking up all the cases that call the
 same procedure.  */


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||damian at rouson dot net
 AssignedTo|unassigned at gcc dot gnu   |janus at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-12-01 09:11:50
   date||


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

[Bug c++/42057] [4.5 Regression] ICE with invalid parameter of virtual function

[paolo at gcc dot gnu dot org]

--- Comment #4 from paolo at gcc dot gnu dot org  2009-12-01 09:20 ---
Subject: Bug 42057

Author: paolo
Date: Tue Dec  1 09:19:47 2009
New Revision: 154865

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154865
Log:
2009-12-01  Paolo Carlini  

PR c++/42057
* g++.dg/parse/crash54.C: New.

Added:
trunk/gcc/testsuite/g++.dg/parse/crash54.C
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/42057] [4.5 Regression] ICE with invalid parameter of virtual function

[paolo dot carlini at oracle dot com]

--- Comment #5 from paolo dot carlini at oracle dot com  2009-12-01 09:22 
---
Done, thank you.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/42131] Weird translation of DO loops

[rguenther at suse dot de]

--- Comment #26 from rguenther at suse dot de  2009-12-01 09:42 ---
Subject: Re:  Weird translation of DO loops

On Mon, 30 Nov 2009, tkoenig at gcc dot gnu dot org wrote:

> 
> 
> --- Comment #22 from tkoenig at gcc dot gnu dot org  2009-11-30 19:15 
> ---
> (In reply to comment #21)
> 
> > the "sign" for unsigned steps is always 1, you don't seem to account
> > for unsignedness?
> 
> (Un)fortunately, there are no unsigned varaibles in Fortran.
> 
> > Note that I believe generating
> > 
> >   step_sign = fold_build3 (fold_build2 (LT_EXPR, boolean_type_node,
> >   step, build_int_cst (TREE_TYPE (step), 
> > 0)),
> >  build_int_cst (type, -1), build_int_cst (type, 1));
> > 
> > is better as that allows more freedom for fold and efficient expansion
> > for the target.  Just double-check that it also works for the
> > unrolling ;)
> 
> That doesn't work (something about fold_build3 needing five arguments
> instead of three), so think I'll submit my patch "as is".

Ah, of course ... more like

step_sign = fold_build3 (COND_EXPR, type,
 fold_build2 (LT_EXPR, boolean_type_node,
   step, build_int_cst (TREE_TYPE (step), 0)),
  build_int_cst (type, -1), build_int_cst (type, 1));

Which still would be prefered IMHO.

Richard.

> Thanks for your comments! 
> > Thanks,
> > Richard.
> > 
> 
> 
> 


-- 


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

[Bug ada/42236] New: ICE for dispatching call involving explicit dereference

[fweimer at bfk dot de]

The following program triggers a bug box.

gcc-4.4 -c t.adb
+===GNAT BUG DETECTED==+
| 4.4.2 (x86_64-pc-linux-gnu) Assert_Failure sinfo.adb:1149|
| Error detected at t.adb:49:13|
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact gcc-4.4 or gnatmake command that you entered.  |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files).   |
+==+

The bug is also present in GCC 4.3.  It would be nice if there was
some sort of workaround; I need this to adjust code to the changed
semantics of limited return types in Ada 2005.

In GCC 4.3, the crash happens at this point in
sem_disp.check_dispatching_call:

539   else
540  Func :=
541Entity (Name
542  (Original_Node
543(Expression (Original_Node (Actual);
544   end if;

GDB reports:

(gdb) print pn(actual)
N_Explicit_Dereference (Node_Id=1864) (source,analyzed)
 Sloc = 8744  t.adb:49:52
 Etype = N_Defining_Identifier "transaction" (Entity_Id=1670)
 Prefix = N_Identifier "R168b" (Node_Id=1863)
$7 = void
(gdb) print pn(original_node(actual))
N_Explicit_Dereference (Node_Id=1864) (source,analyzed)
 Sloc = 8744  t.adb:49:52
 Etype = N_Defining_Identifier "transaction" (Entity_Id=1670)
 Prefix = N_Identifier "R168b" (Node_Id=1863)
$8 = void

with Ada.Finalization;

procedure T is

   package Transactions is
  type Transaction is limited private;
  function No_Transaction return access Transaction;

   private
  pragma Inline (No_Transaction);

  type Transaction is new Ada.Finalization.Limited_Controlled with record
 Handle : Natural := 0;
  end record;
   end;

   package body Transactions is
  No_Txn : aliased Transaction;

  function No_Transaction return access Transaction is
  begin
 return No_Txn'Access;
  end No_Transaction;
   end Transactions;

   package Databases is
  type Database is limited private;
  procedure Open
(D : in out Database;
 T : Transactions.Transaction);
   private
  type Database is new Ada.Finalization.Limited_Controlled with record
 Handle : Natural := 0;
  end record;
   end Databases;

   package body Databases is
  procedure Open
(D : in out Database;
 T : Transactions.Transaction) is
  begin
 null;
  end;
   end;

   DB : Databases.Database;

begin
   Databases.Open (DB, Transactions.No_Transaction.all);
end T;


-- 
   Summary: ICE for dispatching call involving explicit dereference
   Product: gcc
   Version: 4.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fweimer at bfk dot de
 GCC build triplet: x86_64-linux-gnu
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


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

[Bug tree-optimization/42216] [4.5 Regression] rev 15458[78] regress 464.h264ref peak 20%

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-12-01 09:58 ---
It was indeed Bernds patch.  Bernd - the patch discription suggested it was
a compile-time performance fix and not going to change code?  There is quite
big effect (including this negative one) on SPEC CPU 2006 on x86_64 ...


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-12-01 09:58:01
   date||
Summary|[4.5 Regression] 464.h264ref|[4.5 Regression] rev
   |peak regressed 20%  |15458[78] regress
   ||464.h264ref peak 20%


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

[Bug tree-optimization/42027] [4.5 Regression] Performance regression in convolution loop optimization

[nbenoit at tuxfamily dot org]

--- Comment #4 from nbenoit at tuxfamily dot org  2009-12-01 10:11 ---
It seems that this regression first appeared with revision 151080

* with -O1
GCC-4.4.2  7.4 s
GCC-trunk-r151078  7.4 s
GCC-trunk-r151079  7.4 s
GCC-trunk-r151080  9.4 s
GCC-trunk-r151081  9.4 s
GCC-trunk-r151082  9.4 s

Changelog for revision 151080
http://gcc.gnu.org/ml/gcc-patches/2009-08/msg01336.html

009-08-25  Michael Matz  

* expr.h (jumpifnot_1, jumpif_1, do_jump_1): Declare.
* dojump.c (do_jump_by_parts_greater): Take two operands instead of
full expression.
(do_jump_by_parts_equality, do_compare_and_jump): Ditto.
(jumpifnot_1, jumpif_1): New wrappers for do_jump_1.
(do_jump): Split out code for simple binary comparisons into ...
(do_jump_1): ... this, taking the individual operands and code.
Change callers to helper function above accordingly.
* expr.c (expand_expr_real_1): Use jumpifnot_1 for simple binary
comparisons.


-- 

nbenoit at tuxfamily dot org changed:

   What|Removed |Added

 CC||matz at suse dot de


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

[Bug c++/42237] New: internal compiler error: verify_stmts failed

[mario-baumann at web dot de]

Compiling of qt-x11-opensource-src-4.5.3-64/tools/qdoc3/cppcodeparser.cpp
failed with:

>  g++ -c -fpreprocessed -m32 -O2 cppcodeparser.1.i -o cppcodeparser.1.o
cppcodeparser.1.i: In function 'QMutableListIterator::previous()':
cppcodeparser.1.i:18150:1: error: invalid rhs for gimple memory store
*ISRA.13_16(D);

*ISRA.12_2(D);

# .MEM_9 = VDEF <.MEM_14>
*ISRA.13_16(D) = *ISRA.12_2(D);

cppcodeparser.1.i:18150:1: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

I have attached a reduced version of cppcodeparser.cpp
(cppcodeparser.1.cpp.bz2) together with the preprocessed file
(cppcodeparser.1.i.bz2)


-- 
   Summary: internal compiler error: verify_stmts failed
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mario-baumann at web dot de
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug c++/42237] internal compiler error: verify_stmts failed

[mario-baumann at web dot de]

--- Comment #1 from mario-baumann at web dot de  2009-12-01 10:56 ---
Created an attachment (id=19195)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19195&action=view)
Reduced version of cppcodeparser.cpp


-- 


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

[Bug c++/42237] internal compiler error: verify_stmts failed

[mario-baumann at web dot de]

--- Comment #2 from mario-baumann at web dot de  2009-12-01 10:56 ---
Created an attachment (id=19196)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19196&action=view)
preprocessed cpp file of cppcodeparser.1.cpp


-- 


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

[Bug c++/42237] internal compiler error: verify_stmts failed

[mario-baumann at web dot de]

--- Comment #3 from mario-baumann at web dot de  2009-12-01 11:00 ---
> uname -a
Linux yoda.intec.dom 2.6.18-164.el5 #1 SMP Thu Sep 3 03:28:30 EDT 2009 x86_64
x86_64 x86_64 GNU/Linux

> rpm -qa "glibc*" | grep -e 'glibc-[0-9]' | sort -u
glibc-2.5-42

> g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/opt/gcc/4.5.0-20091130-svn154785/x86_64/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --with-cloog=/opt/gcc/svn/aux
--with-gmp=/opt/gcc/svn/aux --with-mpc=/opt/gcc/svn/aux
--with-mpfr=/opt/gcc/svn/aux --with-ppl=/opt/gcc/svn/aux --disable-nls
--enable-languages=c,c++,fortran
--prefix=/opt/gcc/4.5.0-20091130-svn154785/x86_64
Thread model: posix
gcc version 4.5.0 20091130 (experimental) (GCC) 

> ld -v
GNU ld (GNU Binutils) 2.20.51.20091130


-- 

mario-baumann at web dot de changed:

   What|Removed |Added

 CC||mario-baumann at web dot de


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

[Bug tree-optimization/42237] [4.5 Regression] internal compiler error: verify_stmts failed

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-12-01 11:14 ---
Confirmed.  IPA-SRA generates this.

# .MEM_9 = VDEF <.MEM_14>
*ISRA.13_16(D) = *ISRA.12_2(D);

if that's invalid gimple it means that the type is is_gimple_reg_type.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
  Component|c++ |tree-optimization
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code, wrong-
   ||code
   Last reconfirmed|-00-00 00:00:00 |2009-12-01 11:14:34
   date||
Summary|internal compiler error:|[4.5 Regression] internal
   |verify_stmts failed |compiler error: verify_stmts
   ||failed
   Target Milestone|--- |4.5.0


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

[Bug target/42235] redundant memory move from parameter space to spill space

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||missed-optimization


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

[Bug tree-optimization/42027] [4.5 Regression] Performance regression in convolution loop optimization

[matz at gcc dot gnu dot org]

--- Comment #5 from matz at gcc dot gnu dot org  2009-12-01 11:24 ---
Hmpf, something fishy is going on, as this patch should have been only
refactoring without influence on the generated code.  I'll look at it.


-- 

matz at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |matz at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-11-27 11:18:44 |2009-12-01 11:24:11
   date||


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

[Bug c++/42238] New: Missing warning about uninitialized variable

[ext at sidvind dot com]

When compiling the following code I expect a warning about usage of
uninitialized variable.

int main(int argc, const char*[]){
do {
int a = a;
} while(1);

return 0;
}

Even when compiled with "-Wall -Winit-self" I get no warning. I have tried with
both g++-4.4.2 and g++-4.2.4 with the same result.

This is a simplification of the case I posted on the gcc-help list
(http://gcc.gnu.org/ml/gcc-help/2009-11/msg00250.html).


-- 
   Summary: Missing warning about uninitialized variable
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ext at sidvind dot com
 GCC build triplet: x86_64-pc-linux-gnu
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


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

[Bug middle-end/41611] [4.5 Regression] guard variable is emitted even when the guarded symbol isn't

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2009-12-01 12:15 ---
Re-confirmed.  Rafael - as you seem to have caused this can you look into it?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2009-10-06 23:28:16 |2009-12-01 12:15:09
   date||


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

[Bug tree-optimization/41491] [4.5 regression] ICE in set_value_range, at tree-vrp.c:386

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2009-12-01 12:23 
---
A cross to spu-elf from x86_64 doesn't ICE.  Can someone re-confirm that the
bug is still happening?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Priority|P2  |P3


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

[Bug tree-optimization/42237] [4.5 Regression] internal compiler error: verify_stmts failed

[jamborm at gcc dot gnu dot org]

--- Comment #5 from jamborm at gcc dot gnu dot org  2009-12-01 13:04 ---
Right. IPA-SRA currently relies on that it can always replace a memory
reference with a memory reference.  But both sides of this assignment
were originally one field structures turned into scalars and so the
assumption does not hold.  It seems I need to detect this particular
case and handle at the same place where I fix types.


-- 

jamborm at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jamborm at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-12-01 11:14:34 |2009-12-01 13:04:45
   date||


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

[Bug c++/42232] [4.4 Regression] ICE in cleanup_omp_return

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2009-12-01 13:34 ---
Reduced testcase:
extern int foo (void);
extern int g;

void
bar ()
{
#pragma omp critical
  {
int j;
for (j = 0; j < foo (); j++) ;
if (0)
  if (g >= 4) ;
  }
}


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-12-01 13:34:58
   date||


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

[Bug tree-optimization/41498] ICE with graphite flags on trunk

[eres at il dot ibm dot com]

--- Comment #6 from eres at il dot ibm dot com  2009-12-01 13:45 ---
(In reply to comment #5)
> test.f works on amd64-linux on the graphite branch.
> I am doing the merge of the graphite branch to trunk,
> and this should be fixed then.

Running test.f using trunk -r154872 on powerpc64-suse-linux gives the
following:
(this message also appears when running SPEC2006 benchmarks)

/home/eres/mainline_45/build/bin/gfortran -c   -m64 -O3 -mcpu=power6 
-ffast-math -maltivec  -fno-loop-parallelize-all -fgraphite -fno-loop-block
-fno-loop-interchange -fno-loop-strip-mine -fgraphite-identity -ftree-vectorize
test.f
f951: sorry, unimplemented: Graphite loop optimizations cannot be used


-- 


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

[Bug ada/42239] New: Pragma Inline_Always removes function calls with side effects

[fweimer at bfk dot de]

The following program (to be run through gnatchop) is supposed
to exit with status 17.  It exits with status 0 instead.  Inspecting
the generated machine code reveals that the call to Close is
not emitted:

 <_ada_u>:
   0:   55  push   %rbp
   1:   48 89 e5mov%rsp,%rbp
   4:   c9  leaveq
   5:   c3  retq

(This is at -O0, -O2 is similar.  Sorry for the misnomer; the test suite
which caught this had an actual close call there; I've changed it to exit
here for easier testing.)

This bug has also been observed with GCC 4.3.4.

with Interfaces.C; use Interfaces.C;

package POSIX_Base is
   function C_Close (FD : int) return int;
   pragma Import (C, C_Close, "exit");
end POSIX_Base;

with Interfaces.C; use Interfaces.C;

package POSIX is
   procedure Close (FD : int);

private
   pragma Inline_Always (Close);
end POSIX;

with POSIX_Base; use POSIX_Base;

package body POSIX is
   procedure Close (FD : int) is
  Status : constant int := C_Close (FD);
  pragma Unreferenced (Status);
   begin
  null;
   end;
end POSIX;

with POSIX; use POSIX;

procedure U is
begin
   Close (17);
end;


-- 
   Summary: Pragma Inline_Always removes function calls with side
effects
   Product: gcc
   Version: 4.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fweimer at bfk dot de
 GCC build triplet: x86_64-pc-linux-gnu
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


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

[Bug tree-optimization/41498] ICE with graphite flags on trunk

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2009-12-01 14:09 ---
You seem to have outdated graphite build requirements so it wasn't compiled in.


-- 


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

[Bug tree-optimization/42237] [4.5 Regression] internal compiler error: verify_stmts failed

[jamborm at gcc dot gnu dot org]

--- Comment #6 from jamborm at gcc dot gnu dot org  2009-12-01 14:10 ---
Created an attachment (id=19197)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19197&action=view)
Simple testcase

A simple test case that exhibits this bug and ICEs on both i386 and x86_64.


-- 


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

[Bug ada/42239] Pragma Inline_Always removes function calls with side effects

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-12-01 14:13 ---
On trunk I see

_ada_u:
.LFB1:
.cfi_startproc
pushq   %rbp
.cfi_def_cfa_offset 16
movq%rsp, %rbp
.cfi_offset 6, -16
.cfi_def_cfa_register 6
movl$17, %edi
callexit
leave
.cfi_def_cfa 7, 8
ret

which looks ok.


-- 


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

[Bug testsuite/39776] FAIL: g++.dg/ext/altivec-15.C

[dominiq at lps dot ens dot fr]

--- Comment #6 from dominiq at lps dot ens dot fr  2009-12-01 14:23 ---
It seems to be fixed by the commits in comments #4 and #5. Closing since it
seems unlikely that the fix will be backported to 4.3.


-- 

dominiq at lps dot ens dot fr changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/42237] [4.5 Regression] internal compiler error: verify_stmts failed

[jamborm at gcc dot gnu dot org]

--- Comment #7 from jamborm at gcc dot gnu dot org  2009-12-01 14:47 ---
Created an attachment (id=19198)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19198&action=view)
Patch dealing with such assignments

I'm currently testing this patch to address the problem. 


-- 


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

[Bug tree-optimization/42237] [4.5 Regression] internal compiler error: verify_stmts failed

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2009-12-01 15:00 ---
Ok if it passes.


-- 


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

[Bug fortran/38979] OpenMP extension: THREADPRIVATE for EQUIVALENCEd symbols

[arjen dot verweij at tass-safe dot com]

--- Comment #10 from arjen dot verweij at tass-safe dot com  2009-12-01 
15:10 ---
Hi,

Is there any discussion going on still about this? We are getting rid of all of
our UNIX workstations and moving to Linux. Incorporating the patch as an
optional switch or similar would be nice.

Thanks,

Arjen


-- 


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

[Bug rtl-optimization/34999] Incorrect FDE entries with hot/cold code section splitting (partition_hot_cold_basic_blocks)

[ghazi at gcc dot gnu dot org]

--- Comment #28 from ghazi at gcc dot gnu dot org  2009-12-01 15:14 ---
Backport to 4.4?  Or close this and PR41501?


-- 

ghazi at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING


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

[Bug tree-optimization/41491] [4.5 regression] ICE in set_value_range, at tree-vrp.c:386

[rmansfield at qnx dot com]

--- Comment #11 from rmansfield at qnx dot com  2009-12-01 15:16 ---
I can still reproduce it using a arm-unknown-linux-gnueabi target.  20091201
(experimental) [trunk revision 154872])


-- 


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

[Bug rtl-optimization/34999] Incorrect FDE entries with hot/cold code section splitting (partition_hot_cold_basic_blocks)

[rguenth at gcc dot gnu dot org]

--- Comment #29 from rguenth at gcc dot gnu dot org  2009-12-01 15:16 
---
The CFI stuff isn't on the 4.4 branch, so WONTFIX there.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.5.0


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

[Bug tree-optimization/41501] FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE - `-fprofile-use' fails with '-02'

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2009-12-01 15:17 ---
Too big for backporting (and not a regression?).


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to fail||4.4.3
  Known to work||4.5.0
 Resolution||FIXED
   Target Milestone|--- |4.5.0


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

[Bug fortran/42144] [OOP] deferred TBPs do not work

[dominiq at lps dot ens dot fr]

--- Comment #4 from dominiq at lps dot ens dot fr  2009-12-01 15:19 ---
The patch in comment #3 allows the test in comment #0 to be compiled and run
(though I don't know if the executable is valid). However there are still
errors at link time for the test in comment #1.


-- 


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

[Bug tree-optimization/42216] [4.5 Regression] rev 15458[78] regress 464.h264ref peak 20%

[bernds_cb1 at t-online dot de]

--- Comment #5 from bernds_cb1 at t-online dot de  2009-12-01 15:26 ---
Code generation changes are expected for two reasons - the code became less
conservative when determining conflicts with other registers, so we can usually
rename in more cases.  There are also a few cases where we have to give up on
renaming due to multiword hard register overlaps we can't track.

Unfortunately I don't have access to spec; I'll have to think about how to
track this down.


-- 


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

[Bug tree-optimization/42216] [4.5 Regression] rev 15458[78] regress 464.h264ref peak 20%

[rguenther at suse dot de]

--- Comment #6 from rguenther at suse dot de  2009-12-01 15:35 ---
Subject: Re:  [4.5 Regression] rev 15458[78]
 regress 464.h264ref peak 20%

On Tue, 1 Dec 2009, bernds_cb1 at t-online dot de wrote:

> --- Comment #5 from bernds_cb1 at t-online dot de  2009-12-01 15:26 
> ---
> Code generation changes are expected for two reasons - the code became less
> conservative when determining conflicts with other registers, so we can 
> usually
> rename in more cases.  There are also a few cases where we have to give up on
> renaming due to multiword hard register overlaps we can't track.
> 
> Unfortunately I don't have access to spec; I'll have to think about how to
> track this down.

I will try to come up with a testcase for you.  I suppose it might
be a backend issue as regrename should mainly effect the 2nd
scheduling pass, right?

Richard.


-- 


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

[Bug tree-optimization/41491] [4.5 regression] ICE in set_value_range, at tree-vrp.c:386

[rguenth at gcc dot gnu dot org]

--- Comment #12 from rguenth at gcc dot gnu dot org  2009-12-01 16:17 
---
I can reproduce it with a x86_64 -> arm-unknown-linux-gnueabi cross, so I'll 
look into this.


-- 

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|WAITING |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-12-01 16:17:37
   date||


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

[Bug c/42240] New: wrong Epilog on nacked function

[stefan dot dreyer at yahoo dot de]

Hello!

Following code is Producing an infinit loop, so main() is never reached

extern int main(void);
int main(void){
while(1);
}
#include 
/*Seed aus SRAM Zellen*/
static uint16_t seedram __attribute__ ((section (".noinit")));
void __init_seed(void) __attribute__ ((naked, section (".init8")));
// Bestimme seed aus zufälligem RAM-Inhalt
// !!! FUNKTION NICHT AUFRUFEN   !!!
// !!! FUNKTION WIRD AUTOMATISCH !!!
// !!! IN .init8 vor main AUSGEFÜHRT !!!
void __init_seed (void)
{
uint16_t s = 0;
uint16_t *p = (uint16_t*) (RAMEND+1);
extern uint16_t __noinit_start;

while (p >= &__noinit_start + 1)
s ^= *(--p);

seedram = s;
}


is going to 

while (p >= &__noinit_start + 1)
  8e:   81 e0   ldi r24, 0x01   ; 1
  90:   e2 30   cpi r30, 0x02   ; 2
  92:   f8 07   cpc r31, r24
  94:   c0 f7   brcc.-16; 0x86 <__init_seed+0x12>
s ^= *(--p);

seedram = s;
  96:   30 93 01 01 sts 0x0101, r19
  9a:   20 93 00 01 sts 0x0100, r18
}
  9e:   20 e0   ldi r18, 0x00   ; 0
  a0:   30 e0   ldi r19, 0x00   ; 0
  a2:   f9 cf   rjmp.-14; 0x96 <__init_seed+0x22>

at line a2: an infinit loop starts and never leaves this function.

the Problem is only an Optimation levels O2 and O3

Orginal thread in german Forum:
http://www.mikrocontroller.net/topic/158516

compiler call:

avr-gcc -c -mmcu=atmega168 -I. -gdwarf-2 -DF_CPU=800UL -O2 -funsigned-char
-funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes
-Wa,-adhlns=./main.lst  -std=c99 -MMD -MP -MF .dep/main.o.d main.c -o main.o

linker call:

avr-gcc -mmcu=atmega168 -I. -gdwarf-2 -DF_CPU=800UL -O2 -funsigned-char
-funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes
-Wa,-adhlns=main.o  -std=c99 -MMD -MP -MF .dep/main.elf.d main.o --output
main.elf -Wl,-Map=main.map,--cref -lm

Compiler version:

D:\Daten\Projekte\Eclipse Workspace\test init>avr-gcc -v
Using built-in specs.
Target: avr
Configured with: ../gcc-4.3.2/configure --enable-win32-registry=WinAVR-20090313
--with-gmp=/usr/local --with-mpfr=/usr/local --prefix=/c/WinAVR --target=avr
--enable-languages=c,c++,objc --with-dwarf2 --enable-doc --disable-shared
--disable-libada --disable-libssp --disable-nls
--with-pkgversion='WinAVR20090313'
--with-bugurl='URL:http://sourceforge.net/tracker/?atid=520074&group_id=68108&func=browse'Thread
model: single
gcc version 4.3.2 (WinAVR 20090313)

Greetings Stefan


-- 
   Summary: wrong Epilog on nacked function
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stefan dot dreyer at yahoo dot de
  GCC host triplet: Windows XP
GCC target triplet: AVR


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

[Bug c/42240] wrong Epilog on nacked function

[stefan dot dreyer at yahoo dot de]

--- Comment #1 from stefan dot dreyer at yahoo dot de  2009-12-01 16:19 
---
Created an attachment (id=19199)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19199&action=view)
Compileable testfile


-- 


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

[Bug fortran/40812] Files > 2GB are incorrectly handled on mingw

[burnus at gcc dot gnu dot org]

--- Comment #14 from burnus at gcc dot gnu dot org  2009-12-01 16:21 ---
Some further notes based on the discussion with Kai:

ftruncate: Replace by a configure check for "ftruncate64" and a fallback using
first "SetFilePointer" and then "SetEndOfFile(_get_osfhandle(fd))". Note: The
function SetFilePointer has no more interpretations and checks before, so you
avoid failure-cases in C-runtime. (Thus one may need to handle errno/error
processing manually -> "ierrno()" intrinsic.) See MSDN, e.g. for SetEndOfFile:
  http://msdn.microsoft.com/en-us/library/aa365541%28VS.85%29.aspx

off_t: Replace by _off64_t

lseek: Replace by _lseeki64

(_telli64 also is supported, but I think we do not use it.)

io.h contains the _* functions prototypes and windows.h the Set* functions.

Checking for #ifdef __MINGW32__ should be enough for MinGW(.org|64).


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jb at gcc dot gnu dot org
   Last reconfirmed|2009-09-05 10:10:54 |2009-12-01 16:21:16
   date||


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

[Bug c/42240] wrong Epilog on nacked function

[stefan dot dreyer at yahoo dot de]

--- Comment #2 from stefan dot dreyer at yahoo dot de  2009-12-01 16:44 
---
Created an attachment (id=19200)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19200&action=view)
Compileable testfile


-- 


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

[Bug c/42240] wrong Epilog on nacked function

[stefan dot dreyer at yahoo dot de]

--- Comment #3 from stefan dot dreyer at yahoo dot de  2009-12-01 16:44 
---
Created an attachment (id=19201)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19201&action=view)
generatet assambly file


-- 


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

[Bug c/42240] wrong Epilog on nacked function

[stefan dot dreyer at yahoo dot de]

--- Comment #4 from stefan dot dreyer at yahoo dot de  2009-12-01 16:46 
---
(From update of attachment 19201)
in 
/* epilogue start */

rjmp .L6

infinite, never leaves function


-- 


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

[Bug tree-optimization/42216] [4.5 Regression] rev 154688 regress 464.h264ref peak 20%

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2009-12-01 16:46 ---
Just reverting rev. 154688 and using the training set gets us from

464.h264ref--228 -- S

to

464.h264ref--170 -- S  

at -O3 -ffast-math -funroll-loops -march-native (-march=k8-sse3 -msahf --param
l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=512
-mtune=k8).

After the patch the oprofile looks like

CPU: AMD64 processors, speed 2000 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask
of 0x00 (No unit mask) count 10
samples  %symbol name
2241755  51.1739  SetupFastFullPelSearch
442008   10.0900  BlockMotionSearch
2714296.1961  SubPelBlockMotionSearch
2693376.1483  FastPelY_14
1709613.9026  UMVLine16Y_11
1593113.6367  SetupLargerBlocks
163.5510  SATD
1272302.9044  FastLine16Y_11
72328 1.6511  dct_luma
69728 1.5917  getNonAffNeighbour

All but the *Y_1[14] functions are inside mv-search.c, just re-compiling
that file is enough to reproduce the issue.

after reverting it

CPU: AMD64 processors, speed 2000 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask
of 0x00 (No unit mask) count 10
samples  %symbol name
1223269  36.8289  SetupFastFullPelSearch
450306   13.5573  BlockMotionSearch
3203959.6461  SubPelBlockMotionSearch
2451757.3815  FastPelY_14
1606944.8380  SetupLargerBlocks
1553534.6772  SATD
1532924.6152  UMVLine16Y_11
79531 2.3944  FastLine16Y_11
72455 2.1814  dct_luma
70733 2.1296  getNonAffNeighbour
42828 1.2894  UMVPelY_14
34396 1.0356  UnifiedOneForthPix


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.5 Regression] rev|[4.5 Regression] rev 154688
   |15458[78] regress   |regress 464.h264ref peak 20%
   |464.h264ref peak 20%|


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

[Bug libffi/35484] libffi doesn't support AIX 64bit

[dje at gcc dot gnu dot org]

--- Comment #7 from dje at gcc dot gnu dot org  2009-12-01 16:52 ---
The changes are not available in any version and the changes are not complete.


-- 


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

[Bug target/42240] wrong Epilog on nacked function

[j at uriah dot heep dot sax dot de]

--- Comment #5 from j at uriah dot heep dot sax dot de  2009-12-01 16:58 
---
My first analysis shows that this is likely to be related to the
introduction of RTL prologues/epilogues in GCC 4.3.  GCC 4.2.2
has:

  if (avr_naked_function_p (current_function_decl))
{
  fputs ("/* epilogue: naked */\n", file);
  goto out;
}
...
 out:
  fprintf (file, "/* epilogue end (size=%d) */\n", epilogue_size);
  fprintf (file, "/* function %s size %d (%d) */\n", current_function_name (),
   prologue_size + function_size + epilogue_size, function_size);
  commands_in_file += prologue_size + function_size + epilogue_size;
  commands_in_prologues += prologue_size;
  commands_in_epilogues += epilogue_size;
}

GCC 4.3.4 has:

  /* epilogue: naked  */
  if (cfun->machine->is_naked)
{
  emit_jump_insn (gen_return ());
  return;
}

So apparently, emit_jump_insn (gen_return ()); is responsible for creating
the infinite loop.


-- 


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

[Bug c++/42241] New: Linker unable to resolve class variables used in a conditional expression

[halterman at southern dot edu]

The following code compiles but the linker balks at the use of one of the class
variables used within a conditional expression:


//  simple.cpp

class BiState
{
int state;
public:
static const int OFF = 0,
 ON  = 1;

BiState(): state(OFF) {}

//  This compiles and links
void toggle_1() 
{
if ( state == OFF )
state = ON;
else
state = OFF;
}

//  This compiles and links
void toggle_2() 
{
state = (state == OFF) ? 1 : OFF; 
}

//  This compiles and links
void toggle_3() 
{
state = (state == OFF) ? ON : 0; 
}

//  This compiles but does not link
//  Linker error: BiState::ON and BiState::OFF are undefined references
void toggle_4() 
{
state = (state == OFF) ? ON : OFF; 
}
};

int main()
{
BiState obj;

obj.toggle_1();
obj.toggle_2();
obj.toggle_3();
obj.toggle_4();
}



Command line:
g++ simple.cpp

---
Platform:
Debian 5.0 (Lenny), standard distribution gcc 4.3.2, x86

---
g++ -v:
Using built-in specs.
Target: i486-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-targets=all --enable-cld
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1.1) 

---
Linker output:
/tmp/ccOf6GeQ.o: In function `BiState::toggle_4()':
simple.cpp:(.text._ZN7BiState8toggle_4Ev[BiState::toggle_4()]+0x10): undefined
reference to `BiState::ON'
simple.cpp:(.text._ZN7BiState8toggle_4Ev[BiState::toggle_4()]+0x1b): undefined
reference to `BiState::OFF'
collect2: ld returned 1 exit status


-- 
   Summary: Linker unable to resolve class variables used in a
conditional expression
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: halterman at southern dot edu


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

[Bug tree-optimization/42216] [4.5 Regression] rev 154688 regress 464.h264ref peak 20%

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2009-12-01 17:03 ---
The hot loop is mv-search.c:SetupFastFullPelSearch

  for (pos = 0; pos < max_pos; pos++)
  {
abs_y = offset_y + spiral_search_y[pos];
abs_x = offset_x + spiral_search_x[pos];

if (range_partly_outside)
{
  if (abs_y >= 0 && abs_y <= max_height &&
  abs_x >= 0 && abs_x <= max_width)
  {
PelYline_11 = FastLine16Y_11;
  }
  else
  {
PelYline_11 = UMVLine16Y_11;
  }
}

orgptr = orig_blocks;
bindex = 0;
for (blky = 0; blky < 4; blky++)
{
  LineSadBlk0 = LineSadBlk1 = LineSadBlk2 = LineSadBlk3 = 0;
  for (y = 0; y < 4; y++)
  {
refptr = PelYline_11 (ref_pic, abs_y++, abs_x, img_height, img_width);

LineSadBlk0 += byte_abs [*refptr++ - *orgptr++];
LineSadBlk0 += byte_abs [*refptr++ - *orgptr++];
LineSadBlk0 += byte_abs [*refptr++ - *orgptr++];
LineSadBlk0 += byte_abs [*refptr++ - *orgptr++];
LineSadBlk1 += byte_abs [*refptr++ - *orgptr++];
LineSadBlk1 += byte_abs [*refptr++ - *orgptr++];
LineSadBlk1 += byte_abs [*refptr++ - *orgptr++];
LineSadBlk1 += byte_abs [*refptr++ - *orgptr++];
LineSadBlk2 += byte_abs [*refptr++ - *orgptr++];
LineSadBlk2 += byte_abs [*refptr++ - *orgptr++];
LineSadBlk2 += byte_abs [*refptr++ - *orgptr++];
LineSadBlk2 += byte_abs [*refptr++ - *orgptr++];
LineSadBlk3 += byte_abs [*refptr++ - *orgptr++];
LineSadBlk3 += byte_abs [*refptr++ - *orgptr++];
LineSadBlk3 += byte_abs [*refptr++ - *orgptr++];
LineSadBlk3 += byte_abs [*refptr++ - *orgptr++];
  }
  block_sad[bindex++][pos] = LineSadBlk0;
  block_sad[bindex++][pos] = LineSadBlk1;
  block_sad[bindex++][pos] = LineSadBlk2;
  block_sad[bindex++][pos] = LineSadBlk3;
}
  }

good assembly of the innermost loop:

.L1422:
leal1(%rsi), %r9d
movl64(%rsp), %r8d
movl68(%rsp), %ecx
movl52(%rsp), %edx
movq72(%rsp), %rdi
movl%r9d, 32(%rsp)
call*%rax
movzwl  (%rbx), %ecx
movzwl  (%rax), %edx
movzwl  2(%rbx), %r10d
movzwl  2(%rax), %r11d
movqbyte_abs(%rip), %r9
movzwl  4(%rbx), %esi
subl%ecx, %edx
movzwl  4(%rax), %ecx
movslq  %edx, %r8
subl%r10d, %r11d
movzwl  6(%rax), %r10d
addl(%r9,%r8,4), %r14d
movzwl  6(%rbx), %r8d
movslq  %r11d, %rdi
addl(%r9,%rdi,4), %r14d
movzwl  8(%rbx), %edi
subl%esi, %ecx
movslq  %ecx, %rdx
movzwl  8(%rax), %ecx
subl%r8d, %r10d
addl(%r9,%rdx,4), %r14d
movzwl  10(%rax), %r8d
movzwl  10(%rbx), %edx
movslq  %r10d, %r11
addl(%r9,%r11,4), %r14d
movzwl  12(%rbx), %r11d
subl%edi, %ecx
movzwl  12(%rax), %edi
movslq  %ecx, %rsi
subl%edx, %r8d
addl(%r9,%rsi,4), %r13d
movzwl  14(%rax), %edx
movzwl  14(%rbx), %esi
movslq  %r8d, %r10
subl%r11d, %edi
addl(%r9,%r10,4), %r13d
movzwl  16(%rax), %r11d
movzwl  16(%rbx), %r10d
movslq  %edi, %rcx
addl(%r9,%rcx,4), %r13d
movzwl  18(%rbx), %ecx
subl%esi, %edx
movslq  %edx, %r8
movzwl  18(%rax), %edx
subl%r10d, %r11d
addl(%r9,%r8,4), %r13d
movzwl  20(%rax), %r10d
movzwl  20(%rbx), %r8d
movslq  %r11d, %rdi
addl(%r9,%rdi,4), %ebp
movzwl  22(%rbx), %edi
subl%ecx, %edx
movzwl  22(%rax), %ecx
movslq  %edx, %rsi
subl%r8d, %r10d
addl(%r9,%rsi,4), %ebp
movzwl  24(%rax), %r8d
movzwl  24(%rbx), %esi
movslq  %r10d, %r11
subl%edi, %ecx
addl(%r9,%r11,4), %ebp
movzwl  26(%rax), %edi
movslq  %ecx, %rdx
movzwl  26(%rbx), %r11d
addl(%r9,%rdx,4), %ebp
movzwl  28(%rbx), %edx
subl%esi, %r8d
movslq  %r8d, %r10
movzwl  28(%rax), %r8d
movzwl  30(%rax), %eax
addl(%r9,%r10,4), %r12d
movzwl  30(%rbx), %r10d
subl%r11d, %edi
movslq  %edi, %rcx
addl(%r9,%rcx,4), %r12d
subl%edx, %r8d
subl%r10d, %eax
movslq  %r8d, %rsi
addl(%r9,%rsi,4), %r12d
cltq
addl(%r9,%rax,4), %r12d
addq$32, %rbx
addq$32, %r15
cmpq$128, %r15
je  .L1600
movqPelYline_11(%rip), %rax
movl32(%rsp), %esi
jmp .L1422

bad assembly:

.L1422:
leal1(%rsi), %edx
movl68(%rsp), %ecx
movl64(%rsp), %r8d
movq72(%rsp), %rdi
movl%edx, 32(%rsp)
m

[Bug c++/42241] Linker unable to resolve class variables used in a conditional expression

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-12-01 17:07 ---
You only have a declaration of BiState:: OFF and BiState::ON, you need to
definite it also.

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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/42101] Linking failure with static constants and ternary inline function

[pinskia at gcc dot gnu dot org]

--- Comment #9 from pinskia at gcc dot gnu dot org  2009-12-01 17:07 ---
*** Bug 42241 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||halterman at southern dot
   ||edu


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

[Bug fortran/40812] Files > 2GB are incorrectly handled on mingw

[burnus at gcc dot gnu dot org]

--- Comment #15 from burnus at gcc dot gnu dot org  2009-12-01 17:08 ---
Regarding the ftruncate(64) fall back: one should check that it doesn't operate
on none character devices (isatty) and set errno to something like EBADF.


-- 


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

[Bug tree-optimization/42216] [4.5 Regression] rev 154688 regress 464.h264ref peak 20%

[bernds_cb1 at t-online dot de]

--- Comment #9 from bernds_cb1 at t-online dot de  2009-12-01 17:25 ---
Created an attachment (id=19202)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19202&action=view)
Test patch to attempt to narrow down the problem


-- 


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

[Bug tree-optimization/42216] [4.5 Regression] rev 154688 regress 464.h264ref peak 20%

[bernds_cb1 at t-online dot de]

--- Comment #10 from bernds_cb1 at t-online dot de  2009-12-01 17:27 ---
Yes, regrename should only affect the second scheduling pass.

I'm attaching a stab-in-the-dark patch.  It contains a fix for the ia64
regressions (testing in progress), it adds a few warnings which could be useful
to spot whether the testcase is producing the corner cases we refuse to handle,
and it makes some changes to the register selection.  The idea is to prefer
registers which aren't used in the basic block yet, which should give the best
freedom to the scheduler.

I'd be glad if you could play with this and let me know the results.


-- 


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

[Bug debug/41988] [4.5 Regression] FAIL: g++.dg/debug/*.C -gdwarf-2 -g1 (internal compiler error)

[dominiq at lps dot ens dot fr]

--- Comment #18 from dominiq at lps dot ens dot fr  2009-12-01 17:28 ---
At revision 154851 and later the failures have disappeared (tested on
x86_64-apple-darwin10 and i686-apple-darwin9). Before I close the PR as fixed,
does anybody has an explanation for the failures and their fix?


-- 


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

[Bug tree-optimization/42237] [4.5 Regression] internal compiler error: verify_stmts failed

[jamborm at gcc dot gnu dot org]

--- Comment #9 from jamborm at gcc dot gnu dot org  2009-12-01 17:40 ---
Subject: Bug 42237

Author: jamborm
Date: Tue Dec  1 17:39:44 2009
New Revision: 154874

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154874
Log:
2009-12-01  Martin Jambor  

PR tree-optimization/42237
* tree-sra.c (sra_ipa_modify_assign): Split gimple_reg_type assignments
in between references into two.

* testsuite/gcc.c-torture/compile/pr42237.c: New test.


Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr42237.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-sra.c


-- 


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

[Bug tree-optimization/42237] [4.5 Regression] internal compiler error: verify_stmts failed

[jamborm at gcc dot gnu dot org]

--- Comment #10 from jamborm at gcc dot gnu dot org  2009-12-01 17:49 
---
Fixed.


-- 

jamborm at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug libfortran/40812] Files > 2GB are incorrectly handled on mingw

[jb at gcc dot gnu dot org]

-- 

jb at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jb at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
  Component|fortran |libfortran
   Last reconfirmed|2009-12-01 16:21:16 |2009-12-01 17:59:33
   date||


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

[Bug libstdc++/42242] New: vector::resize unnecessarily calls null constructor

[igodard at pacbell dot net]

This code shows that the resize member function is calling the null constructor
even when the size does not need to be changed.

#include
#include
class c {
public:
c() { std::cerr << "c null constructor called\n"; }
c(int i) : i(i) {}
int i;
};

int main() {
std::vectorf;
f.push_back(c(0));
f.resize(1);
return 0;
}


-- 
   Summary: vector::resize unnecessarily calls null constructor
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net


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

[Bug libstdc++/42242] vector::resize unnecessarily calls null constructor

[redi at gcc dot gnu dot org]

--- Comment #1 from redi at gcc dot gnu dot org  2009-12-01 18:21 ---
this is caused by the default argument to resize:

void
resize(size_type __new_size, value_type __x = value_type());


It would be possible to avoid the default construction by replacing that member
with two overloads of resize, but I'm not sure it's worth doing.


-- 


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

[Bug target/42235] redundant memory move from parameter space to spill space

[ramana at gcc dot gnu dot org]

--- Comment #2 from ramana at gcc dot gnu dot org  2009-12-01 18:26 ---
(In reply to comment #0)
> Compile the attached source code with options -Os -fpic -mthumb, gcc generates
> following code for the constructor:

Could you do some more analysis of where this is coming from using rtl / tree
dumps ? 


-- 


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

[Bug libstdc++/42242] vector::resize unnecessarily calls null constructor

[redi at gcc dot gnu dot org]

--- Comment #2 from redi at gcc dot gnu dot org  2009-12-01 18:30 ---
On second thoughts, it might be necessary to split it into two overloads for
C++1x, because this should work:

#include 

struct moveable {
explicit moveable(int) { }
moveable(const moveable&) = delete;
moveable(moveable&&) { }
};

int main()
{
std::vector v;
moveable m(0);
v.resize(1, m);
}


-- 


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

[Bug fortran/42131] Weird translation of DO loops

[jb at gcc dot gnu dot org]

--- Comment #27 from jb at gcc dot gnu dot org  2009-12-01 18:32 ---
Subject: Bug 42131

Author: jb
Date: Tue Dec  1 18:32:37 2009
New Revision: 154876

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154876
Log:
PR fortran/42131 Sign test using ternary operator

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-stmt.c


-- 


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

[Bug libstdc++/42242] vector::resize unnecessarily calls null constructor

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2009-12-01 18:33 ---
(In reply to comment #1) 
> It would be possible to avoid the default construction by replacing that 
> member
> with two overloads of resize, but I'm not sure it's worth doing.

The C++03 standard only lists the function with the default value so this is
invalid.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug libstdc++/42242] vector::resize unnecessarily calls null constructor

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2009-12-01 18:34 ---
(In reply to comment #2)
> On second thoughts, it might be necessary to split it into two overloads for
> C++1x, because this should work:

But std::vector::resize (size_type sz, T c = T()); is the only one listed at
least in C++03.  What does C++1x say about that function?  You might need to
raise this to the C++ standards committee.


-- 


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

[Bug libstdc++/42242] vector::resize unnecessarily calls null constructor

[redi at gcc dot gnu dot org]

--- Comment #5 from redi at gcc dot gnu dot org  2009-12-01 18:37 ---
(In reply to comment #2)
> On second thoughts, it might be necessary to split it into two overloads for
> C++1x, because this should work:

Gah, ignore that, I'm talking rubbish and that shouldn't work

Andrew, the standard would allow two overloads instead of one, see
[member.functions]/2 - and the C++1x draft specifies two separate overloads. 
It's a reasonable enhancement request IMHO, but necessarily not a bug.


-- 


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

[Bug libfortran/40812] Files > 2GB are incorrectly handled on mingw

[jb at gcc dot gnu dot org]

--- Comment #16 from jb at gcc dot gnu dot org  2009-12-01 18:39 ---
Patch


-- 

jb at gcc dot gnu dot org changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2009-
   ||12/msg00081.html


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

[Bug libstdc++/42242] vector::resize could be split up into two different functions

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2009-12-01 18:40 ---
(In reply to comment #5)
> (In reply to comment #2)
> > On second thoughts, it might be necessary to split it into two overloads for
> > C++1x, because this should work:
> 
> Gah, ignore that, I'm talking rubbish and that shouldn't work
> 
> Andrew, the standard would allow two overloads instead of one, see
> [member.functions]/2

hmm, I missed that :).

Note doesn't a change like this change the ABI?  Which means it has to wait
until v7?


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement
 Status|RESOLVED|UNCONFIRMED
   Keywords||missed-optimization
 Resolution|INVALID |
Summary|vector::resize unnecessarily|vector::resize could be
   |calls null constructor  |split up into two different
   ||functions


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

[Bug bootstrap/42243] New: [4.5 Regression] powerpc-apple-darwin9 bootstrap broken at ffi_darwin.c

[dominiq at lps dot ens dot fr]

Bootstrap on powerpc-apple-darwin9 at revision 154872 is broken:

...
libtool: compile:  /opt/gcc/darwin_buildw/./gcc/xgcc
-B/opt/gcc/darwin_buildw/./gcc/ -B/opt/gcc/gcc4.5w/powerpc-apple-darwin9/bin/
-B/opt/gcc/gcc4.5w/powerpc-apple-darwin9/lib/ -isystem
/opt/gcc/gcc4.5w/powerpc-apple-darwin9/include -isystem
/opt/gcc/gcc4.5w/powerpc-apple-darwin9/sys-include -m64 -DHAVE_CONFIG_H -I.
-I../../../../gcc-4.5-work/libffi -I. -I../../../../gcc-4.5-work/libffi/include
-Iinclude -I../../../../gcc-4.5-work/libffi/src -Wall -g -fexceptions -g -O2
-m64 -MT src/powerpc/ffi_darwin.lo -MD -MP -MF src/powerpc/.deps/ffi_darwin.Tpo
-c ../../../../gcc-4.5-work/libffi/src/powerpc/ffi_darwin.c  -fno-common -DPIC
-o src/powerpc/.libs/ffi_darwin.o
../../../../gcc-4.5-work/libffi/src/powerpc/ffi_darwin.c: In function
'ffi_prep_args':
../../../../gcc-4.5-work/libffi/src/powerpc/ffi_darwin.c:160:6: error: lvalue
required as increment operand
../../../../gcc-4.5-work/libffi/src/powerpc/ffi_darwin.c: In function
'ffi_call':
../../../../gcc-4.5-work/libffi/src/powerpc/ffi_darwin.c:499:6: warning:
passing argument 6 of 'ffi_call_AIX' from incompatible pointer type
../../../../gcc-4.5-work/libffi/src/powerpc/ffi_darwin.c:472:13: note: expected
'void (*)(void)' but argument is of type 'void (*)(struct extended_cif *, long
unsigned int * const)'
../../../../gcc-4.5-work/libffi/src/powerpc/ffi_darwin.c:503:9: warning:
passing argument 6 of 'ffi_call_DARWIN' from incompatible pointer type
../../../../gcc-4.5-work/libffi/src/powerpc/ffi_darwin.c:474:13: note: expected
'void (*)(void)' but argument is of type 'void (*)(struct extended_cif *, long
unsigned int * const)'
...

Likely due to revision 154855:

Subject: Bug 35484

Author: dje
Date: Mon Nov 30 23:34:33 2009
New Revision: 154855

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154855
Log:
2009-11-30  David Edelsohn  

PR target/35484
* src/powerpc/ffitarget.h (POWERPC64): Define for PPC64 Linux and
AIX64.
* src/powerpc/aix.S: Implement AIX64 version.
* src/powerpc/aix_closure.S: Implement AIX64 version.
(ffi_closure_ASM): Use extsb, lha and displament addresses.
* src/powerpc/ffi_darwin.c (ffi_prep_args): Implement AIX64
support.
(ffi_prep_cif_machdep): Same.
(ffi_call): Same.
(ffi_closure_helper_DARWIN): Same.

Modified:
trunk/libffi/ChangeLog
trunk/libffi/src/powerpc/aix.S
trunk/libffi/src/powerpc/aix_closure.S
trunk/libffi/src/powerpc/ffi_darwin.c
trunk/libffi/src/powerpc/ffitarget.h

See also http://gcc.gnu.org/ml/gcc-regression/2009-12/msg4.html .


-- 
   Summary: [4.5 Regression] powerpc-apple-darwin9 bootstrap broken
at ffi_darwin.c
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
 GCC build triplet: powerpc-apple-darwin9
  GCC host triplet: powerpc-apple-darwin9
GCC target triplet: powerpc-apple-darwin9


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

[Bug libstdc++/42242] vector::resize could be split up into two different functions

[redi at gcc dot gnu dot org]

--- Comment #7 from redi at gcc dot gnu dot org  2009-12-01 18:54 ---
Yes, it would be an ABI change, although that symbol isn't exported from the
library.

vector::resize() was changed from one function to two in the n2284 draft, as a
result of n1858, the rationale is the same as for deque, see
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1858.html#23.2.1.2%20-%20deque%20capacity


-- 


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

[Bug libfortran/40812] Files > 2GB are incorrectly handled on mingw

[jb at gcc dot gnu dot org]

--- Comment #17 from jb at gcc dot gnu dot org  2009-12-01 18:58 ---
Updated patch: http://gcc.gnu.org/ml/fortran/2009-12/msg00017.html


-- 

jb at gcc dot gnu dot org changed:

   What|Removed |Added

URL|http://gcc.gnu.org/ml/gcc-  |http://gcc.gnu.org/ml/fortra
   |patches/2009-   |n/2009-12/msg00017.html
   |12/msg00081.html|


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

[Bug libstdc++/42242] vector::resize could be split up into two different functions

[chris at bubblescope dot net]

--- Comment #8 from chris at bubblescope dot net  2009-12-01 19:01 ---
The only change in C++0x is that a new function is added, so it won't break any
existing code, and we will be able to add it without moving to v7.


-- 

chris at bubblescope dot net changed:

   What|Removed |Added

 CC||chris at bubblescope dot net


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

[Bug libstdc++/42242] vector::resize could be split up into two different functions

[igodard at pacbell dot net]

--- Comment #9 from igodard at pacbell dot net  2009-12-01 19:02 ---
FWIW, I think it is a design error in the standard. The resize function seems
to be designed from an assumption that the vector type T is POD. The second
argument should not be a T, it should be a constructor, so any added cells (if
the resize extends the vector) are constructed in place rather than the
construct-a-temp/copy-construct/destruct sequence. Or there should be no second
argument and the null constructor used implicitly iff actually needed.

The actual usecase (that prompted the report) used the vector as a state holder
in a recursive tree walk; the resize was used to cut back the state when
returning from a leaf. The null constructor is seriously non-trivial for the
node type, involving considerable file activity that could fail (a file system
search). The workaround was simple when the problem was discovered: have a
do-nothing null constructor for the vector, with the "real" null constructor
turned into a constructor taking a dummy argument. Of course, that wound up
getting exposed into the exported interface, and required macros to hide. :-(


-- 


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

[Bug libstdc++/42242] vector::resize could be split up into two different functions

[chris at bubblescope dot net]

--- Comment #10 from chris at bubblescope dot net  2009-12-01 19:07 ---
Anyway, the result of this bug is that the fix to resize() given in the latest
draft of C++0x should be applied. The resulting code would only be invoked if
you ask the compiler to use C++0x mode, but if care about performance you
should be doing this anyway, I suspect your types may well benefit from rvalue
references.


-- 


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

[Bug target/42240] wrong epilogue on naked function

[a dot kaiser at gmx dot net]

--- Comment #6 from a dot kaiser at gmx dot net  2009-12-01 19:21 ---
Same for ARM target, when compiled for Thumb instruction set (-fthumb).


-- 

a dot kaiser at gmx dot net changed:

   What|Removed |Added

 CC||a dot kaiser at gmx dot net


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

[Bug libstdc++/42242] vector::resize could be split up into two different functions

[igodard at pacbell dot net]

--- Comment #11 from igodard at pacbell dot net  2009-12-01 19:26 ---
Subject: Re:  vector::resize could be split up into two
 different functions

We await r-value references with baited breath :-)

chris at bubblescope dot net wrote:
> --- Comment #10 from chris at bubblescope dot net  2009-12-01 19:07 
> ---
> Anyway, the result of this bug is that the fix to resize() given in the latest
> draft of C++0x should be applied. The resulting code would only be invoked if
> you ask the compiler to use C++0x mode, but if care about performance you
> should be doing this anyway, I suspect your types may well benefit from rvalue
> references.
>
>
>   


-- 


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

[Bug libstdc++/42242] vector::resize could be split up into two different functions

[chris at bubblescope dot net]

--- Comment #12 from chris at bubblescope dot net  2009-12-01 19:28 ---
No need to wait, they are in g++ 4.3 and 4.4, use -std=c++0x to activate
features from C++0x. Obviously they are all subject to change, but are now
fairly close to standardised.


-- 


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

[Bug middle-end/42238] Missing warning about uninitialized variable

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-12-01 19:31 ---
:
  # a_1 = PHI 
  a_3 = a_1;
  goto ;


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c++ |middle-end


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

[Bug middle-end/42229] [4.5 Regression] cancel_loop_tree: bad read causes ice

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2009-12-01 19:32 ---
0xa5a5a5a5a5a5a5d5 is a GC'd address.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Keywords||GC
Summary|cancel_loop_tree: bad read  |[4.5 Regression]
   |causes ice  |cancel_loop_tree: bad read
   ||causes ice
   Target Milestone|--- |4.5.0


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

[Bug testsuite/42212] [4.5 Regression] ERROR: tcl error sourcing /Users/regress/tbox/svn-gcc/gcc/testsuite/gcc.target/powerpc/powerpc.exp.

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2009-12-01 19:37 ---
Fixed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug target/42240] wrong epilogue on naked function

[a dot kaiser at gmx dot net]

--- Comment #7 from a dot kaiser at gmx dot net  2009-12-01 19:37 ---
Confirmed for 4.4.2.


-- 


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

[Bug c/42199] A problem with -maltivec

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug debug/42234] [4.5 Regression] internal compiler error: verify_ssa failed

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2009-12-01 19:42 ---
Subject: Bug 42234

Author: jakub
Date: Tue Dec  1 19:41:52 2009
New Revision: 154878

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154878
Log:
PR c++/42234
* tree-cfgcleanup.c (cleanup_omp_return): Don't ICE if control_bb
contains no statements.

* g++.dg/gomp/pr42234.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/gomp/pr42234.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-cfgcleanup.c


-- 


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

[Bug middle-end/42196] [4.5 Regression] ICE when SRAing partial assigments to complex number

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
Summary|ICE when SRAing partial |[4.5 Regression] ICE when
   |assigments to complex number|SRAing partial assigments to
   ||complex number
   Target Milestone|--- |4.5.0


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

[Bug debug/42234] [4.5 Regression] internal compiler error: verify_ssa failed

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2009-12-01 19:44 ---
Subject: Bug 42234

Author: jakub
Date: Tue Dec  1 19:44:34 2009
New Revision: 154879

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154879
Log:
PR c++/42234
* tree-cfgcleanup.c (cleanup_omp_return): Don't ICE if control_bb
contains no statements.

* g++.dg/gomp/pr42234.C: New test.

Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/gomp/pr42234.C
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
branches/gcc-4_4-branch/gcc/tree-cfgcleanup.c


-- 


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

[Bug tree-optimization/42211] [4.5 Regression] Segmentation fault with graphite -floop-interchange

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
Summary|Segmentation fault with |[4.5 Regression]
   |graphite -floop-interchange |Segmentation fault with
   ||graphite -floop-interchange
   Target Milestone|--- |4.5.0


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

[Bug c++/42161] use __cxa_vec_dtor instead of loop to reduce code size

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2009-12-01 19:47 ---
Confirmed a generic issue.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  GCC build triplet|i686-linux  |
   GCC host triplet|i686-linux  |
 GCC target triplet|arm-eabi|
   Keywords||missed-optimization
   Last reconfirmed|-00-00 00:00:00 |2009-12-01 19:47:50
   date||


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

[Bug middle-end/41611] [4.5 Regression] guard variable is emitted even when the guarded symbol isn't

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-12-01 12:15:09 |2009-12-01 19:48:11
   date||


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

[Bug middle-end/42178] [4.5 Regression] gcc.dg/graphite/interchange-8.c causes ICE

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
Summary|gcc.dg/graphite/interchange-|[4.5 Regression]
   |8.c causes ICE  |gcc.dg/graphite/interchange-
   ||8.c causes ICE
   Target Milestone|--- |4.5.0


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

[Bug middle-end/42151] [4.5 Regression] verify_cgraph_node failed with -O3 -Winline

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
Summary|verify_cgraph_node failed   |[4.5 Regression]
   |with -O3 -Winline   |verify_cgraph_node failed
   ||with -O3 -Winline
   Target Milestone|--- |4.5.0


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

[Bug bootstrap/42243] [4.5 Regression] powerpc-apple-darwin9 bootstrap broken at ffi_darwin.c

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2009-12-01 19:57 ---
I have no idea if this the right fix, but the following patch allows bootstrap
to proceed:

--- ../_gcc_clean/libffi/src/powerpc/ffi_darwin.c   2009-12-01
13:16:43.0 +0100
+++ ../gcc-4.5-work/libffi/src/powerpc/ffi_darwin.c 2009-12-01
20:51:19.0 +0100
@@ -157,7 +157,7 @@ void ffi_prep_args(extended_cif *ecif, u
case FFI_TYPE_LONGDOUBLE:
 #ifdef POWERPC64
  if (fparg_count < NUM_FPR_ARG_REGISTERS)
-   *((long double *) fpr_base)++ = *(long double *) *p_argv;
+   *(long double *) fpr_base++ = *(long double *) *p_argv;
  else
*(long double *) next_arg = *(long double *) *p_argv;
  next_arg += 2;


-- 


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

[Bug c++/3187] gcc lays down two copies of constructors

[jakub at gcc dot gnu dot org]

--- Comment #36 from jakub at gcc dot gnu dot org  2009-12-01 20:09 ---
Subject: Bug 3187

Author: jakub
Date: Tue Dec  1 20:09:37 2009
New Revision: 154880

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154880
Log:
PR c++/3187
* optimize.c (cdtor_comdat_group): New function.
(maybe_clone_body): Also optimize DECL_COMDAT base/complete cdtors
and in that case put also the deleting dtor in the same comdat group
as base and complete dtor if dtor is virtual.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/optimize.c


-- 


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

[Bug target/42164] [4.5 Regression] internal compiler error: in simplify_subreg, at simplify-rtx.c:5138

[daney at gcc dot gnu dot org]

-- 

daney at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


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

[Bug middle-end/41611] [4.5 Regression] guard variable is emitted even when the guarded symbol isn't

[jason at gcc dot gnu dot org]

--- Comment #9 from jason at gcc dot gnu dot org  2009-12-01 21:58 ---
Subject: Bug 41611

Author: jason
Date: Tue Dec  1 21:58:04 2009
New Revision: 154885

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154885
Log:
PR c++/41611
* decl2.c (get_guard): Copy DECL_COMDAT.
(comdat_linkage): Set DECL_COMDAT unconditionally.

Added:
trunk/gcc/testsuite/g++.dg/abi/guard1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl2.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug debug/41988] [4.5 Regression] FAIL: g++.dg/debug/*.C -gdwarf-2 -g1 (internal compiler error)

[howarth at nitro dot med dot uc dot edu]

--- Comment #19 from howarth at nitro dot med dot uc dot edu  2009-12-01 
22:06 ---
What was the last revision exhibiting this problem?  I suspect it was either
accidentally fixed or went latent. It would be worthwhile to pin down the exact
revision that eliminated these failures so a guess could be made as to which it
is.


-- 


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

[Bug fortran/42144] [OOP] deferred TBPs do not work

[janus at gcc dot gnu dot org]

--- Comment #5 from janus at gcc dot gnu dot org  2009-12-01 22:09 ---
Btw: The example in comment #1 is affected by PR41829, which can be avoided by
moving the subroutine 'rescale' to the main program. However, this still fails
(also with the patch from comment #3):

module foo_module
 implicit none
 private
 public :: foo

 type ,abstract :: foo
 contains
   procedure(times_interface) ,deferred :: times
   procedure(assign_interface) ,deferred :: assign
   generic :: operator(*) => times
   generic :: assignment(=) => assign
 end type

 abstract interface
   function times_interface(this,factor) result(product)
 import :: foo
 class(foo) ,intent(in) :: this
 class(foo) ,allocatable :: product
 real, intent(in) :: factor
   end function
   subroutine assign_interface(lhs,rhs)
 import :: foo
 class(foo) ,intent(inout) :: lhs
 class(foo) ,intent(in) :: rhs
   end subroutine
 end interface

end module

module bar_module
 use foo_module ,only : foo
 implicit none
 private
 public :: bar

 type ,extends(foo) :: bar
   private
   real :: x=1.
 contains
   procedure :: times => times_bar
   procedure :: assign => assign_bar
 end type

contains
 subroutine assign_bar(lhs,rhs)
   class(bar) ,intent(inout) :: lhs
   class(foo) ,intent(in) :: rhs
   select type(rhs)
 type is (bar)
   lhs%x = rhs%x
   end select
 end subroutine
 function times_bar(this,factor) result(product)
   class(bar) ,intent(in) :: this
   real, intent(in) :: factor
   class(foo), allocatable :: product
   select type(this)
 type is (bar)
   allocate(product,source=this)
   select type(product)
 type is(bar)
   product%x = this%x*factor
   end select
   end select
 end function
end module

program main
 use foo_module ,only : foo
 use bar_module ,only : bar
 implicit none
 type(bar) :: unit
 call rescale(unit,3.141592654)
contains
 subroutine rescale(this,scale)
   class(foo) ,intent(inout) :: this
   real, intent(in) :: scale
   this = this*scale! undefined reference to ...
 end subroutine
end program 


-- 


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

[Bug target/42240] wrong epilogue on naked function

[a dot kaiser at gmx dot net]

--- Comment #8 from a dot kaiser at gmx dot net  2009-12-01 22:50 ---
For the ARM target, falling off the end of the function does not make sense
anyway, since the last byte usually is followed by the constant pool. So the
AVR target finally caught up with the ARM target and doesn't work that way
either.


-- 


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

[Bug debug/42244] New: var-tracking ICE for 300.twolf

[janis at gcc dot gnu dot org]

GCC trunk gets an internal compiler error when building SPEC CPU2000 test
300.twolf with "-O2 -g -ffloat-store -fmodulo-sched" on powerpc-linux, as
demonstrated by this minimized testcase:

  extern int numerator, denom;

  double
  compute_and_combination (double states)
  {
for (; numerator > denom; numerator--)
  states *= (double) numerator;
return states;
   }

  elm3b149% /home/janis/tools/gcc-trunk-anonsvn/bin/gcc -O2 -g -ffloat-store
-fmodulo-sched -c bug.c
  bug.c: In function ‘compute_and_combination’:
  bug.c:9:1: internal compiler error: in create_ddg_dep_no_link, at ddg.c:215
  Please submit a full bug report,
  with preprocessed source if appropriate.
  See  for instructions.

The failure started when var-tracking-assignments was enabled by default if
var-tracking was enabled; the test case passes with the additional option
-fno-var-tracking.


-- 
   Summary: var-tracking ICE for 300.twolf
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org
GCC target triplet: powerpc-linux


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

[Bug debug/41988] [4.5 Regression] FAIL: g++.dg/debug/*.C -gdwarf-2 -g1 (internal compiler error)

[dominiq at lps dot ens dot fr]

--- Comment #20 from dominiq at lps dot ens dot fr  2009-12-01 23:20 ---
The last revision for which I saw the failures is revision 154715.


-- 


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