[Bug target/40301] [4.3 regression] SH: miscompile with -O2 -fPIC

[kkojima at gcc dot gnu dot org]

--- Comment #2 from kkojima at gcc dot gnu dot org  2009-05-30 07:12 ---
It seems that gcc-4.3 hits PR30807 again for SH.  Could you try
Christian's patch in the audit trail #2 of 30807 or Joern's
patch in the URL suggested at #4?


-- 

kkojima at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||wrong-code
   Priority|P3  |P4
   Last reconfirmed|-00-00 00:00:00 |2009-05-30 07:12:02
   date||


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

[Bug fortran/40011] Problems with -fwhole-file

[pault at gcc dot gnu dot org]

--- Comment #27 from pault at gcc dot gnu dot org  2009-05-30 08:27 ---
(In reply to comment #25)

> > types that are identical
> I'm not sure this is related, but note comment #8. Even identical types are 
> not
> identical, unless they are sequence type.

Joost,

No, this is not related.  The testing in the front end is more or less OK. 
However, the compiler receives more than one delaration of derived types,
either through explicit declaration, host association or use assocation.  The
middle-end has to ensure that the same backend_decl is used for each. 
Otherwise, when one is assigned to the other, via a defined assignement, it is
found that the TREE_TYPEs are not the same.  I have been trying to move the
backend_decls up to global scope so as to ensure that this happens but I am
missing some essential trick somewhere.  I'll be asking the experts next week
:-)

Paul


-- 


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

[Bug c++/11764] [DR147] g++ does not treat injected class name correctly.

[Woebbeking at web dot de]

--- Comment #13 from Woebbeking at web dot de  2009-05-30 08:46 ---
If you're sure that it's a bug why isn't it fixed yet? Is it that hard that you
need more than six years?

Sure it's no show stopper but it's annoying. I'm using -pedantic and -ansi to
ensure platform independent code and then this...


-- 


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

[Bug c++/40294] method definition can have the class scope multiple time

[Woebbeking at web dot de]

--- Comment #2 from Woebbeking at web dot de  2009-05-30 08:49 ---
Thanks, I didn't know which term I should looking for :-)


-- 


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

[Bug middle-end/31241] Post Increment opportunity missed

[ramana at gcc dot gnu dot org]

--- Comment #5 from ramana at gcc dot gnu dot org  2009-05-30 09:18 ---
This is improved by http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01622.html.
With the patch we get the following code generated. 

.cpu cortex-a8
.eabi_attribute 27, 3
.fpu neon
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 1
.eabi_attribute 30, 2
.eabi_attribute 18, 4
.file   "31241.c"
.text
.align  2
.global foo
.type   foo, %function
foo:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
add r2, r0, #40
.L2:
ldr r3, [r0, #0]
orr r3, r1, r3
str r3, [r0], #4
cmp r0, r2
bne .L2
bx  lr
.size   foo, .-foo
.ident  "GCC: (GNU) 4.5.0 20090527 (experimental)"


-- 


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

[Bug other/40302] [4.5 Regression] GCC must hard-require MPC before release

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-05-30 09:35 ---
Marking as regression to show up in the list of important bugs.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|GCC must hard-require MPC   |[4.5 Regression] GCC must
   |before release  |hard-require MPC before
   ||release
   Target Milestone|--- |4.5.0


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

[Bug tree-optimization/36318] SRA pessimizes struct copies without -Os

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-05-30 09:49 ---
Can you provide a testcase suitable for inclusion in the testsuite?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
   Target Milestone|--- |4.5.0


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

[Bug target/40301] [4.3 regression] SH: miscompile with -O2 -fPIC

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.3.4


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

[Bug c/40303] New: internal compiler error: in stmt_ann, at tree-flow-inline.h:173

[roman dot werpachowski at gmail dot com]

Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../gcc-4.2.4/configure --prefix=/opt/gcc/4.2.4 --enable-shared
--enable-threads=posix --enable-checking=release --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions
--enable-languages=c,c++,fortran --disable-dssi --with-cpu=generic
--host=x86_64-redhat-linux
Thread model: posix
gcc version 4.2.4
 /opt/gcc/4.2.4/libexec/gcc/x86_64-redhat-linux/4.2.4/cc1 -E -quiet -v
-I./src/common -I. -I. -I./src/divonne -DHAVE_CONFIG_H ./src/divonne/Divonne.c
-mtune=generic -fomit-frame-pointer -ffast-math -O3 -fpch-preprocess -o
Divonne.i
ignoring nonexistent directory
"/opt/gcc/4.2.4/lib/gcc/x86_64-redhat-linux/4.2.4/../../../../x86_64-redhat-linux/include"
ignoring duplicate directory "."
#include "..." search starts here:
#include <...> search starts here:
 ./src/common
 .
 ./src/divonne
 /usr/local/include
 /opt/gcc/4.2.4/include
 /opt/gcc/4.2.4/lib/gcc/x86_64-redhat-linux/4.2.4/include
 /usr/include
End of search list.
 /opt/gcc/4.2.4/libexec/gcc/x86_64-redhat-linux/4.2.4/cc1 -fpreprocessed
Divonne.i -quiet -dumpbase Divonne.c -mtune=generic -auxbase-strip Divonne.o
-O3 -version -fomit-frame-pointer -ffast-math -o Divonne.s
GNU C version 4.2.4 (x86_64-redhat-linux)
compiled by GNU C version 4.2.4.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: d4a5ebe8da1d4ab780126ed34b473a99
./src/divonne/Explore.c: In function âExploreâ:
./src/divonne/Explore.c:17: internal compiler error: in stmt_ann, at
tree-flow-inline.h:173


-- 
   Summary: internal compiler error: in stmt_ann, at tree-flow-
inline.h:173
   Product: gcc
   Version: 4.2.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: roman dot werpachowski at gmail dot com
GCC target triplet:  x86_64-redhat-linux


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

[Bug c/40303] internal compiler error: in stmt_ann, at tree-flow-inline.h:173

[roman dot werpachowski at gmail dot com]

--- Comment #1 from roman dot werpachowski at gmail dot com  2009-05-30 
11:28 ---
Created an attachment (id=17935)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17935&action=view)
Test case

Test case showing the bug.


-- 


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

[Bug c/40303] internal compiler error: in stmt_ann, at tree-flow-inline.h:173

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-05-30 12:29 ---
GCC 4.2 is no longer maintained, please upgrade to GCC 4.3.3 or GCC 4.4.0.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 GCC target triplet| x86_64-redhat-linux|x86_64-redhat-linux


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

[Bug c/40303] internal compiler error: in stmt_ann, at tree-flow-inline.h:173

[roman dot werpachowski at gmail dot com]

--- Comment #3 from roman dot werpachowski at gmail dot com  2009-05-30 
12:36 ---
4.4.0 works fine.


-- 

roman dot werpachowski at gmail dot com changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED


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

[Bug fortran/37577] Change internal array descriptor format for better syntax, C interop TR, rank 15

[tkoenig at gcc dot gnu dot org]

--- Comment #5 from tkoenig at gcc dot gnu dot org  2009-05-30 13:17 ---
Subject: Bug 37577

Author: tkoenig
Date: Sat May 30 13:17:14 2009
New Revision: 148002

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148002
Log:
2009-05-30  Thomas Koenig  

PR fortran/37577
PR libfortran/40187
* runtime/in_pack_generic (internal_pack):  Remove unnecessary
test for stride == 0.
* runtime/in_unpack_generic.c (internal_unpack):  Likewise.
* intrinsics/iso_c_binding.c (c_f_pointer_u0):  Take care
of stride in "shape" argument.  Use array access macros for
accessing array descriptors.
* libgfortran.h (struct descriptor_dimension):  Change stride
to _stride, lbound to _lbound and ubound to _ubound.
(GFC_DIMENSION_LBOUND):  Use new name(s) in struct
descriptor_dimension.
(GFC_DIMENSION_UBOUND):  Likewise.
(GFC_DIMENSION_STRIDE):  Likewise.
(GFC_DIMENSION_EXTENT):  Likewise.
(GFC_DIMENSION_SET):  Likewise.
(GFC_DESCRIPTOR_LBOUND):  Likewise.
(GFC_DESCRIPTOR_UBOUND):  Likewise.
(GFC_DESCRIPTOR_EXTENT):  Likewise.
(GFC_DESCRIPTOR_STRIDE):  Likewise.
* io/transfer.c (transfer_array):  Use array access macros.
Use byte-sized strides.

2009-05-30  Thomas Koenig  

PR libfortran/40187
* gfortran.dg/c_f_pointer_shape_tests_4.f03:  New file.
* gfortran.dg/c_f_pointer_shape_tests_4_driver.c:  New file.


Added:
   
branches/fortran-dev/gcc/testsuite/gfortran.dg/c_f_pointer_shape_tests_4.f03
   
branches/fortran-dev/gcc/testsuite/gfortran.dg/c_f_pointer_shape_tests_4_driver.c
Modified:
branches/fortran-dev/gcc/testsuite/ChangeLog.fortran-dev
branches/fortran-dev/libgfortran/ChangeLog.dev
branches/fortran-dev/libgfortran/intrinsics/iso_c_binding.c
branches/fortran-dev/libgfortran/io/transfer.c
branches/fortran-dev/libgfortran/libgfortran.h
branches/fortran-dev/libgfortran/runtime/in_pack_generic.c
branches/fortran-dev/libgfortran/runtime/in_unpack_generic.c


-- 


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

[Bug libfortran/40187] c_f_pointer with stride in SHAPE

[tkoenig at gcc dot gnu dot org]

--- Comment #7 from tkoenig at gcc dot gnu dot org  2009-05-30 13:17 ---
Subject: Bug 40187

Author: tkoenig
Date: Sat May 30 13:17:14 2009
New Revision: 148002

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148002
Log:
2009-05-30  Thomas Koenig  

PR fortran/37577
PR libfortran/40187
* runtime/in_pack_generic (internal_pack):  Remove unnecessary
test for stride == 0.
* runtime/in_unpack_generic.c (internal_unpack):  Likewise.
* intrinsics/iso_c_binding.c (c_f_pointer_u0):  Take care
of stride in "shape" argument.  Use array access macros for
accessing array descriptors.
* libgfortran.h (struct descriptor_dimension):  Change stride
to _stride, lbound to _lbound and ubound to _ubound.
(GFC_DIMENSION_LBOUND):  Use new name(s) in struct
descriptor_dimension.
(GFC_DIMENSION_UBOUND):  Likewise.
(GFC_DIMENSION_STRIDE):  Likewise.
(GFC_DIMENSION_EXTENT):  Likewise.
(GFC_DIMENSION_SET):  Likewise.
(GFC_DESCRIPTOR_LBOUND):  Likewise.
(GFC_DESCRIPTOR_UBOUND):  Likewise.
(GFC_DESCRIPTOR_EXTENT):  Likewise.
(GFC_DESCRIPTOR_STRIDE):  Likewise.
* io/transfer.c (transfer_array):  Use array access macros.
Use byte-sized strides.

2009-05-30  Thomas Koenig  

PR libfortran/40187
* gfortran.dg/c_f_pointer_shape_tests_4.f03:  New file.
* gfortran.dg/c_f_pointer_shape_tests_4_driver.c:  New file.


Added:
   
branches/fortran-dev/gcc/testsuite/gfortran.dg/c_f_pointer_shape_tests_4.f03
   
branches/fortran-dev/gcc/testsuite/gfortran.dg/c_f_pointer_shape_tests_4_driver.c
Modified:
branches/fortran-dev/gcc/testsuite/ChangeLog.fortran-dev
branches/fortran-dev/libgfortran/ChangeLog.dev
branches/fortran-dev/libgfortran/intrinsics/iso_c_binding.c
branches/fortran-dev/libgfortran/io/transfer.c
branches/fortran-dev/libgfortran/libgfortran.h
branches/fortran-dev/libgfortran/runtime/in_pack_generic.c
branches/fortran-dev/libgfortran/runtime/in_unpack_generic.c


-- 


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

[Bug middle-end/40304] New: [4.5 Regression] Revision 147995 breaks stack unwind

[hjl dot tools at gmail dot com]

On Linux/ia32, revision 147995:

http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00974.html

caused

FAIL: g++.dg/eh/async-unwind1.C execution test
FAIL: g++.dg/torture/stackalign/eh-alloca-1.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/eh-alloca-1.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/eh-alloca-1.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/eh-alloca-1.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/eh-alloca-1.C  -O3 -fomit-frame-pointer 
execution test
FAIL: g++.dg/torture/stackalign/eh-alloca-1.C  -O3 -fomit-frame-pointer 
execution test
FAIL: g++.dg/torture/stackalign/eh-alloca-1.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/eh-alloca-1.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-1.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-1.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-1.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-1.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-1.C  -O3 -fomit-frame-pointer 
execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-1.C  -O3 -fomit-frame-pointer 
execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-1.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-1.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-2.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-2.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-2.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-2.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-2.C  -O3 -fomit-frame-pointer 
execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-2.C  -O3 -fomit-frame-pointer 
execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-2.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-2.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/unwind-0.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/unwind-0.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/unwind-0.C  -O3 -fomit-frame-pointer  execution
test
FAIL: g++.dg/torture/stackalign/unwind-0.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/unwind-1.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/unwind-1.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/unwind-1.C  -O3 -fomit-frame-pointer  execution
test
FAIL: g++.dg/torture/stackalign/unwind-1.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/unwind-2.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/unwind-2.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/unwind-2.C  -O3 -fomit-frame-pointer  execution
test
FAIL: g++.dg/torture/stackalign/unwind-2.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/unwind-3.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/unwind-3.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/unwind-3.C  -O3 -fomit-frame-pointer  execution
test
FAIL: g++.dg/torture/stackalign/unwind-3.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/unwind-5.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/unwind-5.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/unwind-5.C  -O3 -fomit-frame-pointer  execution
test
FAIL: g++.dg/torture/stackalign/unwind-5.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/unwind-6.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/unwind-6.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/unwind-6.C  -O3 -fomit-frame-pointer  execution
test
FAIL: g++.dg/torture/stackalign/unwind-6.C  -O3 -g  execution test
FAIL: gcc.target/i386/lea.c scan-assembler leal


-- 
   Summary: [4.5 Regression]  Revision 147995 breaks stack unwind
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug c/40305] New: strict aliasing and inlining

[arnaud dot lb at gmail dot com]

The following code (attaching preprocessed one) crashes with gcc 4.3.3 and gcc
4.4.1 (20090529).

Adding noinline attribute to pop() avoids the crash.

Declaring pop(strict foo *f, void** a) as pop(strict foo *f, int **a) avoids
the crash.

Adding -fno-strict-aliasing avoids the crash.

I'm not sure it does breaks strict aliasing (not the same as casting a "void*"
to a "int*" and dereferencing it). gcc does not prints any warning about strict
aliasing.

Compiled with "gcc-4.4.1 -o out test.c -O3", ran with "./out".

#include 
#include 

struct foo {
int *a;
void **top;
void *storage[1];
};

void crash(struct foo *f);

int main() {
struct foo f;
int i = 0;

memset(&f, 0, sizeof(f));

f.top = &f.storage[1];
f.a = &i;

crash(&f);

assert(f.top == &f.storage[0]);
assert(f.a == f.storage[0]);
assert(f.a == NULL);
}

void pop(struct foo *f, void **a) {
*a = *(--f->top);
}   

__attribute__((noinline))
void crash(struct foo *f) {

while (f->a) {
pop(f, (void**)&f->a);
}   
}


-- 
   Summary: strict aliasing and inlining
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: arnaud dot lb at gmail dot com
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug c/40305] strict aliasing and inlining

[arnaud dot lb at gmail dot com]

--- Comment #1 from arnaud dot lb at gmail dot com  2009-05-30 13:22 ---
Created an attachment (id=17936)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17936&action=view)
preprocessed code


-- 


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

[Bug middle-end/40304] [4.5 Regression] Revision 147995 breaks stack unwind

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


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

[Bug c++/39754] [4.5 Regression] ICE: tree check: accessed elt 2 of tree_vec with 1 elts in tsubst, at cp/pt.c:9248

[hjl at gcc dot gnu dot org]

--- Comment #11 from hjl at gcc dot gnu dot org  2009-05-30 13:50 ---
Subject: Bug 39754

Author: hjl
Date: Sat May 30 13:49:33 2009
New Revision: 148004

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148004
Log:
2009-05-30  H.J. Lu  

Backport from mainline:

2009-05-28  Dodji Seketeli  

PR c++/39754
* g++.dg/template/canon-type-1.C: New test.
* g++.dg/template/canon-type-2.C: Likewise.
* g++.dg/template/canon-type-3.C: Likewise.
* g++.dg/template/canon-type-4.C: Likewise.
* g++.dg/template/canon-type-5.C: Likewise.
* g++.dg/template/canon-type-6.C: Likewise.
* g++.dg/template/canon-type-7.C: Likewise.

2009-05-28  Ira Rosen  

PR tree-optimization/40254
* gcc.dg/vect/pr40254.c: New test.

2009-05-26  Richard Guenther  

PR middle-end/40252
* gcc.c-torture/compile/pr40252.c: New testcase.

2009-05-26  Dodji Seketeli  

PR c++/40007
* g++.dg/template/typedef18.C: New test.
* g++.dg/template/typedef19.C: Likewise.
* g++.dg/template/typedef20.C: Likewise.

2009-05-25  Ira Rosen  

PR tree-optimization/40238
* gcc.dg/vect/pr40238.c: New test.

2009-05-24  Richard Guenther  

PR middle-end/40233
* gcc.c-torture/compile/pr40233.c: New testcase.

Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/canon-type-1.C
  - copied unchanged from r148002,
trunk/gcc/testsuite/g++.dg/template/canon-type-1.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/canon-type-2.C
  - copied unchanged from r148002,
trunk/gcc/testsuite/g++.dg/template/canon-type-2.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/canon-type-3.C
  - copied unchanged from r148002,
trunk/gcc/testsuite/g++.dg/template/canon-type-3.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/canon-type-4.C
  - copied unchanged from r148002,
trunk/gcc/testsuite/g++.dg/template/canon-type-4.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/canon-type-5.C
  - copied unchanged from r148002,
trunk/gcc/testsuite/g++.dg/template/canon-type-5.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/canon-type-6.C
  - copied unchanged from r148002,
trunk/gcc/testsuite/g++.dg/template/canon-type-6.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/canon-type-7.C
  - copied unchanged from r148002,
trunk/gcc/testsuite/g++.dg/template/canon-type-7.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/typedef18.C
  - copied unchanged from r148003,
trunk/gcc/testsuite/g++.dg/template/typedef18.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/typedef19.C
  - copied unchanged from r148003,
trunk/gcc/testsuite/g++.dg/template/typedef19.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/typedef20.C
  - copied unchanged from r148003,
trunk/gcc/testsuite/g++.dg/template/typedef20.C
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40233.c
  - copied unchanged from r148003,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40233.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40252.c
  - copied unchanged from r148003,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40252.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/pr40238.c
  - copied unchanged from r148003,
trunk/gcc/testsuite/gcc.dg/vect/pr40238.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/pr40254.c
  - copied unchanged from r148003,
trunk/gcc/testsuite/gcc.dg/vect/pr40254.c
Modified:
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/40252] [4.5 Regression] Internal compiler error on samba4 (verify_gimple failed)

[hjl at gcc dot gnu dot org]

--- Comment #7 from hjl at gcc dot gnu dot org  2009-05-30 13:50 ---
Subject: Bug 40252

Author: hjl
Date: Sat May 30 13:49:33 2009
New Revision: 148004

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148004
Log:
2009-05-30  H.J. Lu  

Backport from mainline:

2009-05-28  Dodji Seketeli  

PR c++/39754
* g++.dg/template/canon-type-1.C: New test.
* g++.dg/template/canon-type-2.C: Likewise.
* g++.dg/template/canon-type-3.C: Likewise.
* g++.dg/template/canon-type-4.C: Likewise.
* g++.dg/template/canon-type-5.C: Likewise.
* g++.dg/template/canon-type-6.C: Likewise.
* g++.dg/template/canon-type-7.C: Likewise.

2009-05-28  Ira Rosen  

PR tree-optimization/40254
* gcc.dg/vect/pr40254.c: New test.

2009-05-26  Richard Guenther  

PR middle-end/40252
* gcc.c-torture/compile/pr40252.c: New testcase.

2009-05-26  Dodji Seketeli  

PR c++/40007
* g++.dg/template/typedef18.C: New test.
* g++.dg/template/typedef19.C: Likewise.
* g++.dg/template/typedef20.C: Likewise.

2009-05-25  Ira Rosen  

PR tree-optimization/40238
* gcc.dg/vect/pr40238.c: New test.

2009-05-24  Richard Guenther  

PR middle-end/40233
* gcc.c-torture/compile/pr40233.c: New testcase.

Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/canon-type-1.C
  - copied unchanged from r148002,
trunk/gcc/testsuite/g++.dg/template/canon-type-1.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/canon-type-2.C
  - copied unchanged from r148002,
trunk/gcc/testsuite/g++.dg/template/canon-type-2.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/canon-type-3.C
  - copied unchanged from r148002,
trunk/gcc/testsuite/g++.dg/template/canon-type-3.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/canon-type-4.C
  - copied unchanged from r148002,
trunk/gcc/testsuite/g++.dg/template/canon-type-4.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/canon-type-5.C
  - copied unchanged from r148002,
trunk/gcc/testsuite/g++.dg/template/canon-type-5.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/canon-type-6.C
  - copied unchanged from r148002,
trunk/gcc/testsuite/g++.dg/template/canon-type-6.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/canon-type-7.C
  - copied unchanged from r148002,
trunk/gcc/testsuite/g++.dg/template/canon-type-7.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/typedef18.C
  - copied unchanged from r148003,
trunk/gcc/testsuite/g++.dg/template/typedef18.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/typedef19.C
  - copied unchanged from r148003,
trunk/gcc/testsuite/g++.dg/template/typedef19.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/typedef20.C
  - copied unchanged from r148003,
trunk/gcc/testsuite/g++.dg/template/typedef20.C
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40233.c
  - copied unchanged from r148003,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40233.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40252.c
  - copied unchanged from r148003,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40252.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/pr40238.c
  - copied unchanged from r148003,
trunk/gcc/testsuite/gcc.dg/vect/pr40238.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/pr40254.c
  - copied unchanged from r148003,
trunk/gcc/testsuite/gcc.dg/vect/pr40254.c
Modified:
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug tree-optimization/40238] [4.5 Regression] ICE in gimple_verify_flow_info, at tree-cfg.c:4603

[hjl at gcc dot gnu dot org]

--- Comment #5 from hjl at gcc dot gnu dot org  2009-05-30 13:50 ---
Subject: Bug 40238

Author: hjl
Date: Sat May 30 13:49:33 2009
New Revision: 148004

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148004
Log:
2009-05-30  H.J. Lu  

Backport from mainline:

2009-05-28  Dodji Seketeli  

PR c++/39754
* g++.dg/template/canon-type-1.C: New test.
* g++.dg/template/canon-type-2.C: Likewise.
* g++.dg/template/canon-type-3.C: Likewise.
* g++.dg/template/canon-type-4.C: Likewise.
* g++.dg/template/canon-type-5.C: Likewise.
* g++.dg/template/canon-type-6.C: Likewise.
* g++.dg/template/canon-type-7.C: Likewise.

2009-05-28  Ira Rosen  

PR tree-optimization/40254
* gcc.dg/vect/pr40254.c: New test.

2009-05-26  Richard Guenther  

PR middle-end/40252
* gcc.c-torture/compile/pr40252.c: New testcase.

2009-05-26  Dodji Seketeli  

PR c++/40007
* g++.dg/template/typedef18.C: New test.
* g++.dg/template/typedef19.C: Likewise.
* g++.dg/template/typedef20.C: Likewise.

2009-05-25  Ira Rosen  

PR tree-optimization/40238
* gcc.dg/vect/pr40238.c: New test.

2009-05-24  Richard Guenther  

PR middle-end/40233
* gcc.c-torture/compile/pr40233.c: New testcase.

Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/canon-type-1.C
  - copied unchanged from r148002,
trunk/gcc/testsuite/g++.dg/template/canon-type-1.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/canon-type-2.C
  - copied unchanged from r148002,
trunk/gcc/testsuite/g++.dg/template/canon-type-2.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/canon-type-3.C
  - copied unchanged from r148002,
trunk/gcc/testsuite/g++.dg/template/canon-type-3.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/canon-type-4.C
  - copied unchanged from r148002,
trunk/gcc/testsuite/g++.dg/template/canon-type-4.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/canon-type-5.C
  - copied unchanged from r148002,
trunk/gcc/testsuite/g++.dg/template/canon-type-5.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/canon-type-6.C
  - copied unchanged from r148002,
trunk/gcc/testsuite/g++.dg/template/canon-type-6.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/canon-type-7.C
  - copied unchanged from r148002,
trunk/gcc/testsuite/g++.dg/template/canon-type-7.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/typedef18.C
  - copied unchanged from r148003,
trunk/gcc/testsuite/g++.dg/template/typedef18.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/typedef19.C
  - copied unchanged from r148003,
trunk/gcc/testsuite/g++.dg/template/typedef19.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/typedef20.C
  - copied unchanged from r148003,
trunk/gcc/testsuite/g++.dg/template/typedef20.C
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40233.c
  - copied unchanged from r148003,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40233.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40252.c
  - copied unchanged from r148003,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40252.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/pr40238.c
  - copied unchanged from r148003,
trunk/gcc/testsuite/gcc.dg/vect/pr40238.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/pr40254.c
  - copied unchanged from r148003,
trunk/gcc/testsuite/gcc.dg/vect/pr40254.c
Modified:
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/40007] [4.5 regression] specialization causes access problem in primary template

[hjl at gcc dot gnu dot org]

--- Comment #9 from hjl at gcc dot gnu dot org  2009-05-30 13:50 ---
Subject: Bug 40007

Author: hjl
Date: Sat May 30 13:49:33 2009
New Revision: 148004

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148004
Log:
2009-05-30  H.J. Lu  

Backport from mainline:

2009-05-28  Dodji Seketeli  

PR c++/39754
* g++.dg/template/canon-type-1.C: New test.
* g++.dg/template/canon-type-2.C: Likewise.
* g++.dg/template/canon-type-3.C: Likewise.
* g++.dg/template/canon-type-4.C: Likewise.
* g++.dg/template/canon-type-5.C: Likewise.
* g++.dg/template/canon-type-6.C: Likewise.
* g++.dg/template/canon-type-7.C: Likewise.

2009-05-28  Ira Rosen  

PR tree-optimization/40254
* gcc.dg/vect/pr40254.c: New test.

2009-05-26  Richard Guenther  

PR middle-end/40252
* gcc.c-torture/compile/pr40252.c: New testcase.

2009-05-26  Dodji Seketeli  

PR c++/40007
* g++.dg/template/typedef18.C: New test.
* g++.dg/template/typedef19.C: Likewise.
* g++.dg/template/typedef20.C: Likewise.

2009-05-25  Ira Rosen  

PR tree-optimization/40238
* gcc.dg/vect/pr40238.c: New test.

2009-05-24  Richard Guenther  

PR middle-end/40233
* gcc.c-torture/compile/pr40233.c: New testcase.

Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/canon-type-1.C
  - copied unchanged from r148002,
trunk/gcc/testsuite/g++.dg/template/canon-type-1.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/canon-type-2.C
  - copied unchanged from r148002,
trunk/gcc/testsuite/g++.dg/template/canon-type-2.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/canon-type-3.C
  - copied unchanged from r148002,
trunk/gcc/testsuite/g++.dg/template/canon-type-3.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/canon-type-4.C
  - copied unchanged from r148002,
trunk/gcc/testsuite/g++.dg/template/canon-type-4.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/canon-type-5.C
  - copied unchanged from r148002,
trunk/gcc/testsuite/g++.dg/template/canon-type-5.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/canon-type-6.C
  - copied unchanged from r148002,
trunk/gcc/testsuite/g++.dg/template/canon-type-6.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/canon-type-7.C
  - copied unchanged from r148002,
trunk/gcc/testsuite/g++.dg/template/canon-type-7.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/typedef18.C
  - copied unchanged from r148003,
trunk/gcc/testsuite/g++.dg/template/typedef18.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/typedef19.C
  - copied unchanged from r148003,
trunk/gcc/testsuite/g++.dg/template/typedef19.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/typedef20.C
  - copied unchanged from r148003,
trunk/gcc/testsuite/g++.dg/template/typedef20.C
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40233.c
  - copied unchanged from r148003,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40233.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40252.c
  - copied unchanged from r148003,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40252.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/pr40238.c
  - copied unchanged from r148003,
trunk/gcc/testsuite/gcc.dg/vect/pr40238.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/pr40254.c
  - copied unchanged from r148003,
trunk/gcc/testsuite/gcc.dg/vect/pr40254.c
Modified:
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug tree-optimization/40233] [4.5 Regression] Test failures with "alignment of array elements is greater than element size"

[hjl at gcc dot gnu dot org]

--- Comment #6 from hjl at gcc dot gnu dot org  2009-05-30 13:50 ---
Subject: Bug 40233

Author: hjl
Date: Sat May 30 13:49:33 2009
New Revision: 148004

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148004
Log:
2009-05-30  H.J. Lu  

Backport from mainline:

2009-05-28  Dodji Seketeli  

PR c++/39754
* g++.dg/template/canon-type-1.C: New test.
* g++.dg/template/canon-type-2.C: Likewise.
* g++.dg/template/canon-type-3.C: Likewise.
* g++.dg/template/canon-type-4.C: Likewise.
* g++.dg/template/canon-type-5.C: Likewise.
* g++.dg/template/canon-type-6.C: Likewise.
* g++.dg/template/canon-type-7.C: Likewise.

2009-05-28  Ira Rosen  

PR tree-optimization/40254
* gcc.dg/vect/pr40254.c: New test.

2009-05-26  Richard Guenther  

PR middle-end/40252
* gcc.c-torture/compile/pr40252.c: New testcase.

2009-05-26  Dodji Seketeli  

PR c++/40007
* g++.dg/template/typedef18.C: New test.
* g++.dg/template/typedef19.C: Likewise.
* g++.dg/template/typedef20.C: Likewise.

2009-05-25  Ira Rosen  

PR tree-optimization/40238
* gcc.dg/vect/pr40238.c: New test.

2009-05-24  Richard Guenther  

PR middle-end/40233
* gcc.c-torture/compile/pr40233.c: New testcase.

Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/canon-type-1.C
  - copied unchanged from r148002,
trunk/gcc/testsuite/g++.dg/template/canon-type-1.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/canon-type-2.C
  - copied unchanged from r148002,
trunk/gcc/testsuite/g++.dg/template/canon-type-2.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/canon-type-3.C
  - copied unchanged from r148002,
trunk/gcc/testsuite/g++.dg/template/canon-type-3.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/canon-type-4.C
  - copied unchanged from r148002,
trunk/gcc/testsuite/g++.dg/template/canon-type-4.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/canon-type-5.C
  - copied unchanged from r148002,
trunk/gcc/testsuite/g++.dg/template/canon-type-5.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/canon-type-6.C
  - copied unchanged from r148002,
trunk/gcc/testsuite/g++.dg/template/canon-type-6.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/canon-type-7.C
  - copied unchanged from r148002,
trunk/gcc/testsuite/g++.dg/template/canon-type-7.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/typedef18.C
  - copied unchanged from r148003,
trunk/gcc/testsuite/g++.dg/template/typedef18.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/typedef19.C
  - copied unchanged from r148003,
trunk/gcc/testsuite/g++.dg/template/typedef19.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/typedef20.C
  - copied unchanged from r148003,
trunk/gcc/testsuite/g++.dg/template/typedef20.C
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40233.c
  - copied unchanged from r148003,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40233.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40252.c
  - copied unchanged from r148003,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40252.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/pr40238.c
  - copied unchanged from r148003,
trunk/gcc/testsuite/gcc.dg/vect/pr40238.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/pr40254.c
  - copied unchanged from r148003,
trunk/gcc/testsuite/gcc.dg/vect/pr40254.c
Modified:
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug tree-optimization/40254] [4.5 Regression] SPEC2006 403.gcc miscompares

[hjl at gcc dot gnu dot org]

--- Comment #8 from hjl at gcc dot gnu dot org  2009-05-30 13:50 ---
Subject: Bug 40254

Author: hjl
Date: Sat May 30 13:49:33 2009
New Revision: 148004

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148004
Log:
2009-05-30  H.J. Lu  

Backport from mainline:

2009-05-28  Dodji Seketeli  

PR c++/39754
* g++.dg/template/canon-type-1.C: New test.
* g++.dg/template/canon-type-2.C: Likewise.
* g++.dg/template/canon-type-3.C: Likewise.
* g++.dg/template/canon-type-4.C: Likewise.
* g++.dg/template/canon-type-5.C: Likewise.
* g++.dg/template/canon-type-6.C: Likewise.
* g++.dg/template/canon-type-7.C: Likewise.

2009-05-28  Ira Rosen  

PR tree-optimization/40254
* gcc.dg/vect/pr40254.c: New test.

2009-05-26  Richard Guenther  

PR middle-end/40252
* gcc.c-torture/compile/pr40252.c: New testcase.

2009-05-26  Dodji Seketeli  

PR c++/40007
* g++.dg/template/typedef18.C: New test.
* g++.dg/template/typedef19.C: Likewise.
* g++.dg/template/typedef20.C: Likewise.

2009-05-25  Ira Rosen  

PR tree-optimization/40238
* gcc.dg/vect/pr40238.c: New test.

2009-05-24  Richard Guenther  

PR middle-end/40233
* gcc.c-torture/compile/pr40233.c: New testcase.

Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/canon-type-1.C
  - copied unchanged from r148002,
trunk/gcc/testsuite/g++.dg/template/canon-type-1.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/canon-type-2.C
  - copied unchanged from r148002,
trunk/gcc/testsuite/g++.dg/template/canon-type-2.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/canon-type-3.C
  - copied unchanged from r148002,
trunk/gcc/testsuite/g++.dg/template/canon-type-3.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/canon-type-4.C
  - copied unchanged from r148002,
trunk/gcc/testsuite/g++.dg/template/canon-type-4.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/canon-type-5.C
  - copied unchanged from r148002,
trunk/gcc/testsuite/g++.dg/template/canon-type-5.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/canon-type-6.C
  - copied unchanged from r148002,
trunk/gcc/testsuite/g++.dg/template/canon-type-6.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/canon-type-7.C
  - copied unchanged from r148002,
trunk/gcc/testsuite/g++.dg/template/canon-type-7.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/typedef18.C
  - copied unchanged from r148003,
trunk/gcc/testsuite/g++.dg/template/typedef18.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/typedef19.C
  - copied unchanged from r148003,
trunk/gcc/testsuite/g++.dg/template/typedef19.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/typedef20.C
  - copied unchanged from r148003,
trunk/gcc/testsuite/g++.dg/template/typedef20.C
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40233.c
  - copied unchanged from r148003,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40233.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40252.c
  - copied unchanged from r148003,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40252.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/pr40238.c
  - copied unchanged from r148003,
trunk/gcc/testsuite/gcc.dg/vect/pr40238.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/pr40254.c
  - copied unchanged from r148003,
trunk/gcc/testsuite/gcc.dg/vect/pr40254.c
Modified:
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c/40305] strict aliasing and inlining

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2009-05-30 13:50 ---
It is invalid.  f->a is accessed through an incompatible type (void * rather
than int *).  And gcc even warns about it, with -Wstrict-aliasing=2 or
-Wstrict-aliasing=1.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/40306] New: ICE when using auto to declare a local copy inside a member function

[public at alisdairm dot net]

Tested on MinGW 4.4.0

The following code produces an Internal Compiler Error:

template< typename T >
struct test {
   test run() {
  auto tmp = *this;
  return tmp;
   }
};

int main()
{
   test x;
   x.run();
   return 0;
}


Compiler output:

||=== AutoBug01, Debug ===|
In member function 'test test::run()':
error: in type_unification_real, at cp/pt.c:12477|
||=== Build finished: 1 errors, 0 warnings ===|


-- 
   Summary: ICE when using auto to declare a local copy inside a
member function
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: public at alisdairm dot net


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

[Bug c++/40307] New: Problem with auto deducing class type inside one of its own member functions

[public at alisdairm dot net]

The following code demonstrates the problem.  It should compile cleanly, as
demonstrated by the run_pass function, but the run_fail function generates an
error:

template< typename T >
struct test {
   test run_pass() {
  test tmp( *this );
  return tmp;
   }

   test run_fail() {
  auto tmp( *this );
  return tmp;
   }
};

int main()
{
   test x;
   x.run_pass();
   x.run_fail();
   return 0;
}


Compiler output:

||=== AutoBug02, Debug ===|
In member function 'test test::run_fail() [with T = int]':
instantiated from here
error: 'tmp' has incomplete type
||=== Build finished: 1 errors, 0 warnings ===|


-- 
   Summary: Problem with auto deducing class type inside one of its
own member functions
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: public at alisdairm dot net


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

[Bug c++/40308] New: Brace initialization fails for member initializers in constructor for class templates

[public at alisdairm dot net]

Tested against MinGW 4.4.0

The following code fails to compile, with the two specializations yielding
different error messages.

Test code:

template< typename T >
struct test {
   test() : data{} {}

   T data;
};

int main()
{
   test x;
   test y;
   return 0;
}


Compiler output:
||=== BraceInitBug01, Debug ===|
main.cpp||In constructor 'test::test() [with T = int]':|
main.cpp|10|instantiated from here|
main.cpp|3|error: aggregate value used where an integer was expected|
main.cpp||In constructor 'test::test() [with T = int*]':|
main.cpp|11|instantiated from here|
main.cpp|3|error: cannot convert '()' from
type '' to type 'int*'|
||=== Build finished: 2 errors, 0 warnings ===|


-- 
   Summary: Brace initialization fails for member initializers in
constructor for class templates
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: public at alisdairm dot net


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

[Bug fortran/40309] New: gfortran does not support static c/d-tors.

[dave dot korn dot cygwin at gmail dot com]

[ ref: http://gcc.gnu.org/onlinedocs/gccint/Initialization.html ]
[ ref: http://gcc.gnu.org/ml/fortran/2009-05/threads.html#00440 ]

gfortran does not set main_identifier_node to anything.  This causes
gimple_expand_cfg() in cfgexpand.c to fail to emit a call to the libgcc static
init function __main, because the MAIN_NAME_P check in this conditional:

  /* If this function is `main', emit a call to `__main'
 to run global initializers, etc.  */
  if (DECL_NAME (current_function_decl)
  && MAIN_NAME_P (DECL_NAME (current_function_decl))
  && DECL_FILE_SCOPE_P (current_function_decl))
expand_main_function ();

fails.  On cygwin, this means that gfortran's init() function is never set up,
the units and option variables don't get initialised, and "hello world" fails
when it tries to output the first char, with a runtime library error.

The fix is to correctly initialise it somewhere in the fortran compiler's early
 startup, using a line as simple as:

  main_identifier_node = get_identifier ("main");

although I don't know for sure what mangled version of the name "main" to use
for fortran, or where would be the best place in the fortran frontend to put
this code.


-- 
   Summary: gfortran does not support static c/d-tors.
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dave dot korn dot cygwin at gmail dot com
 GCC build triplet: i686-pc-cygwin
  GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin


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

[Bug ada/40310] New: Patches for gcc 4.4.0 to support FreeBSD x86_64

[gcc at coreland dot ath dot cx]

See the attachments.


-- 
   Summary: Patches for gcc 4.4.0 to support FreeBSD x86_64
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at coreland dot ath dot cx
 GCC build triplet: x86_64-pc-freebsd7.2
  GCC host triplet: x86_64-pc-freebsd7.2
GCC target triplet: x86_64-pc-freebsd7.2


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

[Bug ada/40310] Patches for gcc 4.4.0 to support FreeBSD x86_64

[gcc at coreland dot ath dot cx]

--- Comment #1 from gcc at coreland dot ath dot cx  2009-05-30 15:01 ---
Created an attachment (id=17937)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17937&action=view)
Patch to Makefile to use 64 bit FreeBSD system package.


-- 


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

[Bug fortran/40309] gfortran does not support static c/d-tors.

[dave dot korn dot cygwin at gmail dot com]

--- Comment #1 from dave dot korn dot cygwin at gmail dot com  2009-05-30 
15:01 ---

It's not entirely straightforward, it seems.  An earlier attempt appears to
have fizzled out:

http://gcc.gnu.org/ml/fortran/2007-09/threads.html#00289

I do not yet understand Andrew Pinski's objection: 

" This is wrong as it causes the middle-end to also emitt a call to
__main inside MAIN__.  Now you will get two calls to __main which
calls the global constructors now twice. "

as I don't understand what the "also" refers to.  Right now there are precisely
no calls to __main at all.  Perhaps there used to be an actual C-linkage main
function in libgfortran.  Yes, wait a minute, this is what libgfortranbegin
used to get us, is it not?


-- 


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

[Bug ada/40310] Patches for gcc 4.4.0 to support FreeBSD x86_64

[gcc at coreland dot ath dot cx]

--- Comment #2 from gcc at coreland dot ath dot cx  2009-05-30 15:02 ---
Created an attachment (id=17938)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17938&action=view)
64 bit FreeBSD system package.


-- 


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

[Bug ada/40310] Patches for gcc 4.4.0 to support FreeBSD x86_64

[gcc at coreland dot ath dot cx]

--- Comment #3 from gcc at coreland dot ath dot cx  2009-05-30 15:03 ---
I've just noticed that I accidentally left in a "# PATCHED" comment
in the c8.diff patch. Anyone who commits this patch will probably
want to remove that.


-- 


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

[Bug fortran/40309] gfortran does not support static c/d-tors.

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2009-05-30 15:11 ---
(In reply to comment #1)
> It's not entirely straightforward, it seems.  An earlier attempt appears to
> have fizzled out:

That no longer applies because gfortran produces main now.  MAIN__ is not going
to be used but main will be.

Thanks,
Andrew Pinski


-- 


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

[Bug c++/40311] New: brace initialization does not work well with new

[public at alisdairm dot net]

Tested on MinGW 4.4.0

The following code does not compile and should:

int main()
{
   int * a = new int{};
   int * b = new int{5};
   return 0;
}


Compiler output:
main.cpp||In function 'int main()':|
main.cpp|3|error: aggregate value used where an integer was expected|
main.cpp|4|error: aggregate value used where an integer was expected|
main.cpp|3|warning: unused variable 'a'|
main.cpp|4|warning: unused variable 'b'|
||=== Build finished: 2 errors, 2 warnings ===|


-- 
   Summary: brace initialization does not work well with new
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: public at alisdairm dot net


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

[Bug fortran/40309] gfortran does not support static c/d-tors.

[dave dot korn dot cygwin at gmail dot com]

--- Comment #3 from dave dot korn dot cygwin at gmail dot com  2009-05-30 
15:19 ---

About to test this:

$ svn diff -x -p fortran/trans-decl.c
Index: fortran/trans-decl.c
===
--- fortran/trans-decl.c(revision 147949)
+++ fortran/trans-decl.c(working copy)
@@ -3859,7 +3859,8 @@ create_main_function (tree fndecl)
   tmp =  build_function_type_list (integer_type_node, integer_type_node,
   build_pointer_type (pchar_type_node),
   NULL_TREE);
-  ftn_main = build_decl (FUNCTION_DECL, get_identifier ("main"), tmp);
+  main_identifier_node
+= ftn_main = build_decl (FUNCTION_DECL, get_identifier ("main"), tmp);
   DECL_EXTERNAL (ftn_main) = 0;
   TREE_PUBLIC (ftn_main) = 1;
   TREE_STATIC (ftn_main) = 1;


-- 


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

[Bug fortran/40309] gfortran does not support static c/d-tors.

[dave dot korn dot cygwin at gmail dot com]

--- Comment #4 from dave dot korn dot cygwin at gmail dot com  2009-05-30 
15:34 ---
(In reply to comment #3)
> About to test this:

  That was wrong.  This is what I should have said:

$ svn diff fortran/trans-decl.c
Index: fortran/trans-decl.c
===
--- fortran/trans-decl.c(revision 147949)
+++ fortran/trans-decl.c(working copy)
@@ -3859,7 +3859,8 @@
   tmp =  build_function_type_list (integer_type_node, integer_type_node,
   build_pointer_type (pchar_type_node),
   NULL_TREE);
-  ftn_main = build_decl (FUNCTION_DECL, get_identifier ("main"), tmp);
+  main_identifier_node = get_identifier ("main");
+  ftn_main = build_decl (FUNCTION_DECL, main_identifier_node, tmp);
   DECL_EXTERNAL (ftn_main) = 0;
   TREE_PUBLIC (ftn_main) = 1;
   TREE_STATIC (ftn_main) = 1;


-- 


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

[Bug fortran/40309] gfortran does not support static c/d-tors.

[dave dot korn dot cygwin at gmail dot com]

--- Comment #5 from dave dot korn dot cygwin at gmail dot com  2009-05-30 
15:38 ---
The patch in comment 4 works.

dkad...@ubik /tmp/fortran
$ ./hello-fixed.exe
 Hello World!

dkad...@ubik /tmp/fortran
$ gdb ./hello-fixed.exe
GNU gdb 6.8.0.20080328-cvs (cygwin-special)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-cygwin"...
(gdb) disass main
Dump of assembler code for function main:
0x0040114d :push   %ebp
0x0040114e :mov%esp,%ebp
0x00401150 :and$0xfff0,%esp
0x00401153 :sub$0x10,%esp
0x00401156 :call   0x401210 <__main>
0x0040115b :   mov0xc(%ebp),%eax
0x0040115e :   mov%eax,0x4(%esp)
0x00401162 :   mov0x8(%ebp),%eax
0x00401165 :   mov%eax,(%esp)
0x00401168 :   call   0x402320 <*__gfortran_set_args>
0x0040116d :   movl   $0x417b00,0x4(%esp)
0x00401175 :   movl   $0x8,(%esp)
0x0040117c :   call   0x4023b0 <*__gfortran_set_options>
0x00401181 :   call   0x4010e0 
0x00401186 :   mov$0x0,%eax
0x0040118b :   leave
0x0040118c :   ret
0x0040118d :   nop
0x0040118e :   nop
0x0040118f :   nop
End of assembler dump.
(gdb)

I'll try a testsuite run now.


-- 


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

[Bug target/40301] [4.3 regression] SH: miscompile with -O2 -fPIC

[sugioka at itonet dot co dot jp]

--- Comment #3 from sugioka at itonet dot co dot jp  2009-05-30 15:55 
---
Thanks for your reply.
I tried Christian's patch and Joern's patch on x86 cross distcc environment.
Both of them worked for my case.
Thanks.


-- 


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

[Bug c++/11764] [DR147] g++ does not treat injected class name correctly.

[ian at airs dot com]

--- Comment #14 from ian at airs dot com  2009-05-30 16:03 ---
gcc is a free software project driven largely by volunteers.  Interest in
fixing accepts-invalid bugs is generally low; people are generally more
interested in rejects-valid bugs, or in better optimizations, or in avoiding
regressions.  There are, unfortunately, many open bugs, many of which have
higher priority than this one.  If this bug is important to you, you do have
the option of fixing it yourself.


-- 


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

[Bug fortran/40309] gfortran does not support static c/d-tors.

[dave dot korn dot cygwin at gmail dot com]

--- Comment #6 from dave dot korn dot cygwin at gmail dot com  2009-05-30 
16:12 ---
Groan.

PASS: gfortran.dg/Wall.f90 (test for excess errors)
spawn [open ...]
Internal Error: insert(): Duplicate key found!
FAIL: gfortran.dg/Wall.f90 execution test

In other words, exactly what Andrew warned would happen.

Breakpoint 1, __main () at /gnu/winsup/src/winsup/cygwin/dcrt0.cc:993
993   do_global_ctors (user_data->ctors, false);
(gdb) bt
#0  __main () at /gnu/winsup/src/winsup/cygwin/dcrt0.cc:993
#1  0x00401166 in main ()
(gdb) c
Continuing.

Breakpoint 1, __main () at /gnu/winsup/src/winsup/cygwin/dcrt0.cc:993
993   do_global_ctors (user_data->ctors, false);
(gdb) bt
#0  __main () at /gnu/winsup/src/winsup/cygwin/dcrt0.cc:993
#1  0x004010ee in MAIN__ ()
#2  0x00401191 in main ()
(gdb)

For some reason though, there isn't any call to __main in MAIN__ in my original
"hello world" testcase, only in main.  I don't yet understand that.  It may be
to do with the usage of main_program_symbol() in parse.c, which is called from
two places:

case ST_PROGRAM:
  if (seen_program)
goto duplicate_main;
  seen_program = 1;
  prog_locus = gfc_current_locus;

  push_state (&s, COMP_PROGRAM, gfc_new_block);
  main_program_symbol(gfc_current_ns, gfc_new_block->name);
  accept_statement (st);


/* Anything else starts a nameless main program block.  */
default:
  if (seen_program)
goto duplicate_main;
  seen_program = 1;
  prog_locus = gfc_current_locus;

  push_state (&s, COMP_PROGRAM, gfc_new_block);
  main_program_symbol (gfc_current_ns, "MAIN__");


  I'm not sure yet what happens when we take the first one of these clauses and
create a main function that is not called "MAIN__", because there is code in
gfc_sym_mangled_function_id in trans-decl.c that assumes any main function has
the same name:

  /* Main program is mangled into MAIN__.  */
  if (sym->attr.is_main_program)
return get_identifier ("MAIN__");

Possibly this is an inconsistency, and if there's a named main block we create
a main function but then look up what will effectively be an unrelated name.  I
need advice from someone who knows the fortran compiler internals better than
me. 


-- 


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

[Bug ada/40310] Patches for gcc 4.4.0/GNAT to support FreeBSD x86_64

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-05-30 16:18 ---
patches need to be sent to gcc-patc...@gcc.gnu.org together with a ChangeLog
entry following existing practice and a notice how they were tested (bootstrap
and running the testsuite is required).


-- 


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

[Bug middle-end/40244] [4.5 Regression] Revision 147829 caused extra failures

[irar at il dot ibm dot com]

--- Comment #5 from irar at il dot ibm dot com  2009-05-30 16:53 ---
(In reply to comment #4)
> (In reply to comment #1)
> > (In reply to comment #0)
> > > On Linux/ia64, revision 147829:
> > > http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00806.html
> > > caused:
> > > FAIL: Matrix4f -O3 compilation from source
> > 
> > Could you please provide some information, it doesn't fail on x86_64...
> > 
> > > FAIL: gcc.dg/vect/bb-slp-10.c scan-tree-dump-times slp "unsupported 
> > > alignment
> > > in basic block." 1
> > > FAIL: gcc.dg/vect/bb-slp-4.c scan-tree-dump-times slp "basic block 
> > > vectorized
> > > using SLP" 0
> > 
> > I think they can be fixed as following. Could you please check?
> > 
> Yes, it fixed the problem. Thanks.

Thanks.
Is Matrix4f OK now too?


-- 


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

[Bug middle-end/40244] [4.5 Regression] Revision 147829 caused extra failures

[hjl dot tools at gmail dot com]

--- Comment #6 from hjl dot tools at gmail dot com  2009-05-30 16:57 ---
(In reply to comment #5)
> Is Matrix4f OK now too?
> 

Yes.


-- 


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

[Bug fortran/40309] gfortran does not support static c/d-tors.

[dave dot korn dot cygwin at gmail dot com]

--- Comment #7 from dave dot korn dot cygwin at gmail dot com  2009-05-30 
17:09 ---
http://gcc.gnu.org/ml/fortran/2009-05/msg00452.html

We have two functions that both match MAIN_NAME_P, because they share the same
DECL_NAME.  This happens when there is a "PROGRAM main" directive in the
fortran source.


-- 


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

[Bug middle-end/40304] [4.5 Regression] Revision 147995 breaks stack unwind

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2009-05-30 19:00 ---
See http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01942.html


-- 


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

[Bug fortran/40309] gfortran does not support static c/d-tors.

[burnus at gcc dot gnu dot org]

--- Comment #8 from burnus at gcc dot gnu dot org  2009-05-30 21:14 ---
Latest patch - fixing the main_identifier_node (__main() call) problem as in
comment 4 plus fixes the "PROGRAM main" problem.

http://gcc.gnu.org/ml/fortran/2009-05/msg00458.html


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-05-30 21:14:46
   date||


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

[Bug middle-end/30807] sh postreload bug (might be generic in trunk)

[kkojima at gcc dot gnu dot org]

--- Comment #5 from kkojima at gcc dot gnu dot org  2009-05-30 22:56 ---
*** Bug 40301 has been marked as a duplicate of this bug. ***


-- 

kkojima at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||sugioka at itonet dot co dot
   ||jp


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

[Bug rtl-optimization/40301] SH: 4.3 miscompile with -O2 -fPIC

[kkojima at gcc dot gnu dot org]

--- Comment #4 from kkojima at gcc dot gnu dot org  2009-05-30 22:56 ---
Thanks for confirmation.  Then this is a duplicate of PR30807
and a long standing problem of postreload and not a regression.
The problem is that we have no handy test cases for trunk.
Every time this pops up only on older releases and is latent
on mainline at that time.  I'll try again to get a test case
on trunk.


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


-- 

kkojima at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Component|target  |rtl-optimization
 Resolution||DUPLICATE
Summary|[4.3 regression] SH:|SH: 4.3 miscompile with -O2
   |miscompile with -O2 -fPIC   |-fPIC


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

[Bug c/40312] New: Compilings with and with O2 flag lead to different execution results

[tlin at a10networks dot com]

The following simplified standalone C code illustrates this bug.  If we compile
it with and without O2 flag, the executions are different.

The comments at the beginning of the following code has GCC information,
compiling commands, and execution outputs.

 Example C Code =

/*
GCC Version:

gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.1.1/configure --prefix=/usr --libexecdir=/usr/lib
--enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-c99
--enable-long-long --enable-clocale=gnu --enable-languages=c,c++
--disable-multilib --disable-libstdcxx-pch
Thread model: posix
gcc version 4.1.1

Compile commands:

   gcc -o test  test.c; gcc -O2 -o O2_test test.c 

Execution outputs:

./test; ./O2_test 

Output:
./test: Bug[1] 2001:d::2/64 matches 2001:d::1.
 ./O2_test: Bug[0] 2001:c::1/64 matches 2001:d::1.
 */

#include 
#include 
#include 
#include 
#include 
#include 
#include 

typedef unsigned char u8;
typedef unsigned short u16;
typedef unsigned int u32;

static inline int __ipv6_prefix_equal(const u32 *a1, const u32 *a2,
  unsigned int prefixlen)
{
unsigned pdw, pbi;

pdw = prefixlen >> 5;
if (pdw && memcmp(a1, a2, pdw << 2))
return 0;

pbi = prefixlen & 0x1f;
if (pbi && ((a1[pdw] ^ a2[pdw]) & htonl((0x) << (32 - pbi
return 0;

return 1;
}

static inline int ipv6_prefix_equal(const struct in6_addr *a1,
const struct in6_addr *a2,
unsigned int prefixlen)
{
return __ipv6_prefix_equal(a1->s6_addr32, a2->s6_addr32,
   prefixlen);
}

static inline int ipv6_addr_any(const struct in6_addr *a)
{
return ((a->s6_addr32[0] | a->s6_addr32[1] |
 a->s6_addr32[2] | a->s6_addr32[3] ) == 0);
}

struct temp {
unsigned int ipv6_prefixlen;
struct in6_addr ipv6_addr;
struct in6_addr ipv6_lladdr;
} bug[2];

struct in6_addr target;


int find_bug (int link_local_nexthop)
{
int i;

for (i = 0 ; i <= 1; i++) {
if (ipv6_addr_any(&bug[i].ipv6_addr) && !link_local_nexthop)
continue;
if (ipv6_addr_any(&bug[i].ipv6_lladdr) && link_local_nexthop)
continue;
if (ipv6_prefix_equal(&bug[i].ipv6_addr, &target,
bug[i].ipv6_prefixlen)) {
return i;
}
}
return -1;
}


int main(int argc, char ** argv)
{
int i = -1;
char ipv6[3][256];

strcpy(ipv6[0], "2001:c::1");
strcpy(ipv6[1], "2001:d::2");
strcpy(ipv6[2], "2001:d::1");

inet_pton(AF_INET6, ipv6[0], &bug[0].ipv6_addr);
inet_pton(AF_INET6, "fe80:c::1", &bug[0].ipv6_lladdr);  
bug[0].ipv6_prefixlen = 64;

inet_pton(AF_INET6, ipv6[1], &bug[1].ipv6_addr);
inet_pton(AF_INET6, "fe80:2001::1", &bug[1].ipv6_lladdr);   
bug[1].ipv6_prefixlen = 64;

inet_pton(AF_INET6, ipv6[2], &target);  

i = find_bug(0);
if (i == -1)
printf("No match found.\n");
else
printf("%10s: Bug[%d] %s/%u matches %s.\n", argv[0], i,
ipv6[i], bug[i].ipv6_prefixlen, ipv6[2]);
return 0;
}


-- 
   Summary: Compilings with and with O2 flag lead to different
execution results
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tlin at a10networks dot com


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

[Bug rtl-optimization/30807] postreload bug (might be generic in trunk)

[kkojima at gcc dot gnu dot org]

--- Comment #6 from kkojima at gcc dot gnu dot org  2009-05-30 23:02 ---
Reported against 4.3 with another big test case.


-- 

kkojima at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||kkojima at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
  Component|middle-end  |rtl-optimization
 Ever Confirmed|0   |1
  Known to fail||4.3.2
   Priority|P3  |P4
   Last reconfirmed|-00-00 00:00:00 |2009-05-30 23:02:47
   date||
Summary|sh postreload bug (might be |postreload bug (might be
   |generic in trunk)   |generic in trunk)


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

[Bug c/40312] Compiling with O2 flag lead to wrong binary code (X86 system 32bit)

[tlin at a10networks dot com]

--- Comment #1 from tlin at a10networks dot com  2009-05-30 23:08 ---
The one compiled with O2 has wrong binary code.

The problem occurs when GCC compiles the following lines with O2 flag.

"
if (pdw && memcmp(a1, a2, pdw << 2))
return 0;
"

In the binary code, pdw is not shifted left by 2, which leads to wrong result.


-- 


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

[Bug target/40313] New: SH: ICE in dwarf2out_begin_epilogue, at dwarf2out.c:2689

[kkojima at gcc dot gnu dot org]

After r147995,

gcc.c-torture/compile/20080903-1.c fails for -O3 -g on SH with

20080903-1.c:12: internal compiler error: in dwarf2out_begin_epilogue, at
dwarf2out.c:2689

In failing case, sched2 moves a frame related insn in prologue
after NOTE_INSN_EPILOGUE_BEG note:

(note 42 6 43 2 NOTE_INSN_EPILOGUE_BEG)

(insn:TI 43 42 35 2 20080903-1.c:12 (set (reg:SI 7 r7)
(const_int 4096 [0x1000])) 175 {movsi_ie} (nil))

(insn/f 35 43 36 2 20080903-1.c:5 (set (reg/f:SI 14 r14)
(reg/f:SI 15 r15)) 175 {movsi_ie} (nil))

I'm testing a patch which emits a blockage insn before insn 35
when dwarf2out_do_frame returns true.  We already do so when
exception handling is enabled.  It will change the code with
-g.  This isn't good in general but wouldn't be a real problem
in the above situation because if such movement of the frame insn
happened, then no one can expect -g works well in the first place.


-- 
   Summary: SH: ICE in dwarf2out_begin_epilogue, at dwarf2out.c:2689
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kkojima at gcc dot gnu dot org
GCC target triplet: sh-unkonwn-elf


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

[Bug target/40313] SH: ICE in dwarf2out_begin_epilogue, at dwarf2out.c:2689

[kkojima at gcc dot gnu dot org]

-- 

kkojima at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.5.0
   Priority|P3  |P4


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

[Bug fortran/37446] Diagnostic of edit descriptors, esp. EN

[jvdelisle at gcc dot gnu dot org]

--- Comment #1 from jvdelisle at gcc dot gnu dot org  2009-05-31 00:17 
---
I might as well fix this one while I am doing other edit descriptors.


-- 

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|NEW |ASSIGNED
   Last reconfirmed|2009-03-29 09:21:07 |2009-05-31 00:17:03
   date||


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

[Bug target/35179] execs crash in shared lib destructor = do_global_dtors_aux

[radu dot gcc at ohmi dot org]

--- Comment #5 from radu dot gcc at ohmi dot org  2009-05-31 01:52 ---
Created an attachment (id=17939)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17939&action=view)
Improved hello-test case showing working and failing command lines, with
Makefile

This behaviour exists on "Linux beam 2.6.22-15-server #1 SMP Wed Aug 20
19:08:24 UTC 2008 i686 GNU/Linux", running "gcc version 4.1.3 20080308
(prerelease) (Ubuntu 4.1.2-21ubuntu1)"

In my case, I found it accidentally, as there was a stray '-static' on the
command line, even though I was compiling a shared build. Removing '-static'
fixes the problem, but I did bang by head against the wall a couple of times
while looking for the problem.

The attached testcase shows how this bug is duplicated. It is the same testcase
submitted previously, but I added the '-static -shared' combo, as on my system
the original testcase did not reproduce the bug. The output from my run is:

gcc -o hellomain.o -c -g hellomain.c
hellomain.c: In function 'main':
hellomain.c:9: warning: incompatible implicit declaration of built-in function
'exit'
gcc -o hello_.o -g -c -fpic -DPIC hello.c
gcc -o libhello.so -shared -g hello_.o
gcc -g -o hello-exec hellomain.o -L. -lhello
echo Linking with both -static and -shared flags exposes the bug.
Linking with both -static and -shared flags exposes the bug.
gcc -g -static -o hello-exec-gccbug35179 hellomain.o -shared -L. -lhello -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --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.1.3 --program-suffix=-4.1
--enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug
--enable-mpfr --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.3 20080308 (prerelease) (Ubuntu 4.1.2-21ubuntu1)
 /usr/lib/gcc/i486-linux-gnu/4.1.3/collect2 -m elf_i386 --hash-style=both
-shared -o hello-exec-gccbug35179
/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib/crti.o
/usr/lib/gcc/i486-linux-gnu/4.1.3/crtbeginT.o -L.
-L/usr/lib/gcc/i486-linux-gnu/4.1.3 -L/usr/lib/gcc/i486-linux-gnu/4.1.3
-L/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib -L/lib/../lib
-L/usr/lib/../lib hellomain.o -lhello --start-group -lgcc -lgcc_eh -lc
--end-group /usr/lib/gcc/i486-linux-gnu/4.1.3/crtendS.o
/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib/crtn.o
./hello-exec
About to call hello!

Hello, World!
gdb -x gdb.run ./hello-exec-gccbug35179
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...

Program received signal SIGSEGV, Segmentation fault.
0x8426 in __do_global_dtors_aux ()
Current language:  auto; currently asm
The program is running.  Exit anyway? (y or n) [answered Y; input not from
terminal]


-- 


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

[Bug target/35179] execs crash in shared lib destructor = do_global_dtors_aux

[radu dot gcc at ohmi dot org]

--- Comment #6 from radu dot gcc at ohmi dot org  2009-05-31 01:55 ---
(From update of attachment 17939)
Works as expected:
gcc -g -o hello-exec hellomain.o -L. -lhello

Triggers the bug:
gcc -g -static -o hello-exec-gccbug35179 hellomain.o -shared -L. -lhello -v


-- 


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

[Bug rtl-optimization/40314] New: inefficient address calculation of fields of large struct

[carrot at google dot com]

Given a structure and 3 field access

typedef struct network
{
   char inputfile[400];
   int* nodes;
   int* arcs;
   int* stop_arcs;
} network_t;

   int *arc;
   int *node = net->nodes;   <--- A
   void *stop = (void *)net->stop_arcs;  <--- B
   for( arc = net->arcs; arc != (int *)stop; arc++ ) <--- C

GCC generates following instruction sequence in thumb mode with options -O2
-Os, it needs 9 insts to load 3 fields 

   mov r2, #200 <---  A1
   lsl r1, r2, #1   <---  A2
   .loc 1 14 0
   mov r4, #204 <  B1
   lsl r3, r4, #1   <---   B2
   .loc 1 13 0
   ldr r2, [r0, r1]  <  A3
   .loc 1 15 0
   mov r1, #202  <---  C1
   .loc 1 14 0
   ldr r4, [r0, r3]  <--- B3
   .loc 1 15 0
   lsl r3, r1, #1<---  C2
   ldr r3, [r0, r3]   <---  C3

A better method is adjusting the base address first, which is nearer to all 3
fields we will access. Then we can use ldr dest, [base, offset] to load each
fields with only 1 instruction.

Although this opportunity is found in target ARM, it should also be applicable
to other architectures with addressing mode of (base + offset) and offset has a
limited value range.


-- 
   Summary: inefficient address calculation of fields of large
struct
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
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=40314

[Bug rtl-optimization/40314] inefficient address calculation of fields of large struct

[carrot at google dot com]

--- Comment #1 from carrot at google dot com  2009-05-31 02:42 ---
Created an attachment (id=17940)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17940&action=view)
test case to show the opportunity


-- 


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

[Bug rtl-optimization/40314] inefficient address calculation of fields of large struct

[carrot at google dot com]

--- Comment #2 from carrot at google dot com  2009-05-31 02:51 ---
There are a lot of such opportunities in mcf from SPEC CPU 2006.

One possible implementation is to add a pass before cse. In the new pass it
should detect insn patterns like:

(set r200 400) # 400 is offset of field1
(set r201 (mem (plus r100 r200)))  # r100 contains struct base
...
(set r300 404) # 404 is offset of field2
(set r301 (mem (plus r100 r300)))  # r100 contains struct base

And rewrite them as:

(set r200 400) # keep the original insn
(set r250 (plus r100 400)) # r250 is new base
(set r201 (mem (plus r250 0)))
...
(set r300 404)
(set r251 (plus r100 400)) # r251 contains same value as r250
(set r301 (mem (plus r251 4)))

We can let dce and cse remove the redundant code, the final result should look
like:

(set r101 (plus r100 400))
(set r201 (mem (plus r101 0)))
...
(set r301 (mem (plus r101 4)))


-- 


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

[Bug testsuite/40244] [4.5 Regression] Revision 147829 caused extra failures

[irar at il dot ibm dot com]

-- 

irar at il dot ibm dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |irar at il dot ibm dot com
   |dot org |
 Status|NEW |ASSIGNED
  Component|middle-end  |testsuite
   Last reconfirmed|2009-05-29 07:52:46 |2009-05-31 06:45:04
   date||


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

[Bug testsuite/40244] [4.5 Regression] Revision 147829 caused extra failures

[irar at gcc dot gnu dot org]

--- Comment #7 from irar at gcc dot gnu dot org  2009-05-31 06:55 ---
Subject: Bug 40244

Author: irar
Date: Sun May 31 06:55:37 2009
New Revision: 148010

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148010
Log:

PR testsuite/40244
* gcc.dg/vect/bb-slp-4.c: Change the number of data accesses to 2.
* gcc.dg/vect/bb-slp-10.c: Change the store misalignment to 1.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/bb-slp-10.c
trunk/gcc/testsuite/gcc.dg/vect/bb-slp-4.c


-- 


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