https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120131
--- Comment #8 from Vladimir Terzi ---
I initially changed the status, because I assumed that my questions in comment
#2 will be ignored.
(In reply to kargls from comment #6)
> I suppose it is somewhat naive of gfortran contributors to expect t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120131
--- Comment #5 from Vladimir Terzi ---
After a fruitful discussion in Stack Overflow, I understand that the model set
of integers in Fortran is symmetric about zero according to the formula in
section 16.4 of https://j3-fortran.org/doc/year/24/2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120131
Vladimir Terzi changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|DUPLICA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120131
--- Comment #2 from Vladimir Terzi ---
(In reply to Andrew Pinski from comment #1)
> No gfortran is correct this code is invalid without an extra option.
>
> *** This bug has been marked as a duplicate of bug 33285 ***
So you are implying that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120131
Bug ID: 120131
Summary: Misleading and unnecessary error message due to range
check
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117264
--- Comment #10 from Vladimir Terzi ---
(In reply to anlauf from comment #9)
> After some search, I found a gfortran 13.3.0 (openSUSE 15.5, r13-8781),
> that fails also for
>
> program p
> type,abstract::t
> end type t
> type,extends(t)::
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117264
--- Comment #8 from Vladimir Terzi ---
Created attachment 59414
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59414&action=edit
Disassembled executable
Since the error seems to be system-dependent, I disassembled the failing
executable w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117264
--- Comment #7 from Vladimir Terzi ---
(In reply to anlauf from comment #5)
> Please show the exact failing code.
I noticed that my comment is somewhat misleading, so I will clarify.
(In reply to Vladimir Terzi from comment #4)
> That's strang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117264
--- Comment #4 from Vladimir Terzi ---
(In reply to kargls from comment #3)
> Works for me with 13.2.0, 14.2.0, and top of tree on x86_64-*-freebsd.
>
> You can also do the allocation explicitly instead of allocation
> on assignment.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117264
--- Comment #2 from Vladimir Terzi ---
(In reply to anlauf from comment #1)
> Confirmed up to current trunk.
>
> As a workaround, you may try the result clause on function f, e.g.:
>
> function f() result(r)
> class(t), allocatable :: r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117264
Bug ID: 117264
Summary: Segfault when using assignment for allocatable class
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336
Vladimir Terzi changed:
What|Removed |Added
CC||vterzi1996 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114613
Bug ID: 114613
Summary: ALLOCATE with SOURCE forgets to finalize temporary
instances
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114612
Bug ID: 114612
Summary: Deep copy missing for allocatable derived type
components
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108921
Bug ID: 108921
Summary: ICE: using the result of an impure function in
automatic character allocation
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity
15 matches
Mail list logo
