https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
--- Comment #23 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:eb385a4801c45a1c0574810b45fce9e712d34566
commit r14-167-geb385a4801c45a1c0574810b45fce9e712d34566
Author: Harald Anlauf
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
--- Comment #21 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #19)
> PS: I think what you want to with a runtime check and an undefine
> function result is a good idea. I haven't looked to see where
> and how hard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
--- Comment #20 from anlauf at gcc dot gnu.org ---
Created attachment 54894
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54894=edit
Extended testcase
Testcase for Steve's variant of the diagnostic, checking that we also catch
procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
--- Comment #19 from Steve Kargl ---
On Thu, Apr 20, 2023 at 05:22:59AM +, kargl at gcc dot gnu.org wrote:
>
> I think we agree on all points. Here's the diff I envision.
> NOte, I've restricted it to user defined functions. Remove
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
--- Comment #18 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #17)
> (In reply to Steve Kargl from comment #16)
> > First, note, 'allocated(f())' throws an error.
>
> Agree.
>
> > Now, with the original code,
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
--- Comment #17 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #16)
> First, note, 'allocated(f())' throws an error.
Agree.
> Now, with the original code,
>
> is_allocated(f())
>
> The function reference is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
--- Comment #16 from Steve Kargl ---
On Wed, Apr 19, 2023 at 07:15:50PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
>
> --- Comment #15 from anlauf at gcc dot gnu.org ---
> (In reply to Steve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
--- Comment #15 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #13)
> Note 1 in Fortran 2023, Sec. 8.5.3, p. 100, is non-normative
> text. I suppose one can claim that gfortran should throw an
> error when a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
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=109500
--- Comment #13 from Steve Kargl ---
On Wed, Apr 19, 2023 at 05:25:20PM +, leandro.lupori at linaro dot org
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
>
> I'm trying to check with the issue reporter how extensive is his
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
--- Comment #12 from Leandro Lupori ---
(In reply to anlauf from comment #11)
> Do you have anybody else supporting the view that the code in question
> should work as an extension?
>
I know there is some usage of this extension, in code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
--- Comment #11 from anlauf at gcc dot gnu.org ---
(In reply to Leandro Lupori from comment #10)
> Wouldn't it be better to turn this into a warning?
>
> Although using the result of a function as an allocatable argument doesn't
> conform with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
--- Comment #10 from Leandro Lupori ---
Wouldn't it be better to turn this into a warning?
Although using the result of a function as an allocatable argument doesn't
conform with Fortran standards, it has been supported by gfortran for quite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
--- Comment #9 from anlauf at gcc dot gnu.org ---
The following patch rejects the code in comment#0 and regtests ok:
diff --git a/gcc/fortran/interface.cc b/gcc/fortran/interface.cc
index e9843e9549c..64a54c06800 100644
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2023-04-14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
--- Comment #7 from Steve Kargl ---
On Thu, Apr 13, 2023 at 07:44:36PM +, leandro.lupori at linaro dot org
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
>
> --- Comment #5 from Leandro Lupori ---
> Ok, thanks for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
--- Comment #6 from anlauf at gcc dot gnu.org ---
(In reply to Leandro Lupori from comment #5)
> Ok, thanks for the detailed explanations. Now I see that the standard
> doesn't allow the return of an unallocated value. This can be closed as
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
--- Comment #5 from Leandro Lupori ---
Ok, thanks for the detailed explanations. Now I see that the standard doesn't
allow the return of an unallocated value. This can be closed as invalid.
But may I just ask a last related question? As
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
--- Comment #4 from anlauf at gcc dot gnu.org ---
I think one cannot achieve what the OP wants by using allocable function
results. One should use a subroutine instead.
Compiling the code with the NAG compiler gives:
NAG Fortran Compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to Leandro Lupori from comment #2)
> Thanks for the quick response.
>
> What if 'f' is changed to this:
>
> function f()
> integer, allocatable :: f
>
> allocate(f)
> f = 123
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
--- Comment #2 from Leandro Lupori ---
Thanks for the quick response.
What if 'f' is changed to this:
function f()
integer, allocatable :: f
allocate(f)
f = 123
deallocate(f)
end function
Is the program still invalid? gfortran -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
---
24 matches
Mail list logo
