[Bug rtl-optimization/46237] New: SPECint2006 403.gcc fails with -mzarch -m31
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46237 Summary: SPECint2006 403.gcc fails with -mzarch -m31 Product: gcc Version: 4.5.3 Status: UNCONFIRMED Severity: critical Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: kreb...@gcc.gnu.org The 403.gcc testcase throws an ICE when compiled with -m31 -mzarch. The seems to be that IRA does not handle HARD_REGNO_CALL_PART_CLOBBERED properly. Fix proposal: http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01851.html
[Bug rtl-optimization/46237] SPECint2006 403.gcc fails with -mzarch -m31
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46237 Andreas Krebbel krebbel at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Target||s390-ibm-linux Priority|P3 |P2 Host||s390-ibm-linux Known to fail||4.5.2, 4.6.0 Build||s390-ibm-linux
[Bug rtl-optimization/46238] New: s390x bootstrap problem: wrong code generated due to crossjumping
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46238 Summary: s390x bootstrap problem: wrong code generated due to crossjumping Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: kreb...@gcc.gnu.org collect2 gets miscompiled due to a bug in cfgcleanup. try_head_merge_bb moves an insn setting r2 over an insn clobbering that register. DCE removes the set afterwards. try_head_merge_bb doesn't notice due to wrong live info in the 'live_union' variable. Proposed fix: http://gcc.gnu.org/ml/gcc-patches/2010-10/msg02569.html
[Bug rtl-optimization/46238] s390x bootstrap problem: wrong code generated due to crossjumping
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46238 Andreas Krebbel krebbel at gcc dot gnu.org changed: What|Removed |Added Target||s390x-ibm-linux Priority|P3 |P2 CC||bernds at codesourcery dot ||com Host||s390x-ibm-linux Build||s390x-ibm-linux
[Bug c++/46221] huge number of c++ testsuite failures, libstdc++.so alias missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46221 Alan Modra amodra at gmail dot com changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #6 from Alan Modra amodra at gmail dot com 2010-10-30 08:35:46 UTC --- My regression hunt identified revision 165990 http://gcc.gnu.org/ml/gcc-patches/2010-10/msg02275.html
[Bug c++/46239] New: Shouldn't this be a compile time error?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46239
Summary: Shouldn't this be a compile time error?
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rahul.pa...@gmail.com
1 #include
2 long factorial(int arg=2);
3 int main() {
4 coutfactorial();
5 }
6 long factorial(int arg_number) {
7 return arg_number;
8 }
Output:
2
Notice line 2 and 6
Different name is given to argument in declaration and definition.
Also default value is provided in declaration (to a variable name which is not
present in definition) and not in definition.
Shouldn't this trigger some kind of compile error ?
Output of gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.3-4ubuntu5'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc
--enable-targets=all --disable-werror --with-arch-32=i486 --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)
[Bug fortran/46196] [OOP] gfortran compiles invalid generic TBP: dummy arguments are type compatible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46196 --- Comment #9 from janus at gcc dot gnu.org 2010-10-30 09:33:12 UTC --- (In reply to comment #8) I have successfully regtested the following patch Thanks. I also noticed that the fix for pr46067 use the asymmetry of gfc_compare_interfaces!-) Right. --- ../_clean/gcc/fortran/interface.c2010-10-27 23:47:20.0 +0200 +++ gcc/fortran/interface.c2010-10-29 10:55:07.0 +0200 @@ -445,16 +445,16 @@ gfc_compare_derived_types (gfc_symbol *d /* Make sure that link lists do not put this function into an endless recursive loop! */ if (!(dt1-ts.type == BT_DERIVED derived1 == dt1-ts.u.derived) - !(dt1-ts.type == BT_DERIVED derived1 == dt1-ts.u.derived) + !(dt2-ts.type == BT_DERIVED derived2 == dt2-ts.u.derived) gfc_compare_types (dt1-ts, dt2-ts) == 0) return 0; else if ((dt1-ts.type == BT_DERIVED derived1 == dt1-ts.u.derived) - !(dt1-ts.type == BT_DERIVED derived1 == dt1-ts.u.derived)) + !(dt2-ts.type == BT_DERIVED derived2 == dt2-ts.u.derived)) return 0; else if (!(dt1-ts.type == BT_DERIVED derived1 == dt1-ts.u.derived) - (dt1-ts.type == BT_DERIVED derived1 == dt1-ts.u.derived)) + (dt2-ts.type == BT_DERIVED derived2 == dt2-ts.u.derived)) return 0; Can we find any test case which is sensitive to this change? This has disturbed my bug collection for the following tests: AFAICS all of the error messages are correct. Thanks for checking.
[Bug c++/43453] Initialization of char array with string literal fails in mem-initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43453
--- Comment #3 from Johannes Schaub schaub-johannes at web dot de 2010-10-30
09:41:36 UTC ---
(In reply to comment #2)
(In reply to comment #1)
(In reply to comment #0)
Fails to compile, but should work:
struct A {
char x[4];
A():x(bug) { }
};
Error i get is:
main.cpp:3: error: array used as initializer
Why do you think it should work?
For example, the following equivalent code is invalid as well:
char x [4] (bug);
This code is equivalent and is valid. At least, I don't see the Standard
forbidding it. GCC is the only compiler I tested (comeau/edg, clang) that
rejects it.
I'm not actually sure anymore about the validity of this code. One can make a
point about the initializer not being a mere string literal.
At least the draft n3126 makes a difference of this, in that an initializer
like ({a, b, c}) is not regarded as a braced-init-list, but rather as a
parenthesized expression-list where the initializer list is handed as one
argument. So I'm unsure whether an initializer like `(foo)` should be
regarded as a string literal or not.
I think I will send an issue report about this.
[Bug c++/46239] Shouldn't this be a compile time error?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46239 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2010-10-30 10:59:01 UTC --- The names of parameters are only relevant in the definition, you can omit them completely in the declaration, or give them different names. It is an error to redeclare a default parameter, even with the same value. GCC is correct.
[Bug c++/46240] New: ice in maybe_register_def
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46240 Summary: ice in maybe_register_def Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: dcb...@hotmail.com I just tried to compile package octave-3.2.4 with the latest 4.6 snapshot 20101023 on a Fedora Linux box. The compiler said oct-norm.cc: In function 'VectorT dual_p(const VectorT, R, R) [with VectorT = Matrix, R = double]': oct-norm.cc:396:9: internal compiler error: in maybe_register_def, at tree-into-ssa.c:1875 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Source code attached. Flags -g -O3 required.
[Bug c++/46240] ice in maybe_register_def
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46240 --- Comment #1 from dcb dcb314 at hotmail dot com 2010-10-30 11:43:35 UTC --- Created attachment 22204 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22204 gzipped C++ source code
[Bug c++/32402] Error while allocating array of pointers to objects of a pure virtual class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32402
--- Comment #9 from Jonathan Wakely redi at gcc dot gnu.org 2010-10-30
11:46:47 UTC ---
As an extra data point, this compiles with -std=c++0x
struct pure;
void f()
{
pure (*arr[3]);
pure** p = new (decltype(arr));
delete[] p;
}
This shows that allocating an array of pure* is semantically OK, it's just a
bug in parsing or checking the new-expression.
[Bug fortran/46196] [OOP] gfortran compiles invalid generic TBP: dummy arguments are type compatible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46196 --- Comment #10 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-10-30 11:52:46 UTC --- Can we find any test case which is sensitive to this change? I di not find one in store!-( Am I correct to expect that such test will be of the reject valid kind? Clearly (dt1-ts.type == BT_DERIVED derived1 == dt1-ts.u.derived) !(dt1-ts.type == BT_DERIVED derived1 == dt1-ts.u.derived) is always false and the third test is the same. So these tests are just nops and the 'return 0' will never be reached. Then the if-else block reduces to if (!(dt1-ts.type == BT_DERIVED derived1 == dt1-ts.u.derived) gfc_compare_types (dt1-ts, dt2-ts) == 0) return 0; For this case we need a test with 'dt1-ts.type == BT_DERIVED' and 'dt1-ts.u.derived == derived1' and one of these conditions false for dt2. My understanding of the code is not good enough to reach a valid test from that (I don't know where derived* come from.
[Bug debug/46241] New: ice in dwarf2out.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46241 Summary: ice in dwarf2out.c Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: dcb...@hotmail.com Created attachment 22205 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22205 C++ source code I just tried to compile package supertuxkart-0.6.2 with the latest 4.6 snapshot 20101023 on a Fedora Linux box. The compiler said BulletCollision/CollisionDispatch/btCollisionWorld.cpp:659:1: internal compiler error: in dwarf2out_finish, at dwarf2out.c:22866 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Source code attached. Flag -g required.
[Bug middle-end/44569] Debug statements passed to rtx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44569 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|steven at gcc dot gnu.org |ubizjak at gmail dot com --- Comment #6 from Uros Bizjak ubizjak at gmail dot com 2010-10-30 12:49:07 UTC --- Created attachment 22206 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22206 Patch that fixes simplify_subreg_concatn simplify_subreg_concatn passes VOIDmode of const_int elements of (debug_insn 7 4 8 2 (var_location:V16QI vuchar (concatn:V16QI [ (const_int 1 [0x1]) (const_int 2 [0x2]) (const_int 3 [0x3]) (const_int 4 [0x4]) (const_int 1 [0x1]) (const_int 2 [0x2]) (const_int 3 [0x3]) (const_int 4 [0x4]) (const_int 1 [0x1]) (const_int 2 [0x2]) (const_int 3 [0x3]) (const_int 4 [0x4]) (const_int 1 [0x1]) (const_int 2 [0x2]) (const_int 3 [0x3]) (const_int 4 [0x4]) ])) vector-shift2.c:14 -1 (nil)) to simplify_gen_subreg as inner mode. So, in case of VOIDmode, just determine the mode of the elements by using GET_MODE_INNER of vector mode of concatn RTX.
[Bug fortran/46196] [OOP] gfortran compiles invalid generic TBP: dummy arguments are type compatible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46196 --- Comment #11 from Mikael Morin mikael at gcc dot gnu.org 2010-10-30 12:51:54 UTC --- Another bug, we don't check that components are non-null before entering the loop. module type_a type a sequence end type a end module type_a module type_a_bis type a sequence end type a end module type_a_bis use type_a use type_a_bis, only: b = a type(b) :: y call bar(y) contains subroutine bar (x) type(a) :: x end subroutine bar end PS: Dominique, you can start hacking with this testcase. gfc_compare_derived_types is called with it (when comparing type of `y' vs type of `x'). PS2: we will need a new PR in the end.
[Bug c++/46242] New: Segmentation fault in ipcp_driver
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46242 Summary: Segmentation fault in ipcp_driver Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: dcb...@hotmail.com Created attachment 22207 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22207 C++ source code I just tried to compile package sword-1.6.1 with the latest 4.6 snapshot 20101023 on a Fedora Linux box. The compiler said gbfidx.cpp: At global scope: gbfidx.cpp:305:1: internal compiler error: Segmentation fault valgrind says ==3149== Invalid read of size 2 ==3149==at 0xB0CE2E: ipcp_driver (ipa-cp.c:1292) ==3149==by 0x86658E: execute_one_pass (passes.c:1560) ==3149==by 0x866C69: execute_ipa_pass_list (passes.c:1927) ==3149==by 0xB09E37: cgraph_optimize (cgraphunit.c:1730) ==3149==by 0xB0A079: cgraph_finalize_compilation_unit (cgraphunit.c:1016) ==3149==by 0x53E9BC: cp_write_global_declarations (decl2.c:3936) ==3149==by 0x906EA7: toplev_main (toplev.c:931) ==3149==by 0x325FC1EC5C: (below main) (in /lib64/libc-2.12.so) ==3149== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==3149== Source code attached. Flag -O3 required.
[Bug c/46243] New: [4.6 Regression] expected tree that contains ‘decl minimal’ structure, have ‘tree_list’ in start_decl, at c-decl.c:4049
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46243
Summary: [4.6 Regression] expected tree that contains ‘decl
minimal’ structure, have ‘tree_list’ in start_decl, at
c-decl.c:4049
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bonz...@gnu.org
CC: froy...@gcc.gnu.org
I'm seeing the error on the following code:
void Y(Z); /* { dg-error error before } */
which is a modified version of gcc.dg/pr14963.c
pr14963.c:1:1: warning: parameter names (without types) in function declaration
[enabled by default]
pr14963.c:1:1: internal compiler error: tree check: expected tree that contains
‘decl minimal’ structure, have ‘tree_list’ in start_decl, at c-decl.c:4049
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug c/46243] [4.6 Regression] expected tree that contains ‘decl minimal’ structure, have ‘tree_list’ in start_decl, at c-decl.c:4049
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46243 Paolo Bonzini bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.10.30 13:06:26 Known to work||4.5.0 Ever Confirmed|0 |1 Known to fail||4.6.0
[Bug target/46195] r165965 regresses i386 darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46195 --- Comment #23 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2010-10-30 13:17:20 UTC --- Author: hjl Date: Sat Oct 30 13:17:15 2010 New Revision: 166088 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166088 Log: Align long double parameters on stack to 4byte in 32bit. 2010-10-30 H.J. Lu hongjiu...@intel.com PR target/46195 * config/i386/i386.c (contains_aligned_value_p): Renamed to ... (ix86_compat_aligned_value_p): This. (ix86_old_function_arg_boundary): Renamed to ... (ix86_compat_function_arg_boundary): This. Updated. (ix86_contains_aligned_value_p): New. (ix86_function_arg_boundary): Align long double parameters on stack to 4byte in 32bit. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c
[Bug target/46195] r165965 regresses i386 darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46195 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #24 from H.J. Lu hjl.tools at gmail dot com 2010-10-30 13:26:17 UTC --- Fixed.
[Bug middle-end/46242] Segmentation fault in ipcp_driver
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46242 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.10.30 13:35:59 Component|c++ |middle-end CC||jamborm at gcc dot gnu.org Ever Confirmed|0 |1 Target Milestone|--- |4.6.0 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2010-10-30 13:35:59 UTC --- It is caused by revision 162912: http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00123.html
[Bug fortran/44917] [OOP] Detect ambiguous specifics in a generic TBP interface
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44917 --- Comment #3 from janus at gcc dot gnu.org 2010-10-30 13:52:44 UTC --- Author: janus Date: Sat Oct 30 13:52:39 2010 New Revision: 166089 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166089 Log: 2010-10-30 Janus Weil ja...@gcc.gnu.org PR fortran/44917 PR fortran/44926 PR fortran/46196 * interface.c (count_types_test): Symmetrize type check. (generic_correspondence): Ditto. 2010-10-30 Janus Weil ja...@gcc.gnu.org PR fortran/44917 PR fortran/44926 PR fortran/46196 * gfortran.dg/typebound_generic_10.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/typebound_generic_10.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/46196] [OOP] gfortran compiles invalid generic TBP: dummy arguments are type compatible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46196 --- Comment #12 from janus at gcc dot gnu.org 2010-10-30 13:52:44 UTC --- Author: janus Date: Sat Oct 30 13:52:39 2010 New Revision: 166089 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166089 Log: 2010-10-30 Janus Weil ja...@gcc.gnu.org PR fortran/44917 PR fortran/44926 PR fortran/46196 * interface.c (count_types_test): Symmetrize type check. (generic_correspondence): Ditto. 2010-10-30 Janus Weil ja...@gcc.gnu.org PR fortran/44917 PR fortran/44926 PR fortran/46196 * gfortran.dg/typebound_generic_10.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/typebound_generic_10.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/44926] [OOP] Ambiguous interface not detected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44926 --- Comment #2 from janus at gcc dot gnu.org 2010-10-30 13:52:44 UTC --- Author: janus Date: Sat Oct 30 13:52:39 2010 New Revision: 166089 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166089 Log: 2010-10-30 Janus Weil ja...@gcc.gnu.org PR fortran/44917 PR fortran/44926 PR fortran/46196 * interface.c (count_types_test): Symmetrize type check. (generic_correspondence): Ditto. 2010-10-30 Janus Weil ja...@gcc.gnu.org PR fortran/44917 PR fortran/44926 PR fortran/46196 * gfortran.dg/typebound_generic_10.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/typebound_generic_10.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/44917] [OOP] Detect ambiguous specifics in a generic TBP interface
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44917 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org |gnu.org | --- Comment #4 from janus at gcc dot gnu.org 2010-10-30 13:55:27 UTC --- Fixed with r166089. Closing.
[Bug fortran/44926] [OOP] Ambiguous interface not detected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44926 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org |gnu.org | --- Comment #3 from janus at gcc dot gnu.org 2010-10-30 13:56:04 UTC --- Fixed with r166089. Closing.
[Bug bootstrap/46018] [4.6 Regression] Bootstrap fails on i386-pc-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46018 --- Comment #12 from H.J. Lu hjl.tools at gmail dot com 2010-10-30 13:59:08 UTC --- Please try: http://gcc.gnu.org/ml/gcc-patches/2010-10/msg02569.html
[Bug debug/46241] ice in dwarf2out.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46241 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.10.30 14:14:24 CC||rguenth at gcc dot gnu.org Target Milestone|--- |4.6.0 Ever Confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2010-10-30 14:14:24 UTC --- It is caused by revision 164719: http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg01018.html
[Bug middle-end/46240] ice in maybe_register_def
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46240 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.10.30 14:21:40 Component|c++ |middle-end CC||hubicka at gcc dot gnu.org Ever Confirmed|0 |1 Target Milestone|--- |4.6.0 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2010-10-30 14:21:40 UTC --- It is caused by revision 162842: http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00053.html
[Bug fortran/46244] New: gfc_compare_derived_types is buggy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46244 Summary: gfc_compare_derived_types is buggy Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org As noted by Dominique in PR 46196 comment #5, there is a problem in gfc_compare_derived_types (interface.c): --- ../_clean/gcc/fortran/interface.c2010-10-27 23:47:20.0 +0200 +++ gcc/fortran/interface.c2010-10-29 10:55:07.0 +0200 @@ -445,16 +445,16 @@ gfc_compare_derived_types (gfc_symbol *d /* Make sure that link lists do not put this function into an endless recursive loop! */ if (!(dt1-ts.type == BT_DERIVED derived1 == dt1-ts.u.derived) - !(dt1-ts.type == BT_DERIVED derived1 == dt1-ts.u.derived) + !(dt2-ts.type == BT_DERIVED derived2 == dt2-ts.u.derived) gfc_compare_types (dt1-ts, dt2-ts) == 0) return 0; else if ((dt1-ts.type == BT_DERIVED derived1 == dt1-ts.u.derived) - !(dt1-ts.type == BT_DERIVED derived1 == dt1-ts.u.derived)) + !(dt2-ts.type == BT_DERIVED derived2 == dt2-ts.u.derived)) return 0; else if (!(dt1-ts.type == BT_DERIVED derived1 == dt1-ts.u.derived) - (dt1-ts.type == BT_DERIVED derived1 == dt1-ts.u.derived)) + (dt2-ts.type == BT_DERIVED derived2 == dt2-ts.u.derived)) return 0; dt1 = dt1-next;
[Bug fortran/46244] gfc_compare_derived_types is buggy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46244 --- Comment #1 from janus at gcc dot gnu.org 2010-10-30 14:30:27 UTC --- Related test case by Mikael, resulting in a segfault (PR 46196 comment #11): module type_a type a sequence end type a end module type_a module type_a_bis type a sequence end type a end module type_a_bis use type_a use type_a_bis, only: b = a type(b) :: y call bar(y) contains subroutine bar (x) type(a) :: x end subroutine bar end
[Bug fortran/46196] [OOP] gfortran compiles invalid generic TBP: dummy arguments are type compatible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46196 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #13 from janus at gcc dot gnu.org 2010-10-30 14:31:49 UTC --- The original test case is fixed with r166089. The problem mentioned in comment #5 will be tracked by PR 46244.
[Bug fortran/46244] gfc_compare_derived_types is buggy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46244 --- Comment #2 from janus at gcc dot gnu.org 2010-10-30 14:54:49 UTC --- The buggy code in comment #0 is due to: http://gcc.gnu.org/viewcvs?view=revisionrevision=131238 http://gcc.gnu.org/viewcvs?view=revisionrevision=131239 When looking for a test case which is sensitive to the change, linked_list_1.f90 may be a good starting point.
[Bug fortran/46244] gfc_compare_derived_types is buggy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46244
--- Comment #3 from janus at gcc dot gnu.org 2010-10-30 15:04:29 UTC ---
The test case in comment #1 can be fixed by:
Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c (revision 166089)
+++ gcc/fortran/interface.c (working copy)
@@ -424,6 +424,11 @@ gfc_compare_derived_types (gfc_symbol *derived1, g
match. */
for (;;)
{
+ if (dt1 == NULL dt2 == NULL)
+ break;
+ if (dt1 == NULL || dt2 == NULL)
+ return 0;
+
if (strcmp (dt1-name, dt2-name) != 0)
return 0;
@@ -459,11 +464,6 @@ gfc_compare_derived_types (gfc_symbol *derived1, g
dt1 = dt1-next;
dt2 = dt2-next;
-
- if (dt1 == NULL dt2 == NULL)
- break;
- if (dt1 == NULL || dt2 == NULL)
- return 0;
}
return 1;
[Bug fortran/46244] gfc_compare_derived_types is buggy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46244
--- Comment #4 from janus at gcc dot gnu.org 2010-10-30 15:11:19 UTC ---
(In reply to comment #3)
The test case in comment #1 can be fixed by:
Or better:
Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c (revision 166089)
+++ gcc/fortran/interface.c (working copy)
@@ -422,8 +422,11 @@ gfc_compare_derived_types (gfc_symbol *derived1, g
/* Since subtypes of SEQUENCE types must be SEQUENCE types as well, a
simple test can speed things up. Otherwise, lots of things have to
match. */
- for (;;)
+ while (dt1 || dt2)
{
+ if (dt1 == NULL || dt2 == NULL)
+ return 0;
+
if (strcmp (dt1-name, dt2-name) != 0)
return 0;
@@ -459,11 +462,6 @@ gfc_compare_derived_types (gfc_symbol *derived1, g
dt1 = dt1-next;
dt2 = dt2-next;
-
- if (dt1 == NULL dt2 == NULL)
- break;
- if (dt1 == NULL || dt2 == NULL)
- return 0;
}
return 1;
[Bug tree-optimization/46228] code produced for STL container is worse in 4.5.1 than in 4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46228 --- Comment #7 from Jan Hubicka hubicka at gcc dot gnu.org 2010-10-30 15:41:11 UTC --- We predict main() as executed once, not cold, so code inside loop is inlined for speed at -O1/-O2/-O3, but this testcase is compiled with -Os. This seems like usual problem with comdat functions being possibly shared with other compilation units. I will check how -fwhole-program behaves and if I can do something with the heruistics here.
[Bug c++/46245] New: rejects function with late-specified return type as a non-type template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46245
Summary: rejects function with late-specified return type as a
non-type template parameter
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: schaub-johan...@web.de
GCC rejects the following:
templateauto f()-int struct A { };
error: parameter declared 'auto'
[Bug c/46243] [4.6 Regression] expected tree that contains ‘decl minimal’ structure, have ‘tree_list’ in start_decl, at c-decl.c:4049
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46243 Paolo Bonzini bonzini at gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug tree-optimization/46228] code produced for STL container is worse in 4.5.1 than in 4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46228 --- Comment #8 from Jan Hubicka hubicka at gcc dot gnu.org 2010-10-30 16:00:12 UTC --- and BTW -Os also reason why -finline-limits has no effect. As long as we predict code size to grow, we won't inline at -Os. We tend to regress at -Os C++ for this reason. I wonder what can be done about this. Either - we need to improve heuristics to figure out that inlining is smaller than call sequence (if it really is) - we need to teach GCC that comdat functions are not always shared across units as extensively as we tend to believe now. I will take more look tomorrow. Honza
[Bug fortran/46244] gfc_compare_derived_types is buggy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46244 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #5 from Mikael Morin mikael at gcc dot gnu.org 2010-10-30 16:02:27 UTC --- Another one, with mutually recursive types module type_a_b type a sequence type(b), pointer :: pb end type a type b sequence type(a), pointer :: pa end type b end module type_a_b module type_a_b_bis type a sequence type(b), pointer :: pb end type a type b sequence type(a), pointer :: pa end type b end module type_a_b_bis use type_a_b, only: a1 = a, b1 = b use type_a_b_bis, only: a2 = a, b2 = b type(a2) :: y call foo(y) contains subroutine foo(x) type(a1) :: x end subroutine foo end Infinite loop at compile time. I couldn't think of a sane person writing such code anyway.
[Bug fortran/46244] gfc_compare_derived_types is buggy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46244 --- Comment #6 from Mikael Morin mikael at gcc dot gnu.org 2010-10-30 16:03:58 UTC --- (In reply to comment #4) (In reply to comment #3) The test case in comment #1 can be fixed by: Or better: Pre-approved.
[Bug rtl-optimization/37272] [4.5 Regression] IRA has caused ppc64-double-1.c to fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37272 Paolo Bonzini bonzini at gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org Target Milestone|4.4.6 |4.5.2 Summary|[4.4/4.5/4.6 Regression]|[4.5 Regression] IRA has |IRA has caused |caused ppc64-double-1.c to |ppc64-double-1.c to fail|fail --- Comment #4 from Paolo Bonzini bonzini at gnu dot org 2010-10-30 16:07:15 UTC --- Still in http://gcc.gnu.org/ml/gcc-testresults/2010-10/msg02352.html (4.5.2) Not anymore in http://gcc.gnu.org/ml/gcc-testresults/2010-10/msg02388.html (4.4.6) http://gcc.gnu.org/ml/gcc-testresults/2010-10/msg02372.html (4.6.0)
[Bug c++/46246] New: [C++0x] Move constructor required when passing a temporary by copy, but not actually used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46246 Summary: [C++0x] Move constructor required when passing a temporary by copy, but not actually used Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: a.pigno...@sssup.it Created attachment 22208 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22208 test case that fails to compile The attached test case causes a compiler error, GCC seems to need the unavailable move constructor even if a
[Bug c++/46246] [C++0x] Move constructor required when passing a temporary by copy, but not actually used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46246 --- Comment #1 from Alessandro Pignotti a.pignotti at sssup dot it 2010-10-30 16:28:49 UTC --- Created attachment 22209 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22209 test case that shows that the move constructor is not actually used
[Bug c++/46246] [C++0x] Move constructor required when passing a temporary by copy, but not actually used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46246 --- Comment #2 from Alessandro Pignotti a.pignotti at sssup dot it 2010-10-30 16:31:27 UTC --- The secondo attachment compiles, but the move constructor seems not really used. The output is: default bar foo called Moreover i was expecting a call to the copy constructor but that was elided, is this an optimization or something mandated by the standard?
[Bug bootstrap/46018] [4.6 Regression] Bootstrap fails on i386-pc-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46018 --- Comment #13 from Art Haas ahaas at airmail dot net 2010-10-30 17:55:24 UTC --- The patch listed here did not help: http://gcc.gnu.org/ml/gcc-patches/2010-10/msg02569.html The boostrap build still fails: /home/ahaas/gnu/gcc.git/gcc/lto/lto-lang.c: In function 'lto_type_for_mode': /home/ahaas/gnu/gcc.git/gcc/lto/lto-lang.c:951:1: internal compiler error: in dwarf2out_frame_debug_adjust_cfa, at dwarf2out.c:1881
[Bug debug/46241] ice in dwarf2out.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46241 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2010-10-30 18:16:55 UTC --- Mine.
[Bug tree-optimization/46236] Local aggregate not eliminated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46236 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-10-30 18:20:48 UTC --- This is a dup of the PR that says we don't do aggregate copyprop.
[Bug rtl-optimization/46235] inefficient bittest code generation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46235 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-10-30 18:21:48 UTC --- We canonicalize a (1 x) to (a x) 1 very early.
[Bug middle-end/44569] Debug statements passed to rtx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44569 --- Comment #7 from uros at gcc dot gnu.org 2010-10-30 19:55:18 UTC --- Author: uros Date: Sat Oct 30 19:55:16 2010 New Revision: 166092 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166092 Log: PR middle-end/44569 * lower-suberg.c (simplify_subreg_concatn): For VOIDmode elements, determine the mode of a subreg by GET_MODE_INNER of CONCATN RTX. Modified: trunk/gcc/ChangeLog trunk/gcc/lower-subreg.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/46228] code produced for STL container is worse in 4.5.1 than in 4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46228 --- Comment #9 from Zeev Tarantov zeev.tarantov at gmail dot com 2010-10-30 20:05:57 UTC --- Using -fwhole-program I got sane code. But almost all programs that are not trivial cannot be compiled with -fwhole-program without LTO. At least on 4.5 branch LTO is not quite stable. - we need to improve heuristics to figure out that inlining is smaller than call sequence (if it really is) This would be great.
[Bug target/46153] [4.5/4.6 Regression] ICE: in extract_insn, at recog.c:2110 (unrecognizable insn) with -ffloat-store and __builtin_ia32_movlhps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46153 --- Comment #5 from uros at gcc dot gnu.org 2010-10-30 20:32:15 UTC --- Author: uros Date: Sat Oct 30 20:32:11 2010 New Revision: 166093 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166093 Log: PR target/46153 * config/i386/sse.md (sse_movhlps_exp): Use destination returned from ix86_fixup_binary_operands to expand insn. (sse_movlhps_exp): Ditto. (sse_loadhps_exp): Ditto. (sse_loadlps_exp): Ditto. (sse2_loadhpd_exp): Ditto. (sse2_loadlpd_exp): Ditto. testsuite/ChangeLog: PR target/46153 * gcc.target/i386/pr46153.c: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/pr46153.c - copied unchanged from r166031, trunk/gcc/testsuite/gcc.target/i386/pr46153.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/config/i386/sse.md branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
[Bug target/46153] [4.5/4.6 Regression] ICE: in extract_insn, at recog.c:2110 (unrecognizable insn) with -ffloat-store and __builtin_ia32_movlhps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46153 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Uros Bizjak ubizjak at gmail dot com 2010-10-30 20:33:40 UTC --- Fixed.
[Bug middle-end/44569] Debug statements passed to rtx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44569 --- Comment #8 from uros at gcc dot gnu.org 2010-10-30 20:37:57 UTC --- Author: uros Date: Sat Oct 30 20:37:54 2010 New Revision: 166094 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166094 Log: PR middle-end/44569 * lower-suberg.c (simplify_subreg_concatn): For VOIDmode elements, determine the mode of a subreg by GET_MODE_INNER of CONCATN RTX. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/lower-subreg.c
[Bug middle-end/44569] Debug statements passed to rtx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44569 --- Comment #9 from uros at gcc dot gnu.org 2010-10-30 20:50:16 UTC --- Author: uros Date: Sat Oct 30 20:50:12 2010 New Revision: 166095 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166095 Log: PR middle-end/44569 * lower-suberg.c (simplify_subreg_concatn): For VOIDmode elements, determine the mode of a subreg by GET_MODE_INNER of CONCATN RTX. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/lower-subreg.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
[Bug middle-end/44569] Debug statements passed to rtx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44569 --- Comment #10 from uros at gcc dot gnu.org 2010-10-30 20:55:07 UTC --- Author: uros Date: Sat Oct 30 20:55:03 2010 New Revision: 166096 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166096 Log: PR middle-end/44569 * lower-suberg.c (simplify_subreg_concatn): For VOIDmode elements, determine the mode of a subreg by GET_MODE_INNER of CONCATN RTX. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/lower-subreg.c
[Bug middle-end/44569] ICE in simplify_subreg for debug insn with CONCATN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44569 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Target|linux-gnu |x86_64-pc-linux-gnu Status|ASSIGNED|RESOLVED Version|unknown |4.6.0 URL||http://gcc.gnu.org/ml/gcc-p ||atches/2010-10/msg02627.htm ||l Host|host-x86_64-unknown |x86_64-pc-linux-gnu Resolution||FIXED Summary|Debug statements passed to |ICE in simplify_subreg for |rtx |debug insn with CONCATN Target Milestone|--- |4.3.6 Build|xgcc (GCC) 4.6.0 20100610 |x86_64-pc-linux-gnu |(experimental) | --- Comment #11 from Uros Bizjak ubizjak at gmail dot com 2010-10-30 21:01:35 UTC --- Fixed.
[Bug tree-optimization/46193] ICE: in omp_reduction_init, at omp-low.c:2212 with -ftree-parallelize-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46193 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.10.30 21:15:40 Ever Confirmed|0 |1 --- Comment #1 from Uros Bizjak ubizjak at gmail dot com 2010-10-30 21:15:40 UTC --- Confirmed with 4.6.0, backtrace: (gdb) bt #0 fancy_abort (file=0xd11c58 ../../gcc-svn/trunk/gcc/omp-low.c, line=2212, function=0xd138e0 omp_reduction_init) at ../../gcc-svn/trunk/gcc/diagnostic.c:880 #1 0x00708873 in omp_reduction_init (clause=value optimized out, type=0x72054930) at ../../gcc-svn/trunk/gcc/omp-low.c:2212 #2 0x0082a13a in initialize_reductions (slot=value optimized out, data=0x72036b28) at ../../gcc-svn/trunk/gcc/tree-parloops.c:415 #3 0x00c9c1d8 in htab_traverse_noresize (htab=value optimized out, callback=0x82a070 initialize_reductions, info=0x72036b28) at ../../gcc-svn/trunk/libiberty/hashtab.c:784 #4 0x0082c09e in gen_parallel_loop (loop=value optimized out, reduction_list=0x1389f00, n_threads=2, niter=value optimized out) at ../../gcc-svn/trunk/gcc/tree-parloops.c:1640 #5 0x0082d58b in parallelize_loops () at ../../gcc-svn/trunk/gcc/tree-parloops.c:1976 #6 0x008ae469 in tree_parallelize_loops () at ../../gcc-svn/trunk/gcc/tree-ssa-loop.c:589
[Bug tree-optimization/46193] ICE: in omp_reduction_init, at omp-low.c:2212 with -ftree-parallelize-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46193 --- Comment #2 from Uros Bizjak ubizjak at gmail dot com 2010-10-30 21:18:05 UTC --- We have pointer type that triggers assert: #1 0x00708873 in omp_reduction_init (clause=value optimized out, type=0x72054930) at ../../gcc-svn/trunk/gcc/omp-low.c:2212 2212 gcc_assert (INTEGRAL_TYPE_P (type)); (gdb) p debug_generic_expr (type) char * $1 = void
[Bug target/46247] New: bug with loading constant to neon quad register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46247
Summary: bug with loading constant to neon quad register
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.o...@rub.de
code:
++
#include stdint.h
#include string.h
#include stdio.h
#include arm_neon.h
void dbg_neon(uint32x4_t d, char* name){
uint32_t t[4];
int i;
*((uint32x4_t*)(t[0])) = d;
printf(\n %s debug \n, name);
for(i=0;i4;++i){
printf( %s[%2d] = %08X\n,name, i,t[i]);
}
}
int main(){
uint32x4_t qa0, qt0, qx0;
uint32_t t[8]={ 0x78797A63, 0x7C7D7E7F, 0xC0222022, 0x44454647 };
qt0 = (uint32x4_t){ 0, 0x, 0, 0x};
//qa0 = *((uint32x4_t*)(t[0]));
qa0 = vld1q_u32 ((t[0]));
qx0 = veorq_u32(qa0, qt0);
dbg_neon(qt0, qt0);
dbg_neon(qa0, qa0);
dbg_neon(qx0, qx0);
return 0;
}
++
output:
++
qt0 debug
qt0[ 0] =
qt0[ 1] =
qt0[ 2] =
qt0[ 3] =
qa0 debug
qa0[ 0] = 78797A63
qa0[ 1] = 7C7D7E7F
qa0[ 2] = C0222022
qa0[ 3] = 44454647
qx0 debug
qx0[ 0] = 78797A63
qx0[ 1] = 7C7D8180
qx0[ 2] = C0222022
qx0[ 3] = 4445B9B8
++
tested with the following gccs:
$ LC_ALL=C
~/infos/boxes/beagleboard/2010-10-29/usr/local/angstrom/arm/bin/arm-angstrom-linux-gnueabi-gcc
-v
Using built-in specs.
Target: arm-angstrom-linux-gnueabi
Configured with:
/OE/angstrom/build/tmp-angstrom_2008_1/work/i686-armv7a-sdk-angstrom-linux-gnueabi/gcc-cross-sdk-4.3.3-r17.2/gcc-4.3.3/configure
--build=i686-linux --host=i686-linux --target=arm-angstrom-linux-gnueabi
--prefix=/usr/local/angstrom/arm --exec_prefix=/usr/local/angstrom/arm
--bindir=/usr/local/angstrom/arm/bin --sbindir=/usr/local/angstrom/arm/bin
--libexecdir=/usr/local/angstrom/arm/libexec
--datadir=/usr/local/angstrom/arm/share
--sysconfdir=/usr/local/angstrom/arm/etc
--sharedstatedir=/usr/local/angstrom/arm/share/com
--localstatedir=/usr/local/angstrom/arm/var
--libdir=/usr/local/angstrom/arm/lib
--includedir=/usr/local/angstrom/arm/include
--oldincludedir=/usr/local/angstrom/arm/include
--infodir=/usr/local/angstrom/arm/share/info
--mandir=/usr/local/angstrom/arm/share/man --with-gnu-ld --enable-shared
--enable-languages=c,c++,objc,fortran --enable-threads=posix --disable-multilib
--enable-c99 --enable-long-long --enable-symvers=gnu --enable-libstdcxx-pch
--program-prefix=arm-angstrom-linux-gnueabi- --enable-target-optspace
--enable-cheaders=c_std --enable-libssp --disable-bootstrap --disable-libgomp
--disable-libmudflap
--with-sysroot=/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi
--with-build-time-tools=/OE/angstrom/build/tmp-angstrom_2008_1/sysroots/i686-linux/usr/armv7a/arm-angstrom-linux-gnueabi/bin
--with-build-sysroot=/OE/angstrom/build/tmp-angstrom_2008_1/sysroots/armv7a-angstrom-linux-gnueabi
--disable-libunwind-exceptions --disable-libssp --disable-libgomp
--disable-libmudflap
--with-mpfr=/OE/angstrom/build/tmp-angstrom_2008_1/sysroots/i686-linux/usr
--enable-__cxa_atexit
Thread model: posix
gcc version 4.3.3 (GCC)
$ LC_ALL=C arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/home/bg/sat/libexec/gcc/arm-none-eabi/4.5.1/lto-wrapper
Target: arm-none-eabi
Configured with: ../gcc-4.5.1/configure --target=arm-none-eabi
--prefix=/home/bg/sat --enable-interwork --enable-multilib
--enable-languages=c,c++ --with-newlib --disable-shared --with-gnu-as
--with-gnu-ld --disable-nls --disable-werror --with-system-zlib :
(reconfigured) ../gcc-4.5.1/configure --target=arm-none-eabi
--prefix=/home/bg/sat --enable-interwork --enable-multilib
--enable-languages=c,c++ --with-newlib --disable-shared --with-gnu-as
--with-gnu-ld --disable-nls --disable-werror --with-system-zlib
Thread model: single
gcc version 4.5.1 (GCC)
commandline:
$GCC -O2 -S -Wall -mcpu=cortex-a8 -mfloat-abi=softfp -mfpu=neon -static
gcc_bug.c
additional information:
does not happen with -O0 but with -O1, -O2 and -O3.
[Bug fortran/46152] [F03] ALLOCATE with type-spec fails for intrinsic types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46152 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #17 from kargl at gcc dot gnu.org 2010-10-31 03:34:35 UTC --- New patch that I plan to commit within 24 hours. http://gcc.gnu.org/ml/fortran/2010-10/msg00285.html
