[Bug tree-optimization/30125] [4.3 regression] Wrong-code due to aliasing
--- Comment #5 from bonzini at gnu dot org 2007-03-16 09:03 --- Subject: Bug 30125 Author: bonzini Date: Fri Mar 16 09:03:10 2007 New Revision: 122980 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122980 Log: 2007-03-16 Paolo Bonzini [EMAIL PROTECTED] PR rtl-optimization/30125 * df.h (df_get_live_out): New prototype. * df-problems.c (df_get_live_out): New. (df_ri_bb_compute): Use it. Modified: branches/dataflow-branch/gcc/ChangeLog.dataflow branches/dataflow-branch/gcc/df-problems.c branches/dataflow-branch/gcc/df.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30125
[Bug fortran/31194] New: NaN transfer - internal compiler error: in gfc_conv_constant
ICE on valid code. Might be related to PR 18769. Taken from PR 29471 comment 5. real(kind(0d0)) :: NaN = transfer(ishft(int(z'FFF8',8),32),0d0) print *, NaN end gives: foo.f90:1: internal compiler error: in gfc_conv_constant, at fortran/trans-const.c:348 -- Summary: NaN transfer - internal compiler error: in gfc_conv_constant Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code 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=31194
[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821
--- Comment #18 from rguenth at gcc dot gnu dot org 2007-03-16 09:25
---
Gah, let's analyze the effect of this change. First, with
/* Refuse to operate on VARYING ranges, ranges of different kinds
and symbolic ranges. As an exception, we allow BIT_AND_EXPR
because we may be able to derive a useful range even if one of
the operands is VR_VARYING or symbolic range. TODO, we may be
able to derive anti-ranges in some cases. */
if (code != BIT_AND_EXPR
code != TRUTH_AND_EXPR
code != TRUTH_OR_EXPR
(vr0.type == VR_VARYING
|| vr1.type == VR_VARYING
|| vr0.type != vr1.type
|| symbolic_range_p (vr0)
|| symbolic_range_p (vr1)))
{
set_value_range_to_varying (vr);
return;
}
...
/* If we have a RSHIFT_EXPR with a possibly negative shift
count or an anti-range shift count drop to VR_VARYING.
We currently cannot handle the overflow cases correctly. */
if (code == RSHIFT_EXPR
(vr1.type == VR_ANTI_RANGE
|| !vrp_expr_computes_nonnegative (op1, sop)))
{
set_value_range_to_varying (vr);
return;
}
we make sure neither vr0 nor vr1 are anti-ranges and vr1 is = 0.
Now, the hunk above changes us to not reject ranges that include zero for
the shift count. (This makes it possible to handle unsigned half-ranges
[0, n])
If the count is actually zero, we can end up doing x 0 (a left shift of
zero). Does hppa handle this correctly? Does it, for
int foo (unsigned int i)
{
int j = 12048173;
if (i 32)
{
j = j i;
if (j 0)
return 0;
}
return 1;
}
correctly have a value range of [0, 12048173] for j_5? (look at 055t.vrp1
dump)
Obviously I fail to see how this can cause a miscompilation...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169
[Bug target/31161] __builtin_cexpi is broken on Darwin
--- Comment #13 from dominiq at lps dot ens dot fr 2007-03-16 09:27 --- Darwin people. Or at least someone with enough knowledge of ppc asm... Do they exist? If yes, are some living on planet earth? If yes, how do you catch them (at least their attention!-)? Fixed. (The ICE, the wrong-code is tracked by the other PR) I have applied the patch, now the code given in the first post yields: -1 1.22465e-16 6.12323e-17 1 i.e., cexpi returns a wrong answer (first line) when compiled with gcc (so from a practical point of view the fix is worse than the original error unless it breaks enough c codes to make more people to look at the problem). Now I have a question that will show how ignorant I am: what fallback does exactly? If it is just a remapping of cexpi to cexp, then I think it is wrong. If I am not mistaken, cexpi takes real argument x and returns a complex result (cos(x), sin(x)), while cexp takes a complex argument z and returns a complex result exp(real(z))*(cos(imag(z)),sin(imag(z))), so the correct definition of cexpi should be: cexpi(x)=cexp(complex(0,x)) Is this correct? If yes what should be done to implement this behavior? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31161
[Bug fortran/31194] NaN transfer - internal compiler error: in gfc_conv_constant
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-16 09:34 --- I'm not anymore sure whether it is valid or not. Related: NaN = transfer(ishft(int(z'FFF8',8),32),0.0_8) this prints duly NaN with NAG f95, sunf95, ifort, g95 and gfortran. The example of comment 0 prints NaN with g95 and sunf95, ifort prints 0.0 (???) and NAG f95 rejects it with: Error: foo.f90, line 1: INT of non-integer not permitted in an initialisation expression which somehow looks strange. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31194
[Bug fortran/29471] Warn with -std=f95/f2003 when BOZ is used at invalid places
--- Comment #9 from burnus at gcc dot gnu dot org 2007-03-16 09:45 --- The current problem is shown in this bit of code: write(*,*)'NaN(8)=',real(z'FFF8',8) end Note: gfortran does not support Fortran 2003 BOZ yet. gfortran, even with -std=f2003, claims that the BOZ data is too big. Use -fno-range-check to disable this checking. But this will still the old BOZ extension and not the Fortran 2003 BOZ. Even without the reinterpret cast problem, integer BOZ is not handled correctly. This expression also claims the BOZ is too large: int(z'',8) The number is does not fit into -huge(1_8) ... huge(1_8) and is therefore outside of the Fortran standard. - -fno-range-check The traditional behavior is for all BOZ to be initially interpreted as the largets integer type supported. Which is why gfortran gives no error if you use int(BOZ, kind=16). The only hassle with processor dependent definitions is that the result of a given binary value depends on a processor's internal binary format. So, IEEE floats are portable, but other long/quad real numbers are not. Processor dependent in the Fortran language does not only mean the CPU but also the compiler; nonetheless, in this regard most (all?) compilers produce the same result on a given platform. A related problem is that I am trying to create a NaN constant (parameter). I can't use REAL+BOZ, but I also cannot define real :: NaN = 0.0/0.0. In this case, divide-by-zero is invalid math, but should only be a warning and not an error. (I am speaking practically; I don't know what the standards say.) The standard does not say anything about non-Fortran numbers. Fortran 2003 has now support of the IEEE arithmetics, which allows NaN, denormalized numbers and +/-INF, overflowing etc. Thus for a Fortran 95 compiler, the 0./0. can always be rejected, whereas for Fortran 2003 it is a bit unclearer (cf. below for a standard way to get Nan). my personal trick is to use: real :: r, NaN r = 0.0 NaN = 0.0/r which does the NaN at run time. (You still need to have the right compiler flags as otherwise you get an arithmetic exception at run time.) But, good news, I just discovered that this hack works: NaN = transfer(ishft(int(z'FFF8',8),32),0.0_8) I tried that a while back with gfortran and it crashed. A modified version still crashes with gfortran: real(kind(0d0)) :: NaN = transfer(ishft(int(z'FFF8',8),32),0d0) print *, NaN Interestingly, this produces 0.0 with ifort, while g95 and sunf95 give NaN. See PR 31194. What we really need is a NAN(kind=8) intrinsic. Well, one can do in Fortran 2003: use,intrinsic :: ieee_arithmetic real :: NaN NaN = ieee_value(x,ieee_quiet_nan) (Note: IEEE arithmetic is not yet supported by many compilers, especially gfortran does not support it yet.) (In reply to comment #6) My vote is to just ignore the standards when it comes to negative BOZ, the way Intel has done it, which I HOPE is what F2008 says. Sorry, I think most people would like to have a standard conform compiler; we cannot do so. Besides IEEE arithmetic allows what you want. Using transfer is a non-portable way to do so, which assumes a certain internal structure. And using your integer BOZ are supported with -fno-range-check. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29471
[Bug target/31161] __builtin_cexpi is broken on Darwin
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-03-16 09:50 --- Yes, it's supposed to call cexp(complex(0,x)), but now looking at the code there seems to be a typo: narg = fold_build2 (COMPLEX_EXPR, ctype, build_real (type, dconst0), arg); /* Make sure not to fold the cexp call again. */ call = build1 (ADDR_EXPR, build_pointer_type (TREE_TYPE (fn)), fn); return expand_expr (build_call_nary (ctype, call, 1, arg), target, VOIDmode, 0); it builds the call with 'arg' instead of 'narg'. Argh. This bug was introduced by the CALL_EXPR changes: narg = fold_build2 (COMPLEX_EXPR, ctype, build_real (type, dconst0), arg); /* Make sure not to fold the cexp call again. */ call = build1 (ADDR_EXPR, build_pointer_type (TREE_TYPE (fn)), fn); - return expand_expr (build3 (CALL_EXPR, ctype, call, - build_tree_list (NULL_TREE, narg), - NULL_TREE), target, VOIDmode, 0); + return expand_expr (build_call_nary (ctype, call, 1, arg), + target, VOIDmode, 0); I'll fix it in a second. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31161
[Bug tree-optimization/31146] forwprop does not look through casts
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-03-16 10:11 --- Subject: Bug 31146 Author: rguenth Date: Fri Mar 16 10:11:14 2007 New Revision: 122985 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122985 Log: 2007-03-16 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/31146 * tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Restructure to allow recursion of forward_propagate_addr_expr. (forward_propagate_addr_into_variable_array_index): Likewise. (forward_propagate_addr_expr): Likewise. (tree_ssa_forward_propagate_single_use_vars): Likewise. (forward_propagate_addr_expr_1): Recurse on simple copies instead of propagating into them. Do so for useless conversions as well. (forward_propagate_addr_expr): Clean up unused statements after recursion. * g++.dg/tree-ssa/pr31146.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr31146.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-forwprop.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31146
[Bug preprocessor/31195] New: incorrect handling of backslashes in comments
a.c: /* A \ BC */ eof Excecute a comment-preserving preprocessing: $ gcc -E -P -C a.c /* A BC C */ Notice the extra 'C', which is a bug. This bug has some significance as in this particular case there is another tool that has interest in the content of the C comment and now that tool fails. -- Summary: incorrect handling of backslashes in comments Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: matti dot sangi at nokia dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31195
[Bug fortran/31188] ICE on vector subscript of a parameter array
--- Comment #5 from burnus at gcc dot gnu dot org 2007-03-16 10:57 --- Subject: Bug 31188 Author: burnus Date: Fri Mar 16 10:57:45 2007 New Revision: 122987 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122987 Log: 2007-03-16 Paul Thomas [EMAIL PROTECTED] Tobias Burnus [EMAIL PROTECTED] PR fortran/31188 * expr.c (find_array_section): Allow non-expression-constant variables. 2007-03-16 Tobias Burnus [EMAIL PROTECTED] PR fortran/31188 * gfortran.dg/parameter_array_dummy.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/parameter_array_dummy.f90 Modified: trunk/gcc/fortran/expr.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31188
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #83 from jv244 at cam dot ac dot uk 2007-03-16 11:11 --- I upgraded trunk, and now the code compiles again with -march=native, but crashes as follows: Program received signal SIGILL, Illegal instruction. 0x00afa307 in __qs_resp__resp_fit () objdump -d gives me afa2e1: f2 0f 11 84 24 68 02movsd %xmm0,0x268(%rsp) afa2e8: 00 00 afa2ea: dd 84 24 68 02 00 00fldl 0x268(%rsp) afa2f1: f2 0f 11 8c 24 68 02movsd %xmm1,0x268(%rsp) afa2f8: 00 00 afa2fa: dd 84 24 68 02 00 00fldl 0x268(%rsp) afa301: d9 c9 fxch %st(1) afa303: d9 f8 fprem afa305: df e0 fnstsw %ax afa307: 9e (bad) afa308: 7a f9 jp afa303 __qs_resp__resp_fit+0x1383 afa30a: dd d9 fstp %st(1) afa30c: dd 9c 24 68 02 00 00fstpl 0x268(%rsp) afa313: 66 0f 12 ac 24 68 02movlpd 0x268(%rsp),%xmm5 afa31a: 00 00 afa31c: 66 0f 2f ef comisd %xmm7,%xmm5 afa320: 0f 95 c1setne %cl afa323: 66 0f 2f c7 comisd %xmm7,%xmm0 afa327: 0f 92 c2setb %dl afa32a: 66 0f 2f cf comisd %xmm7,%xmm1 afa32e: 0f 92 c0setb %al afa331: 31 d0 xor%edx,%eax /proc/cpuinfo is: vendor_id : AuthenticAMD cpu family : 15 model : 5 model name : AMD Opteron(tm) Processor 840 stepping: 8 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug rtl-optimization/31025] [dataflow] Crash in caller-save.c due to x87 math
--- Comment #2 from bonzini at gnu dot org 2007-03-16 11:18 --- the patch was not responsible for the regressions, and it regtested ok if i paper over the bug in stevenb's patch. so i committed it. -- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31025
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #84 from ubizjak at gmail dot com 2007-03-16 11:21 --- (In reply to comment #83) I upgraded trunk, and now the code compiles again with -march=native, but crashes as follows: Program received signal SIGILL, Illegal instruction. 0x00afa307 in __qs_resp__resp_fit () vendor_id : AuthenticAMD cpu family : 15 model : 5 model name : AMD Opteron(tm) Processor 840 stepping: 8 Could you post your cpuflags? There should be lahf_lm flag present for opterons. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug fortran/31196] New: wrong code generated with gfortran
With a recent gfortran, the following compiles, but generates the wrong results: TYPE datatype INTEGER :: I END TYPE TYPE(datatype) :: data(4) data=(/(datatype(I),I=1,4)/) data=RESHAPE(TRANSPOSE(RESHAPE(data,(/2,2/))),SHAPE(data)) IF (ANY(data(:)%I.NE.(/1,3,2,4/))) CALL ABORT() END -- Summary: wrong code generated with gfortran Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31196
[Bug fortran/31197] New: wrong code generated with gfortran
With a recent gfortran, the following compiles, but generates the wrong results: TYPE data CHARACTER(LEN=3) :: A END TYPE TYPE(data), DIMENSION(10), TARGET :: Z CHARACTER(LEN=10) :: res Z(:)%A=123 write(res,'(10A1)') TRANSPOSE(RESHAPE(Z(:)%A(2:2),(/5,2/))) IF (res.NE.22) CALL ABORT END -- Summary: wrong code generated with gfortran Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31197
[Bug fortran/31198] New: wrong code generated with gfortran
With a recent gfortran, the following compiles, but generates the wrong results: IF (T1(1.0,1.0) .NE. (1.0,1.0) ) CALL ABORT() IF (T1(1.0) .NE. (1.0,0.0)) CALL ABORT() IF (M1(1,2,3) .NE. 3) CALL ABORT() IF (M1(1,2,A4=4) .NE. 4) CALL ABORT() CONTAINS COMPLEX FUNCTION T1(X,Y) REAL :: X REAL, OPTIONAL :: Y T1=CMPLX(X,Y) END FUNCTION T1 INTEGER FUNCTION M1(A1,A2,A3,A4) INTEGER :: A1,A2 INTEGER, OPTIONAL :: A3,A4 M1=MAX(A1,A2,A3,A4) END FUNCTION M1 END -- Summary: wrong code generated with gfortran Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31198
[Bug fortran/31199] New: wrong code generated with gfortran
With a recent gfortran, the following compiles, but generates the wrong results: program write_write character(len=20) :: a,b,c write (10,(a,t1,a,a)) X, ABC, DEF write (10,(a,t1,a),advance='no') X, ABC write (10,(a)) DEF write (10,(a)) ABCDEFXXX REWIND(10) read(10,*) a read(10,*) b read(10,*) c IF (a.NE.b) CALL ABORT() IF (a.NE.c) CALL ABORT() end -- Summary: wrong code generated with gfortran Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31199
[Bug fortran/31200] New: wrong code generated with gfortran
With a recent gfortran, the following compiles, but generates the wrong results: REAL,TARGET :: x CALL s3(f(x)) CONTAINS FUNCTION f(a) REAL,POINTER :: f REAL,TARGET :: a f = a END FUNCTION SUBROUTINE s3(targ) REAL,TARGET :: targ REAL,POINTER :: p p = targ IF (.NOT. ASSOCIATED(p,x)) CALL ABORT() END SUBROUTINE END -- Summary: wrong code generated with gfortran Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31200
[Bug fortran/31201] New: wrong code generated with gfortran
With a recent gfortran, the following compiles, but generates the wrong results: integer*8 :: k=2_8**36+10 integer*4 :: j=10 logical ex,op INQUIRE(unit=k, exist=ex,opened=op) IF (ex) THEN OPEN(unit=k) INQUIRE(unit=j, opened=op) IF (op) CALL ABORT() ENDIF end -- Summary: wrong code generated with gfortran Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31201
[Bug fortran/31202] New: wrong code generated with gfortran
With a recent gfortran, the following compiles, but generates the wrong results: ! http://gcc.gnu.org/ml/fortran/2005-04/msg00139.html real*8 :: a integer*8 :: i1,i2 a=.4999444888487687421729788184165954589843750_8 i2=NINT(.4999444888487687421729788184165954589843750_8) i1=NINT(a) ! 0.499944488848768742 0 0 write(6,'(F40.30,2I2)') a,i1,i2 IF (i1.NE.i2) CALL ABORT() a=4503599627370497.0_8 i1=NINT(a,KIND=8) i2=NINT(4503599627370497.0_8,KIND=8) ! 4503599627370497 4503599627370497 4503599627370497 write(6,*) 4503599627370497_8,i1,i2 IF (i1.NE.i2) CALL ABORT() END -- Summary: wrong code generated with gfortran Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31202
[Bug fortran/31203] New: wrong code generated with gfortran
With a recent gfortran, the following compiles, but generates the wrong results: call s(-3) call s(2**18) contains subroutine s(i) character(LEN=I) a IF(LEN(a).NE.MAX(0,I)) CALL ABORT() end subroutine end -- Summary: wrong code generated with gfortran Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31203
[Bug fortran/31204] New: wrong code generated with gfortran
With a recent gfortran, the following compiles, but generates the wrong results: MODULE mod INTEGER, PARAMETER :: jmin(1:10) = (/ (i, i = 1, 10) /) CONTAINS SUBROUTINE one i = 99 END SUBROUTINE SUBROUTINE two i=0 CALL one IF (i.NE.0) CALL ABORT() END SUBROUTINE END MODULE USE MOD CALL two END -- Summary: wrong code generated with gfortran Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31204
[Bug fortran/31205] New: wrong code generated with gfortran
With a recent gfortran, the following compiles, but generates the wrong results: MODULE TT TYPE data_type INTEGER :: I=2 END TYPE data_type INTERFACE ASSIGNMENT (=) MODULE PROCEDURE set END INTERFACE CONTAINS PURE SUBROUTINE set(x1,x2) TYPE(data_type), INTENT(IN) :: x2 TYPE(data_type), INTENT(OUT) :: x1 CALL S1(x1,x2) END SUBROUTINE PURE SUBROUTINE S1(x1,x2) TYPE(data_type), INTENT(IN) :: x2 TYPE(data_type), INTENT(OUT) :: x1 x1%i=x2%i END SUBROUTINE END MODULE USE TT TYPE(data_type) :: D,E D%I=4 D=D E%I=4 CALL set(E,(E)) IF (D%I.NE.4) CALL ABORT() IF (4.NE.E%I) CALL ABORT() END -- Summary: wrong code generated with gfortran Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31205
[Bug fortran/31206] New: wrong code generated with gfortran
With a recent gfortran, the following compiles, but generates the wrong results: INTEGER, PARAMETER :: K(3)=1, J(3)=2 INTEGER :: I(1) write(6,*) MAXLOC(K,J1) END -- Summary: wrong code generated with gfortran Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31206
[Bug fortran/31207] New: wrong code generated with gfortran
With a recent gfortran, the following compiles, but generates the wrong results: character(len=20) :: b ! write something no advance open(10,FILE=fort.10,POSITION=REWIND) write(10, '(a,t1,a)',advance='no') 'XX', 'ABC' close(10) ! append some data open(10,FILE=fort.10,POSITION=APPEND) write(10, '(a)') 'DEF' close(10) ! check what is in the first record open(10,FILE=fort.10,POSITION=REWIND) read(10,'(a)') b IF (b.NE.ABCXXX) CALL ABORT() END -- Summary: wrong code generated with gfortran Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31207
[Bug fortran/31208] New: wrong code generated with gfortran
With a recent gfortran, the following compiles, but generates the wrong results: SUBROUTINE S1(I,J) character(len=I-J) :: a IF (LEN(a)0) CALL ABORT() END SUBROUTINE CALL S1(1,2) END -- Summary: wrong code generated with gfortran Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31208
[Bug fortran/31209] New: wrong code generated with gfortran
With a recent gfortran, the following compiles, but generates the wrong results: FUNCTION F() RESULT(RES) INTEGER, POINTER :: RES ALLOCATE(RES) RES=2 END FUNCTION F SUBROUTINE S1(f,*,*) INTERFACE FUNCTION F() RESULT(RES) INTEGER, POINTER :: RES END FUNCTION F END INTERFACE RETURN F() END SUBROUTINE PROGRAM TEST INTERFACE FUNCTION F() RESULT(RES) INTEGER, POINTER :: RES END FUNCTION F END INTERFACE INTERFACE SUBROUTINE S1(f,*,*) INTERFACE FUNCTION F() RESULT(RES) INTEGER, POINTER :: RES END FUNCTION F END INTERFACE END SUBROUTINE END INTERFACE CALL S1(F,*1,*2) 1 CONTINUE CALL ABORT() GOTO 3 2 CONTINUE 3 CONTINUE END -- Summary: wrong code generated with gfortran Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31209
[Bug fortran/31210] New: wrong code generated with gfortran
With a recent gfortran, the following compiles, but generates the wrong results: MODULE xml_markups LOGICAL, PRIVATE :: should_write_tags=.TRUE. CONTAINS FUNCTION write_xml_tag(tag) RESULT(res) CHARACTER(LEN=*), INTENT(IN) :: tag CHARACTER(LEN=MERGE(LEN_TRIM(tag),0,should_write_tags)) :: res res=tag END FUNCTION write_xml_tag SUBROUTINE set_write_xml_tags(should_write) LOGICAL, INTENT(IN) :: should_write should_write_tags=should_write END SUBROUTINE END MODULE xml_markups USE xml_markups REAL, PARAMETER :: val=3.1415 character(len=80) :: old,new,new2 ! old style write write(old,'(T2,F12.6)') val ! new style write write(new,'(T2,A,F12.6,A)') write_xml_tag(keword ), val,write_xml_tag(/keyword ) ! if the use has selected --no-xml-output this should be set early CALL set_write_xml_tags(.FALSE.) ! new style write with old result write(new2,'(T2,A,F12.6,A)') write_xml_tag(keword ), val,write_xml_tag(/keyword ) IF (old.NE.new2) CALL ABORT() END -- Summary: wrong code generated with gfortran Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31210
[Bug fortran/31211] New: wrong code generated with gfortran
With a recent gfortran, the following compiles, but generates the wrong results: MODULE T INTERFACE cp_log MODULE PROCEDURE cp_logger_log END INTERFACE TYPE cp_logger_type INTEGER :: a END TYPE cp_logger_type PUBLIC :: cp_log, cp_logger_type CONTAINS SUBROUTINE cp_logger_log(logger) TYPE(cp_logger_type), POINTER ::logger END SUBROUTINE FUNCTION cp_get_default_logger() RESULT(res) TYPE(cp_logger_type), POINTER ::res NULLIFY(RES) END FUNCTION cp_get_default_logger END MODULE T USE T CALL cp_log(cp_get_default_logger()) END -- Summary: wrong code generated with gfortran Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31211
[Bug tree-optimization/31183] ICE in int_cst_value, at tree.c:7684 with -O3 -ftree-loop-linear
--- Comment #5 from spop at gcc dot gnu dot org 2007-03-16 11:30 --- Subject: Bug 31183 Author: spop Date: Fri Mar 16 11:30:48 2007 New Revision: 122988 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122988 Log: PR tree-optimization/31183 * tree-loop-linear.c (gather_interchange_stats, try_interchange_loops): Use double_int instead of unsigned int for representing access_strides. * testsuite/gcc.dg/tree-ssa/pr31183.c: New. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr31183.c Modified: trunk/gcc/ChangeLog trunk/gcc/tree-loop-linear.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31183
[Bug fortran/31212] New: ICE on valid code with gfortran
A recent gfortran ICEs on the following code: CHARACTER(LEN=2), DIMENSION(:), POINTER :: a CHARACTER(LEN=4), DIMENSION(3), TARGET :: b b=(/,,/) a=b(:)(2:3) a=aa IF (ANY(b.NE.(/baab,baab,baab/))) CALL ABORT() END -- Summary: ICE on valid code with gfortran Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31212
[Bug fortran/31213] New: ICE on valid code with gfortran
A recent gfortran ICEs on the following code:
module mykinds
implicit none
integer, parameter :: ik1 = selected_int_kind(2)
integer, parameter :: ik2 = selected_int_kind(4)
integer, parameter :: dp = selected_real_kind(15,300)
end module mykinds
module spec_xpr
use mykinds
implicit none
integer(ik2) c_size
contains
pure function tricky(str,ugly)
character(*), intent(in) :: str
integer(ik1) ia_ik1(len(str))
interface yoagly
pure function ugly(n)
use mykinds
implicit none
integer, intent(in) :: n
complex(dp) ugly(3*n+2)
end function ugly
end interface yoagly
logical la(size(yoagly(size(ia_ik1
integer i
character(tricky_helper((/(.TRUE.,i=1,size(la))/))+c_size) tricky
tricky = repeat('X',len(tricky))
end function tricky
pure function tricky_helper(lb)
logical, intent(in) :: lb(:)
integer tricky_helper
tricky_helper = 2*size(lb)+3
end function tricky_helper
end module spec_xpr
module xtra_fun
implicit none
contains
pure function butt_ugly(n)
use mykinds
implicit none
integer, intent(in) :: n
complex(dp) butt_ugly(3*n+2)
real(dp) pi, sq2
pi = 4*atan(1.0_dp)
sq2 = sqrt(2.0_dp)
butt_ugly = cmplx(pi,sq2,dp)
end function butt_ugly
end module xtra_fun
program spec_test
use mykinds
use spec_xpr
use xtra_fun
implicit none
c_size = 5
write(*,'(1x,i0)') len(tricky('Help me',butt_ugly))
write(*,'(1x,a)') tricky('Help me',butt_ugly)
end program spec_test
--
Summary: ICE on valid code with gfortran
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31213
[Bug fortran/31214] New: ICE on valid code with gfortran
A recent gfortran ICEs on the following code: module type_mod implicit none type x integer x end type x type y integer x end type y type z integer x end type z interface assignment(=) module procedure equals end interface assignment(=) interface operator(//) module procedure a_op_b, b_op_a end interface operator(//) contains subroutine equals(x,y) type(z), intent(in) :: y type(z), intent(out) :: x x%x = y%x end subroutine equals function a_op_b(a,b) type(x), intent(in) :: a type(y), intent(in) :: b type(z) a_op_b type(z) b_op_a entry b_op_a(b,a) a_op_b%x = a%x/b%x end function a_op_b end module type_mod program test use type_mod implicit none type(x) :: x1 = x(19) type(y) :: y1 = y(7) type(z) z1 z1 = x1//y1 write(*,*) 'x1//y1 = ',z1 z1 = y1//x1 write(*,*) 'y1//x1 = ',z1 end program test -- Summary: ICE on valid code with gfortran Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31214
[Bug fortran/31215] New: ICE on valid code with gfortran
A recent gfortran ICEs on the following code:
module test1
implicit none
contains
character(f(x)) function test2(x) result(r)
implicit integer (x)
dimension r(modulo(len(r)-1,3)+1)
integer, intent(in) :: x
interface
pure function f(x)
integer, intent(in) :: x
integer f
end function f
end interface
integer i
do i = 1, len(r)
r(:)(i:i) = achar(mod(i,32)+iachar('@'))
end do
end function test2
end module test1
program test
use test1
implicit none
write(*,*) len(test2(10))
write(*,*) test2(10)
end program test
pure function f(x)
integer, intent(in) :: x
integer f
f = 2*x+1
end function f
--
Summary: ICE on valid code with gfortran
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31215
[Bug fortran/31216] New: ICE on valid code with gfortran
A recent gfortran ICEs on the following code: INTEGER :: I CHARACTER(LEN=100) :: data=1.0 3.0 REAL :: C,D READ(data,*) C,D I=TRANSFER(C/D,I) SELECT CASE(I) CASE (TRANSFER(1.0/3.0,1)) CASE DEFAULT CALL ABORT() END SELECT END -- Summary: ICE on valid code with gfortran Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31216
[Bug fortran/31217] New: ICE on valid code with gfortran
A recent gfortran ICEs on the following code: character(LEN=12) :: b=123456789012 character(LEN=12) :: a=123456789012 FORALL(I=3:10) a(I:I+2)=a(I-2:I) IF (a.NE.121234567890) CALL ABORT() END -- Summary: ICE on valid code with gfortran Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31217
[Bug fortran/31218] New: ICE on valid code with gfortran
A recent gfortran ICEs on the following code: integer, parameter :: i=1 real, parameter :: k=TRANSFER(i,1.0) integer :: j=TRANSFER(k,i) character(LEN=2), parameter :: a=a real, dimension(2,2), parameter :: r=1.0 character(LEN=4) :: b=REPEAT(a,2) real, dimension(4) :: l=RESHAPE(r,(/4/)) character(LEN=3) :: c=TRIM(a ) IF (b.NE.a a ) CALL ABORT() IF (ANY(l.NE.1.0)) CALL ABORT() IF (c.NE.a ) CALL ABORT() IF (j.NE.i) CALL ABORT() END -- Summary: ICE on valid code with gfortran Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31218
[Bug fortran/31219] New: ICE on valid code with gfortran
A recent gfortran ICEs on the following code: INTEGER :: J CHARACTER(LEN=8) :: str J=3 write(str,'(2A4)') (/(F(I,J),I=1,2)/) IF (str.NE. ODD EVE) CALL ABORT() CONTAINS FUNCTION F(K,J) RESULT(I) INTEGER :: K,J CHARACTER(LEN=J) :: I IF (MODULO(K,2).EQ.0) THEN I=EVEN ELSE I=ODD ENDIF END FUNCTION END -- Summary: ICE on valid code with gfortran Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31219
[Bug fortran/31220] New: ICE on valid code with gfortran
A recent gfortran ICEs on the following code: CHARACTER(LEN=4), POINTER :: b CHARACTER(LEN=10) :: r b=F1(1,r) b= b=F1(2,r) b= b=F1(3,r) b= IF (r.NE.1-) CALL ABORT() CONTAINS FUNCTION F1(I,r) result(b) INTEGER :: I CHARACTER(LEN=10), TARGET, SAVE :: a=-- CHARACTER(LEN=10) :: r CHARACTER(LEN=4), POINTER :: b r=a b=a(I:I+3) END FUNCTION END -- Summary: ICE on valid code with gfortran Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31220
[Bug fortran/31221] New: ICE on valid code with gfortran
A recent gfortran ICEs on the following code: MODULE M1 integer, parameter :: N=10 integer, parameter :: i1(N)=(/(j,j=1,N)/) integer, parameter :: i2(N)=MODULO(i1,5) END MODULE M1 USE M1 k=3 select case(k) case (i2(7)) case (i1(N-1)) end select END -- Summary: ICE on valid code with gfortran Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31221
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #85 from jv244 at cam dot ac dot uk 2007-03-16 11:52 --- (In reply to comment #84) Could you post your cpuflags? There should be lahf_lm flag present for opterons. flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #86 from jv244 at cam dot ac dot uk 2007-03-16 12:07 --- (In reply to comment #85) (In reply to comment #84) Could you post your cpuflags? There should be lahf_lm flag present for opterons. sorry, the previous post was of the wrong machine... these are the correct flags and no (lahf_lm): cpu family : 15 model : 5 model name : AMD Opteron(tm) Processor 840 stepping: 8 flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #87 from ubizjak at gmail dot com 2007-03-16 12:16 --- (In reply to comment #86) sorry, the previous post was of the wrong machine... these are the correct flags and no (lahf_lm): cpu family : 15 model : 5 model name : AMD Opteron(tm) Processor 840 stepping: 8 flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow I was just writting the reply about wrong AMD errata 110 workaround. Please wait a couple of minutes, I'll switch descriptions of all AMD processors to default to NO_SAHF. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug fortran/31222] New: Rejected: implicitly-typed dummys used in initialization expressions
Reported at http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/100b8994f011019b/ The following program is rejected with: bar.f90:5.17: dimension a(abs(mode)),b(int(dis)) 1 Error: 'a' argument of 'abs' intrinsic at (1) must be a numeric type bar.f90:5.30: dimension a(abs(mode)),b(int(dis)) 1 Error: 'a' argument of 'int' intrinsic at (1) must be a numeric type - program testprog call mysub1((/-2.0/), (/3.2/),-1, 1.0) contains subroutine mysub1(a,b,mode,dis) dimension a(abs(mode)),b(int(dis)) write (*,*) abs(mode), nint(dis) end subroutine end program -- Summary: Rejected: implicitly-typed dummys used in initialization expressions Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: rejects-valid 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=31222
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #88 from ubizjak at gmail dot com 2007-03-16 12:43 --- (In reply to comment #83) I upgraded trunk, and now the code compiles again with -march=native, but crashes as follows: Program received signal SIGILL, Illegal instruction. 0x00afa307 in __qs_resp__resp_fit () objdump -d gives me afa305: df e0 fnstsw %ax afa307: 9e (bad) afa308: 7a f9 jp afa303 The above (bad) opcode is harmless bug in objdump. The code generation should be fixed by http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01108.html. The issue with older binutils is also fixed by a couple of previous patches. Thanks for your reports! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug java/31223] New: [regression] indirect dispatch not working with static builds
With a static gcj build, target=i686-pc-linux, using -findirect-dispatch to
compile a class will result in this compilation error:
/tmp/cciWx2S5.o: In function `main':ccxsXCuN.i:(.text+0x13): undefined
reference to `_Jv_Compiler_Properties'
:ccxsXCuN.i:(.text+0x30): undefined reference to `JvRunMainName'
/tmp/ccmjyQHx.o: In function `void
Test::main(JArrayjava::lang::String**)':Test.class:(.text+0x2e): undefined
reference to `_Jv_InitClass'
:Test.class:(.text+0x51): undefined reference to `_Jv_ResolvePoolEntry'
/tmp/ccmjyQHx.o: In function `global constructors keyed to
0__ZN4TestC1Ev':Test.class:(.text+0xb6): undefined reference to
`_Jv_RegisterNewClasses'
/tmp/ccmjyQHx.o:(.eh_frame+0x11): undefined reference to `__gcj_personality_v0'
collect2: ld returned 1 exit status
Seen with a host=mingw and host=linux GCJ. This worked with GCJ 4.2.
Workaround:
The problem probably lies in libgcj.spec. In my host=linux and target=linux
libgcj.spec, I have:
*lib: %{static-libgcj:-non_shared} %{s-bc-abi:-lgcj_bc;:-lgcj}
%{static-libgcj:-call_shared} -lm -lpthread -lrt-ldl %(libgcc) %(liborig)
Replacing it with:
*lib: %{s-bc-abi:} -lgcj -lm -lpthread -lrt-ldl %(libgcc) %(liborig)
Will make the compilation work again.
--
Summary: [regression] indirect dispatch not working with static
builds
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mtrudel at gmx dot ch
GCC target triplet: i686-pc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31223
[Bug java/31223] [regression] indirect dispatch not working with static builds
--- Comment #1 from mtrudel at gmx dot ch 2007-03-16 12:57 --- This also breaks the build when a static built GCJ is taken for the compilation of ecj.jar (because it's compiled with -findirect-dispatch). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31223
[Bug preprocessor/31182] preprocessor doubles up digits in token pasting
--- Comment #5 from dsb at boyski dot com 2007-03-16 12:58 --- I just downloaded the latest 4.2 snapshot (gcc-4.2-20070307) and built it but the behavior is the same. Given that the bugfix cited there dates back to October and that it says Known to work: 4.2.0 I assume the patch is present here so it appears to be different from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28709 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31182
[Bug fortran/31196] wrong code generated with RESHAPE/TRANSPOSE
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-16 13:21 --- Expected result: 1 3 2 4 Gfortran: 1 3 1 3 This is correctly calculated with g95, NAG f95 and sunf95. gfortran compiles and gives the wrong result and ifort gives an ICE. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Known to fail||4.1.3 4.2.0 4.3.0 Priority|P3 |P2 Last reconfirmed|-00-00 00:00:00 |2007-03-16 13:21:37 date|| Summary|wrong code generated with |wrong code generated with |gfortran|RESHAPE/TRANSPOSE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31196
[Bug fortran/31197] wrong code generated with TRANSPOSE/RESHAPE and strings
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-16 13:25 --- Expected: 22 The TRANSPOSE(RESHAPE(Z(:)%A(2:2),(/5,2/))) gives: 22.#65533;L+ res contains: 22#65533;+2#65533;? -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2007-03-16 13:25:05 date|| Summary|wrong code generated with |wrong code generated with |gfortran|TRANSPOSE/RESHAPE and ||strings http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31197
[Bug fortran/31198] [Regression 4.3] wrong code: Max() with optional arguments
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-16 13:42 --- The first two lines work, but the M() calls fail (SIGSEGV): D.1257 = *a3; if (D.1257 M.0) [...] D.1258 = *a4; That is: There is no optional check. cmplx has one: D.1260 = y != 0B ? *y : 0.0; __result_t1 = COMPLEX_EXPR *x, D.1260; -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-16 13:42:06 date|| Summary|wrong code generated with |[Regression 4.3] wrong code: |gfortran|Max() with optional ||arguments http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31198
[Bug bootstrap/31224] New: some installation scripts and Makefiles do not run on stock Solaris
Some scripts and Makefiles used during the bootstrap process use options provided by GNU tools (bash, test, diff) which are not supported by stock Solaris 2.8 tools. The errors I have encountered so far (I'm still fighting with installation) are: missing -a flag between two tests use of test -e, which should be replaced by test -f (or test -d for directories) use of set -C in shell (which has no equivalent) use of diff -U 0, which should be replaced by diff -C 0 with the additional trick to add a space between the initial '-' or '+' character and the line The concerned files are libjava/classpath/lib/gen-classlist.sh.in, libjava/classpath/lib/Makefile.am and libjava/classpath/scripts/check_jni_methods.sh. I will post a patch for this in a few minutes. -- Summary: some installation scripts and Makefiles do not run on stock Solaris Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Luc dot Maisonobe at free dot fr GCC build triplet: sparc-sun-solaris2.8 GCC host triplet: sparc-sun-solaris2.8 GCC target triplet: sparc-sun-solaris2.8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31224
[Bug fortran/31199] write with t1 format gives wrong output
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-16 13:54 --- Current result: a = ABCDEFXXX b = ABCDEF c = ABCDEFXXX Expected (g95/ifort): ABCDEFXXX ABCDEFXXX ABCDEFXXX (NAG f95 has: ABCDEFXXX ABCXXDEF ABCDEFXXX ) -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||jvdelisle at gcc dot gnu dot ||org, burnus at gcc dot gnu ||dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2007-03-16 13:54:17 date|| Summary|wrong code generated with |write with t1 format gives |gfortran|wrong output http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31199
[Bug bootstrap/31224] some installation scripts and Makefiles do not run on stock Solaris
--- Comment #1 from Luc dot Maisonobe at free dot fr 2007-03-16 13:56 --- Created an attachment (id=13213) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13213action=view) patch changing commands flags to ones hopefully more widely supported This patch is neither fully tested nor complete. It is merely provided as a reference and to clarify the problem. I am not sure the chosen flags are the good ones (for example I didn't understand what the inial test with the missing -a and the compound -ef flags intended to do). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31224
[Bug bootstrap/31224] some installation scripts and Makefiles do not run on stock Solaris
--- Comment #2 from Luc dot Maisonobe at free dot fr 2007-03-16 13:59 --- In the provided patch, I replaced a sequence of mkdir commands with a single mkdir -p. I know the -p flag is not supported everywhere (or at least was not supported years ago), but since this option is used elsewhere in the Makefile.am, I considered it was not a problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31224
[Bug fortran/31200] wrong code: procedure call with pointer-returning-function as argument
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-16 14:07 ---
The problem is:
s3(f(x))
which is translated as
{
real4 D.1254;
D.1254 = *f (x);
s3 (D.1254);
}
instead of
D.1254 = f(x)
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||burnus at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||wrong-code
Last reconfirmed|-00-00 00:00:00 |2007-03-16 14:07:34
date||
Summary|wrong code generated with |wrong code: procedure call
|gfortran|with pointer-returning-
||function as argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31200
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #89 from jv244 at cam dot ac dot uk 2007-03-16 14:16 --- Thanks for your reports! and you for your fixes... things are back to working now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug target/31161] __builtin_cexpi is broken on Darwin
--- Comment #15 from dominiq at lps dot ens dot fr 2007-03-16 14:43 --- This bug was introduced by the CALL_EXPR changes: Good catch! Can you date the bug, i.e., was it introduced between snapshots 20070216 and 20070223? Thanks for the work. i'ld just like to see the darwin people as helpful! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31161
[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821
--- Comment #19 from dave at hiauly1 dot hia dot nrc dot ca 2007-03-16 14:43 --- Subject: Re: Bootstrap comparison error at revision 122821 If the count is actually zero, we can end up doing x 0 (a left shift of zero). Does hppa handle this correctly? Does it, for The hardware doesn't support a left shift of zero, so at the moment the expanders and patterns require that the shift length be greater than zero. I recently fixed a bug in this area. Should copies be generated for this case? Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169
[Bug fortran/31225] New: gfortran dislikes implicitly type subroutine arguments
The following valid code is rejected by gfortran: (When the lines giving explicit type to mode and dis are uncommented, gfortran compiles it fine.) $ cat a.f90 subroutine mysub1(a,b,mode,dis) ! integer :: mode ! real :: dis dimension a(abs(mode)),b(int(dis)) print *, mod write (*,*) abs(mode), nint(dis) end subroutine program testprog call mysub1((/1.,2./),(/1.,2.,3./),-2, 3.2) end $ gfortran a.f90 a.f90:4.18: dimension a(abs(mode)),b(int(dis)) 1 Error: 'a' argument of 'abs' intrinsic at (1) must be a numeric type a.f90:4.31: dimension a(abs(mode)),b(int(dis)) 1 Error: 'a' argument of 'int' intrinsic at (1) must be a numeric type -- Summary: gfortran dislikes implicitly type subroutine arguments Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31225
[Bug fortran/31225] gfortran dislikes implicitly type subroutine arguments
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.1.2 4.2.0 4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-03-16 14:50:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31225
[Bug fortran/31221] ICE on valid code with gfortran
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-16 15:02 --- Reduced testcase: $ cat a.f90 integer, parameter :: i2(1)=MODULO((/1/),5) call foo(i2) end $ gfortran a.f90 a.f90: In function MAIN__: a.f90:1: internal compiler error: in gfc_conv_array_initializer, at fortran/trans-array.c:3693 It has something to do with PR29507, though the patch there (comment #3) does not fix it (it gives a different error). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||29507 Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||4.1.2 4.2.0 4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-03-16 15:02:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31221
[Bug fortran/29507] INDEX in an array initialization causes ICE
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-03-16 15:04 --- (In reply to comment #3) Since this bug is related to PR31221, I tried your patch on the other testcase, and it fails: $ cat a.f90 integer, parameter :: i2(1)=MODULO((/1/),5) call foo(i2) end $ gfortran a.f90 a.f90:1.45: integer, parameter :: i2(1)=MODULO((/1/),5) 1 Internal Error at (1): check_init_expr(): Unknown expression type I don't know if it exposes another bug or exposes something missing in your patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29507
[Bug fortran/31222] Rejected: implicitly-typed dummys used in initialization expressions
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-16 15:05 --- *** Bug 31225 has been marked as a duplicate of this bug. *** -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31222
[Bug fortran/31225] gfortran dislikes implicitly type subroutine arguments
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-16 15:05 --- *** This bug has been marked as a duplicate of 31222 *** -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31225
[Bug fortran/31222] Rejected: implicitly-typed dummys used in initialization expressions
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-03-16 15:06 --- Tobias, you beat me to it, I only got PR31225 :) Here is the analysis I posted in my bug-report: The following valid code is rejected by gfortran: (When the lines giving explicit type to mode and dis are uncommented, gfortran compiles it fine.) $ cat a.f90 subroutine mysub1(a,b,mode,dis) ! integer :: mode ! real :: dis dimension a(abs(mode)),b(int(dis)) print *, mod write (*,*) abs(mode), nint(dis) end subroutine program testprog call mysub1((/1.,2./),(/1.,2.,3./),-2, 3.2) end -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.1.3 4.2.0 4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-03-16 15:06:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31222
[Bug preprocessor/31195] incorrect handling of backslashes in comments
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-16 15:12 --- *** This bug has been marked as a duplicate of 24024 *** -- 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=31195
[Bug preprocessor/24024] [4.0/4.1/4.2/4.3 Regression] gcc -E -C processes \ incorrectly inside C comments
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-03-16 15:12 --- *** Bug 31195 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||matti dot sangi at nokia dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24024
[Bug fortran/31220] ICE on valid code with gfortran
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-16 15:13 --- Confirmed, but it's a duplicate of PR29396. Testcase was reduced to: FUNCTION F1() CHARACTER(LEN=4), TARGET, SAVE :: a= CHARACTER(LEN=4), POINTER :: F1 F1=a(1:) END FUNCTION *** This bug has been marked as a duplicate of 29396 *** -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31220
[Bug fortran/29396] segfault with character pointer association
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-03-16 15:13 --- *** Bug 31220 has been marked as a duplicate of this bug. *** -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29396
Re: [Bug c++/31187] New: [4.2 regression] extern declaration of variable in anonymous namespace prevents use of its address as template argument
zak at transversal dot com [EMAIL PROTECTED] writes:
| The following code, which compiles fine on gcc 4.1.2 and I believe is valid,
| fails on an up-to-date checkout from the 4.2 branch:
|
| --
| class foo { };
|
| namespace
| {
| extern foo foo1;
| foo foo1;
| }
|
| template foo *
| class bar { };
|
| bar foo1 bar1;
| ---
|
| giving the error:
|
| test.cc:12: error: 'unnamed::foo1' is not a valid template argument of type
| 'foo*' because 'unnamed::foo1' does not have external linkage
| test.cc:12: error: invalid type in declaration before ';' token
|
|
| ... which I would only expect if foo1 were declared static.
Yes, this is a bug in the compiler. I suspect it was introduced when
the the back was told to treat declarations at unnamed namespaces
ast static. That of course is an optimization and should be appear at
the front-end.
-- gaby
[Bug c++/31187] [4.2/4.3 regression] extern declaration of variable in anonymous namespace prevents use of its address as template argument
--- Comment #2 from gdr at cs dot tamu dot edu 2007-03-16 15:15 ---
Subject: Re: New: [4.2 regression] extern declaration of variable in
anonymous namespace prevents use of its address as template argument
zak at transversal dot com [EMAIL PROTECTED] writes:
| The following code, which compiles fine on gcc 4.1.2 and I believe is valid,
| fails on an up-to-date checkout from the 4.2 branch:
|
| --
| class foo { };
|
| namespace
| {
| extern foo foo1;
| foo foo1;
| }
|
| template foo *
| class bar { };
|
| bar foo1 bar1;
| ---
|
| giving the error:
|
| test.cc:12: error: 'unnamed::foo1' is not a valid template argument of
type
| 'foo*' because 'unnamed::foo1' does not have external linkage
| test.cc:12: error: invalid type in declaration before ';' token
|
|
| ... which I would only expect if foo1 were declared static.
Yes, this is a bug in the compiler. I suspect it was introduced when
the the back was told to treat declarations at unnamed namespaces
ast static. That of course is an optimization and should be appear at
the front-end.
-- gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31187
[Bug fortran/29396] segfault with character pointer association
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-03-16 15:15 --- Joost filed PR31220, which is a duplicate of this one, but contains an interesting testcase (compile run) to check and add to the testsuite when we're done with this bug: CHARACTER(LEN=4), POINTER :: b CHARACTER(LEN=10) :: r b=F1(1,r) b= b=F1(2,r) b= b=F1(3,r) b= IF (r.NE.1-) CALL ABORT() CONTAINS FUNCTION F1(I,r) result(b) INTEGER :: I CHARACTER(LEN=10), TARGET, SAVE :: a=-- CHARACTER(LEN=10) :: r CHARACTER(LEN=4), POINTER :: b r=a b=a(I:I+3) END FUNCTION END -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.2.0 4.3.0 Last reconfirmed|2007-01-28 22:15:31 |2007-03-16 15:15:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29396
[Bug bootstrap/31224] some installation scripts and Makefiles do not run on stock Solaris
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-16 15:20 --- /bin/sh is not a POSIX shell in Solaris and GCC depends a POSIX shell. test -ef is actually POSIX, read the man page on solaris, it will say it is not avaible with /bin/sh. Anyways you did not read: http://gcc.gnu.org/install/specific.html#x-x-solaris2 Which says: The Solaris 2 /bin/sh will often fail to configure libstdc++-v3, boehm-gc or libjava. We therefore recommend using the following initial sequence of commands % CONFIG_SHELL=/bin/ksh % export CONFIG_SHELL -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31224
[Bug c++/7302] -Wnon-virtual-dtor should't complain of protected dtor
--- Comment #17 from pluto at agmk dot net 2007-03-16 15:22 --- Created an attachment (id=13214) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13214action=view) extended patch against gcc-4.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7302
[Bug fortran/31219] ICE on valid code with gfortran
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-16 15:23 --- Reduced testcase: $ cat a.f90 call gee( [f(1)] ) contains function f(k) result(i) integer :: k character(len=k) :: i end function end $ ./bin/gfortran a.f90 a.f90:1: internal compiler error: Segmentation fault The backtrace is: Program received signal SIGSEGV, Segmentation fault. get_frame_type (info=0x0) at /utmp/coudert/gfortran/trunk/gcc/tree-nested.c:199 199 tree type = info-frame_type; (gdb) where #0 get_frame_type (info=0x0) at /utmp/coudert/gfortran/trunk/gcc/tree-nested.c:199 #1 0x006b8a04 in get_chain_decl (info=0xdcc3f0) at /utmp/coudert/gfortran/trunk/gcc/tree-nested.c:305 #2 0x006b9af4 in get_nonlocal_debug_decl (info=0xdcc3f0, decl=0x2a984ca000) at /utmp/coudert/gfortran/trunk/gcc/tree-nested.c:852 #3 0x006bc1d3 in convert_nonlocal_reference (tp=0x2a984cecb0, walk_subtrees=0x7fbfffea7c, data=Variable data is not available. ) at /utmp/coudert/gfortran/trunk/gcc/tree-nested.c:923 #4 0x007b076b in walk_tree (tp=0x2a984cecb0, func=0x6bc100 convert_nonlocal_reference, data=0x7fbfffec90, pset=0x0) at /utmp/coudert/gfortran/trunk/gcc/tree.c:8000 #5 0x007b087f in walk_tree (tp=0x2a984cd448, func=0x6bc100 convert_nonlocal_reference, data=0x7fbfffec90, pset=0x0) at /utmp/coudert/gfortran/trunk/gcc/tree.c:8235 -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||4.1.3 4.2.0 4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-03-16 15:23:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31219
[Bug fortran/31219] ICE on valid code with gfortran
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-03-16 15:25
---
Forgot to say: the original tree dump is
f (__result, .__result, k)
{
(void) 0;
MAIN__ ()
{
static void f (char[1:] , int4, int4 );
_gfortran_set_std (68, 127, 0);
{
void * D.1377;
void * D.1374;
struct array1_unknown atmp.3;
void * D.1367;
struct array1_unknown atmp.0;
atmp.0.dtype = (SAVE_EXPR (unnamed type) (..__result + -1) + 1 6) +
49;
atmp.0.dim[0].stride = 1;
atmp.0.dim[0].lbound = 0;
atmp.0.dim[0].ubound = 0;
D.1367 = _gfortran_internal_malloc64 ((int8) (SAVE_EXPR (unnamed type)
(..__result + -1) + 1));
atmp.0.data = D.1367;
atmp.0.offset = 0;
{
char[1:D.1371] * pstr.2;
int4 D.1371;
int4 * D.1370;
static int4 C.1369 = 1;
D.1370 = C.1369;
D.1371 = *D.1370;
pstr.2 = (char[1:D.1371] *) _gfortran_internal_malloc (D.1371);
f (pstr.2, D.1371, D.1370);
__builtin_memcpy ((*(char[0:][1:..__result] *) atmp.0.data)[0], pstr.2,
D.1371);
_gfortran_internal_free ((void *) pstr.2);
}
atmp.3.dtype = (SAVE_EXPR (unnamed type) (..__result + -1) + 1 6) +
49;
atmp.3.dim[0].stride = 1;
atmp.3.dim[0].lbound = 0;
atmp.3.dim[0].ubound = 0;
D.1374 = _gfortran_internal_malloc64 ((int8) (SAVE_EXPR (unnamed type)
(..__result + -1) + 1));
atmp.3.data = D.1374;
atmp.3.offset = 0;
{
int8 S.4;
S.4 = 0;
while (1)
{
if (S.4 0) goto L.1;
(*(char[0:][1:..__result] *) atmp.3.data)[S.4] =
(*(char[0:][1:..__result] *) atmp.0.data)[S.4];
S.4 = S.4 + 1;
}
L.1:;
}
D.1377 = _gfortran_internal_pack (atmp.3);
gee (D.1377, ..__result);
if (D.1377 != (char[0:][1:..__result] *) atmp.3.data)
{
_gfortran_internal_unpack (atmp.3, D.1377);
_gfortran_internal_free (D.1377);
}
_gfortran_internal_free (atmp.0.data);
_gfortran_internal_free (atmp.3.data);
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31219
Bitfield conversion bug in 4.2?
Hi,
The following code compiles fine in GCC 4.1.
enum E { e };
struct S {
E v:5;
};
S s;
int main() { if (!s.v) return 0; }
In 4.2 (20070307), it gives the following error:
test.cpp: In function 'int main()':
test02.cpp:6: error: could not convert 's.S::v' to 'bool'
test02.cpp:6: error: in arguument to unary !
Is this a bug or new behavior? If the latter, what is this attributed
to?
Thanks,
Eric.
[Bug c++/7302] -Wnon-virtual-dtor should't complain of protected dtor
--- Comment #18 from manu at gcc dot gnu dot org 2007-03-16 15:30 --- (In reply to comment #17) Created an attachment (id=13214) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13214action=view) [edit] extended patch against gcc-4.2 Hi Pawel, if the bug exists in mainline, the patch should be against mainline (I think this patch will apply to mainline anyway). The patch needs testcases, and it should be sent to [EMAIL PROTECTED] Also, + warning (0, %q#T has virtual functions and accessible + non-virtual destructor, t) should be: + warning (OPT_Wnon_virtual_dtor, +%q#T has virtual functions and accessible + non-virtual destructor, t) Also + || DECL_FRIENDLIST( TYPE_MAIN_DECL (t))) should be + || DECL_FRIENDLIST (TYPE_MAIN_DECL (t))) Thanks for the patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7302
[Bug fortran/31217] ICE on valid code with gfortran
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-16 15:32 --- Reduced testcase: character(len=1) :: a=1 forall(i=1:1) a(i:i) = a(i:i) end Adding Roger Sayle in the CC list, since you're our FORALL expert :) Program received signal SIGSEGV, Segmentation fault. integer_onep (expr=0x0) at /utmp/coudert/gfortran/trunk/gcc/tree.c:1311 1311 STRIP_NOPS (expr); (gdb) where #0 integer_onep (expr=0x0) at /utmp/coudert/gfortran/trunk/gcc/tree.c:1311 #1 0x00493a5e in allocate_temp_for_forall_nest_1 (type=0x2a984c7b40, size=0x2a984c68a0, block=0x7fbfffec60, ptemp1=0x7fbfffe8b8) at /utmp/coudert/gfortran/trunk/gcc/fortran/trans-stmt.c:2076 #2 0x00494d84 in gfc_trans_assign_need_temp (expr1=0xe02610, expr2=0xe029a0, wheremask=0x0, invert=0 '\0', nested_forall_info=0xdcec70, block=0x7fbfffec60) at /utmp/coudert/gfortran/trunk/gcc/fortran/trans-stmt.c:2181 #3 0x004986c5 in gfc_trans_forall_1 (code=0xe02e30, nested_forall_info=0x0) at /utmp/coudert/gfortran/trunk/gcc/fortran/trans-stmt.c:2629 #4 0x004665c7 in gfc_trans_code (code=0xe02e30) at /utmp/coudert/gfortran/trunk/gcc/fortran/trans.c:553 #5 0x00479e96 in gfc_generate_function_code (ns=0xdf9060) at /utmp/coudert/gfortran/trunk/gcc/fortran/trans-decl.c:3217 -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||sayle at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||4.1.3 4.2.0 4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-03-16 15:32:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31217
[Bug fortran/31215] ICE on valid code with gfortran
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-16 15:37 --- All compilers I know reject this code, except g95. The list includes Lahey, which is a reason for me to doubt whether this code is legal or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31215
[Bug c++/7302] -Wnon-virtual-dtor should't complain of protected dtor
--- Comment #19 from pluto at agmk dot net 2007-03-16 15:39 --- (In reply to comment #18) The patch needs testcases, i have a testcase but my tcl/autogen/dejagnu crashes with magic `spawn failed' message :/ e.g.: (...) Executing on host: /home/users/pluto/rpm/BUILD/gcc-4.2-20070307/builddir/gcc/xgcc -B/home/users/pluto/rpm/BUILD/gcc-4.2-20070307/builddir/gcc/ -O0 -w -fno-show-column -c -o 2105-1.o /home/users/pluto/rpm/BUILD/gcc-4.2-20070307/gcc/testsuite/gcc.c-torture/compile/2105-1.c (timeout = 300) compiler exited with status -1 output is: spawn failed FAIL: gcc.c-torture/compile/2105-1.c -O0 (test for excess errors) Excess errors: spawn failed -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7302
[Bug fortran/31215] ICE on valid code with gfortran
--- Comment #2 from burnus at gcc dot gnu dot org 2007-03-16 15:56 --- (In reply to comment #1) All compilers I know reject this code, except g95. The list includes Lahey, which is a reason for me to doubt whether this code is legal or not. NAG f95 and g95 compile it and output: 21 ABCDEFGHIJKLMNOPQRSTUABCDEFGHIJKLMNOPQRSTUABCDEFGHIJKLMNOPQRSTU (ifort, sunf95 write: dimension r(modulo(len(r)-1,3)+1) ^ fortcom: Error: foo.f90, line 6: The data types of the argument(s) are invalid. [LEN] dimension r(modulo(len(r)-1,3)+1) ^ foo.f90, Line = 6, Column = 33: ERROR: Array R is used recursively to declare its own bounds. In any case, an ICE is an error. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31215
[Bug c++/7302] -Wnon-virtual-dtor should't complain of protected dtor
--- Comment #20 from manu at gcc dot gnu dot org 2007-03-16 16:13 --- (In reply to comment #19) (In reply to comment #18) The patch needs testcases, i have a testcase but my tcl/autogen/dejagnu crashes with magic `spawn failed' message :/ No idea. Ask in the gcc list, perhaps someone could help you. I would just remove completely and reinstall DejaGNU. Or just use the GCC Compile Farm for testing. I have a script there that you just say PATCH=/path/to/patch ./gccfarming bootstrap And it bootstraps and regression tests the patch and sends you the results by email. It also has a patchqueue mode where filenames of patches are read from a file and bootstrapped+tested in sequence, and you can add more names at the end of the file on the fly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7302
[Bug fortran/31144] gfortran module symbol names are not standard compliant
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-03-16 16:27 --- Confirmed, this should be fixed for 4.3.0 Intel and Portland compilers use a broken mechanism. Sun gives the following name to symbol FOO in module MOD: mod.foo_ It seems clean to me. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Known to fail||4.1.3 4.2.0 4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-03-16 16:27:41 date|| Summary|Gfortran module names are |gfortran module symbol names |not Standards compliant |are not standard compliant Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31144
[Bug fortran/31200] wrong code: procedure call with pointer-returning-function as argument
--- Comment #2 from pault at gcc dot gnu dot org 2007-03-16 17:10 --- (In reply to comment #1) real4 D.1254; D.1254 = *f (x); s3 (D.1254); } instead of D.1254 = f(x) Funnily enough, I have been hit by the same problem in implementing procedure pointers. I will attempt to come to grips with it. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-03-16 14:07:34 |2007-03-16 17:10:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31200
[Bug c++/31226] New: static const volatile variables don't get linked correctly
The following program does not link:
#include iostream
class A {
public:
static bool const volatile doit = true;
};
using namespace std;
int main()
{
if( A::doit ) cout doit is true;
else cout doit is false;
}
The link error is:
$ g++ -o mytest mytest.cc
/tmp/ccdPkdpO.o: In function `main':
/tmp/ccdPkdpO.o(.text+0x11): undefined reference to `A::doit'
collect2: ld returned 1 exit status
If volatile is removed, everything works.
--
Summary: static const volatile variables don't get linked
correctly
Product: gcc
Version: 3.3.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zickzack at w84u dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31226
[Bug c++/31226] static const volatile variables don't get linked correctly
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-16 18:01 --- You forgot to declare it, you only defined it. Add: bool const volatile A::doit; to your code and it will work. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31226
[Bug tree-optimization/31227] New: [4.3 Regression] -Warray-bounds doesn't play together with loop optimizations
typedef __SIZE_TYPE__ size_t;
extern size_t strlen (const char *);
struct iovec
{
void *iov_base;
size_t iov_len;
};
struct S
{
const char *abday[7];
const char *day[7];
const char *abmon[12];
const char *mon[12];
const char *am_pm[2];
};
extern void foo (size_t, struct iovec *);
void
bar (struct S *time)
{
struct iovec iov[43];
size_t cnt;
iov[0].iov_base = (void *) abc;
iov[0].iov_len = 3;
iov[1].iov_base = (void *) def;
iov[1].iov_len = 3;
for (cnt = 0; cnt = 7; ++cnt)
{
iov[2 + cnt].iov_base = (void *) (time-abday[cnt] ?: );
iov[2 + cnt].iov_len = strlen (iov[2 + cnt].iov_base) + 1;
}
for (; cnt = 14; ++cnt)
{
iov[2 + cnt].iov_base = (void *) (time-day[cnt - 7] ?: );
iov[2 + cnt].iov_len = strlen (iov[2 + cnt].iov_base) + 1;
}
for (; cnt = 26; ++cnt)
{
iov[2 + cnt].iov_base = (void *) (time-abmon[cnt - 14] ?: );
iov[2 + cnt].iov_len = strlen (iov[2 + cnt].iov_base) + 1;
}
for (; cnt = 38; ++cnt)
{
iov[2 + cnt].iov_base = (void *) (time-mon[cnt - 26] ?: );
iov[2 + cnt].iov_len = strlen (iov[2 + cnt].iov_base) + 1;
}
for (; cnt = 40; ++cnt)
{
iov[2 + cnt].iov_base = (void *) (time-am_pm[cnt - 38] ?: );
iov[2 + cnt].iov_len = strlen (iov[2 + cnt].iov_base) + 1;
}
foo (2 + cnt, iov);
}
issues at -O2 -Wall bogus warnings:
/tmp/w.c:24: warning: array subscript is above array bounds
/tmp/w.c:24: warning: array subscript is above array bounds
Apparently tree loop optimizations decide to use time-abmon[14] and
time-mon[30] pointers (which are outside of the range of the arrays) and then
dereferences that pointer - 112B (96B is the size of abmon array and 16B are
extra 2 pointers because the other array is biased by 2).
The testcase is extracted from glibc.
--
Summary: [4.3 Regression] -Warray-bounds doesn't play together
with loop optimizations
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31227
[Bug c++/31226] static const volatile variables don't get linked correctly
--- Comment #2 from bangerth at dealii dot org 2007-03-16 18:18 --- (In reply to comment #1) You forgot to declare it, you only defined it. In fact the other way around: you declared (and initialized) the variable but you forgot to give a definition (which asks the compiler to actually allocate space for it). W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31226
[Bug fortran/31217] ICE using FORALL on character substrings
--- Comment #2 from tbm at cyrius dot com 2007-03-16 18:43 --- Roger once mentioned that he's not receiving messages sent to his gcc account. I'm CCing his personal one in case this is still true. -- tbm at cyrius dot com changed: What|Removed |Added CC||roger at eyesopen dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31217
[Bug libgcj/31228] New: Race condition between setting close-on-exec and Runtime.exec()
Runtime.exec() could fork/exec the external process between the time a file descriptor is opened and and when close-on-exec is set on it. -- Summary: Race condition between setting close-on-exec and Runtime.exec() Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: daney at gcc dot gnu dot org GCC host triplet: *-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31228
[Bug fortran/31229] New: kind parameter in function declaration fails to find use-associated parameters
Bil Kleb posted the following code on comp.lang.fortran on 2007/3/16; Richard Maine agreed that it is valid but pointed out that it's a consistent weak spot in many compilers. I tested it on GFortran, and it does indeed fail here. debian-gfortran:~/test more kleb1.f90 module kinds integer, parameter :: dp = selected_real_kind(15) end module kinds module test_undeclared_kind; contains REAL(DP) function declared_dp_before_defined() use kinds, only: dp declared_dp_before_defined = 1.0_dp end function end module debian-gfortran:~/test ~/bin-trunk/bin/gfortran kleb1.f90 kleb1.f90:6.9: REAL(DP) function declared_dp_before_defined() 1 Error: Parameter 'dp' at (1) has not been declared or is a variable, which does not reduce to a constant expression [...] debian-gfortran:~/test ~/bin-trunk/bin/gfortran --version GNU Fortran (GCC) 4.3.0 20070316 (experimental) -- Summary: kind parameter in function declaration fails to find use-associated parameters Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brooks at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31229
[Bug tree-optimization/31227] [4.3 Regression] -Warray-bounds doesn't play together with loop optimizations
--- Comment #1 from jakub at gcc dot gnu dot org 2007-03-16 19:17 ---
Another testcase, this time from glibc's malloc.c:
struct malloc_chunk {
long prev_size;
long size;
struct malloc_chunk* fd;
struct malloc_chunk* bk;
};
typedef struct malloc_chunk* mchunkptr;
struct malloc_state {
mchunkptrtop;
mchunkptrlast_remainder;
mchunkptrbins[128 * 2 - 2];
};
#define bin_at(m, i) \
(mchunkptr) (((char *) ((m)-bins[((i) - 1) * 2])) \
- __builtin_offsetof (struct malloc_chunk, fd))
void malloc_init_state(struct malloc_state *av)
{
int i;
mchunkptr bin;
for (i = 1; i 128; ++i) {
bin = bin_at(av,i);
bin-fd = bin-bk = bin;
}
}
at -O2 -Wall this warns:
warning: array subscript is below array bounds
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31227
[Bug target/31111] Problem while compiling gcc for sh-elf
--- Comment #3 from mstein at phenix dot rootshell dot be 2007-03-16 19:18 --- Revisions after 122791 no longer have the reported problem. -- mstein at phenix dot rootshell dot be changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
[Bug target/30222] gcc.target/i386/vectorize1.c ICEs
--- Comment #4 from brett dot albertson at stratech dot com 2007-03-16 19:23 --- Is this slated to be fixed before 4.2.0 comes out? Also, I think this can be marked as confirmed. Brett -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30222
[Bug fortran/31212] ICE on valid code with gfortran
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-16 19:30 --- Exact duplicate of PR29396. *** This bug has been marked as a duplicate of 29396 *** -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31212
[Bug fortran/29396] segfault with character pointer association
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-03-16 19:30 --- *** Bug 31212 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29396
[Bug tree-optimization/30965] Fails to tree-combine conditions in COND_EXPRs
--- Comment #2 from jv244 at cam dot ac dot uk 2007-03-16 19:38 --- just to keep track, patch here: http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00129.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30965
[Bug fortran/31214] ICE on valid code with gfortran
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-16 19:42 --- Reduced testcase: module test implicit none interface operator(.foo.) module procedure b_op_a end interface operator(.foo.) contains function a_op_b() integer, intent(in) :: a, b integer :: a_op_b, b_op_a entry b_op_a(a,b) end function a_op_b end module test $ gfortran -c a.f90 a.f90:13.17: entry b_op_a(a,b) 1 Internal Error at (1): insert_bbt(): Duplicate key found! -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||4.1.3 4.2.0 4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-03-16 19:42:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31214
