--- Comment #17 from pault at gcc dot gnu dot org 2008-11-30 07:50 ---
Fixed on trunk and 4.3.
Comment #13 has migrated to PR38324.
Thanks for the report
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #16 from pault at gcc dot gnu dot org 2008-11-29 20:43 ---
Subject: Bug 34143
Author: pault
Date: Sat Nov 29 20:42:22 2008
New Revision: 142284
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142284
Log:
2008-11-24 Paul Thomas <[EMAIL PROTECTED]>
PR fortran
--- Comment #15 from burnus at gcc dot gnu dot org 2008-11-27 13:21 ---
I think PR is fixed on the trunk (4.4) [-> back porting?], except of the issue
of comment 13 (-> different PR?).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34143
--- Comment #14 from pault at gcc dot gnu dot org 2008-11-24 06:35 ---
Subject: Bug 34143
Author: pault
Date: Mon Nov 24 06:34:16 2008
New Revision: 142148
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142148
Log:
2008-11-24 Paul Thomas <[EMAIL PROTECTED]>
PR fortran
--- Comment #13 from dominiq at lps dot ens dot fr 2008-02-12 10:54 ---
The problem of conversion shows up even without -fdefault-integer-8 along with
bound problems as shown by the following code:
integer, parameter :: ik=4
type :: struct
integer(4), allocatable :: ib(:)
end type st
--- Comment #12 from pault at gcc dot gnu dot org 2008-02-11 17:48 ---
(In reply to comment #11)
OK I have a fix, up to a wrinkle that raises a standard question:
alloc_comp_constructor.f90 now compiles and runs OK but aborts because the
bounds are changed by the implicit conversion wh
--- Comment #11 from burnus at gcc dot gnu dot org 2008-02-06 09:09 ---
> Is the correct thing to throw an error or to quietly do the conversion?
I tried the example (with integer(4) and integer(8)) with several compilers and
none of them gave an error. (With -Wall g95 gives a conversion
--- Comment #10 from pault at gcc dot gnu dot org 2008-02-06 08:33 ---
This bug is caused by gfc_conv_intrinsic_conversion calling
gfc_conv_intrinsic_function_args, which builds a temporary without checking if
the allocatable array 'yy' has been allocated or not.
This can be cured by lo
--- Comment #9 from pault at gcc dot gnu dot org 2008-02-05 13:05 ---
I've knocked back it's priority but have assigned it to myself to compensate.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #8 from pault at gcc dot gnu dot org 2008-02-05 12:57 ---
I just noticed that this is due to incorrect or non-existent type/kind checking
in the constructor 'mytype'. With -fdefault-integer-8, yy has KIND=8, whereas
the corresponding component has KIND=4, as given by the dec
--- Comment #7 from pault at gcc dot gnu dot org 2007-11-30 07:49 ---
(In reply to comment #5)
> Erik, Paul, as authors of the original patch and testcases, can you confirm my
> conclusion that the code in comment #4 (and thus, the
> gfortran.dg/alloc_comp_constructor_1.f90 testcase) is
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Last reconfirmed|2007-11-29 11:25:01 |2007-11-29 11:2
--- Comment #6 from burnus at gcc dot gnu dot org 2007-11-22 13:18 ---
(In reply to comment #4)
> The Intel and Sun compilers complain that this code is not legal, because you
> can't do "x = mytype(yy, bar)" if yy is not allocated.
I cannot reproduce this with the Sun Compiler, only wi
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-11-22 08:56
---
Erik, Paul, as authors of the original patch and testcases, can you confirm my
conclusion that the code in comment #4 (and thus, the
gfortran.dg/alloc_comp_constructor_1.f90 testcase) is not legal, for the reason
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-11-20 13:03
---
The Intel and Sun compilers complain that this code is not legal, because you
can't do "x = mytype(yy, bar)" if yy is not allocated.
Otherwise, a reduced testcase on x86_64-linux is:
type t
integer, alloca
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-11-18 23:41
---
OK, the original test case fails as reported. Replacing aborts with printin
the line number that fails:
fail 39
fail 40
fail 80
fail 81
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34143
--- Comment #2 from tkoenig at gcc dot gnu dot org 2007-11-18 22:04 ---
(In reply to comment #1)
> The test case given here passes for me on x86-64 with both -m32 and -m64 and
> with or without -fdefault-integer-8. hmm!
Does the original test case pass?
--
http://gcc.gnu.org/bugzil
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-11-18 21:48
---
The test case given here passes for me on x86-64 with both -m32 and -m64 and
with or without -fdefault-integer-8. hmm!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34143
18 matches
Mail list logo
