[Bug fortran/34546] New: Incorrect array identified in out of bounds runtime error
I think this one's a bit bizarre. (But then again, which bugs aren't? ;-) $ cat is isotope* isotope.f90 [EMAIL PROTECTED] Bug9]$ cat isotope.f90 program fred implicit none integer,parameter::NoJmax=6000 integer,parameter::MaxTotalJ=100 integer,parameter::ER=14513 real,parameter::EnergyFactor=1.5 real(kind=8),dimension(ER:nint(EnergyFactor*ER),6)::pT real(kind=8),dimension(0:MaxTotalJ,0:NoJmax,6)::JTEJ integer::JJ,E JTEJ=1 pT=2 write(*,*)ER JJ=0 E=2000 write(*,*)size(JTEJ(JJ,E,:)) write(*,*)size(pT(E,:)) write(10,*)JJ,E,real(JTEJ(JJ,E,:)) write(10,*)JJ,E,real(JTEJ(JJ,E,:)*pT(E,:)) end $ gfortran --version GNU Fortran (GCC) 4.3.0 20071109 (experimental) Copyright (C) 2007 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING $ gfortran -Wall -W -Wtabs -g -fbounds-check -O -o isotope isotope.f90 $ ./isotope 14513 6 6 At line 23 of file isotope.f90 Fortran runtime error: Array reference out of bounds for array 'jtej', lower bound of dimension 1 exceeded(2000 < 14513) Yes, it's bad code. But what's with the bounds of pT being projected onto JTEJ? (Of course, apologies if it's been fixed since November!) -- Summary: Incorrect array identified in out of bounds runtime error Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: terry at chem dot gu dot se GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34546
[Bug fortran/34545] ICE when compiling Fortran 95 code
--- Comment #6 from dfranke at gcc dot gnu dot org 2007-12-21 09:47 --- I can not reproduce the valgrind error, but ... > module blk1_mod > implicit none > integer :: numclusters = 2 > end module blk1_mod ... the ICE goes away if 'numclusters' is defined as a parameter. Further reduced testcase: module blk1_mod implicit none integer :: numclusters = 2 end module blk1_mod module kmeans_aux implicit none contains function get_nfirst( ) result(fnres) use blk1_mod, only: numclusters implicit none real :: fnres(numclusters) end function get_nfirst end module kmeans_aux program kmeans_driver use blk1_mod use kmeans_aux implicit none integer, allocatable :: nfirst(:) allocate(nfirst(1:numclusters)) nfirst(1:numclusters) = get_nfirst( ) end program kmeans_driver -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34545
[Bug fortran/34546] Incorrect array identified in out of bounds runtime error
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-12-21 10:10 --- Confirmed. Reduced testcase: $> cat pr34546.f90 program fred implicit none real :: JTEJ(0:100,0:6000,6) = 1.0 real :: pT(1:2, 6) = 2.0 write(*,*) JTEJ(0,1000,:) * pT(1000,:) end $> fortran-svn -g -Wall -fbounds-check pr34546.f90 && ./a.out At line 6 of file pr34546.f90 Fortran runtime error: Array reference out of bounds for array 'jtej', lower bound of dimension 1 exceeded(1000 < 1) -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC host triplet|x86_64-unknown-linux-gnu| Known to fail||4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-12-21 10:10:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34546
[Bug fortran/34547] New: NULL(): Fortran 2003 changes, accepts invalid, ICE on invalid
The following gives an ICE: print *, NULL() The program is invalid as the MOLD of NULL([MOLD]) is required in this context (see F2003, 13.7.88): "If MOLD is absent, the characteristics of the result are determined by the entity with which the reference is associated. See Table 13.1. MOLD shall not be absent in any other context." Table 13.1 contains: rhs of pointer assignment; initialization of an object in a declaration; default component init; struct constr; actual argument; in a DATA statement. Likewise for Fortran 97, see 7.1.4.1 around Table 7.2 - and 13.14.79. - integer, allocatable :: i(:) print *, NULL(i) Prints: Error: 'mold' argument of 'null' intrinsic at (1) must be a POINTER. While Fortran 97 has: "MOLD shall be a pointer and may be of any type." Fortran 2003 has: "MOLD shall be a pointer or allocatable. It may be of any type or may be a procedure pointer". NULL as actual argument: external foo call foo(NULL()) is invalid without a MOLD as (F2003, similar in F97): "If any type parameters of the contextual entity are deferred, those type parameters of the result are deferred. If any type parameters of the contextual entity are assumed, MOLD shall be present. If the context of the reference to NULL is an actual argument to a generic procedure, MOLD shall be present if the type, type parameters, or rank is required to resolve the generic reference. MOLD shall also be present if the reference appears as an actual argument corresponding to a dummy argument with assumed character length." --- Someone could also check whether we do the right thing for: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/5a1e0cc2c7eb95cc/ -- Summary: NULL(): Fortran 2003 changes, accepts invalid, ICE on invalid Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code, rejects-valid, accepts-invalid, diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34547
[Bug fortran/34387] FAIL: gfortran.dg/optional_dim_2.f90
--- Comment #6 from rsandifo at gcc dot gnu dot org 2007-12-21 11:06 --- FWIW, this also fails on mips-linux-gnu (or at least mips64-linux-gnu -mabi=32, which should be the same thing). The problem is that cshift0's target-independent function type says that the SHIFT and DIM arguments are integers, rather than pointers to integers. So on this target, we say that the DIM argument is an 8-byte integer rather than a 4-byte pointer to an 8-byte integer. Richard -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added CC||rsandifo at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34387
[Bug fortran/34536] Make support of 2.0**-3*5 tighter: Print warning by default
--- Comment #5 from dfranke at gcc dot gnu dot org 2007-12-21 11:09 --- Added a default warning and errors on -std=f*. Currently regtesting. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-12-20 14:23:04 |2007-12-21 11:09:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34536
[Bug fortran/34532] Doc error or rej.valid vendor extension: Integer as logical in IF expressions
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-12-21 13:01 ---
Index: gfortran.texi
===
--- gfortran.texi (revision 131109)
+++ gfortran.texi (working copy)
@@ -1165,12 +1165,17 @@ zero, and @code{.TRUE.} is interpreted a
@code{.FALSE.} and any nonzero value is interpreted as @code{.TRUE.}.
@smallexample
- INTEGER :: i = 1
- IF (i) PRINT *, 'True'
+LOGICAL :: l
+l = 1
[EMAIL PROTECTED] smallexample
[EMAIL PROTECTED]
+INTEGER :: i
+i = .TRUE.
@end smallexample
-However, there is no implicit conversion of @code{LOGICAL} and
[EMAIL PROTECTED] values performed during I/O operations.
+However, there is no implicit conversion of @code{INTEGER} values in
[EMAIL PROTECTED], nor of @code{LOGICAL} or @code{INTEGER} values
+in I/O operations.
@node Hollerith constants support
@section Hollerith constants support
Ok?
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
CC||dfranke at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34532
[Bug fortran/34545] ICE when compiling Fortran 95 code
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34545
[Bug target/20366] AIX g++ -D_LARGE_FILES fails to compile #include
--- Comment #10 from dje at watson dot ibm dot com 2007-12-21 14:58 --- Subject: Re: AIX g++ -D_LARGE_FILES fails to compile #include > Why is this? -D_LARGE_FILES simply enables LFS. xlC works with and without > -D_LARGE_FILES. Shouldn't G++ work as effectively as xlC? You are mixing multiple questions and issues. -D_LARGE_FILES redefines all I/O functions to use the 64-bit versions. xlC has its own system header files. G++ needs to use the AIX system header files with changes from fixincludes, combined with libstdc++ header files that perform their own redefinitions. "Shouldn't G++ work as effectively..." is a business question, not a technical question. Many major AIX customers use GCC, but none have told IBM that they will not buy a system unless GCC works better. That sets investment priorities. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20366
[Bug fortran/34514] Accepts invalid: Dimensions specified for N after initialisation
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-12-21 14:06 --- Patch looks good to me. Adding DATA-statements to the mashup leads to ICEs (PR24978), so this is taken care of ;) Assigned PR to Tobias and added patch URL. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||12/msg00821.html Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34514
[Bug testsuite/29071] gcc.dg/20020919-1.c compilation test fails on powerpc-apple-darwin8 at -m64
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2007-12-21 15:11 --- I just noticed that passing -D__powerpc64__ on the compile line for this test at -m64 for powerpc-apple-darwin9 allows the missed clobbers seem to be detected. Shouldn't... # ifndef __powerpc64__ # define REG3 "8" # define REG4 "9" # endif in the gcc.dg/20020919-1.c testcase be rewritten to also include those definitions when __powerpc__ and __LP64__ are both defined? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29071
[Bug fortran/34421] ENTRY functions: Character with different stringlength not rejected
--- Comment #1 from burnus at gcc dot gnu dot org 2007-12-21 14:12 --- Patch: http://gcc.gnu.org/ml/fortran/2007-12/msg00238.html (I really miss the patch tracker!) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34421
[Bug fortran/34514] Accepts invalid: Dimensions specified for N after initialisation
--- Comment #2 from burnus at gcc dot gnu dot org 2007-12-21 14:00 --- One-week-old, unreviewed patch: http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00821.html Error messages for your example: dimension :: n(3) 1 Error: Dimensions specified for n at (1) after its initialisation aaa.f90:3.17: parameter (n = 42) 1 Error: Initializing already initialized variable at (1) aaa.f90:1.12: integer :: n = 4 1 Error: Function 'n' at (1) cannot have an initializer aaa.f90:1.12: integer :: n = 4 1 Error: 'n' at (1) is not a VALUE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34514
[Bug fortran/34514] Accepts invalid: Dimensions specified for N after initialisation
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-12-21 13:45 --- This seems to be a more general problem: $> cat pr34514.f90 integer :: n = 4 dimension :: n(3) parameter (n = 42) print *, n(2) end $> gfortran-svn -g -Wall pr34514.f90 && ./a.out 42 -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-12-21 13:45:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34514
[Bug fortran/34514] Accepts invalid: Dimensions specified for N after initialisation
--- Comment #4 from dominiq at lps dot ens dot fr 2007-12-21 15:04 --- With the patch in http://gcc.gnu.org/ml/fortran/2007-12/msg00221.html, the test case #1 gives: pr34514.f90:2.14: dimension :: n(3) 1 Error: Dimensions specified for n at (1) after its initialisation pr34514.f90:3.17: parameter (n = 42) 1 Error: Initializing already initialized variable at (1) pr34514.f90:1.12: integer :: n = 4 1 Error: Function 'n' at (1) cannot have an initializer pr34514.f90:1.12: integer :: n = 4 1 Error: 'n' at (1) is not a VALUE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34514
[Bug testsuite/29071] gcc.dg/20020919-1.c compilation test fails on powerpc-apple-darwin8 at -m64
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2007-12-21 15:46 --- Wouldn't something like... --- 20020919-1.c.org2007-12-21 10:28:40.0 -0500 +++ 20020919-1.c2007-12-21 10:44:27.0 -0500 @@ -41,7 +41,9 @@ || defined (__POWERPC__) || defined (PPC) || defined (_IBMR2) # define REG1 "6" # define REG2 "7" -# ifndef __powerpc64__ +# if !defined(__powerpc64__) && !((defined (__powerpc__) || defined (__PPC__) \ +|| defined (__ppc__) || defined (__POWERPC__) || defined (PPC) \ +|| defined (_IBMR2)) && defined(__LP64__)) # define REG3 "8" # define REG4 "9" # endif be more correct here? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29071
[Bug rtl-optimization/34529] [4.1/4.2/4.3 Regression] Wrong code with altivec stores and offsets
--- Comment #7 from dje at gcc dot gnu dot org 2007-12-21 14:36 --- When reload converts the offset address to an indexed address, it re-uses the same register to which the global variable symbol was assigned. -- dje at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-12-21 14:36:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34529
[Bug regression/34548] New: GCC generates too many alignment adds for alloca
WRT http://gbenson.livejournal.com/2007/12/21/ GCC is being overzealous because of a default that was local to one file was made global on 2003-10-07, and this changed the behavior of the #if statement in explow.c's allocate_dynamic_stack_space(): #if defined (STACK_DYNAMIC_OFFSET) || defined (STACK_POINTER_OFFSET) #define MUST_ALIGN 1 #else #define MUST_ALIGN (PREFERRED_STACK_BOUNDARY < BIGGEST_ALIGNMENT) #endif Unfortunately, STACK_POINTER_OFFSET isn't a preprocessor constant on all ports. We could change the above to: #if defined (STACK_DYNAMIC_OFFSET) #define MUST_ALIGN 1 #else #define MUST_ALIGN (STACK_POINTER_OFFSET || PREFERRED_STACK_BOUNDARY < BIGGEST_ALIGNMENT) #endif but on at least one port (pa), STACK_POINTER_OFFSET depends on the size of the outgoing arguments of a function, which we don't necessarily know yet at the point we expand alloca builtins. For pa, it's never zero, but for other ports it might be, and then this would break. BTW, function.c still provides a no-longer-necessary default for STACK_POINTER_OFFSET. -- Summary: GCC generates too many alignment adds for alloca Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aoliva at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34548
[Bug fortran/24978] ICE in gfc_assign_data_value_range
-- dfranke at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|dfranke at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24978
[Bug fortran/24978] ICE in gfc_assign_data_value_range
--- Comment #13 from dfranke at gcc dot gnu dot org 2007-12-21 17:41 --- Created an attachment (id=14804) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14804&action=view) set of valid testcases -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24978
[Bug fortran/24978] ICE in gfc_assign_data_value_range
--- Comment #12 from dfranke at gcc dot gnu dot org 2007-12-21 17:40 --- Getting rid of the ICEs does not seem to be too difficult. Unfortunately, internal reworking seems to be necessary to actually solve every aspect of this PR. I will attach two sets of testcases; a list of valid DATA-statements and a list of invalid ones. Neither list claims to be exhaustive, however, they might be useful for anyone going to tackle this. Some notes: * the invalid testcases sport at least three different ICEs, two asserts in data.c (gfc_assign_data_value,gfc_assign_data_value_range) and one deep down (middle-end/back-end?) in varasm.c. I assume that the latter one will go away as soon as the splay-tree look ups are fixed for all the testcases, no additional investigation necessary. * DATA statements are handled in inverse ordering to their specification. For me it helped a lot to get them in native ordering, i.e. by declaration. * resolve.c (resolve_data_variables) states: "[...] data lists should only be resolved once." -- they seem to be resolved twice. To be seen in integer :: b(3) data b(-2) / 1 / end where the out-of-bounds warning is printed twice. * out-of-bounds checks need to be errors for DATA-statements Unassigning myself. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24978
[Bug fortran/24978] ICE in gfc_assign_data_value_range
--- Comment #14 from dfranke at gcc dot gnu dot org 2007-12-21 17:41 --- Created an attachment (id=14805) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14805&action=view) set of invalid testcases -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24978
[Bug target/31897] [4.3 Regression] 30% speed regression with -m32 on Opteron with rnflow
--- Comment #8 from ubizjak at gmail dot com 2007-12-21 18:57 --- Confirmed on K8 at http://gcc.gnu.org/ml/gcc-patches/2007-12/msg01042.html -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords|missed-optimization | Last reconfirmed|-00-00 00:00:00 |2007-12-21 18:57:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31897
[Bug testsuite/33082] [4.3 Regression] Revision 127491 causes FAIL: gcc.dg/dfp/convert-bfp-fold.c (test for excess errors)
--- Comment #6 from ubizjak at gmail dot com 2007-12-21 19:26 --- *** Bug 31625 has been marked as a duplicate of this bug. *** -- ubizjak at gmail dot com changed: What|Removed |Added CC||janis at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33082
[Bug tree-optimization/31625] [4.3 Regression] decimal float comparison after conversion no longer folded
--- Comment #1 from ubizjak at gmail dot com 2007-12-21 19:26 --- *** This bug has been marked as a duplicate of 33082 *** -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31625
[Bug target/20366] AIX g++ -D_LARGE_FILES fails to compile #include
--- Comment #11 from bugzilla-gcc at thewrittenword dot com 2007-12-21 19:14 --- (In reply to comment #10) > Subject: Re: AIX g++ -D_LARGE_FILES fails to compile #include > > xlC has its own system header files. G++ needs to use the AIX > system header files with changes from fixincludes, combined with libstdc++ > header files that perform their own redefinitions. Agreed. So, all that's left is for someone to do the work. I forgot about the libstdc++ headers that would need to change. We're going to try and have someone here work on this in the next 1-2 months as we're getting bitten by this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20366
[Bug libfortran/34540] [4.3 Regression] cshift, eoshift, kind=1 and kind=2 arguments...
--- Comment #2 from tkoenig at gcc dot gnu dot org 2007-12-21 19:49 --- The problem is with dim. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34540
[Bug libfortran/34540] [4.3 Regression] cshift, eoshift, kind=1 and kind=2 arguments...
--- Comment #3 from tkoenig at gcc dot gnu dot org 2007-12-21 20:56 ---
The problem is with the lines
if (dim->expr_type != EXPR_CONSTANT)
{
/* Mark this for later setting the type in gfc_conv_missing_dummy.
*/
dim->representation.length = shift->ts.kind;
}
else
{
gfc_resolve_dim_arg (dim);
/* Convert dim to shift's kind to reduce variations. */
if (dim->ts.kind != shift->ts.kind)
gfc_convert_type_warn (dim, &shift->ts, 2, 0);
}
For the test case, we take the first branch, which means we never
adjust dim's kind.
Jerry, you did some work in this area. I'mm CC: ing you on
this in case this rings a bell.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34540
[Bug middle-end/24306] [4.0 Regression] va_arg gets confused when skipping over certain zero-sized types with -msse
--- Comment #13 from howarth at nitro dot med dot uc dot edu 2007-12-21 20:45 --- Reversing the change... http://gcc.gnu.org/viewcvs/trunk/gcc/builtins.c?r1=108629&r2=108854&pathrev=108854 reduces the failures at -m64 on powerpc-apple-darwin9 from... Running /sw/src/fink.build/gcc43-4.2.999-20071219/gcc-4.3-20071219/gcc/testsuite/gcc.dg/compat/struct-layout-1.exp ... FAIL: tmpdir-gcc.dg-struct-layout-1/t001 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t003 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t005 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t006 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t008 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t016 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t024 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t026 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t028 c_compat_x_tst.o-c_compat_y_tst.o execute ...to... Running /sw/src/fink.build/gcc43-4.2.999-20071219/gcc-4.3-20071219/gcc/testsuite/gcc.dg/compat/struct-layout-1.exp ... FAIL: tmpdir-gcc.dg-struct-layout-1/t003 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t005 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t008 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t016 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t026 c_compat_x_tst.o-c_compat_y_tst.o execute -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24306
[Bug fortran/34549] New: cshifting by a real value
This is quite amusing (and also, presumably, easy to fix :-) $ cat cshift-real.f90 program main implicit none real, dimension(2,2) :: r data r /1.0, 2.0, 3.0, 4.0/ print *,cshift(r,shift=2.3,dim=1) end program main $ gfortran cshift-real.f90 $ We get the expected error message for eoshift. -- Summary: cshifting by a real value Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34549
[Bug fortran/34438] gfortran not compliant w.r.t default initialization of derived type component and implicit SAVE attribute
--- Comment #9 from pault at gcc dot gnu dot org 2007-12-21 21:20 --- Subject: Bug 34438 Author: pault Date: Fri Dec 21 21:20:38 2007 New Revision: 131124 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131124 Log: 2007-12-21 Paul Thomas <[EMAIL PROTECTED]> PR fortran/34438 * trans-decl.c (gfc_finish_var_decl): Do not mark derived types with default initializers as TREE_STATIC unless they are in the main program scope. (gfc_get_symbol_decl): Pass derived types with a default initializer to gfc_defer_symbol_init. (init_default_dt): Apply default initializer to a derived type. (init_intent_out_dt): Call init_default_dt. (gfc_trans_deferred_vars): Ditto. * module.c (read_module): Check sym->module is there before using it in a string comparison. 2007-12-21 Paul Thomas <[EMAIL PROTECTED]> PR fortran/34438 * gfortran.dg/default_initialization_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/default_initialization_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34438
[Bug target/8835] [mcore-elf] bootstrap ICE at expr.c:2771
--- Comment #20 from rask at gcc dot gnu dot org 2007-12-21 21:56 --- Fixed as of revision 131125 on mainline and not a 4.1/4.2 regression. -- rask at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.3.0 | Known to work||4.3.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8835
[Bug libfortran/34540] [4.3 Regression] cshift, eoshift, kind=1 and kind=2 arguments...
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-12-21 21:07 --- Yes, this is my doing in fixing PR33317. I will look at it tonight. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2007-12-20 21:16:21 |2007-12-21 21:07:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34540
[Bug fortran/34549] cshifting by a real value
-- tkoenig at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-12-21 21:07:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34549
[Bug fortran/34549] cshifting by a real value
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-12-21 21:39 --- > (and also, presumably, easy to fix :-) check.c (gfc_check_cshift): /* TODO: more requirements on shift parameter. */ Who knows? :) -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34549
[Bug target/8835] [mcore-elf] bootstrap ICE at expr.c:2771
--- Comment #19 from rask at gcc dot gnu dot org 2007-12-21 21:53 --- Subject: Bug 8835 Author: rask Date: Fri Dec 21 21:53:23 2007 New Revision: 131125 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131125 Log: 2007-12-13 Andrew Pinski <[EMAIL PROTECTED]> Rask Ingemann Lambertsen <[EMAIL PROTECTED]> PR target/8835 * config/mcore/mcore.c (mcore_function_value): Call promote_mode instead of PROMOTE_MODE. testsuite/ 2007-12-13 Kazu Hirata <[EMAIL PROTECTED]> PR target/8835 * gcc.dg/pr8835-1.c: New. Added: trunk/gcc/testsuite/gcc.dg/pr8835-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/mcore/mcore.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8835
[Bug c++/34550] reference data template args appear to be broken in 4.2.1 ?
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-21 22:27 ---
You forgot "const" in the second template.
Changing that to:
template < class T, const int & R >
Cat < T, R > :: Cat ( int )
{
}
Allows for this to work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34550
[Bug target/34210] ffs builtin calls undefined __ffshi2
--- Comment #3 from rask at gcc dot gnu dot org 2007-12-21 22:20 --- You want something like this in libgcc/config/avr/t-avr to get the 16-bit versions: # Extra 16-bit integer functions. intfuncs16 = _absvXX2 _addvXX3 _subvXX3 _mulvXX3 _negvXX2 _ffsXX2 _clzXX2 \ _ctzXX2 _popcountXX2 hiintfuncs16 = $(subst XX,hi,$(intfuncs16)) siintfuncs16 = $(subst XX,si,$(intfuncs16)) iter-items := $(hiintfuncs16) iter-labels := $(siintfuncs16) iter-sizes := $(patsubst %,2,$(siintfuncs16)) $(patsubst %,2,$(hiintfuncs16)) include $(srcdir)/empty.mk $(patsubst %,$(srcdir)/siditi-object.mk,$(iter-items)) libgcc-objects += $(patsubst %,%$(objext),$(hiintfuncs16)) ifeq ($(enable_shared),yes) libgcc-s-objects += $(patsubst %,%_s$(objext),$(hiintfuncs16)) endif -- rask at gcc dot gnu dot org changed: What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34210
[Bug c++/34551] FAIL: g++.dg/overload/arg[14].C (test for errors ...)
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-21 22:57 --- Should have been fixed by: http://gcc.gnu.org/ml/gcc-cvs/2007-12/msg00567.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34551
[Bug c++/34551] New: FAIL: g++.dg/overload/arg[14].C (test for errors ...)
Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/g++/../../g++ -B/test/gnu/ gcc/objdir/gcc/testsuite/g++/../../ /test/gnu/gcc/gcc/gcc/testsuite/g++.dg/overl oad/arg1.C -nostdinc++ -I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/ include/hppa64-hp-hpux11.11 -I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++ -v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/test/gnu/gcc/gcc/libst dc++-v3/include/backward -I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessa ge-length=0 -std=c++98 -fno-show-column -S -o arg1.s(timeout = 300) FAIL: g++.dg/overload/arg1.C (test for errors, line 14) FAIL: g++.dg/overload/arg1.C (test for errors, line 15) FAIL: g++.dg/overload/arg1.C (test for errors, line 16) FAIL: g++.dg/overload/arg1.C (test for errors, line 23) PASS: g++.dg/overload/arg1.C (test for excess errors) Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/g++/../../g++ -B/test/gnu/ gcc/objdir/gcc/testsuite/g++/../../ /test/gnu/gcc/gcc/gcc/testsuite/g++.dg/overl oad/arg4.C -nostdinc++ -I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/ include/hppa64-hp-hpux11.11 -I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++ -v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/test/gnu/gcc/gcc/libst dc++-v3/include/backward -I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessa ge-length=0 -std=c++98 -fno-show-column -S -o arg4.s(timeout = 300) FAIL: g++.dg/overload/arg4.C (test for errors, line 14) FAIL: g++.dg/overload/arg4.C (test for errors, line 15) FAIL: g++.dg/overload/arg4.C (test for errors, line 16) FAIL: g++.dg/overload/arg4.C (test for errors, line 30) PASS: g++.dg/overload/arg4.C (test for excess errors) Introduced between revisions 131096 and 131109. -- Summary: FAIL: g++.dg/overload/arg[14].C (test for errors ...) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa*-*-* GCC host triplet: hppa*-*-* GCC target triplet: hppa*-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34551
[Bug c++/34550] New: reference data template args appear to be broken in 4.2.1 ?
Code below builds w/o issues using earlier gcc and other compilers -
thought you might want to know about the issue.
Thanks in adv, and happy holidays.
template < class T, const int & R >
class Cat {
public:
Cat ( int );
};
template < class T, int & R >
Cat < T, R > :: Cat ( int )
{
}
extern const int myConstant = 4;
int main ()
{
Cat < float, myConstant > cat ( 2 );
return 0;
}
bash-3.00$ g++ cat.cpp
cat.cpp:13: error: invalid use of incomplete type 'class Cat'
cat.cpp:6: error: declaration of 'class Cat'
bash-3.00$ g++ -v
Using built-in specs.
Target: sparc-sun-solaris2.10
Configured with: ../../gcc-4.2.1/configure
Thread model: posix
gcc version 4.2.1
--
Summary: reference data template args appear to be broken in
4.2.1 ?
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: johill at lanl dot gov
GCC build triplet: sparc-sun-solaris2.10
GCC host triplet: sparc-sun-solaris2.10
GCC target triplet: sparc-sun-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34550
[Bug fortran/34325] Wrong error message for syntax error
--- Comment #7 from dfranke at gcc dot gnu dot org 2007-12-21 22:17 --- *** Bug 24759 has been marked as a duplicate of this bug. *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||schnetter at aei dot mpg dot ||de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34325
[Bug fortran/24759] Unclear error message for a syntax error
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-12-21 22:17 --- Fixed by Jerry. Closing as dupe. *** This bug has been marked as a duplicate of 34325 *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24759
[Bug libfortran/34540] [4.3 Regression] cshift, eoshift, kind=1 and kind=2 arguments...
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-12-21 22:18 --- Patch is testing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34540
[Bug target/20366] AIX g++ -D_LARGE_FILES fails to compile #include
--- Comment #12 from dje at gcc dot gnu dot org 2007-12-21 23:23 --- If AIX G++ users are focussing on 64-bit apps and large files, I'm willing to switch the default to _LARGE_FILES. The changes would be in gcc/config/rs6000/aix*.h CPP_SPEC and libstdc++/config/os/aix/os_defines.h, plus any fallout from the change. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20366
[Bug target/20366] AIX g++ -D_LARGE_FILES fails to compile #include
--- Comment #13 from bugzilla-gcc at thewrittenword dot com 2007-12-21 23:25 --- (In reply to comment #12) > If AIX G++ users are focussing on 64-bit apps and large files, I'm willing to > switch the default to _LARGE_FILES. The changes would be in > gcc/config/rs6000/aix*.h CPP_SPEC and libstdc++/config/os/aix/os_defines.h, > plus any fallout from the change. We only care about -D_LARGE_FILES to support files >2G while running a 32-bit app. We're not building any 64-bit apps. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20366
[Bug target/34525] [4.3 Regression] ICE in extract_insn, at recog.c:1990 on hppa
--- Comment #6 from danglin at gcc dot gnu dot org 2007-12-21 23:37 --- Subject: Bug 34525 Author: danglin Date: Fri Dec 21 23:37:07 2007 New Revision: 131126 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131126 Log: PR target/34525 * pa.c (legitimize_pic_address): Emit insn to load function label forced to memory. Modified: trunk/gcc/ChangeLog trunk/gcc/config/pa/pa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34525
[Bug target/34525] [4.3 Regression] ICE in extract_insn, at recog.c:1990 on hppa
--- Comment #7 from danglin at gcc dot gnu dot org 2007-12-21 23:58 --- This problem should now be fixed. I had modified the testcase and this led me to think I'd killed the ICE ;) I have to say that the code in the original testcase is probably very wrong for hppa. Like ia64, function pointers point to function descriptors (when the plabel bit is set). The function descriptor also may point to a stub and not the function code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34525
[Bug libfortran/34540] [4.3 Regression] cshift, eoshift, kind=1 and kind=2 arguments...
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-12-22 01:57 --- Subject: Bug 34540 Author: jvdelisle Date: Sat Dec 22 01:57:07 2007 New Revision: 131133 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131133 Log: 2007-12-21 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/34540 * iresolve.c (gfc_resolve_cshift): Take optional dim path only if the argument is an optional itself. * iresolve.c (gfc_resolve_eoshift): Same. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/iresolve.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34540
[Bug libfortran/34540] [4.3 Regression] cshift, eoshift, kind=1 and kind=2 arguments...
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2007-12-22 02:00 --- Subject: Bug 34540 Author: jvdelisle Date: Sat Dec 22 01:59:56 2007 New Revision: 131134 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131134 Log: 2007-12-21 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/34540 * gfortran.dg/shift-kind_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/shift-kind_2.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34540
[Bug libfortran/34540] [4.3 Regression] cshift, eoshift, kind=1 and kind=2 arguments...
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2007-12-22 02:00 --- Fixed on trunk. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34540
[Bug bootstrap/34481] stage3-intl: error: C compiler cannot create executables
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-22 02:38 --- can you try not building in the source directory and use an building directory? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34481
[Bug c/34552] New: optimization of bit-shifts leads to strange results
The example below copies a float from one location to the next. When compiling
with -O1 or less using 4.1.2, z equals *baz, and the program displays "ok, no
bug." When compiling with -O2 or greater, z doesn't equal *baz, and the
program prints "whoah: 23423.234375 should equal
8523244312281203485966336.00". Also of note, when one prints the value of
q before defining *baz using -O2, the value of *baz changes to 0.0. This
problem did not occur using gcc 4.0.1 with -O2.
#include
#include
int main(int argc, char **argv) {
float z = 23423.23424;
uint32_t* foo = (uint32_t*)&z;
uint8_t zbuf[4] = {0,0,0,0};
zbuf[3] = ((*foo) & 0x00ffL);
zbuf[2] = ((*foo) & 0xff00L) >> 8;
zbuf[1] = ((*foo) & 0x00ffL) >> 16;
zbuf[0] = ((*foo) & 0xff00L) >> 24;
uint32_t q =
(((uint32_t)zbuf[0] << 24) |
((uint32_t)zbuf[1] << 16) |
((uint32_t)zbuf[2] << 8) |
((uint32_t)zbuf[3]));
float *baz = (float*)&q;
if (z == *baz)
fprintf (stderr, "okay, no bug\n");
else
fprintf (stderr, "whoah: %f should equal %f\n", z, *baz);
return 0;
}
--
Summary: optimization of bit-shifts leads to strange results
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: blake dot tregre at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34552
[Bug c/34552] optimization of bit-shifts leads to strange results
--- Comment #1 from blake dot tregre at gmail dot com 2007-12-22 03:43 --- Created an attachment (id=14806) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14806&action=view) test code shown in bug report -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34552
[Bug c/34552] optimization of bit-shifts leads to strange results
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-12-22 05:38 --- uint32_t* foo = (uint32_t*)&z; zbuf[3] = ((*foo) & 0x00ffL); It is obvious you are violating C/C++ aliasing rules which leads to undefined behavior. Use either -fno-strict-aliasing, an union, or memcpy. *** This bug has been marked as a duplicate of 21920 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34552
[Bug c/21920] aliasing violations
--- Comment #126 from pinskia at gcc dot gnu dot org 2007-12-22 05:38 --- *** Bug 34552 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||blake dot tregre at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920
[Bug fortran/33595] FAIL: gfortran.dg/nint_2.f90 -O0 execution test
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-12-22 07:37 --- nint_2.f90 is also broken on Cygwin. Should we make that a separate PR? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33595
