https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278
--- Comment #31 from anlauf at gcc dot gnu.org ---
I've just checked the various comments.
What's left:
- comment#2 : the testcase still fails. See also comment#7 about the invalid
partial initialization
- lack of diagnostics of overlapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278
--- Comment #30 from Vittorio Zecca ---
On the following source code I still have the ICE:
type t
integer g
end type
type(t) :: u=t(1)
data u%g /2/ ! should emit diagnostic here
end
gfortran -S gfbug63.f
gfb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278
--- Comment #29 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:bd85b4dd2dd7b00b6342ed1e33fb48035a3dcb61
commit r11-7564-gbd85b4dd2dd7b00b6342ed1e33fb48035a3dcb61
Author: Harald Anlauf
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278
--- Comment #28 from anlauf at gcc dot gnu.org ---
Patch for accepts-invalid / ice-on-invalid-code (parameter + data) part:
https://gcc.gnu.org/pipermail/fortran/2021-March/055768.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278
--- Comment #27 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #26)
> (In reply to kargl from comment #23)
> > (In reply to anlauf from comment #21)
> > > There's also valid code that ICEs, and invalid code that is silently
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278
--- Comment #26 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #23)
> (In reply to anlauf from comment #21)
> > There's also valid code that ICEs, and invalid code that is silently
> > accepted.
> >
> > Invalid code:
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278
--- Comment #25 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #24)
> (In reply to anlauf from comment #21)
> Looks like the patch from comment #2 that I posted 9 years ago. LoL.
> Bug must not hit real code too often as no on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278
--- Comment #24 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #21)
>
> And after fixing an obvious NULL pointer dereference,
>
> diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
> index 37a0c85fa30..783a0bbdd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278
--- Comment #22 from anlauf at gcc dot gnu.org ---
The -fdump-fortran-original of the last example in comment#21 contains
symtree: 'z' || symbol: 'z'
type spec : (DERIVED t)
attributes: (VARIABLE IMPLICIT-SAVE DATA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278
--- Comment #20 from kargl at gcc dot gnu.org ---
*** Bug 91939 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278
--- Comment #19 from G. Steinmetz ---
Adding a "parameter" attribute :
$ cat z8.f90
program p
type t
real :: a
real :: b = 2.0
end type
type(t), parameter :: z = t(4.0, 5.0)
data z%a /3.0/
end
$ cat z9.f90
program p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278
--- Comment #18 from G. Steinmetz ---
Update and simplified a bit, ICEs down to at least version 5 :
$ cat z1.f90
module m
type t
sequence
real :: a
real :: b = 2.0
end type
type(t) :: z
data z%a /3.0/
end
$ cat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278
Dominique d'Humieres changed:
What|Removed |Added
CC||gs...@t-online.de
--- Comment #17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278
--- Comment #16 from Jürgen Reuter ---
In addition to what Tobias remarked, NAG now gives a clear error message:
NAG Fortran Compiler Release 6.1(Tozai) Build 6138
Error: data.f90, line 13: Object TRLKOLD of type ACTIVE is default-initialised,
t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278
--- Comment #14 from Dominique d'Humieres ---
> I think that 1 << 31 is undefined because "1" is assumed (signed) int.
> Maybe it should be 1u << 31 ?
I have tried it, but it does not work.
> Anyway on 6.1.0 I have no runtime error message.
Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278
--- Comment #13 from Vittorio Zecca ---
I think that 1 << 31 is undefined because "1" is assumed (signed) int.
Maybe it should be 1u << 31 ?
Anyway on 6.1.0 I have no runtime error message.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278
--- Comment #12 from Dominique d'Humieres ---
The ICE is gone with the patch in comment 2, however I get at run time
../../../work/libgcc/config/i386/cpuinfo.c:346:17: runtime error: left shift of
1 by 31 places cannot be represented in type 'in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278
--- Comment #11 from Vittorio Zecca ---
Same ICE in 6.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278
--- Comment #10 from Dominique d'Humieres ---
Related to pr50410.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278
Dominique d'Humieres changed:
What|Removed |Added
CC||zeccav at gmail dot com
--- Comme
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278
Tobias Burnus changed:
What|Removed |Added
Keywords|ice-on-valid-code |ice-on-invalid-code
Status|UN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278
Thomas Henlich changed:
What|Removed |Added
CC||thenlich at users dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278
--- Comment #6 from Tobias Burnus 2011-06-14
12:32:02 UTC ---
I have now filled an interpretation request (J3/11-201) - in time for WG5 and
J3 meeting (m195), which is end of June. Let's see what J3/WG5 will decide. Cf.
http://j3-fortran.org/doc/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278
--- Comment #5 from Tobias Burnus 2011-06-08
05:55:26 UTC ---
(In reply to comment #4)
> I have now asked at c.l.f:
Richard and Dick think the standard is very unclear; they are slightly inclined
to conclude that it is invalid, but suggest to fi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278
--- Comment #4 from Tobias Burnus 2011-06-07
09:17:05 UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> > The following aborts. Note sure if it is conforming.
> Hence, it seems to be valid, but I wouldn't mind if someone could cross
28 matches
Mail list logo
