[Bug fortran/111853] f951: Segmentation fault at gfc_expression_rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111853 --- Comment #4 from Steve Kargl --- On Thu, Mar 14, 2024 at 09:00:22AM +, fxcoudert at gcc dot gnu.org wrote: > > --- Comment #3 from Francois-Xavier Coudert --- > This seems safe to backport, what do you think? > Paul just landed a big patch dealing with a number of ASSOCIATE issues. I have followed all of his changes. I'm not opposed to a backport, but may be more involved than a simple patch.
[Bug fortran/114023] complex part%ref of complex named constant array cannot be used in an initialization expression.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114023 --- Comment #3 from Steve Kargl --- On Wed, Mar 13, 2024 at 06:02:58PM +, jvdelisle at gcc dot gnu.org wrote: > > --- Comment #2 from Jerry DeLisle --- > Steve, Anuj is interested in digging in on this one. This will be a learning > experience. > That's fine with. If Anuj or you have questions or want me to look at something, just ping me.
[Bug fortran/110644] Error in gfc_format_decoder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644 --- Comment #21 from Steve Kargl --- On Fri, Mar 08, 2024 at 08:01:02PM +, kyle.shores44 at gmail dot com wrote: > > (In reply to Steve Kargl from comment #19) > > > > It seems your code is hitting a NULL pointer dereference when > > generating a warning. In resolve.cc(resolve_procedure_expression), > > one finds > > > > /* A non-RECURSIVE procedure that is used as procedure expression within > > its > > own body is in danger of being called recursively. */ > > if (is_illegal_recursion (sym, gfc_current_ns)) > > gfc_warning (0, "Non-RECURSIVE procedure %qs at %L is possibly calling" > > " itself recursively. Declare it RECURSIVE or use" > > " %<-frecursive%>", sym->name, >where); > > > > for whatever reason >where is a NULL pointer. If I change > > the above to remove >where, then your code compiles with > > a bunch of warningsi, e.g., > > > > [ 95%] Building Fortran object > > test/oldtuv/CMakeFiles/oldphotolib.dir/util/la_srb.type.F90.o > > /usr/home/sgk/tmp/tuv-x/test/oldtuv/util/la_srb.type.F90:873:28: > > > > 873 | end module la_srb_type > > |1 > > Warning: Non-RECURSIVE procedure 'get_config_array' at (1) is possibly > > calling itself recursively. Declare it RECURSIVE or use '-frecursive' > > > > Unfortunately, without a much smaller example code, I cannot go > > any further in debugging your problem. > > Well that's odd, that function doesn't call itself recursively > If shuffling the USE statements around allows your code to compile, then it is likely that gfortran cannot tell if there is an indirect recursion. gfortran tries to help the user with a warning about **possible** recursion. There is likely an issue with how gfortran is searching namespaces, but % find . -name \*.F90 | xargs wc -l | grep total 96683 total % find . -name \*.f90 | xargs wc -l | grep total 4238 total Chopping 100 kLOC to something that is managable is beyond what I can do.
[Bug fortran/110644] Error in gfc_format_decoder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644 --- Comment #19 from Steve Kargl --- On Fri, Mar 08, 2024 at 05:42:05PM +, kyle.shores44 at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644 > > --- Comment #17 from Kyle Shores --- > I was able to get tuv-x to compile by putting use statements in problematic > files at the top of the module. In one case, I had to match the use ordering > to > the order that the objects were used in the module (unsure if that mattered), > and I also removed an object in a use only statement that wasn't used in that > same file and then it compiled (these last two issues were for the same file > test/unit/radiator/from_host.F90) > > It seems your code is hitting a NULL pointer dereference when generating a warning. In resolve.cc(resolve_procedure_expression), one finds /* A non-RECURSIVE procedure that is used as procedure expression within its own body is in danger of being called recursively. */ if (is_illegal_recursion (sym, gfc_current_ns)) gfc_warning (0, "Non-RECURSIVE procedure %qs at %L is possibly calling" " itself recursively. Declare it RECURSIVE or use" " %<-frecursive%>", sym->name, >where); for whatever reason >where is a NULL pointer. If I change the above to remove >where, then your code compiles with a bunch of warningsi, e.g., [ 95%] Building Fortran object test/oldtuv/CMakeFiles/oldphotolib.dir/util/la_srb.type.F90.o /usr/home/sgk/tmp/tuv-x/test/oldtuv/util/la_srb.type.F90:873:28: 873 | end module la_srb_type |1 Warning: Non-RECURSIVE procedure 'get_config_array' at (1) is possibly calling itself recursively. Declare it RECURSIVE or use '-frecursive' Unfortunately, without a much smaller example code, I cannot go any further in debugging your problem.
[Bug fortran/110644] Error in gfc_format_decoder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644 --- Comment #16 from Steve Kargl --- On Fri, Mar 08, 2024 at 04:44:52PM +, kyle.shores44 at gmail dot com wrote: > I have not made a smaller example, but we have since removed json-fortran as a > dependency for tuv-x. > > So it should be easier to view the failure in tuv-x. I have not made the time > to try to reduce the code to an example, but maybe this could help. > > Following this instructions should show an error > > git clone https://github.com/NCAR/tuv-x > cd tuv-x > mkdir build && cd build > FC=g++-13 cmake .. > make > FC=g++-13? Should that be gfortran13? I get % env FC=/usr/home/sgk/work/x/bin/g++ cmake .. -- The Fortran compiler identification is GNU 14.0.1 -- The CXX compiler identification is GNU 14.0.1 -- The C compiler identification is GNU 14.0.1 -- Detecting Fortran compiler ABI info -- Detecting Fortran compiler ABI info - failed -- Check for working Fortran compiler: /usr/home/sgk/work/x/bin/g++ -- Check for working Fortran compiler: /usr/home/sgk/work/x/bin/g++ - broken CMake Error at /usr/local/share/cmake/Modules/CMakeTestFortranCompiler.cmake:59 (message): The Fortran compiler "/usr/home/sgk/work/x/bin/g++"
[Bug fortran/114141] ASSOCIATE and complex part ref when associate target is a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114141 --- Comment #11 from Steve Kargl --- On Thu, Feb 29, 2024 at 06:33:51PM +, pault at gcc dot gnu.org wrote: > --- Comment #10 from Paul Thomas --- > (In reply to Jerry DeLisle from comment #9) > > --- snip --- > > > % gfcx -o z a.f90 > > > a.f90:5:6: > > > > > > 5 | x%im = 42 > > > | 1 > > > Error: 'x' at (1) associated to expression cannot be used in > > > a variable definition context (assignment) > > > > > > Mikael, thanks for the feedback. I'll see if I can fix > > > the parentheses case this weekend. > > > > This is definitely a 42 case, which is why I had three '?' in my reply. > > > > And if you understand this, you are OK in my book. :) > > BTW Both nagfor and ifort compile the testcase without complaint. > > Your fix is closely related to my patch for not-yet-parsed function selectors. > I know you had some ASSOCIATE patches in the works, and certainly do not want to interfere. Do you want to incorporate my patch or some variation into your work? I'm hoping to take a stab at the issue Jerry raised with parentheses this weekend.
[Bug fortran/114141] ASSOCIATE and complex part ref when associate target is a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114141 --- Comment #8 from Steve Kargl --- On Wed, Feb 28, 2024 at 08:24:16PM +, sgk at troutmask dot apl.washington.edu wrote: > > Indeed. Bit more reading of F2023, 11.1.3 agrees with you. > >11.1.3.1 > >The ASSOCIATE construct associates named entities with expressions >or variables during the execution of its block. These named construct >entities (19.4) are associating entities (19.5.1.6). The names are >associate names. > >11.1.3.3(5) The associating entity itself is a variable, but ... > > The "but ..." applies to whether the selector is a definable variable. > > So, 'y = x%im' is allowed, but 'x%im = 42' is disallowed because > the selector is not definable. Interesting twist. This then > suggests that Jerry's use of parentheses should be accepted. > As a quick follow-up. program p associate(x => sin(cmplx(0.5,0.5))) print *, x print *, x%im ! <-- allowed with my patch x%im = 42 ! <-- this is an error print *, x end associate end % gfcx -o z a.f90 a.f90:5:6: 5 | x%im = 42 | 1 Error: 'x' at (1) associated to expression cannot be used in a variable definition context (assignment) Mikael, thanks for the feedback. I'll see if I can fix the parentheses case this weekend.
[Bug fortran/114141] ASSOCIATE and complex part ref when associate target is a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114141 --- Comment #7 from Steve Kargl --- On Wed, Feb 28, 2024 at 07:27:24PM +, mikael at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114141 > > --- Comment #6 from Mikael Morin --- > (In reply to kargl from comment #5) > > (In reply to Mikael Morin from comment #4) > > > > > (In reply to kargl from comment #3) > > > > Yep, agreed. I went back an re-read the section about ASSOCIATE. > > > > Not sure how I convinced myself that a constant expression, which > > > > reduces to a constant is okay. > > > > > > > Not sure how you convinced yourself it isn't. ;-) > > > > x => log(cmplx(-1,0)) > > > > R1104 association is associate-name => selector > > > > R1105 selector is expr > >or variable > > > > R902 variable is designator > >or function-reference > > > > R901 designatoris object-name > >or array-element > >or array-section > >or coindexed-named-object > >or complex-part-designator > >or structure-component > >or substring > > > > log(cmplx(-1,0)) is certainly not a designator. > > > > log(cmplx(-1,0)) is a function-reference. But this then > > leads to > > > > C902 (R902) function-reference shall have a data pointer result. > > > > > > log(cmplx(-1,0)) violates C902, so this then means that it > > must be an expr. > Agreed. > > > One now needs > > > > > > R915 complex-part-designator is designator % RE > > or designator % IM > > > > C922 (R915) The designator shall be of complex type. > > > > which shows that expr%im is invalid; even though log(cmplx(-1,0)) > > reduces to a constant (i.e., it's not a named constant. This > > is likely the error [pun intended] in my ways.). > > > This is about x%im, which is a different expression from log(cmplx(-1, 0)). > x is an associate-name, and thus (I think) an object-name, and a valid > designator, even if it's associated selector isn't. > Indeed. Bit more reading of F2023, 11.1.3 agrees with you. 11.1.3.1 The ASSOCIATE construct associates named entities with expressions or variables during the execution of its block. These named construct entities (19.4) are associating entities (19.5.1.6). The names are associate names. 11.1.3.3(5) The associating entity itself is a variable, but ... The "but ..." applies to whether the selector is a definable variable. So, 'y = x%im' is allowed, but 'x%im = 42' is disallowed because the selector is not definable. Interesting twist. This then suggests that Jerry's use of parentheses should be accepted.
[Bug fortran/114024] ICE allocate statement with source=cmp%re and z an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114024 --- Comment #1 from Steve Kargl --- On Tue, Feb 20, 2024 at 09:42:21PM +, kargl at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114024 > > allocate (xx, source = cmp%re) > > > gfcx -c 0093/0093_0130.f90 > 0093/0093_0130.f90:10:36: > >10 | allocate (xx, source = cmp(1:3)%re) > |1 Whoops. Wrong backtrace. Nonetheless, I still has an issue with cmp%re. Note, inserting parentheses allows the code to compile, i.e, 'source = (cmp%re))'.
[Bug fortran/113883] allocatable length parameter used but is undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113883 --- Comment #4 from Steve Kargl --- On Tue, Feb 13, 2024 at 04:51:02AM +, cvs-commit at gcc dot gnu.org wrote: > The trunk branch has been updated by Jerry DeLisle : > > https://gcc.gnu.org/g:6caec7d9ec37e60e718a12934c85bac9c12757ac > Thanks, Jerry.
[Bug fortran/113845] ice in gfc_get_array_ss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113845 --- Comment #5 from Steve Kargl --- On Fri, Feb 09, 2024 at 10:06:47PM +, anlauf at gcc dot gnu.org wrote: > > --- Comment #4 from anlauf at gcc dot gnu.org --- > Created attachment 57374 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57374=edit > Proof-of-concept patch > > The attached - hackish - patch tries to avoid the infinite recursion by > fixing up the character length especially for the intrinsics ADJUST[LR]. > > I'm not entirely happy with this, but could not yet find a better place. > And in gfc_resolve_adjustl the backend_decl is not yet set. > You're much quicker than I! I only just identified the infinite recursion and where it was occurring in the scalarizer. I got sidetrack on a whole different issue. I'm wondering if we need to worry about other actual arguments. I note subroutine test_adjustl(x) character(*) :: x(100) x = adjustl(x) call bar(x) end subroutine does not cause problems.
[Bug fortran/113823] ice in gfc_get_element_type, at fortran/trans-types.cc:1286
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113823 --- Comment #7 from Steve Kargl --- On Thu, Feb 08, 2024 at 08:43:08PM +, dcb314 at hotmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113823 > > --- Comment #6 from David Binderman --- > (In reply to Steve Kargl from comment #5) > > That's not what I meant. There is no bug1006.f90 in > > the llvm-project repo. What is the actual URL to the > > actual testcase? It should look something like > > > > https://github.com/llvm/llvm-project/tree/main/flang/test/bug1006.f90 > > bug1006.f90 is my local file name for it. > > It is just a copy of the original file > Lower/HLFIR/array-ctor-derived.f90 in the flang test suite. > > That has an URL of > https://github.com/llvm/llvm-project/tree/main/flang/test/Lower/HLFIR/array-ctor-derived.f90 > Thanks. This may allow a gfortran contributor to see how other developers handled the code. Although not with this bug report, some contain an analysis of what the Fortran standard requires with a particular piece of code.
[Bug fortran/113823] ice in gfc_get_element_type, at fortran/trans-types.cc:1286
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113823 --- Comment #5 from Steve Kargl --- On Thu, Feb 08, 2024 at 07:38:59PM +, dcb314 at hotmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113823 > > --- Comment #4 from David Binderman --- > (In reply to kargl from comment #3) > > If you do post the others, is it possible to include a URL to LLVM > > repository? This will allow us to give proper credit for the code. > > https://github.com/llvm/llvm-project/ > That's not what I meant. There is no bug1006.f90 in the llvm-project repo. What is the actual URL to the actual testcase? It should look something like https://github.com/llvm/llvm-project/tree/main/flang/test/bug1006.f90
[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152
--- Comment #17 from Steve Kargl ---
On Mon, Jan 22, 2024 at 05:35:41PM +, anlauf at gcc dot gnu.org wrote:
> --- Comment #16 from anlauf at gcc dot gnu.org ---
> (In reply to Steve Kargl from comment #14)
> > On Sun, Jan 21, 2024 at 09:52:39PM +, anlauf at gcc dot gnu.org wrote:
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152
> > >
> > > I think that you cannot do
> > >
> > > + if (MPFR_HALF_CYCLE)
> > >
> > > you really must use
> > >
> > > #if MPFR_HALF_CYCLE
> > >
> >
> > #include
> > #include "mpfr.h"
> >
> > #define MPFR_HALF_CYCLE (MPFR_VERSION_MAJOR * 100 + MPFR_VERSION_MINOR >=
> > 402)
> >
> > int
> > main(void)
> > {
> >if (MPFR_HALF_CYCLE)
> > printf("here\n");
> >else
> > printf("there\n");
> >return (0);
> > }
> >
> > % cc -o z -I/usr/local/include a.c && ./z
>
> This does not test the right thing.
>
> % cat sgk.cc
> #include
>
> #define MPFR_HALF_CYCLE 0
This is not what the pre-processor should be doing
(on at least FreeBSD). See below.
> int
> main(void)
> {
>if (MPFR_HALF_CYCLE)
> printf_not_declared_if_0 ("here\n");
>else
> printf ("there\n");
>return (0);
> }
>
> % g++ sgk.cc
> sgk.cc: In function 'int main()':
> sgk.cc:9:7: error: 'printf_not_declared_if_0' was not declared in this scope
>printf_not_declared_if_0 ("here\n");
>^~~~
Of course, it will fail. You need to actually have a
printf_not_declared_if_0 function defined during parsing.
#include
#include
#define MPFR_HALF_CYCLE 1
#define printf_not_declared_if_0(a) abort()
int
main(void)
{
if (MPFR_HALF_CYCLE)
printf_not_declared_if_0 ("here\n");
else
printf ("there\n");
return (0);
}
~/work/x/bin/g++ -I/usr/local/include -o z a.cc && ./z
Abort (core dumped)
Changing 1 to 0 the MPFR_HALF_CYCLE define.
~/work/x/bin/g++ -I/usr/local/include -o z a.cc && ./z
there
Going back to my original example and g++ from master, I'm seeing
% ~/work/x/bin/g++ -I/usr/local/include -E a.cc
int
main(void)
{
if ((
# 9 "a.cc" 3
4
# 9 "a.cc"
* 100 +
# 9 "a.cc" 3
2
# 9 "a.cc"
>= 402))
printf("here\n");
else
printf("there\n");
return (0);
}
and with clang++
% c++ -E -I/usr/local/include a.cc
int
main(void)
{
if ((4 * 100 + 2 >= 402))
printf("here\n");
else
printf("there\n");
return (0);
}
Is there something that is different between your OS and FreeBSD?
Or is there some fundamental difference between C and C++ that
I am unaware of?
[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152
--- Comment #14 from Steve Kargl ---
On Sun, Jan 21, 2024 at 09:52:39PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152
>
> I think that you cannot do
>
> + if (MPFR_HALF_CYCLE)
>
> you really must use
>
> #if MPFR_HALF_CYCLE
>
#include
#include "mpfr.h"
#define MPFR_HALF_CYCLE (MPFR_VERSION_MAJOR * 100 + MPFR_VERSION_MINOR >= 402)
int
main(void)
{
if (MPFR_HALF_CYCLE)
printf("here\n");
else
printf("there\n");
return (0);
}
% cc -o z -I/usr/local/include a.c && ./z
here
% cc -E -I/usr/local/include a.c | grep -v mpfr_ | grep -v gmp | cat -s
...
int
main(void)
{
if ((4 * 100 + 2 >= 402))
printf("here\n");
else
printf("here\n");
return (0);
}
Are you sure that your testing is finding the right mpfr.h?
If I add
#ifdef MPFR_VERSION_MAJOR
#undef MPFR_VERSION_MAJOR
#endif
#define MPFR_VERSION_MAJOR 3
above the define for MPFR_HALF_CYCLE in simplify.cc, it compiles
for me. With this simple program
real, parameter :: x = cospi(1.)
print *,x
end
gdb ends up in the else { } branch.
Breakpoint 1, gfc_simplify_cospi (x=0x803e24b60)
at ../../gcc/gcc/fortran/simplify.cc:2085
2085 result = gfc_get_constant_expr (x->ts.type, x->ts.kind, >where);
(gdb) n
2101 mpfr_inits2 (2 * mpfr_get_prec (x->value.real), cs, n, r, NULL);
[Bug fortran/82943] [F03] Error with type-bound procedure of parametrized derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82943 --- Comment #17 from Steve Kargl --- On Sat, Jan 20, 2024 at 09:37:17PM +, jvdelisle at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82943 > > --- Comment #16 from Jerry DeLisle --- > (In reply to Alexander Westbrooks from comment #15) > > Created attachment 57176 [details] > > Proposed Patch to fix PR82943, PR86148, PR86268 > > I am attempting to roll with this. Steve, do you know where the copyright > assignment forms are? I a,m hunting for them and I asked on the gcc IRC > channel > as well. > I beleive that FSF assignments are not public. It's been along since I dealt with someone getting an assignment. I recall asking someone on the GCC steering committee for confirmation. I haven't dealt with the DCO method.
[Bug libfortran/113313] execute_command_line hangs at run time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113313
--- Comment #7 from Steve Kargl ---
On Thu, Jan 11, 2024 at 07:03:05AM +, john.harper at vuw dot ac.nz wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113313
>
> --- Comment #2 from john.harper at vuw dot ac.nz ---
> Thank you! You may wish to know that in my Ubuntu system the program
> runs properly if the function iam is used in an assignment statement not a
> print statement.
Interesting. One of the first things that the internal
implementation does is
/* Flush all I/O units before executing the command. */
flush_all_units();
libgfortran is supposedly thread-safe and looking into
flush_all_units() shows some unlocking and testing for
locks. With 'print *, iam('john')', there may be lock
contention.
[Bug fortran/113305] ICE with do concurrent and ivdep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113305 --- Comment #5 from Steve Kargl --- On Wed, Jan 10, 2024 at 06:24:40PM +, ivan.pribec at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113305 > > --- Comment #3 from Ivan Pribec --- > In the mail archive > (https://gcc.gnu.org/legacy-ml/fortran/2014-02/msg00077.html) I've read a > message implying that do concurrent gets translated into a regular for-loop > annotated with "#pragma ivdep", which assures the loop optimizer there are no > loop-carried dependencies. That said, I'm aware there is no good reason why > you'd want to use this directive on a do concurrent loop. > Note, I'm not saying that using '!GCC$ ivdep' is wrong. It's that gfortran parses the do-concurrent correctly, but whatever compiler pass(es) that ivdep activates seems to mishandle the terminated linked list. it->var holds information about 'i' and it->next points to the next do-index if one exists or is NULL. ivdep seems to corrupt the NULL.
[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152 --- Comment #11 from Steve Kargl --- On Fri, Dec 29, 2023 at 08:34:38PM +, anlauf at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152 > > --- Comment #10 from anlauf at gcc dot gnu.org --- > (In reply to kargl from comment #0) > > Created attachment 56949 [details] > > patch with implementation > > Not a review, just a comment: > > diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc > index 87fefe46cfd..4e546ddb8fa 100644 > --- a/gcc/fortran/simplify.cc > +++ b/gcc/fortran/simplify.cc > @@ -30,6 +30,14 @@ along with GCC; see the file COPYING3. If not see > #include "constructor.h" > #include "version.h" /* For version_string. */ > > +/* MPFR 4.2.0 introduced half-cycle trigonometric functions, e.g., sinpi(x). > + Introduce a macro so older versions of the MPFR can still be used. */ > + > +#ifdef MPFR_HALF_CYCLE > +#undef MPFR_HALF_CYCLE > +#endif > +#define MPFR_HALF_CYCLE (MPFR_VERSION_MAJOR > 3 && MPFR_VERSION_MINOR > 1) > + > /* Prototypes. */ > > > This does not look right, as it would exclude e.g. all mpfr-[5-9].[01] > How about: > > #define MPFR_HALF_CYCLE (MPFR_VERSION_MAJOR * 100 + MPFR_VERSION_MINOR >= 402) > Indeed, it looks like I'm skipping all .0 and .1 minor releases. I'll adopt your suggestion, and include it in an updated patch.
[Bug fortran/112873] F2023 degree trig functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 --- Comment #28 from Steve Kargl --- On Thu, Dec 14, 2023 at 08:35:32PM +, jvdelisle at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 > > --- Comment #27 from Jerry DeLisle --- > Created attachment 56882 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56882=edit > Description changes > > This is what I arrived at going through. OK? > Thanks. That looks goog, but I think we need to also update what is returned. ASIND has The real part of the result is in degrees and lies in the range -90 \leq \Re \asin(x) \leq 90. Writing the "The real part of" seems redundant if not a bit misleading.
[Bug fortran/112873] F2023 degree trig functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
--- Comment #25 from Steve Kargl ---
On Thu, Dec 14, 2023 at 07:48:08PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
>
> --- Comment #24 from anlauf at gcc dot gnu.org ---
> (In reply to Jerry DeLisle from comment #23)
> > I am going to suggest the following. The wording was confusing around the
> > functionality of the option vs the intrinsics. Hope this is OK?
> >
> > @opindex @code{fdec-math}
> > @item -fdec-math
> > Obsolete flag. The purpose of this option was to
> > enable legacy math intrinsics such as COTAN and degree-valued trigonometric
> > functions (e.g. TAND, ATAND, etc...) for compatibility with older code. This
> > option is no longer operable. The trigonometric functions are now either
> > part of Fortran 2023 or GNU extensions.
>
> I am not a native speaker, so this is certainly better than what I wrote.
>
Your English is much better than my non-existent German. ;-)
The above is fine for the -fdec-math option. However, we'll need
to audit the description of each function to cleanup the non-support
for complex. For example, ASIND has
_Arguments_:
X The type shall be either ‘REAL’ and a magnitude
that is less than or equal to one - or be ‘COMPLEX’.
_Return value_:
The return value is of the same type and kind as X. The real part
of the result is in degrees and lies in the range -90 \leq \Re
\asin(x) \leq 90.
These should likely read
_Arguments_:
X The type shall be ‘REAL’. The magnitude of X should be
less than or equal to one.
_Return value_:
The return value is of the same type and kind as X. The
result is in degrees and lies in the range -90 \leq \Re
\asin(x) \leq 90.
[Bug fortran/112873] F2023 degree trig functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 --- Comment #19 from Steve Kargl --- On Thu, Dec 14, 2023 at 05:03:35PM +, jvdelisle at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 > > --- Comment #18 from Jerry DeLisle --- > I have the patch applied. > > make pdf and make info work as expected. I fixed a minor typo in a comment > for > intrinsic.cc. I have a few of the git magics to do. Shall I submit to the list > before commit? > Given that Harald reviewed my initial submission, and you now have taken the patch and reviewed it sufficiently to find a typo, I think you can commit it. Submit whatever you've committed to the list and refer to the PR for our discussion.
[Bug fortran/112873] F2023 degree trig functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 --- Comment #17 from Steve Kargl --- On Wed, Dec 13, 2023 at 05:36:55PM +, jvdelisle at gcc dot gnu.org wrote: > > Do we need any other test cases? > I think that we need not added any testcases. The degree trig function have been available for awhile now. The patch simply changes the visibility to be F2023 instead of a DEC Fortran extension.
[Bug fortran/112873] F2023 degree trig functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 --- Comment #15 from Steve Kargl --- On Mon, Dec 11, 2023 at 07:53:01PM +, jvdelisle at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 > > --- Comment #13 from Jerry DeLisle --- > (In reply to anlauf from comment #12) > > > Jerry or myself can do the commit later. > > > > Looking at my addition again, I think that this change to invoke.texi: > > > > "... These functions are now GNU extensions." > > > > should correctly read: "These functions are now either part of Fortran 2023 > > or GNU extensions." > > > > Note to myself to fix this. > > Hi Harald and Steve, please let me commit this for the practice. I will fix > that last comment you made and see how this goes. > Jerry, are you starting with the patch submitted by Harald that fixes the doc issue. It seems 'gmake pdf', which is what I use to check doc changes, works while 'gmake info' fails. I assume that this is how Harald found the issue. Thanks for taking up the commit.
[Bug fortran/112873] F2023 degree trig functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 --- Comment #11 from Steve Kargl --- On Sun, Dec 10, 2023 at 09:45:33PM +, anlauf at gcc dot gnu.org wrote: > > here's a minor update that fully removes the "Extended math intrinsics" node. > Otherwise your patch would not compile here. Once agin thanks. I thought I did a 'gmake pdf' after my changes, but may have missed that step. > The flag -fdec-math now seems fully dysfunctional, i.e. it does nothing. > I adjusted the documentation (intrinsic.texi, invoke.texi) declaring it > obsolete. In looking (briefly) at -fdec-math, I'm not sure it ever had an effect. I left -fdec-math in options.cc for backwards compatibilities in Makefiles as it should be a no-opt. > Can you have a look? If you think everything is fine, please submit to the > ML so that others have a chance to have a look. Or should I do it? I'll give your updated patch a scan early next week. I can submit the patch to both fortran@ and gcc-patches@. AS you know, I won't be committing it as I am too git incompetent to do so.
[Bug fortran/112873] F2023 degree trig functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
--- Comment #7 from Steve Kargl ---
On Thu, Dec 07, 2023 at 07:59:25PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
>
> --- Comment #6 from anlauf at gcc dot gnu.org ---
> (In reply to Steve Kargl from comment #5)
> > On Wed, Dec 06, 2023 at 09:58:18PM +, anlauf at gcc dot gnu.org wrote:
> > > In your experience, how good (or bad) is a naive inline version
> > > like we do for the degree versions?
> >
> > It would be possible to use a naive version, but it will
> > likely not approach the requirements placed on these functions
> > by at least the IEEE 754 and C23 standards.
>
> I see. The naive version would have done only range reduction and scaling,
> maybe good enough for F2023 ("SINPI (X) is approximately equal to SIN (X×π)")
> but not more.
>
> Also, one needs mpfr-4.2.0 or higher for simple simplification, or do more
> work.
Correct. A newer version of MPFR contains these functions. In fact,
the MPFR developer and I cross-checked each other. We can probably
use a naive implementation with high precision if an older MPFR is
used.
> > I think gfortran
> > should test with configure for these functions in libm and
> > use those if available (e.g., HAVE_COSPI, etc). In libgfortran,
> > we'll need fallbacks if not available. To see the complexity
> > of the implementation details see
> >
> > https://cgit.freebsd.org/src/tree/lib/msun/src/s_cospi.c
> >
> > Header files defining computation kernels and these use
> > the computation kernels for sin() and cos() from fdlibm.
> >
> > https://cgit.freebsd.org/src/tree/lib/msun/src/k_cospi.h
> > https://cgit.freebsd.org/src/tree/lib/msun/src/k_sinpi.h
> >
> > Note, AFAIK, glibc does not implement these functions.
>
> Right.
>
> Would you like to open a separate PR for dealing with the half-cycle
> trigonometric functions?
Yes, I'll add a new PR for the half-cycle functions, and
point to here for the initial discussion.
[Bug fortran/112873] F2023 degree trig functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 --- Comment #5 from Steve Kargl --- On Wed, Dec 06, 2023 at 09:58:18PM +, anlauf at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 > > anlauf at gcc dot gnu.org changed: > >What|Removed |Added > > Ever confirmed|0 |1 >Last reconfirmed||2023-12-06 > Status|UNCONFIRMED |NEW > > --- Comment #4 from anlauf at gcc dot gnu.org --- > (In reply to Steve Kargl from comment #3) > > PS: I implemented the half-cycle trig functions (e.g., sinpi, ...) for > > FreeBSD a few years ago. These have a 2-clause BSD license. I'm > > willing to dual-license the code with LGPL if you think these might > > be good fallback routines. > > Thanks for the offer. But do we actually need fallback routines? > > In your experience, how good (or bad) is a naive inline version > like we do for the degree versions? It would be possible to use a naive version, but it will likely not approach the requirements placed on these functions by at least the IEEE 754 and C23 standards. I think gfortran should test with configure for these functions in libm and use those if available (e.g., HAVE_COSPI, etc). In libgfortran, we'll need fallbacks if not available. To see the complexity of the implementation details see https://cgit.freebsd.org/src/tree/lib/msun/src/s_cospi.c Header files defining computation kernels and these use the computation kernels for sin() and cos() from fdlibm. https://cgit.freebsd.org/src/tree/lib/msun/src/k_cospi.h https://cgit.freebsd.org/src/tree/lib/msun/src/k_sinpi.h Note, AFAIK, glibc does not implement these functions. Finally, for FreeBSD's cospif(x), here's exhaustive testing for its floating accuracy: % tlibm cospi -x 0x1p-9 -X 0x2p23 -fDE cospi Interval tested for cospif: [0.00195312,1.67772e+07] count: 276824064 (276824064) xm = 6.66955039e-02f, /* 0x3d8897a7 */ flt = 9.78128791e-01f, /* 0x3f7a66a6 */ dbl = 9.7812876099954837e-01, /* 0x3fef4cd4, 0xaff8a456 */ ULP = 0.50090
[Bug fortran/112873] F2023 degree trig functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
--- Comment #3 from Steve Kargl ---
On Wed, Dec 06, 2023 at 08:56:32PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
>
> --- Comment #2 from anlauf at gcc dot gnu.org ---
> The patch looks mostly fine, but can you explain why you make some of the
> specific functions generic? Like:
>
> + make_generic ("dacosd", GFC_ISYM_ACOSD, GFC_STD_GNU);
>
> Because we do not make the ordinary specific dacos generic, only acos.
I'm probably mis-remembering how make_generic() works. I'll look
at this PR over weekend and fix up the patch.
> Do you also plan to provide a patch for gfortran.texi abd intrinsic.texi?
Whoops. I forgot about the *.texi files. I'll update those this
weekend as well.
Thanks for the response.
PS: I implemented the half-cycle trig functions (e.g., sinpi, ...) for
FreeBSD a few years ago. These have a 2-clause BSD license. I'm
willing to dual-license the code with LGPL if you think these might
be good fallback routines.
[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684 --- Comment #25 from Steve Kargl --- On Mon, Nov 06, 2023 at 03:34:42PM +, trnka at scm dot com wrote: > > If expr->where is pointing to NULL, then something is definitely not > > set up correctly or your code is now going through a different code > > path in the compiler. > > Sorry for the delay with testing this, I was busy with other more pressing > tasks. No problem. I have very limited time to look at gfortran bugs and yours caught my eye. > It's not that expr->where would be NULL completely, but its components (nextc > and lb) are both NULL. Sorry about that. I did mean to say the components not just expr->where. In any event, the locus is clearly not correct. > > If this is related to setting up the artificial __final_* procedure, > > then it might be missing properly setting the locus. This patch > > simply sets the locus of the artificial procedure and its arguments > > to that of the derived symbol. This might prevent the ICE, but > > lead to a bogus error message. Can you test this? > > Tested, does not change a thing. The error does not seem to directly have > anything to do with the __final_*, but with building the __vtab_* using a > structure constructor, which is likely happening at a different place as > a side effect of Paul's finalization improvements. Bummer. I was hoping that it would give a better pointer to where gfortran needs to handle the locus. > As this seems to be a different (although possibly related) issue, > I have created PR112407 for further follow-up and posted my new > observations in there. I saw the new PR. Thanks for the in depth analysis. In setting up the constructor for a __vtab_* (an internal symbol), we likely need to ensure the locus is properly set in each list member.
[Bug fortran/104649] ICE in gfc_match_formal_arglist, at fortran/decl.cc:6733 since r6-1958-g4668d6f9c00d4767
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104649 --- Comment #7 from Steve Kargl --- On Fri, Oct 27, 2023 at 05:18:02PM +, cvs-commit at gcc dot gnu.org wrote: > > > commit r14-4983-gc6430d3e6d3279c7e4be9d189031a17bb3dec347 > Author: Harald Anlauf > Date: Thu Oct 26 22:32:35 2023 +0200 > Thanks for taking care of this issue. Sorry about missing the second case, and good catch.
[Bug fortran/110644] Error in gfc_format_decoder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644 --- Comment #11 from Steve Kargl --- On Fri, Oct 20, 2023 at 03:13:06PM +, aluaces at udc dot es wrote: > Ok, indeed they were some warnings. I had to use _current_locus, as you > suggested, so now all of them are pointed at the end of the file. Yeah, this is one of the places I though it would point to. The other place would be the first line in the file. Either way, it is bogus location. > Yes, I am using OOP: we have a "states" class that has its assignment and copy > methods. Those are the ones that I think that they are called implicitly by > the compiler, and gfortran is struggling to point exactly where. Thanks for confirmation. When a 'class' entity is involved, gfortran may generate an internal entity to resolve the class. Unfortunately, the location information is sometimes not properly propagated, and it seems you've found one of those places. > I think now I may be able to get a minimal case for aiding solving this bug. > Let me see if I can. This would be much appreciated. BTW, as it seems you know your way around gdb, if you have a breakpoint set where you found expr->where contained NULL pointers, you can do (gdb) p *expr to dump the structure. You'll see *expr->ts.type == BT_CLASS (basic type CLASS). IIRC, *expr->symtree->name will have the name of the entity. If it starts with __vtab (or _vtab), it is an internally generated symbol.
[Bug fortran/111880] [9/10/11/12/13] False positive warning of obsolescent COMMON block with Fortran submodule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111880 --- Comment #3 from Steve Kargl --- On Thu, Oct 19, 2023 at 05:20:46PM +, zed.three at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111880 > > --- Comment #2 from zed.three at gmail dot com --- > The common block is in 'third_party_module', rather than 'foo', > unless you mean that it is visible from 'foo'? Exactly. 'not_my_code' is in the namespace for foo through use association of third_party_module. It seems that trying to hide 'not_my_code' with PRIVATE or 'use third_party_module, only : some_param' in foo does not mute the warning. Likely, due to -std=f2018 and F2018, Sec. 4.2.
[Bug fortran/110644] Error in gfc_format_decoder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644 --- Comment #9 from Steve Kargl --- On Thu, Oct 19, 2023 at 04:00:10PM +, aluaces at udc dot es wrote: > > No, I meant building *gcc* with those flags, but alas each gcc compilation > stage was still building with "-O2" so almost all of the compiler structures > are still optimized. Ah. Yes, that can be a pain. The only way I've ever "fixed" this problem is hacking configure to use "-O -g" instead of "-O2 -g". > Nevertheless I did what you suggest and climbed up those 6 levels to find that > indeed expr->where has null fields. To me it is not very strange since in my > code there is a structure that has copy and assignment members. gfortran is > arguing about them being called in another module, but of course there is no > physical place where they are called, as this is done implicitly by the > compiler when using those kind of objects, if I am correct. This is definitely a bug in that expr->where should be set. Are you using OOP? > I am rebuilding with your suggested gfc_current_locus change and reporting the > results. It may simply give you nonsense, but the compiliation should continue. This may be a warning that can then be ignored.
[Bug fortran/110644] Error in gfc_format_decoder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644 --- Comment #7 from Steve Kargl --- On Thu, Oct 19, 2023 at 08:00:27AM +, aluaces at udc dot es wrote: > > It says something about a non-recursive function likely calling itself. I > will > inspect my source, even it is a bit too big. Maybe a better solution would be > if I compiled gcc with debugging flags. Can I just use C_FLAGS="-O0 -g" and > CXX_FLAGS="-O0 -g" at configure time, or if is there a specific configure > flag? I doubt that these options will help with this problem. Those are for building your application with debugging info. The issue is the compiler itself is dying. > 1078gcc_assert (loc->nextc - loc->lb->line >= 0); > (gdb) bt > #0 gfc_format_decoder (pp=0x2706750, text=0x7fffb840, spec=0x2708d10 "L", > precision=, wide=false, set_locus=false, hash=false, > quoted=0x7fffb667, buffer_ptr=0x2708b00) > at ../../gcc-13.2.0/gcc/fortran/error.cc:1078 > #1 0x01b44c0a in pp_format (pp=, > text=text@entry=0x7fffb840) at ../../gcc-13.2.0/gcc/pretty-print.cc:1475 > #2 0x01b34e02 in diagnostic_report_diagnostic (context=0x26ee380 > , diagnostic=diagnostic@entry=0x7fffb840) at > ../../gcc-13.2.0/gcc/diagnostic.cc:1592 > #3 0x0071cbc8 in gfc_report_diagnostic (diagnostic=0x7fffb840) at > ../../gcc-13.2.0/gcc/fortran/error.cc:890 > #4 gfc_warning(int, const char *, typedef __va_list_tag __va_list_tag *) > (opt=0, > gmsgid=0x1c9c420 "Non-RECURSIVE procedure %qs at %L is possibly calling > itself recursively. Declare it RECURSIVE or use %<-frecursive%>", > ap=ap@entry=0x7fffb9c8) > at ../../gcc-13.2.0/gcc/fortran/error.cc:923 > #5 0x0071d287 in gfc_warning (opt=opt@entry=0, > gmsgid=gmsgid@entry=0x1c9c420 "Non-RECURSIVE procedure %qs at %L is possibly > calling itself recursively. Declare it RECURSIVE or use %<-frecursive%>") > at ../../gcc-13.2.0/gcc/fortran/error.cc:954 I suspect that the locus associate with %L in the above error message is undefined (i.e., a NULL pointer). This likely means expr in the next frame is missing some info. > #6 0x007a275f in resolve_procedure_expression (expr=0x32a9530) at > ../../gcc-13.2.0/gcc/fortran/resolve.cc:1956 Can you do (gdb) up 6 (gdb) p *expr You'll likely see expr->where is either NULL or its components are. My sources are bit newer, resolve.cc:1974 is if (is_illegal_recursion (sym, gfc_current_ns)) gfc_warning (0, "Non-RECURSIVE procedure %qs at %L is possibly calling" " itself recursively. Declare it RECURSIVE or use" " %<-frecursive%>", sym->name, >where); You can try replacing >where with gfc_current_locus. I don't remember if the & is needed with gfc_current_locus.
[Bug fortran/110644] Error in gfc_format_decoder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
--- Comment #5 from Steve Kargl ---
On Wed, Oct 18, 2023 at 03:56:32PM +, aluaces at udc dot es wrote:
> --- Comment #4 from Alberto Luaces ---
> I got the same error in almost the same circumstances (crash in
> error.cc:1078).
>
> I have a large codebase and I could not prepare a minimal testcase, but I have
> built gfortran 13 from source with the aim to debug the crash.
>
> Hoewever, even I set "set follow-fork-mode children", f951 crashes and I
> cannot
> navigate through the backtrace nor see the arguments of the functions.
>
> Is there any reference for debugging gcc in order to send some useful
> information to this bug?
>
If you've built 13 and still have the source files and build
directory, then locate the installed l f951. For me, I have
${HOME}/work/x/libexec/gcc/x86_64-unknown-freebsd14.0/14.0.0/f951
In following, I'm going to use ${PATH} for the above path.
Go to the directory where your project dies. Suppose it is
compiling foo.f90 when it crashes. Do the following.
gdb ${PATH}/f951
(gdb) b error.cc:1078
(gdb) run foo.f90
Line 1078 is
gcc_assert (loc->nextc - loc->lb->line >= 0);
so the source file information looks corrupt. You may need to
continue the process a few to generate the crash, i.e.,
(gdb) c
(gdb) bt
This will generate a backtrace. Post that.
[Bug fortran/107716] Getting negative values with NINT when using doubleprecision values in range on i386
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107716 --- Comment #6 from Steve Kargl --- On Wed, Sep 20, 2023 at 07:07:37PM +, mikael at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107716 > > --- Comment #5 from Mikael Morin --- > (In reply to kargl from comment #4) > > What the heck does "RESOLVED MOVED"? > > I think it means this PR is not a gcc bug and the problem is tracked on some > other project's bug tracker (it is "moved" there). > > Not sure where else the problem is tracked in this case. > Thanks, Mikael. After a bit of duck-duck-go, I've come to a similar conclusion. <$0.02> If a url/pointer to where the bug is actually tracked is not available, this status should not be used. It is useless. I'll also note that if one clicks on the 'status:' label a list of stati (statuses?) and their meaining can be found. MOVED is not among the list.
[Bug fortran/99711] Crash when reading an allocated character array in namelist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99711 --- Comment #19 from Steve Kargl --- On Thu, Aug 31, 2023 at 12:58:15PM +, philippe.wautelet at aero dot obs-mip.fr wrote: > > What is the status of this bug? > > It seems that it is not present any more in the 12.x and 13.x GCC versions. > Looks like it is fixed by the patch for some other bug report. A scan of gcc/fortran/ChangeLog shows a number patches that tinker with the character length for deferred length strings. I don't which one is the responsiblei, and since I don't use git (other than for trivial 'git diff' and 'git pull') doing a bisection is beyond my skillset. Someone should likely convert your testcase into something that the testsuite can digest, and commit it.
[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684
--- Comment #23 from Steve Kargl ---
On Wed, Aug 09, 2023 at 04:19:52PM +, trnka at scm dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684
>
> --- Comment #22 from Tomáš Trnka ---
> (In reply to Steve Kargl from comment #21)
> > I missed your comment #7 as simply grabbed the "slightly
> > more simplified" attachment and started a bug hunt from there.
> > Do either of the other testcase attachments exhibit the issue?
>
> Unfortunately, none of the testcases attached to this bug happen to trigger
> that particular issue. It seems to pop up in many different modules in our
> codebase, but they are all modules with quite complicated dependency trees, so
> isolating a small testcase from them is not straigtforward (I need to start
> from several tens of thousands of SLOC worth of stuff and manually try to
> reduce it from there, which is tedious at best).
>
> That's why I was hoping one of you GCC devs might have an idea of what could
> possibly be wrong (and some suggestions on what to look at in the gfortran
> internals or which pieces of code to start playing with).
>
> The bad part is that what should just be a warning ends up bringing the
> compiler down because it hits an assert in the diagnostic printing code. Does
> expr->where being completely blank sound suspicious? Perhaps something to do
> with the artificially generated code?
If expr->where is pointing to NULL, then something is definitely not
set up correctly or your code is now going through a different code
path in the compiler. Normally, if the locus can be NULL, one has
something like
if (!expr->where)
gcc_error ("Use last known locus --> %C");
else
gcc_error ("Use expr->where locus--> %L", >where);
You're clearly not getting this.
If this is related to setting up the artificial __final_* procedure,
then it might be missing properly setting the locus. This patch
simply sets the locus of the artificial procedure and its arguments
to that of the derived symbol. This might prevent the ICE, but
lead to a bogus error message. Can you test this?
diff --git a/gcc/fortran/class.cc b/gcc/fortran/class.cc
index 9d0c802b867..ee591793c19 100644
--- a/gcc/fortran/class.cc
+++ b/gcc/fortran/class.cc
@@ -1739,6 +1739,7 @@ generate_finalization_wrapper (gfc_symbol *derived,
gfc_namespace *ns,
name = xasprintf ("__final_%s", tname);
gfc_get_symbol (name, sub_ns, );
sub_ns->proc_name = final;
+ final->declared_at = derived->declared_at;
final->attr.flavor = FL_PROCEDURE;
final->attr.function = 1;
final->attr.pure = 0;
@@ -1756,6 +1757,7 @@ generate_finalization_wrapper (gfc_symbol *derived,
gfc_namespace *ns,
/* Set up formal argument. */
gfc_get_symbol ("array", sub_ns, );
+ array->declared_at = derived->declared_at;
array->ts.type = BT_DERIVED;
array->ts.u.derived = derived;
array->attr.flavor = FL_VARIABLE;
@@ -1774,6 +1776,7 @@ generate_finalization_wrapper (gfc_symbol *derived,
gfc_namespace *ns,
/* Set up formal argument. */
gfc_get_symbol ("byte_stride", sub_ns, _stride);
+ byte_stride->declared_at = derived->declared_at;
byte_stride->ts.type = BT_INTEGER;
byte_stride->ts.kind = gfc_index_integer_kind;
byte_stride->attr.flavor = FL_VARIABLE;
@@ -1787,6 +1790,7 @@ generate_finalization_wrapper (gfc_symbol *derived,
gfc_namespace *ns,
/* Set up formal argument. */
gfc_get_symbol ("fini_coarray", sub_ns, _coarray);
+ fini_coarray->declared_at = derived->declared_at;
fini_coarray->ts.type = BT_LOGICAL;
fini_coarray->ts.kind = 1;
fini_coarray->attr.flavor = FL_VARIABLE;
[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684
--- Comment #21 from Steve Kargl ---
On Wed, Aug 09, 2023 at 10:08:45AM +, trnka at scm dot com wrote:
>
> --- Comment #17 from Tomáš Trnka ---
> (In reply to kargl from comment #10)
> > diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
> > index 3cd470ddcca..b0bb8bc1471 100644
> > --- a/gcc/fortran/resolve.cc
> > +++ b/gcc/fortran/resolve.cc
> > @@ -17966,7 +17966,9 @@ resolve_types (gfc_namespace *ns)
> >
> >for (n = ns->contained; n; n = n->sibling)
> > {
> > - if (gfc_pure (ns->proc_name) && !gfc_pure (n->proc_name))
> > + if (gfc_pure (ns->proc_name)
> > + && !gfc_pure (n->proc_name)
> > + && !n->proc_name->attr.artificial)
> > gfc_error ("Contained procedure %qs at %L of a PURE procedure must "
> >"also be PURE", n->proc_name->name,
> >>proc_name->declared_at);
> >
> > pault, dos the above look correct?
>
> On our codebase, this patch behaves just like the patch in comment #5, in that
> it also triggers the issue described in comment #7 (assert in a warning about
> non-recursive procedures getting called recursively).
>
> Does either of you have any idea as to what that issue could be about? Or is
> isolating a testcase our only hope?
I missed your comment #7 as simply grabbed the "slightly
more simplified" attachment and started a bug hunt from there.
Do either of the other testcase attachments exhibit the issue?
The code in class.cc(generate_finalization_wrapper) sets
final->attr.pure = 0;
final->attr.recursive = 1;
final->attr.artificial = 1;
for the artificial __final_* wrapper function. So, the routine
should be recursive.
[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684
--- Comment #12 from Steve Kargl ---
On Mon, Aug 07, 2023 at 10:04:54PM +, kargl at gcc dot gnu.org wrote:
>
> diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
> index 3cd470ddcca..b0bb8bc1471 100644
> --- a/gcc/fortran/resolve.cc
> +++ b/gcc/fortran/resolve.cc
> @@ -17966,7 +17966,9 @@ resolve_types (gfc_namespace *ns)
>
>for (n = ns->contained; n; n = n->sibling)
> {
> - if (gfc_pure (ns->proc_name) && !gfc_pure (n->proc_name))
> + if (gfc_pure (ns->proc_name)
> + && !gfc_pure (n->proc_name)
> + && !n->proc_name->attr.artificial)
> gfc_error ("Contained procedure %qs at %L of a PURE procedure must "
>"also be PURE", n->proc_name->name,
>>proc_name->declared_at);
>
> pault, dos the above look correct?
>
This patch passes a regression test with no new regressions
on x86_64-*-*freebsd.
[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684 --- Comment #11 from Steve Kargl --- On Mon, Aug 07, 2023 at 10:04:54PM +, kargl at gcc dot gnu.org wrote: > > Note final->attr.pure = 0 seems to contradict C1595 while constructing > the wrapper. I'm not too familiar with this portion of gfortran's > internals. Either the attribute should be set to 1 or the error > message can be suppressed through inspection of final->attr.artificial. > Whoops, I thought I included C1595 Any procedure referenced in a pure subprogram, including oner referenced via a defined operation, defined assignment, defined input/output, or finalization, shall be pure.
[Bug fortran/110825] TYPE(*) dummy argument to generate an unused hidden argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110825 --- Comment #3 from Steve Kargl --- On Wed, Jul 26, 2023 at 08:54:01PM +, anlauf at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110825 > > --- Comment #1 from anlauf at gcc dot gnu.org --- > (In reply to kargl from comment #0) > > Thus, when compiled and executed the program hits 'STOP 1'. Likely, > > gfortran needs to add a possibly unused hidden argument to the argument list > > for a TYPE(*) dummy argument. > > I guess it should be the other way around: if the dummy argument is TPYE(*), > we only pass a reference to the actual argument, but no hidden argument, > as is the case for bind(c). This is also what the called procedure expects. I had not thought about how gfortran handles bind(c). In my codes that use bind(c), I use an array with character(len=1) with the last element set to c_null_char. On the C side, it looks like a C null-terminated string. I don't use type(*) in my codes, so I'm unsure how, or even if, the length type parameter would/(need to) be passed along. > What if the caller passed a type other than character? That's why I wrote '***possibly unused*** hidden argument' > So we just need to update the caller (the "monster" gfc_conv_procedure_call). > > Do you have an idea what would be the use of the hidden argument here anyway? Hmmm, a scan of F2018 suggest that type(*) has rather limited uses C710 An assumed-type variable name shall not appear in a designator or expression except as an actual argument corresponding to a dummy argument that is assumed-type, or as the first argument to the intrinsic function IS_CONTIGUOUS, LBOUND, PRESENT, RANK, SHAPE, SIZE, or UBOUND, or the function C_LOC from the intrinsic module ISO_C_BINDING. I suspect that a hidden argument isn't needed. This means that gfc_conv_procedure_call will need to suppress a hidden argument for a type(*) dummy argument when the actual argument is of character type. > As TYPE(*) is rather new, and I did not find any mentioning of it in the > ABI specification, we should clarify what we want and also document it at > > https://gcc.gnu.org/onlinedocs/gfortran/Argument-passing-conventions.html Sorry, I cannot be of much help. type(*) is well off my radar for my owns codes.
[Bug fortran/99139] ICE: gfc_get_default_type(): Bad symbol '__tmp_UNKNOWN_0_rank_1'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99139 --- Comment #9 from Steve Kargl --- On Sat, Jul 15, 2023 at 06:15:44AM +, pault at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99139 > > --- Comment #8 from Paul Thomas --- > (In reply to anlauf from comment #7) > > Updating known-to-work/known to fail version. > > > > Paul/Steve: do you want to assign this PR to one of you? > > I am of two minds as to whether or not to backport the patch or to close the > PRs as resolved. > > Thoughts? > Is this patch a "side-effect" of your larger attack on ASSOCIATE bugs? If it's independent of that effort, I see no reason to backport.
[Bug fortran/103796] ICE in gfc_conv_expr_val, at fortran/trans-expr.c:9446 since r8-6395-gf8862a1b2afad9d1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103796 --- Comment #7 from Steve Kargl --- On Tue, Jul 04, 2023 at 09:34:02PM +, jvdelisle at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103796 > > Jerry DeLisle changed: > >What|Removed |Added > > CC||jvdelisle at gcc dot gnu.org > > --- Comment #6 from Jerry DeLisle --- > This appears to be fixed on trunk. Can we close it? > Yes. Likely fixed by 2022-05-10 Harald Anlauf PR fortran/105526 * resolve.cc (check_team): New. (gfc_resolve_code): Add checks for arguments to coarray intrinsics FORM TEAM, CHANGE TEAM, and SYNC TEAM.
[Bug fortran/100607] ICE with SELECT RANK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100607 --- Comment #12 from Steve Kargl --- On Fri, Jun 02, 2023 at 06:06:59PM +, anlauf at gcc dot gnu.org wrote: > > --- Comment #11 from anlauf at gcc dot gnu.org --- > Fixed. > Thanks for taking care of the commit.
[Bug fortran/106035] F2018 allows an IMPORT statement within the BLOCK construct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106035 --- Comment #6 from Steve Kargl --- On Fri, Jun 02, 2023 at 05:51:17PM +, jde...@santafe-conicet.gov.ar wrote: > > --- Comment #5 from Jorge D'Elia --- > > The access restriction is a reason of the use IMPORT statements in the > projects, since it is a very convenient and nifty way to detect any name > collision between local entities and host-associated entities, and well as, in > BLOCK statements, for the same purpose. Jorge, I agree with you 100% on the usefulness of IMPORT. The 2nd patch I attached to this PR is almost complete. That is, 'import', 'import, none', and 'import, all' work as defined in F2018. Unfortunately, 'import, only :: a, b, etc' does not work and I haven't had time to work out the details. My first thought is to create a list of allowed use-associated symbols. The list would be added to the current namespace after verifying the symbols are in a parent namespace, but that's as far as I've gotten.
[Bug fortran/109358] Wrong formatting with T-descriptor during stream output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358 --- Comment #7 from Steve Kargl --- On Fri, Jun 02, 2023 at 01:51:02AM +, jvdelisle at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358 > > Jerry DeLisle changed: > >What|Removed |Added > > Status|NEW |ASSIGNED > > --- Comment #6 from Jerry DeLisle --- > I have been doing some additional checking and tried this. It is a variation > which is not STREAM related: > > program tabs > implicit none > integer :: fd > open(newunit=fd, file="test.txt", form="formatted") > write(fd, "(a)") "12345678901234567890123456789" > write(fd, "(i4, t25, t2, i4.4)") 1234, 0123 > close(fd) > end program tabs > > With gfortran gcc 10.4.1 20230121 (GCC) > > $ gfc10 -static -o tabs.x tabs.f90 > $ ./tabs.x > $ cat test.txt > 12345678901234567890123456789 > 12340123 > > It seems to me this should be: > > 10123 > > Am I wrong? > I think you're right. t25 will position you 25 spaces from the left tab limit and then you get repositioned with t2 by 2 spaces from the left tab limit.
[Bug fortran/100607] ICE with SELECT RANK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100607 --- Comment #8 from Steve Kargl --- On Thu, Jun 01, 2023 at 07:26:43PM +, anlauf at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100607 > > --- Comment #7 from anlauf at gcc dot gnu.org --- > (In reply to kargl from comment #6) > > Created attachment 55191 [details] > > patch that fixes bug > > > > The patch, which was previously submitted, still applies and fixes the bug. > > Sure. > > Do you have an answer to your own remarks in comment#5? > I've concluded that the bug was reported 2 years agos. It was fixed by a tentative patch 2 years laters. 'case_value == -1' is for 'rank(*)'. 'case_value == -2' appears to be for non-'rank(*)' cases, and those are handled in the preceding nested for-loop.
[Bug fortran/109865] different results when routine moved inside the contains statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 --- Comment #10 from Steve Kargl --- On Tue, May 16, 2023 at 03:55:51PM +, Gary.White at ColoState dot edu wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 > > --- Comment #9 from GARY.WHITE at ColoState dot edu dot edu> --- > Another clue. I'm seeing the same bug in gfortran-13, except that I have to > use -O0 for both cases of mc11ad.f90 in or out of the contains statement. > > Similarly, if I put the set of va09ad.f90 routines in a module, I have to use > -O0 to get correct answers. -O3 causes a bug with va09ad.f90 in a module as > well. > Can you use valgrind? I got the zip file, but reducing that will be a pain. First, the included lapack, blas, and linpack archives are useless to me. Second, there is just way too much code with a complete lack of familiarity to try to reduce this. I suspect you may have to go old school with 'print *' debugging in the problematic subroutine.
[Bug fortran/109865] different results when routine moved inside the contains statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 --- Comment #4 from Steve Kargl --- On Mon, May 15, 2023 at 07:11:17PM +, Gary.White at ColoState dot edu wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 > (In reply to kargl from comment #2) > > (In reply to gary.wh...@colostate.edu from comment #0) > > > > > Options being used to compile the code: > > > COPTIONS = -cpp -std=f2018 -c -D ieee -D dbleprecision -m64 > > > -fsignaling-nans -ffpe-summary='invalid','zero','overflow','underflow' -O3 > > > -funroll-loops -ffast-math > > > > What happens if you remove -ffast-math and use -O0 or -O1? > > -O0 generates correct code with or without -ffastmath, -O1 does not generate > correct code. I assume you've also tried with -fcheck=all. Your report states you're using og12. If it supports the sanitizer, can you add -fsanitize=undefined to the options?
[Bug fortran/109641] Gfortran fails to overload intrinsic operator (*) if operands are complex. It works with real ones.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109641 --- Comment #9 from Steve Kargl --- On Fri, Apr 28, 2023 at 01:37:48AM +, adelson.oliveira at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109641 > > --- Comment #8 from Adelson Oliveira --- > Then I should have defined the operations with double precision as well? > I have tested, but mostly yes. If I do a -fdump-parse-tree of your code, I see code: ASSIGN teste:v(FULL) 1.e0 ASSIGN teste:m(FULL) (complex 1.e0 1.e0) ASSIGN teste:r(FULL) (* __convert_r4_c4[[((teste:v(FULL)))]] teste:m(FULL)) If you have mixed REAL and DOUBLE PRECISION, you'll likely have an implicit __convert_r4_r8.
[Bug fortran/109575] Implement runtime check for valid function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109575
--- Comment #3 from Steve Kargl ---
On Fri, Apr 21, 2023 at 08:24:45PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109575
>
> --- Comment #2 from anlauf at gcc dot gnu.org ---
> I have some idea how (and where) the runtime checks need to be implemented,
> but I am confused by the following observations on the occurence of an
> explicit RETURN statement and the use of a RESULT variable:
>
> __attribute__((fn spec (". ")))
> integer(kind=4) q2 ()
> {
> integer(kind=4) f;
>
> f = 2;
> return f;
> }
>
>
> __attribute__((fn spec (". ")))
> integer(kind=4) g ()
> {
> integer(kind=4) __result_g;
>
> return __result_g;
> return __result_g;
> }
>
So, if I follow you correctly, you're worried by about
the two 'return __result_g' versus the one 'return f'?
Dead code elimination likely removes the second
'return __result_g'. It indeed seems odd!
[Bug fortran/109500] SIGABRT when calling a function that returns an unallocated value
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
> the esym check will enable it for any subprogram.
>
>
> diff --git a/gcc/fortran/interface.cc b/gcc/fortran/interface.cc
> index db79b104dc2..f3bcdd76d6a 100644
> --- a/gcc/fortran/interface.cc
> +++ b/gcc/fortran/interface.cc
> @@ -3622,6 +3622,18 @@ gfc_compare_actual_formal (gfc_actual_arglist **ap,
> gfc_formal_arglist *formal,
> goto match;
> }
>
> + if (a->expr->expr_type == EXPR_FUNCTION
> + && a->expr->value.function.esym
> + && f->sym->attr.allocatable)
> + {
> + if (where)
> + gfc_error ("Actual argument for %qs at %L is a function result "
> + "and the dummy argument is ALLOCATABLE",
> + f->sym->name, >expr->where);
> + ok = false;
> + goto match;
> + }
> +
>/* Check intent = OUT/INOUT for definable actual argument. */
>if (!in_statement_function
> && (f->sym->attr.intent == INTENT_OUT
>
The patch passes regtesting.
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 this might be to implement.
[Bug fortran/109500] SIGABRT when calling a function that returns an unallocated value
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 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 result is marked with the allocatable > > attribute. > > You mean when the function result is not allocated in that case? First, note, 'allocated(f())' throws an error. Error: 'array' argument of 'allocated' intrinsic at (1) must be a variable You get this error regardless of the allocation status of the function result. Now, with the original code, is_allocated(f()) The function reference is evaluated, and then the function result (aka it's value) is argument associated with an allocatable dummy argument. This is technically wrong as the actual argument (aka value returned by the function reference) should not have the allocatable attribute. Fortran 2018 15.5.2.6 Allocatable dummy variables The requirements in this subclause apply to actual arguments that correspond to allocatable dummy data objects. The actual argument shall be allocatable. It is permissible for the actual argument to have an allocation status of unallocated. I'll repeat. The actual argument is the value resulting from the function reference. The "shall" in "shall be allocatable" applies to something the programmer must ensure. > > Unfortunately, it is likely a catch-22 situation > > in that gfortran needs to know the function result is allocatable > > so it can do the allocaton within the function, but it is not > > an allocatable outside of the function. Not sure gfortran > > can mark an internal symbol to do both. > > I checked how to implement a run-time check for a non-allocated > function result, but did this in the wrong place - in the caller. > This did work when I did allocate and the deallocate before return, > otherwise the result variable is simply undefined, and the check does > not work. > > So a run-time check needs to be put where the function return is generated. > If we go back to the original code and modify to allocate f by say doing 'f = 42' in f(), gfortran produces % gfcx -o z -Wall a.f90 && ./z T This is the problem. Yes, f is allocated and assigned 42. The printed 'T' is bogus because 42 is value of the function. 42 is no allocatable. One place to possibly check for an error is when gfortran resolves argument association. If a dummy argument is allocatable, the actual argument needs to be allocatable and cannot not also be a function result variable.
[Bug fortran/109500] SIGABRT when calling a function that returns an unallocated value
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 usage of this > extension and how much effort it would require for him to avoid using it. > It's not an extension. It is a bug in the original Fortran code. The Fortran standard requires a function result to be available at the completion of execution of a function reference. The code in the original bug report clearly violates this. 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 result is marked with the allocatable attribute. Unfortunately, it is likely a catch-22 situation in that gfortran needs to know the function result is allocatable so it can do the allocaton within the function, but it is not an allocatable outside of the function. Not sure gfortran can mark an internal symbol to do both.
[Bug fortran/109500] SIGABRT when calling a function that returns an unallocated value
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 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 mentioned in the last comment > and according to Note 1 in F2018 8.5.3 ALLOCATABLE attribute, the result of > referencing a function cannot be used as an allocatable argument. This is > however allowed by gfortran (and ifort), with the exception of intrinsic > procedures, and seems to work correctly. Should this be considered an > extension > or does it just work by accident and there are no guarantees at all when using > it? > I suspect it works by accident, but I don't have enough time at the moment to go read the gfortran source. What is likely happening is gfortran checks that the actual and dummy argument both have the allocatable attribute. For the actual argument, the symbol is probably marked an allocatable attribute and an internal attribute that designates this as a function-result, and gfortran does not check for the latter.
[Bug fortran/109453] [REGRESSION] UBOUND incorrect when used in declartion of another array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109453 --- Comment #4 from Steve Kargl --- On Sun, Apr 09, 2023 at 01:25:16AM +, jvdelisle at gcc dot gnu.org wrote: > $ gfc -v > Using built-in specs. > COLLECT_GCC=gfc > COLLECT_LTO_WRAPPER=/home/jerry/dev/usr/libexec/gcc/x86_64-pc-linux-gnu/13.0.1/lto-wrapper > Target: x86_64-pc-linux-gnu > Configured with: ../trunk/configure --prefix=/home/jerry/dev/usr > --enable-languages=c,c++,fortran --enable-libgomp --disable-bootstrap > Thread model: posix > Supported LTO compression algorithms: zlib > gcc version 13.0.1 20230407 (experimental) (GCC) > > So that makes this a regression I believe. I get the expected output with GNU Fortran (GCC) 13.0.1 20230408 (experimental) that I built this morning with Paul's large patch. It definitely fails with GNU Fortran (FreeBSD Ports Collection) 11.3.0 I don't have 12.x installed to test.
[Bug fortran/100607] ICE with SELECT RANK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100607
--- Comment #5 from Steve Kargl ---
On Mon, Apr 03, 2023 at 08:16:20PM +, anlauf at gcc dot gnu.org wrote:
> --- Comment #3 from anlauf at gcc dot gnu.org ---
> (In reply to kargl from comment #2)
> > Remove ice-on-invalid-code as I don't get an ICE.
> >
> > The following patch suppresses the error message with the temporary variable
> > and removes duplicated code. Please commit.
> >
> > diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
> > index 46585879ddc..3462d43f346 100644
> > --- a/gcc/fortran/resolve.cc
> > +++ b/gcc/fortran/resolve.cc
> > @@ -9909,11 +9909,6 @@ resolve_select_rank (gfc_code *code, gfc_namespace
> > *old_ns)
> >|| gfc_expr_attr (code->expr1).pointer))
> > gfc_error ("RANK (*) at %L cannot be used with the pointer or "
> >"allocatable selector at %L", >where,
> > >expr1->where);
> > -
> > - if (case_value == -1 && (gfc_expr_attr (code->expr1).allocatable
> > - || gfc_expr_attr (code->expr1).pointer))
> > - gfc_error ("RANK (*) at %L cannot be used with the pointer or "
> > - "allocatable selector at %L", >where,
> > >expr1->where);
> > }
> >
> >/* Add EXEC_SELECT to switch on rank. */
>
> This is a gem: not dead code, but un-dead code ... ;-)
>
What I haven't concluded yet is if the code was copied
with the intention to edit for another error condition,
e.g., "case_value == -2" or check on code->expr2.
[Bug fortran/109322] -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109322 --- Comment #11 from Steve Kargl --- On Thu, Mar 30, 2023 at 07:21:21PM +, pinskia at gcc dot gnu.org wrote: > > For ILP32 (32bit x86) and LLP64IL32 (64bit Windows/mingw) targets, it will use > c_long_long which is outputted wrong. Anyways I fixed the bug with respect of > c_long_long being outputted incorrectly as long_long rather than "long long" > too. (r13-6940-ga7df3bea9cf1e4 and backported to GCC 12: > r12-9370-g429b75db39aa89 ). > I quite agree that your patch fixed a problem. My comment was meant for the OP, who would like to "integer(c_int64_t) a" translated to "int64_t a;" That's isn't going to happen anytime soon. I left the PR open as an enhancement request. In 10 years, if I'm still around I close it.
[Bug fortran/109322] -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109322
--- Comment #9 from Steve Kargl ---
On Wed, Mar 29, 2023 at 07:42:08PM +, sgk at troutmask dot
apl.washington.edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109322
>
> --- Comment #3 from Steve Kargl ---
> On Wed, Mar 29, 2023 at 05:50:05PM +, emr-gnu at hev dot psu.edu wrote:
> >
> >
> > Extending my original demonstrator, if you add a "INTEGER(KIND=C_INT64_T) ::
> > E", you get the following output:
> >
> > > gfortran -m32 -fc-prototypes -fsyntax-only foo.f90
> >
> > long a;
> > {...}
> > long_long e;
> > } bar;
>
> The companion C processor is gcc. It is generating
> prototypes for that C processor. If one is manipulating
> the environment with a command line option such as -m32
> or -m64, then one likely needs to use the same option
> with gcc. Does 'gcc -m32' support "long_long"? If it
> doesn't, then you'll need to hack on
>
> gcc/fortran/dump-parse-tree.cc
> gcc/fortran/iso-c-binding.def
> gcc/fortran/trans-types.cc
If one instruments, write_decl() in dump-parse-tree.cc to
dump the table of bind(c) types, one can see why you get
what you get.
% cat a.f90
module foo
use, intrinsic :: iso_c_binding
implicit none
public :: bar
type, bind(c) :: bar
integer(c_int64_t) a
end type
end module
% gfcx -fc-prototypes -fsyntax-only a.f90 | grep "value=8 IN"
2 value=8 INTEGER c_long
3 value=8 INTEGER c_long_long
4 value=8 INTEGER c_intmax_t
5 value=8 INTEGER c_intptr_t
6 value=8 INTEGER c_ptrdiff_t
7 value=8 INTEGER c_size_t
12 value=8 INTEGER c_int64_t
17 value=8 INTEGER c_int_least64_t
22 value=8 INTEGER c_int_fast64_t
typedef struct bar {
long a;
} bar;
The for-loop in write_decl() breaks on the first match to
to both value=8 and INTEGER. It never reaches the 12th
table entry for c_int64_t.
[Bug fortran/109322] -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109322
--- Comment #7 from Steve Kargl ---
On Wed, Mar 29, 2023 at 09:28:38PM +, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109322
>
> --- Comment #5 from Andrew Pinski ---
> There is a bug with -m32 and fc-prototypes though, it should be long long
> rather than long long. Let me provide a patch for that.
>
This replaces '_' by ' ', but would certainly break if int_t
is in type_name.
diff --git a/gcc/fortran/dump-parse-tree.cc b/gcc/fortran/dump-parse-tree.cc
index 3b24bdc1a6c..3921adfbe01 100644
--- a/gcc/fortran/dump-parse-tree.cc
+++ b/gcc/fortran/dump-parse-tree.cc
@@ -3807,6 +3807,7 @@ write_decl (gfc_typespec *ts, gfc_array_spec *as, const
char *sym_name,
bool func_ret, locus *where, bool bind_c)
{
const char *pre, *type_name, *post;
+ char *bp, buf[81];
bool asterisk;
enum type_return rok;
@@ -3819,7 +3820,15 @@ write_decl (gfc_typespec *ts, gfc_array_spec *as, const
char *sym_name,
gfc_typename (ts));
return;
}
- fputs (type_name, dumpfile);
+
+#if 1
+ bp = [0];
+ strncpy(bp, type_name, 80);
+ for (; *bp != '\0'; bp++)
+if (*bp == '_') *bp = ' ';
+#endif
+
+ fputs (buf, dumpfile);
fputs (pre, dumpfile);
if (asterisk)
fputs ("*", dumpfile);
[Bug fortran/109322] -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109322
--- Comment #3 from Steve Kargl ---
On Wed, Mar 29, 2023 at 05:50:05PM +, emr-gnu at hev dot psu.edu wrote:
>
>
> Extending my original demonstrator, if you add a "INTEGER(KIND=C_INT64_T) ::
> E", you get the following output:
>
> > gfortran -m32 -fc-prototypes -fsyntax-only foo.f90
>
> long a;
> {...}
> long_long e;
> } bar;
The companion C processor is gcc. It is generating
prototypes for that C processor. If one is manipulating
the environment with a command line option such as -m32
or -m64, then one likely needs to use the same option
with gcc. Does 'gcc -m32' support "long_long"? If it
doesn't, then you'll need to hack on
gcc/fortran/dump-parse-tree.cc
gcc/fortran/iso-c-binding.def
gcc/fortran/trans-types.cc
[Bug fortran/104572] ICE in gfc_resolve_finalizers, at fortran/resolve.cc:13646
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104572 --- Comment #3 from Steve Kargl --- On Tue, Mar 21, 2023 at 09:02:14PM +, anlauf at gcc dot gnu.org wrote: > --- Comment #2 from anlauf at gcc dot gnu.org --- > (In reply to kargl from comment #1) > > Self explanatory. > > > > diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc > > Yes. Either this or: I'm fine with gfortran emitting either error message. As we've both put eyes on the bug, go ahead and use your error message and commit.
[Bug fortran/109223] parameters for a type on IMPLICIT do not work. For example: IMPLICIT TYPE(REAL(KIND=REAL128)) fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109223
--- Comment #7 from Steve Kargl ---
On Tue, Mar 21, 2023 at 12:27:58PM -0700, Steve Kargl wrote:
>
> So, there is a chunk of code in decl.cc(4682-4689 or so),
>
> if (implicit_flag == 1)
> {
> if (matched_type && gfc_match_char (')') != MATCH_YES)
> return MATCH_ERROR;
>
> return MATCH_YES;
> }
>
> causing the problem. The implicit_flag == 1 conditional was
> added in 2004 (revision e5ddaa24beae) to check for 'IMPLICIT
> CHARACTER'. The code block was updated in revision 0fb56814562a
> when 'TYPE(intrinsic-type-spec)' was added to gfortran.
>
> I have no idea how this was suppose to work.
Well, I figured that out. The code allows
'implicit real (a-z)'
to be parsed and compiled. The downside is that it
blocks OP's code. A simplied code
program testit
! implicit real(a-z) ! Works
! implicit real(4) (a-z) ! Works
implicit type(real(4)) (a-z) ! Whoops.
type(real(4)) :: quad
if (kind(quad) /= 4) stop 1
end program testit
So, 'type(intrinsic-type-spec)' seems to be broken
when placed in 'implicit type(intrinsic-type-spec)'.
[Bug fortran/109223] parameters for a type on IMPLICIT do not work. For example: IMPLICIT TYPE(REAL(KIND=REAL128)) fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109223
--- Comment #6 from Steve Kargl ---
On Tue, Mar 21, 2023 at 02:57:49PM +, kargl at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109223
>
> --- Comment #5 from kargl at gcc dot gnu.org ---
> (In reply to urbanjost from comment #4)
> > User-defined types work and as I read the ISO standard are supported, and
> > TYPE(REAL) works; it is only when a parameter is added that it fails;
> > nvfortran fails for user-defined type declared below it but it works with
> > one defined via a USE from a module; while gfortran allows the type to be
> > defined after the use,
> > but I consider that a nvfortran bug myself.
>
> Ah, yeah, you're right. I failed to follow the EBNF in R864.
> It seems that gfortran is getting tripped up with the character
> following the basic type name, ie., the kind selector part.
>
So, there is a chunk of code in decl.cc(4682-4689 or so),
if (implicit_flag == 1)
{
if (matched_type && gfc_match_char (')') != MATCH_YES)
return MATCH_ERROR;
return MATCH_YES;
}
causing the problem. The implicit_flag == 1 conditional was
added in 2004 (revision e5ddaa24beae) to check for 'IMPLICIT
CHARACTER'. The code block was updated in revision 0fb56814562a
when 'TYPE(intrinsic-type-spec)' was added to gfortran.
I have no idea how this was suppose to work.
[Bug driver/109135] Wrong make utility called with LTO testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109135
--- Comment #7 from Steve Kargl ---
On Wed, Mar 15, 2023 at 08:35:41AM +, rguenth at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109135
>
> --- Comment #6 from Richard Biener ---
> (In reply to Steve Kargl from comment #4)
> > On Tue, Mar 14, 2023 at 10:36:27PM +, sgk at troutmask dot
> > apl.washington.edu wrote:
> >
> > Looking in obj/gcc/Makefile at line 341 I see the comment
> >
> > # Make sure the $(MAKE) variable is defined.
> >
> > followed by no checking to see if MAKE is defined.
>
> Makefile.in has
>
> # Make sure the $(MAKE) variable is defined.
> @SET_MAKE@
>
> configure has
>
> if eval test \$ac_cv_prog_make_${ac_make}_set = yes; then
> { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
> $as_echo "yes" >&6; }
> SET_MAKE=
> else
> { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
> $as_echo "no" >&6; }
> SET_MAKE="MAKE=${MAKE-make}"
> fi
>
> from AC_PROG_MAKE_SET which seems to check whether make sets $MAKE.
> That appearantly succeeds for you. Do you "properly" do sth like
>
> MAKE=gmake ../configure
>
> so configure sees which make you are using? I think if your gmake
No. I simply use '../configure ; gmake -j6 bootstrap'.
This has worked for years. I'm currently using GNU
make 4.3. If MAKE is not being set to gmake, then I
would expect bootstrap to fail.
I plan to run gmake with debugging output, and need to
check gmake.info to see how to dump the environment
information.
> doesn't set it then even recursive configure invocations from gmake
> will resort to 'make'
>
> but then I _think_ that gmake itself sets $MAKE (if it was not set?) for
> sub-processes. But maybe only if it thinks its recursive make?
I suppose I'll start using the 'MAKE=gmake ..' form or some variation
as I use tcsh.
[Bug driver/109135] Wrong make utility called with LTO testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109135 --- Comment #5 from Steve Kargl --- On Tue, Mar 14, 2023 at 10:36:27PM +, sgk at troutmask dot apl.washington.edu wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109135 > > --- Comment #3 from Steve Kargl --- > On Tue, Mar 14, 2023 at 10:25:53PM +, pinskia at gcc dot gnu.org wrote: > > > > --- Comment #1 from Andrew Pinski --- > > This is not a testsuite issue but rather the issue is the lto code is > > calling > > make ... > > > > That explains why groping around in gcc/testsuite for > a rogue make or MAKE was coming up empty. > > I'm in the middle of doing a serial 'gmake check-fortran', > which takes a long time on my system. Is there a way > to invoke only lto testing? > Answered my own question. % gmake RUNTESTFLAGS="dg.exp=pr71526.f90" check-fortran ... === gfortran Summary === # of expected passes1 % gmake -j 1 RUNTESTFLAGS="dg.exp=pr71526.f90" check-fortran ... === gfortran Summary === # of expected passes1 % gmake -j 2 RUNTESTFLAGS="dg.exp=pr71526.f90" check-fortran ... FAIL: gfortran.dg/pr71526.f90 -O (test for excess errors) === gfortran Summary === # of unexpected failures1 % setenv MAKE gmake % gmake -j 2 RUNTESTFLAGS="dg.exp=pr71526.f90" check-fortran ... === gfortran Summary === # of expected passes1 So, the work around is to explicitly set MAKE to gmake before running the testsuite.
[Bug driver/109135] Wrong make utility called with LTO testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109135 --- Comment #4 from Steve Kargl --- On Tue, Mar 14, 2023 at 10:36:27PM +, sgk at troutmask dot apl.washington.edu wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109135 > > --- Comment #3 from Steve Kargl --- > On Tue, Mar 14, 2023 at 10:25:53PM +, pinskia at gcc dot gnu.org wrote: > > > > --- Comment #1 from Andrew Pinski --- > > This is not a testsuite issue but rather the issue is the lto code is > > calling > > make ... > > > > That explains why groping around in gcc/testsuite for > a rogue make or MAKE was coming up empty. > > I'm in the middle of doing a serial 'gmake check-fortran', > which takes a long time on my system. Is there a way > to invoke only lto testing? So, 'gmake check-fortran' finishes without any lto issues. It seems one must invoke the checking with 'gmake -j6 check-fortran' to get failures. Looking in obj/gcc/Makefile at line 341 I see the comment # Make sure the $(MAKE) variable is defined. followed by no checking to see if MAKE is defined.
[Bug driver/109135] Wrong make utility called with LTO testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109135 --- Comment #3 from Steve Kargl --- On Tue, Mar 14, 2023 at 10:25:53PM +, pinskia at gcc dot gnu.org wrote: > > --- Comment #1 from Andrew Pinski --- > This is not a testsuite issue but rather the issue is the lto code is calling > make ... > That explains why groping around in gcc/testsuite for a rogue make or MAKE was coming up empty. I'm in the middle of doing a serial 'gmake check-fortran', which takes a long time on my system. Is there a way to invoke only lto testing?
[Bug fortran/92639] Error: Integer too big for its kind at (1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92639 --- Comment #4 from Steve Kargl --- On Wed, Mar 01, 2023 at 05:51:29PM +, cessenat at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92639 > > --- Comment #2 from Olivier Cessenat --- > integer(kind=4) valid range is -2147483648_4 to +2147483647_4. > So I consider this is a gfortran bug. > > Moreover, if -2147483648_4 is considered out of range, why > -2147483647_4 - 1_4 is not ? Constant elimination makes it evaluated to > -2147483648_4. > > I disagree with the term "there are no negative integers" > [-2147483648_4 is equal to +2147483648_4] exceeds huge(1) % cat a.f90 print *, huge(1) end % gfortran -o z a.f90 && ./z 2147483647 I've already explained the issue. But, I'll go over it one more time. -2147483648_4 is parsed as unary minus operator and an operand of 2147483648_4. 2147483648_4 exceeds huge(1). Fortunately, gfortran can save you, and the error message even tells you. 1 | i = -2147483648_4 | 1 Error: Integer too big for its kind at (1). This check can be disabled with the option '-fno-range-check' So, let me amend the quote above "there are no negative integer-literal constants."
[Bug middle-end/108878] Mis-optimization with splitting floating point into a significand and exponent.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108878 --- Comment #8 from Steve Kargl --- On Wed, Feb 22, 2023 at 08:48:07AM +, rguenth at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108878 > > --- Comment #6 from Richard Biener --- > For the specific testcase I also wonder if the Fortran frontend optimization > pass can somehow unify these? This might be possible. Thomas knows the frontend pass better than I. Thomas, do you think it would be possible to replace m = exponent(x) f = fraction(x) with a single function/subroutine call?
[Bug middle-end/108878] Mis-optimization with splitting floating point into a significand and exponent.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108878
--- Comment #4 from Steve Kargl ---
On Tue, Feb 21, 2023 at 09:49:38PM +, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108878
>
> --- Comment #2 from Andrew Pinski ---
> So the right way of fixing this is to have a builtin versions of "frexp" which
> return a complex type and that is pure for -fno-math-errno and such. And gets
> expanded to frexp correctly.
>
A complex type seems out-of-place as the exponent() returns
an integer and fraction() a real. __builtin_frexp() already
returns the info. I was hoping that he following:
_5 = *x_4(D);
__builtin_frexpf (_5, );
_1 = D.4261;
*m_7(D) = _1;
D.4261 ={v} {CLOBBER(eol)};
_2 = __builtin_frexpf (_5, );
*f_11(D) = _2;
D.4263 ={v} {CLOBBER(eol)};
could be transformed into
[local count: 1073741824]:
_5 = *x_4(D);
_2 = __builtin_frexpf (_5, );
_1 = D.4263;
*m_7(D) = _1;
*f_11(D) = _2;
D.4263 ={v} {CLOBBER(eol)};
[Bug fortran/108663] Accepts invalid bug with pdtXXX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108663 --- Comment #1 from Steve Kargl --- > $ gfortran-13-20221218 -c z1.f90 # missing error > $ > $ gfortran-13-20230115 -c z1.f90 > z1.f90:12:7: > >12 |use m, only: t, pdtt, s > | 1 > internal compiler error: in check_complete_insertion, at hash-table.h:578 For the record, the entity 'pdtt' is not specified in the module. It is constructed by gfortran in decl.cc(gfc_get_pdt_instance) when parsing a parameterized derived type. The symbol pdtt means PDT type t, and it appears to inserted into the namespace. A likely better name would have been _PDT_t, because the leading underscore means the name cannot conflict with a user's code and gfortran downcases all parsed code so PDT shows that the symbol is artificial.
[Bug fortran/108621] [12 regression]: bind(c) pointer array spurious maybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108621 --- Comment #2 from Steve Kargl --- On Wed, Feb 01, 2023 at 06:13:33PM +, kargl at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108621 > > This appears to be related to Sandra and Tobias's work on CFI. In particular, > trans-expr.cc(gfc_conv_gfc_desc_to_cfi_desc) appear to not handle an > intent(out) deferred entity. gfortran eventually gets to line 5818 and > following where the `tree gfx` and `tree idx` are getting manipulated, but > `fsym->as` shows > It seems that bugzilla does not recognize the email address that Tobias's uses in ChangeLong. Try to cc him here to see if he gets added to the audit trail.
[Bug fortran/103506] [10/11/12/13 Regression] ICE in gfc_free_namespace, at fortran/symbol.c:4039 since r10-2798-ge68a35ae4a65d2b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103506 --- Comment #10 from Steve Kargl --- On Fri, Jan 27, 2023 at 02:06:12AM +, jvdelisle at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103506 > > --- Comment #7 from Jerry DeLisle --- > > Well we sure are not going to completely rewrite gfortran. Sometimes I think > we just ought to accept ice-on-invalid and just toss out all those bug reports > as the effort to fix them is not worth the benefit from doing so. > A number of these would go away if gfortran set -fmax-error=1 as the default.
[Bug fortran/103506] [10/11/12/13 Regression] ICE in gfc_free_namespace, at fortran/symbol.c:4039 since r10-2798-ge68a35ae4a65d2b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103506 --- Comment #6 from Steve Kargl --- On Thu, Jan 26, 2023 at 02:56:02AM +, jvdelisle at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103506 > > --- Comment #5 from Jerry DeLisle --- > I found that the attached patch does not work. At the point of assertion many > of the other functions to free memory have null pointers which leads to > segfaults all along the way. > > The following approach appears to work, however, obviously there is a lot of > memory left not freed, so we would rely on the OS to clean it up. Maybe this > is > ok, not sure. > I think that it is ok. A lot of the gfortran FE code assumes that it is dealing with a conforming Fortran program. Many failing test cases are constructed from invalid Fortran code (see any of a number of Gerhard's PR), which takes torturous paths through the Fortran FE. The only other option is to check the pointers, but this is going to get ugly with some of the structs we have. Something like if (a->b->c->d) free(...) becomes if (a && a->b && a->b->c && a->b->c->d) free(...)
[Bug fortran/108528] [13 Regression] ICE in gfc_compare_array_spec(): Array spec clobbered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108528 --- Comment #5 from Steve Kargl --- On Wed, Jan 25, 2023 at 07:44:05PM +, anlauf at gcc dot gnu.org wrote: > > --- Comment #3 from anlauf at gcc dot gnu.org --- > Steve, I'm going to commit your patch. > Thanks.
[Bug fortran/108527] [13 Regression] ICE in compare_bound_int(): Bad expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108527 --- Comment #5 from Steve Kargl --- On Tue, Jan 24, 2023 at 08:51:03PM +, anlauf at gcc dot gnu.org wrote: > --- Comment #4 from anlauf at gcc dot gnu.org --- > The patch in comment#2 regtests cleanly. > > I can package it and submit if you agree. > Fine with me.
[Bug fortran/102595] ICE in var_element, at fortran/decl.c:298 since r10-5607-gde89b5748d68b76b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102595 --- Comment #9 from Steve Kargl --- On Sun, Jan 15, 2023 at 08:07:16PM +, jvdelisle at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102595 > > --- Comment #8 from Jerry DeLisle --- > I started to do some variations on the z1.f90 case: > > program p >complex, parameter :: x(0) = 2 x is a zero-sized array. program p complex, parameter :: x(0) = 2 print *, size(x) end program p
[Bug fortran/108369] FM509 Fails to compile with error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369 --- Comment #12 from Steve Kargl --- On Fri, Jan 13, 2023 at 11:49:44AM +, ben.brewer at codethink dot co.uk wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369 > > --- Comment #11 from Ben Brewer --- > So I was using "-x f77" which I would expect to instruct the compiler to run > in > a mode compatible with Fortran 77, it seems non-intuitive to have to enable > -std=legacy to compile the very tests which define f77. > gfortran started life as a Fortran 95 compiler with a bunch of extensions. The -x f77 option might be a relic from g77 and only effects whether one has fixed source form code or free source form code. "f77" appears twice in gcc.info under the description of the -x option. The meaning of "-x f77" isn't actually documented. To set the Fortran standard conformance, use the -std option (e.g., -std=legacy, -std=f95, -std=f2003, -std=f2008, -std=f2018). There isn't an -std=f77, If one is compiling old code, it is recommended to use -std=legacy to turn off a bunch of warning/errors.
[Bug fortran/108369] FM509 Fails to compile with error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369 --- Comment #10 from Steve Kargl --- On Fri, Jan 13, 2023 at 01:09:22AM +, jvdelisle at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369 > > --- Comment #6 from Jerry DeLisle --- > Unbelievable! I found the folder in my test directory. The NIST test suite > passes as before with my test script using the latest gfortran trunk rev 13. > > I do some comparisons way back with some example outputs in some of these > cases. I will zip this up and send it to Ben and Steve. > > I was actually surprised things still passed. > Thanks Jerry. I have NIST, but have only ever done compile tests. I've not tried to actually run all of the tests.
[Bug fortran/108369] FM509 Fails to compile with error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369 --- Comment #4 from Steve Kargl --- On Wed, Jan 11, 2023 at 09:50:37PM +, kargl at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369 > > --- Comment #3 from kargl at gcc dot gnu.org --- > (In reply to anlauf from comment #1) > > (In reply to Ben Brewer from comment #0) > > Workaround: either use -std=legacy or fix the above argument declaration to: > > > > CHARACTER C1D001(*)*8,CVD001*8 > > While the workaround will work, it does so because it disables > -fallow-argument-mismatch. But, that feature emitting a bogus > error/warning. > > Note the following all compile and execute. TKR is satisfied > as I discussion in comment #2. > After looking into this a bit closer, Harald is indeed correct with the need for -std=legacy (or -fallow-argument-mismatch). In the line CALL SN512(C1N001(5)(2:9),CVCOMP) 'C1N001(5)(2:9)' is a substring of the array element 'C1N001(5)', which is a scalar (ie., rank = 0). The interface for SN512 is SUBROUTINE SN512(C1D001,CVD001) CHARACTER C1D001(6)*8,CVD001*8 The first dummy argument is a rank 1 array. Now, if the test is changed to pass an array section such as CALL SN512(C1N001(4:5)(2:9),CVCOMP) then gfortran gives % gfcx -w -c fm509.f fm509.f:378:17: 378 | CALL SN512(C1N001(4:5)(2:9),CVCOMP) 03770509 | 1 Error: Actual argument contains too few elements for dummy argument 'c1d001' (16/48) at (1) which I believe may be wrong.
[Bug fortran/97345] FE passes do_subscript leaks gmp memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97345 --- Comment #6 from Steve Kargl --- On Tue, Jan 10, 2023 at 09:50:08PM +, cvs-commit at gcc dot gnu.org wrote: > > --- Comment #5 from CVS Commits --- > The master branch has been updated by Harald Anlauf : > > https://gcc.gnu.org/g:fec9fc1a17ec44461cee841513f1b6b8ad680fe4 > > commit r13-5095-gfec9fc1a17ec44461cee841513f1b6b8ad680fe4 > Author: Harald Anlauf > Date: Tue Jan 10 22:41:17 2023 +0100 > > Fortran: frontend passes do_subscript leaks gmp memory [PR97345] > > gcc/fortran/ChangeLog: > > PR fortran/97345 > * frontend-passes.cc (do_subscript): Clear used gmp variables. > Thanks for taking care of this one. Sorry I got sidetracked.
[Bug fortran/107995] ICE: Segmentation fault, without backtrace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107995 --- Comment #7 from Steve Kargl --- On Mon, Dec 12, 2022 at 08:23:39PM +, anlauf at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107995 > > --- Comment #6 from anlauf at gcc dot gnu.org --- > Can we close this one? (Target milestone 13)? > Yes, I think so. The code surely is a corner case.
[Bug fortran/107995] ICE: Segmentation fault, without backtrace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107995 --- Comment #3 from Steve Kargl --- On Sat, Dec 10, 2022 at 07:37:06PM +, anlauf at gcc dot gnu.org wrote: > (In reply to kargl from comment #1) > > This patch prevents the ICE. > > The patch is mostly good, but does not set the errmsg variable, which > leads to garbage in the printed error message. > > We could do the following (haven't found a better one yet): > Don't see the point in complicating the patch as there is at least one earlier error message. But, since I won't be committing a chnage, I certainly won't object to your patch.
[Bug fortran/81615] save-temps and gfortran produces *.f90 files instead of *.i or *i90 files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81615
--- Comment #15 from Steve Kargl ---
On Sat, Dec 10, 2022 at 01:47:44AM +, barrowes at alum dot mit.edu wrote:
>
> Thanks for engaging, and thanks for the suggestion. I might be able to do this
> over the winter. Could you give me a hint as to where to look. Which files.
>
I suspect that you should start by understand gcc/fortran/lang-specs.h.
That's where most of the the filename suffixes are defined. In particular,
this chuck of code
/* Identical to gcc.cc (cpp_options), but omitting %(cpp_unique_options)
and -fpch-preprocess on -save-temps. */
#define CPP_ONLY_OPTIONS"%1 %{m*} %{f*} %{g*:%{!g0:%{g*} \
%{!fno-working-directory:-fworking-directory}}} \
%{std*} %{W**} %{w} \
%{O*} %{undef}"
[Bug fortran/81615] save-temps and gfortran produces *.f90 files instead of *.i or *i90 files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81615
--- Comment #11 from Steve Kargl ---
On Fri, Dec 09, 2022 at 01:50:56AM +, barrowes at alum dot mit.edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81615
>
> --- Comment #10 from Ben Barrowes ---
> The reason the stdout redirection doesn't work for me is because
> I want to save these preprocessed files during a "make" session.
> When I make, thousands of fotran files are preprocessed and compiled.
> How do I save the stdout from each one into its own directory?
>
% cat > a1.f90
subroutine foo
end subroutine foo
% cp a1.f90 b1.f90
% cp a1.f90 c1.f90
% cp a1.f90 d1.f90
% cat Makefile
FC = gfortran11
FF = -cpp -E
IN = f90
OUT = txt
NAMES = a1 b1 c1 d1
all:
.for i in ${NAMES}
${FC} ${FF} $i.${IN} > $i.${OUT}
.endfor
% make
gfortran11 -cpp -E a1.f90 > a1.txt
gfortran11 -cpp -E b1.f90 > b1.txt
gfortran11 -cpp -E c1.f90 > c1.txt
gfortran11 -cpp -E d1.f90 > d1.txt
% ls
Makefilea1.txt b1.txt c1.txt d1.txt
a1.f90 b1.f90 c1.f90 d1.f90
The preprocessed files appear in the same directory with its source
source file. It's trivial matter to have preprocess stuffed into
its own directory.
PS: Having to preprocess thousands of Fortran files into individual
directories seems to be poor software design.
[Bug fortran/107874] merge not using all its arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874 --- Comment #5 from Steve Kargl --- On Sun, Nov 27, 2022 at 08:00:35PM +, anlauf at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874 > > --- Comment #3 from anlauf at gcc dot gnu.org --- > (In reply to kargl from comment #2) > > Harald, you are likely right the patch can be moved down. I'll programmed > > up the example from the Fortran 2018 standard, which works as expected. So, > > there is definitely something about a scalar mask choosing the actual > > argument before both are evaluated. > > > >program foo > > Steve, > > this example from the standard seems to be working down to 7.5 for me. > Am I missing something? Do we need this in the testsuite? You are not missing anything. I wanted an example that works with or without the patch John included, so that we don't accidently introduce a regression. > I'd say it's rather the following two lines replacing the loop in the > reproducer in comment#0: > > print *, merge(tstuff(),fstuff(),.true.) > print *, merge(tstuff(),fstuff(),.false.) > > This is mis-simplified in simplify.cc:4909 Good find! This may indeed be a source of the issue.
[Bug fortran/107753] gfortran returns NaN in complex divisions (x+x*I)/(x+x*I) and (x+x*I)/(x-x*I)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107753 --- Comment #12 from Steve Kargl --- On Sat, Nov 19, 2022 at 08:14:01PM +, anlauf at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107753 > > --- Comment #11 from anlauf at gcc dot gnu.org --- > (In reply to Weslley da Silva Pereira from comment #7) > > More data for the discussion: > > 1. In a Ubuntu 18.04.5 LTS, using GNU Fortran 7.5.0, I tested optimization > > flags `-O` but still reproduce the wrong result for complex divisions with > > huge numbers. See > > It is possible that gfortran's dependence on optimization level depends > on the version. If one wants to test run-time behavior and avoid > compile-time simplification, it may be helpful to add: > > volatile :: x, y, z > > I then get consistent results for -O0 / -O1. > The optimization level is irrelevant. gfortran unilaterally uses -fcx-fortran-rules, and there is no way to disable this option to user the slower, but stricter, evaluation. One will always get complex division computed by a+ib a + b(d/c) b - a(d/c) = -- + i |c| > |d| c+id c + d(d/c) c + d(d/c) and similar for |d| > |c|. There are a few problems with this. d/c can trigger an invalid underflow exception. If d == c, you then have numerators of a + b and b - a, you can get a invalid overflow for a = huge() and b > 1e291_8.
[Bug fortran/107753] gfortran returns NaN in complex divisions (x+x*I)/(x+x*I) and (x+x*I)/(x-x*I)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107753 --- Comment #9 from Steve Kargl --- On Fri, Nov 18, 2022 at 11:24:29PM +, sgk at troutmask dot apl.washington.edu wrote: > > Does anyone know what is meant by "Fortran rules"? F66 does not > have any particular algorithm specified. I'll look at F77 shortly. > Well, I hunted down the origins of -fcx-fortran-rules. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29549 So, it appears to be an optimization, where Smith's algorithm will fail for extreme values of the real and imaginary parts of the complex number.
[Bug fortran/107753] gfortran returns NaN in complex divisions (x+x*I)/(x+x*I) and (x+x*I)/(x-x*I)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107753 --- Comment #6 from Steve Kargl --- On Fri, Nov 18, 2022 at 11:24:29PM +, sgk at troutmask dot apl.washington.edu wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107753 > > --- Comment #5 from Steve Kargl --- > On Fri, Nov 18, 2022 at 10:05:21PM +, kargl at gcc dot gnu.org wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107753 > > > > --- Comment #4 from kargl at gcc dot gnu.org --- > > (In reply to anlauf from comment #3) > > > I guess the reporter assumes that gcc uses a clever algorithm like Smith's > > > to handle such extreme cases of complex division. Not sure if that one is > > > available by some compilation flag, and I think it would impact > > > performance. > > > > > > In any case, if the reporter wants to get robust results and in a portable > > > way, I would advise him to change/fix his algorithm accordingly. It > > > appears > > > that a few other compilers behave here like gfortran. > > > > It's likely coming from the middle-end where gcc.info has > > the option > > > > '-fcx-fortran-rules' > > Complex multiplication and division follow Fortran rules. Range > > reduction is done as part of complex division, but there is no > > checking whether the result of a complex multiplication or division > > is 'NaN + I*NaN', with an attempt to rescue the situation in that > > case. > > Does anyone know what is meant by "Fortran rules"? F66 does not > have any particular algorithm specified. I'll look at F77 shortly. > I add the subroutine subroutine ohno complex(dp), parameter :: a = cmplx(huge(1.d0),huge(1.d0),dp) complex(dp), parameter :: b = a / a write(*,*) a write(*,*) b end subroutine ohno % gfortran -o z a.f90 && ./z (1.79769313486231571E+308,1.79769313486231571E+308) (NaN,0.) (1.79769313486231571E+308,1.79769313486231571E+308) (1.,0.) The last two lines are from ohno.
[Bug fortran/107753] gfortran returns NaN in complex divisions (x+x*I)/(x+x*I) and (x+x*I)/(x-x*I)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107753
--- Comment #5 from Steve Kargl ---
On Fri, Nov 18, 2022 at 10:05:21PM +, kargl at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107753
>
> --- Comment #4 from kargl at gcc dot gnu.org ---
> (In reply to anlauf from comment #3)
> > I guess the reporter assumes that gcc uses a clever algorithm like Smith's
> > to handle such extreme cases of complex division. Not sure if that one is
> > available by some compilation flag, and I think it would impact performance.
> >
> > In any case, if the reporter wants to get robust results and in a portable
> > way, I would advise him to change/fix his algorithm accordingly. It appears
> > that a few other compilers behave here like gfortran.
>
> It's likely coming from the middle-end where gcc.info has
> the option
>
> '-fcx-fortran-rules'
> Complex multiplication and division follow Fortran rules. Range
> reduction is done as part of complex division, but there is no
> checking whether the result of a complex multiplication or division
> is 'NaN + I*NaN', with an attempt to rescue the situation in that
> case.
Does anyone know what is meant by "Fortran rules"? F66 does not
have any particular algorithm specified. I'll look at F77 shortly.
Tracking down what -fcx-fortran-rules does, one finds the
eventually flag_complex_method is set to 1. The lower of
complex division occurs in gcc/tree-complex.cc (expand_complex_division).
If I use this patch
% git diff gcc/tree-complex.cc | cat
diff --git a/gcc/tree-complex.cc b/gcc/tree-complex.cc
index ea9df6114a1..8051b7a3843 100644
--- a/gcc/tree-complex.cc
+++ b/gcc/tree-complex.cc
@@ -1501,6 +1501,7 @@ expand_complex_division (gimple_stmt_iterator *gsi, tree
type,
break;
case 2:
+ case 1:
if (SCALAR_FLOAT_TYPE_P (inner_type))
{
expand_complex_libcall (gsi, type, ar, ai, br, bi, code, true);
@@ -1508,7 +1509,6 @@ expand_complex_division (gimple_stmt_iterator *gsi, tree
type,
}
/* FALLTHRU */
- case 1:
/* wide ranges of inputs must work for complex divide. */
expand_complex_div_wide (gsi, inner_type, ar, ai, br, bi, code);
break;
to force gfortran through the C language code path, I get
void doit (complex(kind=8) & restrict z)
{
complex(kind=8) _1;
complex(kind=8) _2;
complex(kind=8) _3;
real(kind=8) _7;
real(kind=8) _8;
real(kind=8) _9;
real(kind=8) _10;
real(kind=8) _11;
real(kind=8) _12;
:
_7 = REALPART_EXPR <*z_5(D)>;
_8 = IMAGPART_EXPR <*z_5(D)>;
_1 = COMPLEX_EXPR <_7, _8>;
_9 = REALPART_EXPR <*z_5(D)>;
_10 = IMAGPART_EXPR <*z_5(D)>;
_2 = COMPLEX_EXPR <_9, _10>;
_3 = __divdc3 (_7, _8, _9, _10);
_11 = REALPART_EXPR <_3>;
_12 = IMAGPART_EXPR <_3>;
REALPART_EXPR <*z_5(D)> = _11;
IMAGPART_EXPR <*z_5(D)> = _12;
return;
}
with the result
% gfcx -o z -fdump-tree-all a.f90 && ./z
(1.79769313486231571E+308,1.79769313486231571E+308)
(1.,0.)
So, is -fcx-fortran-rules a relic of g77 past?
[Bug fortran/107707] ICE in gfc_compare_actual_formal, at fortran/interface.cc:3284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107707 --- Comment #3 from Steve Kargl --- On Wed, Nov 16, 2022 at 09:16:17PM +, anlauf at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107707 > > anlauf at gcc dot gnu.org changed: > >What|Removed |Added > > CC||anlauf at gcc dot gnu.org > > --- Comment #2 from anlauf at gcc dot gnu.org --- > (In reply to kargl from comment #1) > > Fixed by > > > > diff --git a/gcc/fortran/interface.cc b/gcc/fortran/interface.cc > > Simple and obvious. > > If you don't object, I can commit it for you. > Unfortunately, committing patches requires knowledge of git and going through some prelim setting up of an environment.
[Bug fortran/107397] [10/11/12/13 Regression] ICE in gfc_arith_plus, at fortran/arith.cc:654
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107397 --- Comment #5 from Steve Kargl --- On Fri, Oct 28, 2022 at 08:31:58PM +, anlauf at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107397 > > --- Comment #4 from anlauf at gcc dot gnu.org --- > (In reply to kargl from comment #3) > > This patch fixes the ICE and issues an error. It has passed > > regression testing. > > Great! > > Do you plan to submit your patch? (Hint: git gcc-commit-mklog). > No. I have no idea how to add a testcase to git. Every time I've tried, I end up deleting my git repository and grabbing a new clone. Not a pleasant developer experience.
[Bug fortran/107441] optional arguments are identified as "present" when missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107441 --- Comment #9 from Steve Kargl --- On Thu, Oct 27, 2022 at 09:11:08PM +, anlauf at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107441 > > --- Comment #8 from anlauf at gcc dot gnu.org --- > (In reply to anlauf from comment #7) > > However, while working on variations of the testcase, I hit an ICE for: > > > > subroutine test3 (w) > > character, intent(in), value, optional :: w > > print*, 'present(w) is ', present(w) > > end subroutine test3 > > > > It is not new, though. > > This is now tracked in PR107444. > If no other issues pop up and if this is an old issue, you can probably commit your fix for current issue as you've opened a new bug report. Thanks for pecking away at gfortran bugs.
[Bug fortran/103413] [10/11/12/13 Regression] ICE: Invalid expression in gfc_element_size since r10-2083-g8dc63166e0b85954
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103413 --- Comment #15 from Steve Kargl --- On Wed, Oct 26, 2022 at 07:22:47PM +, anlauf at gcc dot gnu.org wrote: > Status|NEW |ASSIGNED > > --- Comment #14 from anlauf at gcc dot gnu.org --- > Submitted: https://gcc.gnu.org/pipermail/fortran/2022-October/058384.html > Looks good to me. I think you can commit.
[Bug fortran/103413] [10/11/12/13 Regression] ICE: Invalid expression in gfc_element_size since r10-2083-g8dc63166e0b85954
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103413 --- Comment #12 from Steve Kargl --- On Wed, Oct 26, 2022 at 06:24:04PM +, anlauf at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103413 > > --- Comment #11 from anlauf at gcc dot gnu.org --- > (In reply to kargl from comment #10) > > Well, a boz is typeless, so it cannot be compatible with any other type. > > So, I would assume, you could do > > > > if (ts1->type == BT_BOZ || ts2->type == BT_BOZ) > >return false; > > Yes, that's better. > > > There is a caveat in that Fortran 2023 is going to allow > > things like > > > > real :: x = z'1234' > > > > if gfc_type_compatible is used in simple assignments, gfortran will > > need to deal with that. > > It is currently not used in those cases. Hmmm, I wonder if there is duplicate code within gfortran that re-implements gfc_type_compatible. If time permits, I'll see what comes with a grep of "->type == *->type". > The following is already rejected: > > program p > real :: r > data r / z'1234' / > r = z'1234' > print *, r > end > > pr103413-boz.f90:3:18: > > 3 | data r / z'1234' / > | 1 > Error: BOZ literal constant near (1) cannot be assigned to a REAL variable > [see > '-fno-allow-invalid-boz'] F2018 If a data-stmt-constant is a boz-literal-constant, the corresponding variable shall be of type integer. F2023 is unchanged. > pr103413-boz.f90:4:6: > > 4 | r = z'1234' > | 1 > Error: BOZ literal constant at (1) is neither a DATA statement value nor an > actual argument of INT/REAL/DBLE/CMPLX intrinsic subprogram [see > '-fno-allow-invalid-boz'] This I need to look up in F2023. The statement may be allowed only in an initialization expression. > Interestingly, -fno-allow-invalid-boz is not an allowed option... > But even when using -fallow-invalid-boz, which degrades the above > to a warning, I never get to gfc_type_compatible. The lack of -fno-allow-invalid-boz was intentional. A BOZ in an invalid context is an error. -fallow-invalid-boz allows that invalid context, but issues a warning. The only way to disable the warning is with -w (ie., you disable all warnings).
[Bug fortran/107266] Reject kind=4 characters for BIND(C) – it invalid and generates wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107266 --- Comment #13 from Steve Kargl --- On Tue, Oct 18, 2022 at 10:40:59AM +, burnus at gcc dot gnu.org wrote: > > (In reply to kargl from comment #9) > > Please commit the patch in comment #7. character(kind=4) is not > > interoperable > > (unless C_CHAR is CHARACTER(KIND=4) which it isn't). This is an extension > > and > > gfortran should flag. > > While I concur that the example in comment 1 is not interoperable according to > the Fortran 2018 standard, I think the patch of comment 7 rejects too much > (cf. > '(b)' below.) > > Still, I think something should/could be done – hence, I did not close this > PR. > Namely: > > * * * > > For C interoperability, I think there are two parts to this: > > (a.1) module m; character(kind=4) :: c; end module m > (a.2) subroutine foo(x) bind(C) > character(kind=4) :: x > > To both the following applies (F2018, 18.3.1 Interoperability of intrinsic > types): > > "A Fortran intrinsic type with particular type parameter values is > interoperable with a C type if the type and kind type parameter value are > listed in the table on the same row as that C type. If the type is character, > the length type parameter is interoperable > if and only if its value is one." > > Hence, neither 'foo' nor 'c' are interoperable. I'm confused by what you are trying to show with (a.1). The standard has "If the length is not specified in a char-selector or a * char-length, the length is 1.", so that last sentence is no relevant. Moreover, there is no C binding issue as you did not write module m character(kind=4), bind(c) :: c end module m gfortran accepts the above when it should be rejected because of C820 A variable with the BIND attribute shall be interoperable (18.3). For (a.2), this should also be rejected per C1556 A variable that is a dummy argument of a procedure that has ar proc-language-binding-spec shall be assumed-type or of interoperable type and kind type parameters. > (b) subroutine bar(x, y, z) bind(C) > character(kind=4,len=*) :: x > character(kind=4) :: y(:) > character(kind=4), allocatable :: z > > This one is valid as F2018's "18.3.6 Interoperability of procedures and > procedure interfaces" states: > It's not valid per C1556 above and C1555 If proc-language-binding-spec is specified for a procedure, each dummy argument of type CHARACTER with the ALLOCATABLE or POINTER attribute shall have deferred character length.
[Bug fortran/107266] Reject kind=4 characters for BIND(C) – it invalid and generates wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107266 --- Comment #12 from Steve Kargl --- On Tue, Oct 18, 2022 at 05:29:58PM +, sgk at troutmask dot apl.washington.edu wrote: > > % gfcx -c -std=f2018 a.f90 > a.f90:1:30: > > 1 | character(kind=4) function bar(x, y, z) bind(C) > | 1 > Error: GNU Extension: Symbol 'bar' at (1) with type CHARACTER(KIND=4) cannot > have the BIND(C) attribute > > The patch checks a *function* result variable for an interoperable > CHARACTER kind. > BTW, Fortran standard contains C1553 If proc-language-binding-spec is specified for a function, the function result shall be an interoperable scalar variable. So, accepting "character(kind=4) foo() bind(c)" is questionable (unless kind=4 is C_CHAR, which it isn't).
[Bug fortran/107266] Reject kind=4 characters for BIND(C) – it invalid and generates wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107266 --- Comment #11 from Steve Kargl --- On Tue, Oct 18, 2022 at 10:40:59AM +, burnus at gcc dot gnu.org wrote: > > (b) subroutine bar(x, y, z) bind(C) > character(kind=4,len=*) :: x > character(kind=4) :: y(:) > character(kind=4), allocatable :: z > > This one is valid as F2018's "18.3.6 Interoperability of procedures and > procedure interfaces" states: I'm going to assume that you did not compile the above, or read the patch. % gfcx -c a.f90 a.f90:1:22: 1 | subroutine bar(x, y, z) bind(C) | 1 Error: Allocatable character dummy argument 'z' at (1) must have deferred length as procedure 'bar' is BIND(C) % cat a.f90 subroutine bar(x, y, z) bind(C) character(kind=4,len=*) :: x character(kind=4) :: y(:) character(kind=4,len=:), allocatable :: z end subroutine bar % gfcx -c a.f90 && nm a.o | grep bar T bar % gfcx -c -std=f2018 a.f90 && nm a.o | grep bar T bar % cat a.f90 character(kind=4) function bar(x, y, z) bind(C) character(kind=4,len=*) :: x character(kind=4) :: y(:) character(kind=4,len=:), allocatable :: z end function bar % gfcx -c a.f90 && nm a.o | grep bar T bar % gfcx -c -std=f2018 a.f90 a.f90:1:30: 1 | character(kind=4) function bar(x, y, z) bind(C) | 1 Error: GNU Extension: Symbol 'bar' at (1) with type CHARACTER(KIND=4) cannot have the BIND(C) attribute The patch checks a *function* result variable for an interoperable CHARACTER kind.
