[Bug target/40301] [4.3 regression] SH: miscompile with -O2 -fPIC
--- 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
--- 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.
--- 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
--- 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
--- 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
--- 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
--- 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 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
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
--- 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=17935action=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
--- 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
--- 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
--- 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=gccview=revrev=148002 Log: 2009-05-30 Thomas Koenig tkoe...@gcc.gnu.org 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 tkoe...@gcc.gnu.org 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
--- 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=gccview=revrev=148002 Log: 2009-05-30 Thomas Koenig tkoe...@gcc.gnu.org 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 tkoe...@gcc.gnu.org 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
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
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 string.h
#include assert.h
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
--- 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=17936action=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 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
--- 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=gccview=revrev=148004 Log: 2009-05-30 H.J. Lu hongjiu...@intel.com Backport from mainline: 2009-05-28 Dodji Seketeli do...@redhat.com 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 i...@il.ibm.com PR tree-optimization/40254 * gcc.dg/vect/pr40254.c: New test. 2009-05-26 Richard Guenther rguent...@suse.de PR middle-end/40252 * gcc.c-torture/compile/pr40252.c: New testcase. 2009-05-26 Dodji Seketeli do...@redhat.com 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 i...@il.ibm.com PR tree-optimization/40238 * gcc.dg/vect/pr40238.c: New test. 2009-05-24 Richard Guenther rguent...@suse.de 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)
--- 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=gccview=revrev=148004 Log: 2009-05-30 H.J. Lu hongjiu...@intel.com Backport from mainline: 2009-05-28 Dodji Seketeli do...@redhat.com 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 i...@il.ibm.com PR tree-optimization/40254 * gcc.dg/vect/pr40254.c: New test. 2009-05-26 Richard Guenther rguent...@suse.de PR middle-end/40252 * gcc.c-torture/compile/pr40252.c: New testcase. 2009-05-26 Dodji Seketeli do...@redhat.com 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 i...@il.ibm.com PR tree-optimization/40238 * gcc.dg/vect/pr40238.c: New test. 2009-05-24 Richard Guenther rguent...@suse.de 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
--- 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=gccview=revrev=148004 Log: 2009-05-30 H.J. Lu hongjiu...@intel.com Backport from mainline: 2009-05-28 Dodji Seketeli do...@redhat.com 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 i...@il.ibm.com PR tree-optimization/40254 * gcc.dg/vect/pr40254.c: New test. 2009-05-26 Richard Guenther rguent...@suse.de PR middle-end/40252 * gcc.c-torture/compile/pr40252.c: New testcase. 2009-05-26 Dodji Seketeli do...@redhat.com 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 i...@il.ibm.com PR tree-optimization/40238 * gcc.dg/vect/pr40238.c: New test. 2009-05-24 Richard Guenther rguent...@suse.de 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
--- 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=gccview=revrev=148004 Log: 2009-05-30 H.J. Lu hongjiu...@intel.com Backport from mainline: 2009-05-28 Dodji Seketeli do...@redhat.com 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 i...@il.ibm.com PR tree-optimization/40254 * gcc.dg/vect/pr40254.c: New test. 2009-05-26 Richard Guenther rguent...@suse.de PR middle-end/40252 * gcc.c-torture/compile/pr40252.c: New testcase. 2009-05-26 Dodji Seketeli do...@redhat.com 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 i...@il.ibm.com PR tree-optimization/40238 * gcc.dg/vect/pr40238.c: New test. 2009-05-24 Richard Guenther rguent...@suse.de 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
--- 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=gccview=revrev=148004 Log: 2009-05-30 H.J. Lu hongjiu...@intel.com Backport from mainline: 2009-05-28 Dodji Seketeli do...@redhat.com 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 i...@il.ibm.com PR tree-optimization/40254 * gcc.dg/vect/pr40254.c: New test. 2009-05-26 Richard Guenther rguent...@suse.de PR middle-end/40252 * gcc.c-torture/compile/pr40252.c: New testcase. 2009-05-26 Dodji Seketeli do...@redhat.com 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 i...@il.ibm.com PR tree-optimization/40238 * gcc.dg/vect/pr40238.c: New test. 2009-05-24 Richard Guenther rguent...@suse.de 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
--- 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=gccview=revrev=148004 Log: 2009-05-30 H.J. Lu hongjiu...@intel.com Backport from mainline: 2009-05-28 Dodji Seketeli do...@redhat.com 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 i...@il.ibm.com PR tree-optimization/40254 * gcc.dg/vect/pr40254.c: New test. 2009-05-26 Richard Guenther rguent...@suse.de PR middle-end/40252 * gcc.c-torture/compile/pr40252.c: New testcase. 2009-05-26 Dodji Seketeli do...@redhat.com 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 i...@il.ibm.com PR tree-optimization/40238 * gcc.dg/vect/pr40238.c: New test. 2009-05-24 Richard Guenther rguent...@suse.de 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
--- 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
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()
{
testint x;
x.run();
return 0;
}
Compiler output:
||=== AutoBug01, Debug ===|
In member function 'testT testT::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
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()
{
testint x;
x.run_pass();
x.run_fail();
return 0;
}
Compiler output:
||=== AutoBug02, Debug ===|
In member function 'testT testT::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
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()
{
testint x;
testint* y;
return 0;
}
Compiler output:
||=== BraceInitBug01, Debug ===|
main.cpp||In constructor 'testT::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 'testT::test() [with T = int*]':|
main.cpp|11|instantiated from here|
main.cpp|3|error: cannot convert 'brace-enclosed initializer list()' from
type 'brace-enclosed initializer list' 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.
[ 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
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
--- 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=17937action=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.
--- 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
--- 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=17938action=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
--- 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.
--- 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
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.
--- 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.
--- 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.
--- 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 http://gnu.org/licenses/gpl.html 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 main+0:push %ebp 0x0040114e main+1:mov%esp,%ebp 0x00401150 main+3:and$0xfff0,%esp 0x00401153 main+6:sub$0x10,%esp 0x00401156 main+9:call 0x401210 __main 0x0040115b main+14: mov0xc(%ebp),%eax 0x0040115e main+17: mov%eax,0x4(%esp) 0x00401162 main+21: mov0x8(%ebp),%eax 0x00401165 main+24: mov%eax,(%esp) 0x00401168 main+27: call 0x402320 *__gfortran_set_args 0x0040116d main+32: movl $0x417b00,0x4(%esp) 0x00401175 main+40: movl $0x8,(%esp) 0x0040117c main+47: call 0x4023b0 *__gfortran_set_options 0x00401181 main+52: call 0x4010e0 MAIN__ 0x00401186 main+57: mov$0x0,%eax 0x0040118b main+62: leave 0x0040118c main+63: ret 0x0040118d main+64: nop 0x0040118e main+65: nop 0x0040118f main+66: 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
--- 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.
--- 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.
--- 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
--- 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
--- 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
--- 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.
--- 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
--- 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.
--- 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)
--- 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 target/35179] execs crash in shared lib destructor = do_global_dtors_aux
--- 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=17939action=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 http://gnu.org/licenses/gpl.html 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
--- 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
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
--- 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=17940action=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
--- 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
