[Bug middle-end/39943] [4.5 Regression] Failed SPEC CPU 2000
--- Comment #7 from dominiq at lps dot ens dot fr 2009-05-03 10:24 --- The test gcc.c-torture/compile/pr39943.c fails on powerpc-apple-darwin9.6, see http://gcc.gnu.org/ml/gcc-testresults/2009-05/msg00169.html: FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer (internal compiler error) FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer -funroll-loops (internal compiler error) FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (internal compiler error) FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gcc.c-torture/compile/pr39943.c -O3 -g (internal compiler error) FAIL: gcc.c-torture/compile/pr39943.c -O3 -g (test for excess errors) The failure is: [karma] f90/bug% gcc45 -O3 /opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr39943.c /opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr39943.c: In function 'gl_fog_index_pixels': /opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr39943.c:1: error: invalid conversion in gimple call vector unsigned int __vector signed int # .MEM_98 = VDEF <.MEM_97> vect_var_.47_88 = __builtin_altivec_vctuxs (vect_var_.46_87); /opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr39943.c:1: internal compiler error: verify_stmts failed -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39943
[Bug target/40009] altivec __builtin_vec_ctu has wrong tyes
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-03 11:06 --- Looking at rs6000.c likely many more builtins are affected. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40009
[Bug target/40009] altivec __builtin_vec_ctu has wrong tyes
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-03 11:12 --- Huh. It uses build_opaque_vector_type, but /* Nonzero in an IDENTIFIER_NODE if the name is a local alias, whose uses are to be substituted for uses of the TREE_CHAINed identifier. */ #define TYPE_VECTOR_OPAQUE(NODE) \ (VECTOR_TYPE_CHECK (NODE)->base.deprecated_flag) WTF?? It looks like frontend concept - see c-common.c:vector_targets_convertible_p. Why is this frontend specific when a _backend_ sets it? What semantics is it supposed to have - yeah well, proper documentation for the flag would have been a start... -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40009
[Bug target/40009] altivec __builtin_vec_ctu has wrong tyes
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-05-03 11:16 --- IMHO the frontend should, for TYPE_VECTOR_OPAQUE "conversions" emit VIEW_CONVERT_EXPRs to honour GIMPLE/GENERIC type system requirements. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40009
[Bug target/40009] New: altivec __builtin_vec_ctu has wrong tyes
It should have an unsigned vector result def_builtin (MASK_ALTIVEC, "__builtin_vec_ctu", opaque_ftype_opaque_int, ALTIVEC_BUILTIN_VEC_CTU); this casues FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer (internal compiler error) FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer -funroll-loops (internal compiler error) FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (internal compiler error) FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gcc.c-torture/compile/pr39943.c -O3 -g (internal compiler error) FAIL: gcc.c-torture/compile/pr39943.c -O3 -g (test for excess errors) The failure is: [karma] f90/bug% gcc45 -O3 /opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr39943.c /opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr39943.c: In function 'gl_fog_index_pixels': /opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr39943.c:1: error: invalid conversion in gimple call vector unsigned int __vector signed int # .MEM_98 = VDEF <.MEM_97> vect_var_.47_88 = __builtin_altivec_vctuxs (vect_var_.46_87); -- Summary: altivec __builtin_vec_ctu has wrong tyes Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org GCC target triplet: powerpc*-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40009
[Bug middle-end/39943] [4.5 Regression] Failed SPEC CPU 2000
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-05-03 11:06 --- Please do not clutter existing (closed) bugreports like this. -> PR40009. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39943
[Bug target/40009] altivec __builtin_vec_ctu has wrong tyes
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-05-03 11:18 --- For the case in question, vctuxs doesn't look like an instruction that has an opaque return type. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40009
[Bug fortran/36260] Audit intrinsic.texi and check whether keyword= names match
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-01-03 23:59:27 |2009-05-03 12:09:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36260
[Bug target/40009] altivec __builtin_vec_ctu has wrong tyes
--- Comment #5 from bonzini at gnu dot org 2009-05-03 12:11 --- In many cases, opaque types are used in the prototypes just to avoid warnings. You're right that the front-end should insert VIEW_CONVERT_EXPRs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40009
[Bug fortran/36260] Audit intrinsic.texi and check whether keyword= names match
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2009-05-03 12:37 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00076.html -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36260
[Bug fortran/38830] Document lack of "Variable Format Expression" support
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2009-05-03 12:40 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00077.html -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Keywords||patch Last reconfirmed|2009-03-29 08:44:26 |2009-05-03 12:40:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38830
[Bug fortran/36382] Support $ as first character in symbol names and in IMPLICT
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2009-05-03 12:52 --- Doc patch here: http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00078.html I am against allowing $ as first letter in identifiers, as there now are much better ways to do that (and it's not such a common practice anyway). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Keywords||documentation, patch Last reconfirmed|2009-03-28 13:58:14 |2009-05-03 12:52:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36382
[Bug target/40009] altivec __builtin_vec_ctu has wrong tyes
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-05-03 13:29 --- Ok, so the builtins should have a proper, but opaque vector type (like for VEC_CTU it should be an unsigned vector type, not a signed one). Thus, the TYPE_VECTOR_OPAQUE description should read like /* Nonzero in a VECTOR_TYPE if the frontends should not emit warnings about missing conversions to other vector types of the same size. */ #define TYPE_VECTOR_OPAQUE(NODE) \ (VECTOR_TYPE_CHECK (NODE)->base.deprecated_flag) ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40009
[Bug middle-end/23169] Fortran INTENT information not used in the middle-end for optimizations
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2009-05-03 13:32 --- (In reply to comment #11) > The original testcase in #0 appears to be fixed if compiled with -fwhole-file. > Andrew's comment #4 appears to be still an issue?! Here's a full testcase showing the remaining issue: integer function foo() interface integer function bar(b) integer, intent(in) :: b end function end interface integer :: b, d, k b = 12 d = b k = bar(b) foo = d - b end function In this code, the return value of function foo should not be computed, because it's guaranteed to be 0. The missed optimization is still present. This is something that the middle-end should be taught to honour, so I'm switching the component to middle-end. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Component|fortran |middle-end Last reconfirmed|2006-01-08 05:22:43 |2009-05-03 13:32:52 date|| Summary|INTENT information not used |Fortran INTENT information |in the middle-end for |not used in the middle-end |optimizations |for optimizations http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23169
[Bug fortran/30668] -fwhole-file should catch function of wrong type
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2009-05-03 13:53 --- I guess -fwhole-file should catch this one, but it does not. The testcase I used is: integer function two() two = 2 end function two program xx ! real, external :: two print *, two(), kind(two()) end program xx You can comment or uncomment the line with "external", both versions should be caught. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||pault at gcc dot gnu dot org Severity|enhancement |minor Last reconfirmed|2007-03-18 17:53:03 |2009-05-03 13:53:02 date|| Summary|catch function of wrong type|-fwhole-file should catch ||function of wrong type http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30668
[Bug target/40009] altivec __builtin_vec_ctu has wrong tyes
--- Comment #7 from bonzini at gnu dot org 2009-05-03 14:00 --- > Ok, so the builtins should have a proper, but opaque vector type (like for > VEC_CTU it should be an unsigned vector type, not a signed one). No, there's no reason to have >1 opaque vector type for a single mode (or even for a single width). BTW, the opaque vector types were actually invented for SPE, and only later recycled for the implementation of Altivec. > Nonzero in a VECTOR_TYPE if the frontends should not emit warnings > about missing conversions to other vector types of the same size. Yes, will commit a patch to change it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40009
[Bug target/40009] altivec __builtin_vec_ctu has wrong tyes
--- Comment #8 from bonzini at gnu dot org 2009-05-03 14:25 --- What's remaining was already in the database. *** This bug has been marked as a duplicate of 30210 *** -- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40009
[Bug target/30210] Altivec builtins have inaccurate return types
--- Comment #9 from bonzini at gnu dot org 2009-05-03 14:25 --- *** Bug 40009 has been marked as a duplicate of this bug. *** -- bonzini at gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30210
[Bug target/30210] Altivec builtins have inaccurate return types
--- Comment #10 from bonzini at gnu dot org 2009-05-03 14:26 --- The wrong types in __builtin_altivec_ctu cause this: FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer (internal compiler error) FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer -funroll-loops (internal compiler error) FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (internal compiler error) FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gcc.c-torture/compile/pr39943.c -O3 -g (internal compiler error) FAIL: gcc.c-torture/compile/pr39943.c -O3 -g (test for excess errors) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30210
[Bug target/40009] altivec __builtin_vec_ctu has wrong tyes
--- Comment #9 from bonzini at gnu dot org 2009-05-03 14:34 --- To be more specific, the builtin call is created by the vectorizer, and the vectorizer is quite careless in matching types. The front-end *does* insert VIEW_CONVERT_EXPRs and so does rs6000-c.c. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40009
[Bug target/30210] Altivec builtins have inaccurate return types
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-05-03 15:54 --- And as there is _builtin_altivec_cts in addition to _builtin_altivec_ctu these builtins should better have correct types from the start. In fact they look more constrained than "opaque" anyway - so why are they using opaque arguments / return types at all? Not an enhancement, wrong-code in the middle-end sense. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|enhancement |normal Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30210
[Bug tree-optimization/22372] Vectorizer produces mis-match types
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-05-03 15:56 --- *** This bug has been marked as a duplicate of 30210 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22372
[Bug target/30210] Altivec builtins have inaccurate return types
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-05-03 15:56 --- *** Bug 22372 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30210
[Bug target/30210] [4.5 Regression] Altivec builtins have inaccurate return types
--- Comment #13 from rguenth at gcc dot gnu dot org 2009-05-03 15:57 --- And now "causing" regressions with type checking enabled. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|Altivec builtins have |[4.5 Regression] Altivec |inaccurate return types |builtins have inaccurate ||return types Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30210
[Bug middle-end/22370] Vec lower produces mis-match types
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-05-03 15:59 --- Seems to be fixed at least in 4.5. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22370
[Bug tree-optimization/22373] loop linear produces type mis-match
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-03 16:01 --- Seems to work with 4.5. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22373
[Bug c/23145] struct {int i;} is not compatiable with struct {int i,j}
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-05-03 16:04 --- With --combine? It indeed doesn't complain. But I also don't see type mismatches with type checking. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23145
[Bug tree-optimization/23166] SCCP causes type mismatch
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-05-03 16:05 --- Fixed at least with 4.5. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23166
[Bug tree-optimization/23347] PRE produces type mismatch in PHIs when compiling java from bytecode
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-05-03 16:06 --- It is supposedly fixed as we can bootstrap libjava with type checking enabled. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23347
[Bug middle-end/25269] gcc.target/x86_64/abi/test_passing_unions.c fails with some type mismatches
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-03 16:07 --- Works for me. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25269
[Bug tree-optimization/28721] SRA vs Ada and type mismatches
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-03 16:07 --- Works for me. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28721
[Bug middle-end/28723] Fortran vs Inliner creates mismatch types
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-03 16:08 --- Works for me. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28723
[Bug tree-optimization/23329] hack in may_propagate_copy should be able to removed
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-05-03 16:13 --- Mine. I have a patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-07-09 05:20:06 |2009-05-03 16:13:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23329
[Bug libfortran/22423] Warnings when building libgfortran
--- Comment #16 from fxcoudert at gcc dot gnu dot org 2009-05-03 16:28
---
Many new warnings:
../../../trunk/libgfortran/runtime/string.c: In function compare0:
../../../trunk/libgfortran/runtime/string.c:39: warning: comparison between
signed and unsigned integer expressions
Fixed by:
Index: runtime/string.c
===
--- runtime/string.c(revision 147057)
+++ runtime/string.c(working copy)
@@ -36,7 +36,10 @@
/* Strip trailing blanks from the Fortran string. */
len = fstrlen (s1, s1_len);
- if (len != strlen(s2)) return 0; /* don't match */
+
+ if ((size_t) len != strlen(s2))
+return 0; /* don't match */
+
return strncasecmp (s1, s2, len) == 0;
}
../../../trunk/libgfortran/io/transfer.c: In function read_block_direct:
../../../trunk/libgfortran/io/transfer.c:468: warning: comparison between
signed and unsigned integer expressions
Fixed by:
Index: io/transfer.c
===
--- io/transfer.c (revision 147057)
+++ io/transfer.c (working copy)
@@ -465,7 +465,7 @@
/* Check whether we exceed the total record length. */
if (dtp->u.p.current_unit->flags.has_recl
- && (nbytes > dtp->u.p.current_unit->bytes_left))
+ && ((gfc_offset) nbytes > dtp->u.p.current_unit->bytes_left))
{
to_read_record = dtp->u.p.current_unit->bytes_left;
short_record = 1;
../../../trunk/libgfortran/io/list_read.c: In function nml_read_obj:
../../../trunk/libgfortran/io/list_read.c:2464: warning: comparison between
bt and enum
../../../trunk/libgfortran/io/list_read.c: In function nml_get_obj_data:
../../../trunk/libgfortran/io/list_read.c:2712: warning: comparison between
bt and enum
../../../trunk/libgfortran/io/list_read.c:2734: warning: comparison between
bt and enum
../../../trunk/libgfortran/io/list_read.c:2768: warning: comparison between
bt and enum
../../../trunk/libgfortran/io/write.c: In function nml_write_obj:
../../../trunk/libgfortran/io/write.c:1261: warning: comparison between bt
and enum
../../../trunk/libgfortran/io/write.c:1339: warning: comparison between bt
and enum
All these come from the use of two different enums for one purpose: the bt enum
in libgfortran/io/io.h and the anonymous enum containing GFC_DTYPE_UNKNOWN,
GFC_DTYPE_INTEGER and friends in gcc/fortran/libgfortran.h. I'm not sure at all
why there are two different enums, why their constants are sometimes used as if
they were interchangeable (all the warnings above come from such uses), but
what I know is that they shouldn't: the constants don't even come in the same
order!
Compare:
GFC_DTYPE_UNKNOWN = 0,
GFC_DTYPE_INTEGER,
GFC_DTYPE_LOGICAL,
GFC_DTYPE_REAL,
GFC_DTYPE_COMPLEX,
GFC_DTYPE_DERIVED,
GFC_DTYPE_CHARACTER
with
BT_NULL, /* ok, null and unknown are close enough */
BT_INTEGER,
BT_LOGICAL,
BT_CHARACTER, /* oops */
BT_REAL, /* re-oops */
BT_COMPLEX /* final oops */
/* and where is "derived"? */
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Last reconfirmed|2007-10-18 13:22:40 |2009-05-03 16:28:50
date||
Version|4.0.2 |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22423
[Bug c/23145] struct {int i;} is not compatiable with struct {int i,j}
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-05-03 16:38 --- Even if you don't see the ICE, the code is still invalid as mentioned. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Last reconfirmed|2005-11-08 03:29:23 |2009-05-03 16:38:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23145
[Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
--- Comment #4 from pault at gcc dot gnu dot org 2009-05-03 17:14 --- (In reply to comment #3) > with gfortran -c -O0 --param ggc-min-heapsize=320 CP2K_2009-05-01.f90 > things compile file (and need some 6Gb of memory). > Joost, Do you have any idea of what change to g2k might have caused this? Even with no optimization, it brings my Core 2 Quad to a complete halt. The fact that it is garbage handling is worrying and maybe indicates that it may be something other than the fortran frontend. Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
[Bug other/40010] New: Parallel make issue when building man pages
The gcc manpage is not always created due to a dependency missing for gcc.pod in gcc/Makefile.in. invoke.texi depends upon gcc-vers.texi being generated, but no such dependency is listed. This was found by 6vvetjsrt26xsrzlh1z0zn4d2gr...@gmail.com in https://bugs.gentoo.org/show_bug.cgi?id=256608 I'm attaching a patch by him which fixes this issue. -- Summary: Parallel make issue when building man pages Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: halcy0n at gentoo dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40010
[Bug other/40010] Parallel make issue when building man pages
--- Comment #1 from halcy0n at gentoo dot org 2009-05-03 17:43 --- Created an attachment (id=17793) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17793&action=view) gcc-pod-missing-dependency -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40010
[Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-05-03 17:52 --- Does it work if you increase the default stack limit? ulimit -s unlimited -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
[Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
--- Comment #6 from jv244 at cam dot ac dot uk 2009-05-03 18:59 --- (In reply to comment #4) > Do you have any idea of what change to g2k might have caused this? Even with > no optimization, it brings my Core 2 Quad to a complete halt. The fact that it > is garbage handling is worrying and maybe indicates that it may be something > other than the fortran frontend. No idea what change in CP2K could have triggered this. I have been using a similar test based on CP2K_2007_06, and that thus not seem to trigger this error. I think it is a front-end issue, as it definitely still has not yet finished writing the .mod files. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
[Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
--- Comment #7 from jv244 at cam dot ac dot uk 2009-05-03 19:14 --- (In reply to comment #5) > Does it work if you increase the default stack limit? ulimit -s unlimited trunk does indeed pass with ulimit -s and 4.4.0 as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
[Bug libfortran/22423] Warnings when building libgfortran
--- Comment #17 from jvdelisle at gcc dot gnu dot org 2009-05-03 19:29 --- There is a warning in list_read.c left over from the big IO patch that was merged in. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22423
[Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-05-03 19:37 --- This is not a new problem - our recursive GC manages to do this in some cases. What helps sometimes is to adjust the way structures are linked to avoid too deep recursion. Maybe the GFortran FE trees are not optimized for that? Thus, the question is what are we recursing on here? type.next_variant if my sources are matching yours (look at gt-fortran-f95-lang.h:337). What type do we have so many variants of? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
[Bug target/39975] Support big endian ARM by default.
--- Comment #1 from mikpe at it dot uu dot se 2009-05-03 19:39 --- (In reply to comment #0) > Create a default configuration that honours big endian ARM by default. PR31938 > refers to this. Looks like a dupe of PR16350. And most of the de-facto standard patch people have been applying to get this support is in gcc-4.3. But see comment #22 in PR16350 for a missing hunk (MULTILIB_DEFAULTS should also use TARGET_ENDIAN_OPTION and not hard-code "mlittle-endian"). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39975
[Bug rtl-optimization/39914] [4.4 Regression] 96% performance regression in floating point code; part of the problem started 2009/03/12-13
--- Comment #15 from uros at gcc dot gnu dot org 2009-05-03 19:40 --- Subject: Bug 39914 Author: uros Date: Sun May 3 19:40:35 2009 New Revision: 147081 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147081 Log: Backport from mainline: 2009-04-28 Uros Bizjak PR rtl-optimization/39914 * ira-conflicts.c (ira_build_conflicts): Prohibit call used registers for allocnos created from user-defined variables only when not optimizing. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/ira-conflicts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39914
[Bug rtl-optimization/39914] [4.4 Regression] 96% performance regression in floating point code; part of the problem started 2009/03/12-13
--- Comment #16 from ubizjak at gmail dot com 2009-05-03 19:41 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39914
[Bug fortran/40011] New: Problems with -fwhole-file
Summary of the problems with -fwhole-file I have found so far.
>From http://gcc.gnu.org/ml/fortran/2009-03/msg00310.html:
(1) From a first look the several "Segmentation fault" are coming from
recursive functions, the simplest code being the following:
[ibook-dhum] f90/bug% cat recurs_test_1.f90
! { dg-do compile }
RECURSIVE FUNCTION eval_args(q) result (r)
INTEGER NNODE
PARAMETER (NNODE = 10)
TYPE NODE
SEQUENCE
INTEGER car
INTEGER cdr
END TYPE NODE
TYPE(NODE) heap(NNODE)
INTEGER r, q
r = eval_args(heap(q)%cdr)
END FUNCTION eval_args
[ibook-dhum] f90/bug% gfc -c -fwhole-file recurs_test_1.f90
gfc: Internal error: Segmentation fault (program f951)
Please submit a full bug report.
See for instructions.
(2) I have also an ICE (already reported in PR26227
http://gcc.gnu.org/ml/gcc-bugs/2009-03/msg02321.html) for
[ibook-dhum] f90/bug% cat arr_fun.f90
function test(n)
real, dimension(2) :: test
integer:: n
test = n
! print *, test
return
end function test
program arr
real, dimension(2) :: res
res = test(2)
print *, res
end program
[ibook-dhum] f90/bug% gfc -fwhole-file arr_fun.f90
arr_fun.f90: In function 'arr':
arr_fun.f90:8: internal compiler error: in fold_convert, at fold-const.c:2547
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
(3) And I think the following are false positives:
[ibook-dhum] f90/bug% cat specifics_red_4.f90
subroutine test_d(fn, val, res)
double precision fn
double precision val, res
print *, fn(val), res
end subroutine
subroutine test_c(fn, val, res)
complex fn
complex val, res
print *, fn(val), res
end subroutine
program specifics
intrinsic dcos
intrinsic dcosh
intrinsic dexp
intrinsic conjg
call test_d (dcos, 1d0, dcos(1d0))
call test_d (dcosh, 1d0, dcosh(1d0))
call test_d (dexp, 1d0, dexp(1d0))
call test_c (conjg, (1.0,1.0) , conjg((1.0,1.0)))
end program
[ibook-dhum] f90/bug% gfc -fwhole-file specifics_red_4.f90
specifics_red_4.f90:25.15:
call test_d (dcos, 1d0, dcos(1d0))
1
Error: Type/rank mismatch in argument 'fn' at (1)
specifics_red_4.f90:26.15:
call test_d (dcosh, 1d0, dcosh(1d0))
1
Error: Type/rank mismatch in argument 'fn' at (1)
specifics_red_4.f90:27.15:
call test_d (dexp, 1d0, dexp(1d0))
1
Error: Type/rank mismatch in argument 'fn' at (1)
specifics_red_4.f90:29.15:
call test_c (conjg, (1.0,1.0) , conjg((1.0,1.0)))
1
Error: Type/rank mismatch in argument 'fn' at (1)
>From http://gcc.gnu.org/ml/fortran/2009-03/msg00316.html
Your patch fixes some Segmentation faults (a couple), but not this one:
! { dg-do compile }
program test
interface
function bad_stuff(n)
integer :: bad_stuff (2)
integer :: n(2)
end function bad_stuff
recursive function rec_stuff(n) result (tmp)
integer :: n(2), tmp(2)
end function rec_stuff
end interface
integer :: res(2)
res = bad_stuff((/-19,-30/))
end program test
recursive function bad_stuff(n)
integer :: bad_stuff (2)
integer :: n(2), tmp(2), ent = 0, sent = 0
save ent, sent
ent = -1
entry rec_stuff(n) result (tmp)
if (ent == -1) then
sent = ent
ent = 0
end if
ent = ent + 1
tmp = 1
if(maxval (n) < 5) then
tmp = tmp + rec_stuff (n+1)
ent = ent - 1
endif
if (ent == 1) then
if (sent == -1) then
bad_stuff = tmp + bad_stuff (1)
end if
ent = 0
sent = 0
end if
end function bad_stuff
>From http://gcc.gnu.org/ml/fortran/2009-03/msg00317.html
A simpler test:
recursive function fac(i) result (res)
integer :: i, j, k, res
k = 1
goto 100
entry bifac(i,j) result (res)
k = j
100 continue
if (i < k) then
res = 1
else
res = i * bifac(i-k,k)
end if
end function
program test
external fac
external bifac
integer :: fac, bifac
print *, fac(5)
print *, bifac(5,2)
print*, fac(6)
print *, bifac(6,2)
print*, fac(0)
print *, bifac(1,2)
end program test
>From http://gcc.gnu.org/ml/fortran/2009-04/msg00031.html
some ICEs on the polyhedron test suite (see also pr39896):
[ibook-dhum] lin/test% gfc -fwhole-file aermod.f90
f951: internal compiler error: Bus error
[ibook-dhum] lin/test% gfc -fwhole-file air.f90
f951: internal compiler error: Bus error
[ibook-dhum] lin/test
[Bug target/10242] [ARM] subsequent use of plus and minus operators could be improved
--- Comment #7 from mikpe at it dot uu dot se 2009-05-03 19:53 --- (In reply to comment #6) > Created an attachment (id=17475) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17475&action=view) [edit] > Proposed fix -- will commit after trunk reopens Ping, trunk is open now, no? I've been using this proposed fix in my gcc-4.3.4 based compiler for more than a month now without ill effects. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10242
[Bug tree-optimization/23329] hack in may_propagate_copy should be able to removed
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-05-03 19:56 --- Subject: Bug 23329 Author: rguenth Date: Sun May 3 19:55:55 2009 New Revision: 147082 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147082 Log: 2009-05-03 Richard Guenther PR middle-end/23329 * tree-ssa.c (useless_type_conversion_p_1): Use get_deref_alias_set. Do not lose casts from array types with unknown extent to array types with known extent. * tree-ssa-copy.c (may_propagate_copy): Remove hack checking for alias set compatibility. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-copy.c trunk/gcc/tree-ssa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23329
[Bug c/39983] ICE: type mismatch in address expression
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-05-03 19:57 --- Subject: Bug 39983 Author: rguenth Date: Sun May 3 19:57:32 2009 New Revision: 147083 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147083 Log: 2009-05-03 Richard Guenther PR c/39983 * c-typeck.c (array_to_pointer_conversion): Do not built ADDR_EXPRs of arrays of pointer-to-element type. * c-gimplify.c (c_gimplify_expr): Revert change fixing up wrong ADDR_EXPRs after-the-fact. * c-common.c (strict_aliasing_warning): Strip pointer conversions for obtaining the original type. * builtins.c (fold_builtin_memset): Handle array types. (fold_builtin_memory_op): Handle folded POINTER_PLUS_EXPRs and array types * gcc.c-torture/compile/pr39983.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr39983.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/c-common.c trunk/gcc/c-gimplify.c trunk/gcc/c-typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39983
[Bug c/39983] ICE: type mismatch in address expression
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-05-03 19:57 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39983
[Bug tree-optimization/23329] hack in may_propagate_copy should be able to removed
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-05-03 19:58 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23329
[Bug target/26463] -O2, -O3, -Os segment fault due to bad array index on ARM
--- Comment #4 from mikpe at it dot uu dot se 2009-05-03 20:05 --- (In reply to comment #3) > Comment #2 indicates that there isn't a problem with a 4.x series compiler . > I'd like some feedback if this problem exists today with a more recent version > of the compiler. I can't reproduce the problem with either gcc-4.3.4 20090405 or gcc-4.4.1 20090428 on an armv5tel-unknown-linux-gnueabi system. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26463
[Bug debug/40012] New: Bad debug info for local variables
Given the attached program compiled with gcc -ggdb3 -o dlmod dlmod.i the DW_AT_location for the variable 'problem' seems to be off by 16 bytes, so when I try to examine the variable from the debugger that returns the wrong value. Below is some information about my compiler: svnversion reports that I am using revision 147075. $ gcc --version --verbose Using built-in specs. gcc (GCC) 4.5.0 20090503 (experimental) Copyright (C) 2009 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Target: i686-pc-linux-gnu Configured with: ../trunk/configure --enable-languages=c,c++ --prefix=/usr/local /gcc-head --enable-shared --with-system-zlib --without-included-gettext --enable -threads --disable-nls --enable-__cxa_atexit --enable-clocale=gnu --enable-libst dcxx-debug --with-arch=core2 --with-tune=core2 --enable-checking=release --enabl e-concept-checks --disable-libgomp --disable-libmudflap --disable-libssp Thread model: posix -- Summary: Bad debug info for local variables Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gcc at magfr dot user dot lysator dot liu dot se GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40012
[Bug debug/40012] Bad debug info for local variables
--- Comment #1 from gcc at magfr dot user dot lysator dot liu dot se 2009-05-03 22:05 --- Created an attachment (id=17794) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17794&action=view) Test case demonstrating the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40012
[Bug c++/40013] New: [4.4 regression] ICE when creating a local array with size from the return value of a member function of an object in a nested class in a template class
I get an ICE when compiling this code using GCC 4.4 from svn:
template class TestClass {
public:
struct Subclass { struct { int c() {return 0;} } b; };
void test();
};
template void TestClass::test() {
Subclass a;
int d[a.b.c()];
}
int main() {
TestClass that;
that.test();
}
goff...@asplode tmp % g++ -v testcase.cpp -o testcase --save-temps
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.4.1_pre/work/gcc-4.4.1-/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.4.1-pre
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.1-pre/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.1-pre
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.1-pre/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.1-pre/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.1-pre/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-fixed-point --enable-nls --without-included-gettext
--with-system-zlib --disable-checking --disable-werror --enable-secureplt
--enable-multilib --enable-libmudflap --disable-libssp --enable-libgomp
--enable-cld --disable-libgcj --enable-languages=c,c++,fortran --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo SVN' --with-ppl
--with-cloog
Thread model: posix
gcc version 4.4.1-pre built 20090502 (prerelease) rev. 147067 (Gentoo SVN)
COLLECT_GCC_OPTIONS='-v' '-o' 'testcase' '-save-temps' '-shared-libgcc'
'-mtune=generic'
/usr/libexec/gcc/x86_64-pc-linux-gnu/4.4.1-pre/cc1plus -E -quiet -v
-D_GNU_SOURCE testcase.cpp -mtune=generic -fpch-preprocess -o testcase.ii
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.1-pre/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.1-pre/include/g++-v4
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.1-pre/include/g++-v4/x86_64-pc-linux-gnu
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.1-pre/include/g++-v4/backward
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.1-pre/include
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.1-pre/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-o' 'testcase' '-save-temps' '-shared-libgcc'
'-mtune=generic'
/usr/libexec/gcc/x86_64-pc-linux-gnu/4.4.1-pre/cc1plus -fpreprocessed
testcase.ii -quiet -dumpbase testcase.cpp -mtune=generic -auxbase testcase
-version -o testcase.s
GNU C++ (Gentoo SVN) version 4.4.1-pre built 20090502 (prerelease) rev.
147067 (x86_64-pc-linux-gnu)
compiled by GNU C version 4.4.1-pre built 20090502 (prerelease)
rev. 147067, GMP version 4.3.0, MPFR version 2.4.1-p5.
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128109
Compiler executable checksum: 0168ca3d6bfe22e6160ea49ab7a5ec7b
testcase.cpp: In member function âvoid TestClass::test() [with I =
char]â:
testcase.cpp:12: instantiated from here
testcase.cpp:8: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug bootstrap/40014] New: GGC build on Solaris 8 system fails
Hi I tried to build GCC 4.4.0 on my Solaris 8 system. Output from "uname -a": "SunOS catnip.eecg 5.8 Generic_117350-61 sun4u sparc SUNW,Sun-Blade-1500 I used GCC 3.4.6 for the build. The build compiled fine for about 4 hours then I received the following error: configure: error: GNU Fortran is not working; please report a bug in http://gcc.gnu.org/bugzilla, attaching /local/s rc/gcc/obj_solaris/obj_4.4.0/sparc-sun-solaris2.8/libgfortran/config.log gmake[1]: *** [configure-target-libgfortran] Error 1 I used the following commands for the build. The same commands worked fine when building GCC 3.4.6. --- setenv LD_LIBRARY_PATH /local/lib /local/src/gcc/gcc-4.4.0/configure --prefix=/local/gcc/gcc-4.4.0 --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --with-libiconv-prefix=/local gmake MAKE=gmake LDFLAGS="-L/local/lib -R/local/lib" bootstrap --- I tried to add on the "config.log" top this description but it was rejected because of the number of lines. How do I add an attachment of the "config.log" file on the bugzilla web page? -thanks peterp Dept. of Computer and Electrical Eng. 10 King's College Rd., University of Toronto, Toronto, Ontario CANADA M5S 3G4 Peter Pereira pet...@eecg.utoronto.ca -- Summary: GGC build on Solaris 8 system fails Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: peterp at eecg dot utoronto dot ca http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40014
[Bug target/38570] [arm] -mthumb generates sub-optimal prolog/epilog
--- Comment #6 from carrot at google dot com 2009-05-04 02:21 --- We can compute the maximum possible function length first. If the length is not large enough far jump is not necessary, and we can do this optimization safely. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38570
[Bug middle-end/39973] [4.5 Regression] Revision 146817 miscompiled 416.gamess in SPEC CPU 2006
--- Comment #2 from hjl dot tools at gmail dot com 2009-05-04 03:30 --- It is reproducible with test data, -i test. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39973
[Bug middle-end/40015] New: [4.5.0 Regression] Revision 147083 failed gfortran.dg/array_memcpy_4.f90
Revision 147083: http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00057.html triggered: FAIL: gfortran.dg/array_memcpy_4.f90 -O scan-tree-dump-times original "d = " 1 -- Summary: [4.5.0 Regression] Revision 147083 failed gfortran.dg/array_memcpy_4.f90 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=40015
[Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
--- Comment #9 from jv244 at cam dot ac dot uk 2009-05-04 04:39 --- (In reply to comment #8) > Thus, the question is what are we recursing on here? type.next_variant > if my sources are matching yours (look at gt-fortran-f95-lang.h:337). gt_ggc_m_9tree_node ((*x).generic.type.next_variant); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
[Bug middle-end/40015] [4.5.0 Regression] Revision 147083 failed gfortran.dg/array_memcpy_4.f90
--- Comment #1 from hp at gcc dot gnu dot org 2009-05-04 05:54 --- Seen for cris-elf too... -- hp at gcc dot gnu dot org changed: What|Removed |Added CC||hp at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-04 05:54:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40015
[Bug libgomp/39939] MinGW 4.3.0 fails to link sample programme.
--- Comment #13 from julian1844 at yahoo dot com 2009-05-04 06:23 --- (In reply to comment #12) Should I conclude that the MinGW site is now www.equation.com? > (In reply to comment #11) > > (In reply to comment #9, comment #10) > > I did not build MinGW 4.3.0. I got it from the official MinGW site > > (gcc-4.3.0-20080502-mingw32-alpha). I have also found that on > > www.equation.com > > there are even newer versions (binaries), like 4.3.3 with OpenMP 2.5, 4.4.0 > > with OpenMP 3.0 and MinGW 4.5 compilation snapshot. They seem to work fine > > with > > OpenMP. > > Its a shame that www.equation.com doesn't tell us how to obtain their source > code for the gcc, gdb ands make binaries. > > > > They aren't present on the official MinGW site. Why? > > No one has had put them there. > Danny > > > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39939
[Bug middle-end/40015] [4.5.0 Regression] Revision 147083 failed gfortran.dg/array_memcpy_4.f90
--- Comment #2 from dominiq at lps dot ens dot fr 2009-05-04 06:30 ---
Confirmed on i686-apple-darwin9, array_memcpy_4.f90.003t.original is
MAIN__ ()
{
struct t d[5];
struct t s[5];
static integer(kind=4) options.0[8] = {68, 255, 0, 0, 0, 1, 0, 1};
_gfortran_set_options (8, (void *) &options.0);
(void) __builtin_memcpy ((void *) &d, (void *) &s, 60);
}
and does not depend on the optimization level.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40015
[Bug middle-end/40015] [4.5.0 Regression] Revision 147083 failed gfortran.dg/array_memcpy_4.f90
--- Comment #3 from dominiq at lps dot ens dot fr 2009-05-04 06:32 ---
At revision 147065 I get:
MAIN__ ()
{
struct t d[5];
struct t s[5];
static integer(kind=4) options.0[8] = {68, 255, 0, 0, 0, 1, 0, 1};
_gfortran_set_options (8, (void *) &options.0);
d = VIEW_CONVERT_EXPR(s);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40015
[Bug c/29186] optimzation breaks floating point exception flag reading
--- Comment #20 from kreckel at ginac dot de 2009-05-04 06:47 --- So, Joseph explained that the code should execute as expected, at least with -frounding-math as a workaround. However, with GCC 4.4 it is still not possible to write code that takes advantage of those advanced features of IEEE754, even on hardware that supports it directly. Could someone, please, set this bug's status to something less inappropriate than "unconfirmed"? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186
