[Bug fortran/113412] New: ATAN(Y,X) does not check arguments and generates wrong error message.

[Bug fortran/113412] New: ATAN(Y,X) does not check arguments and generates wrong error message.

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113412

            Bug ID: 113412
           Summary: ATAN(Y,X) does not check arguments and generates wrong
                    error message.
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: kargl at gcc dot gnu.org
  Target Milestone: ---

Fortran 2008 added the misguided form ATAN(Y,X) where Y could be missing.
However, if Y is present, then X is required to have the same type and
kind as Y.

Consider,

% cat a.f90
program main
   real(4) x
   real(8) y
   x = 1.
   y = x
   print*, atan(y,x), atan2(y,x)
end


% gfcx -o z a.f90
a.f90:6:10:

    6 |    print*, atan(y,x), atan2(y,x)
      |          1
Error: Too many arguments in call to ‘atan’ at (1)
a.f90:6:30:

    6 |    print*, atan(y,x), atan2(y,x)
      |                              1
Error: ‘x’ argument of ‘atan2’ intrinsic at (1) must be the same type
and kind as ‘y’

The error message for atan(y,x) is wrong.

[Bug fortran/113412] ATAN(Y,X) does not check arguments and generates wrong error message.

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113412

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2024-01-16
           Priority|P3                          |P4

[Bug fortran/113412] ATAN(Y,X) does not check arguments and generates wrong error message.

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113412

--- Comment #1 from kargl at gcc dot gnu.org ---
Ugh.  This seems to be by design.

The error message 
  Error: Too many arguments in call to ‘atan’ at (1)
is queued by intrinsic.cc(sort_actual) and appears to take
precedence over an error queued by check.cc(gfc_check_atan2).
For a robust error message, if looks like we'll need to 
special case the one versus to argument atan(), atand(),
and atanpi() cases intrinsic.cc(sort_actual).  In pseudocode,
change

whoops:
  gfc_error ("Too many arguments in call to %qs at %L", name, where);
  return false;

to

whoops:
  if (name == "atan")
     check for two arguments and issue error
  else
     above gfc_error() 

  return false;

[Bug fortran/113412] ATAN(Y,X) does not check arguments and generates wrong error message.

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113412

--- Comment #2 from kargl at gcc dot gnu.org ---
With the patch at the end of this message and this source code,


program foo
   integer(8) x
   real(8) y, z
   x = 1
   y = x
   z = atan(y,x)
   print *, z
end

I get 

% gfcx -c a.f90
a.f90:6:14:

    6 |    z = atan(y,x)
      |              1
Error: 'x' argument of 'atan' intrinsic at (1) must be the same type and kind
as 'x'

which is almost correct (one of 'x' should be 'y').

diff --git a/gcc/fortran/intrinsic.cc b/gcc/fortran/intrinsic.cc
index c35f2bdd183..c30165dacef 100644
--- a/gcc/fortran/intrinsic.cc
+++ b/gcc/fortran/intrinsic.cc
@@ -4371,7 +4371,10 @@ sort_actual (const char *name, gfc_actual_arglist **ap,
     goto do_sort;

 whoops:
-  gfc_error ("Too many arguments in call to %qs at %L", name, where);
+  if (strncmp(name, "atan", 4) == 0)
+    gfc_check_atan_2 ((*ap)->expr, (*ap)->next->expr);
+  else
+    gfc_error ("Too many arguments in call to %qs at %L", name, where);
   return false;

 keywords:

[Bug fortran/113412] ATAN(Y,X) does not check arguments and generates wrong error message.

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113412

--- Comment #3 from kargl at gcc dot gnu.org ---
Created attachment 57109
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57109&action=edit
patch

The attached patch has been regtested.  There were no regression.

[Bug fortran/113412] ATAN(Y,X) does not check arguments and generates wrong error message.

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113412

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |anlauf at gcc dot gnu.org

--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to kargls from comment #3)
> Created attachment 57109 [details]
> patch
> 
> The attached patch has been regtested.  There were no regression.

Steve,

I just tried your patch.  While it fixes comment#0, it misses:

  print *, atan(1.d0,1.0)
end

I get as traceback:

f951: internal compiler error: Segmentation fault
0x1121b3f crash_signal
        ../../gcc-trunk/gcc/toplev.cc:319
0x9cde02 sort_actual
        ../../gcc-trunk/gcc/fortran/intrinsic.cc:4381
0x9ceac2 check_specific
        ../../gcc-trunk/gcc/fortran/intrinsic.cc:4795
0x9cf2f0 gfc_intrinsic_func_interface(gfc_expr*, int)
        ../../gcc-trunk/gcc/fortran/intrinsic.cc:5067
0xa350b1 resolve_unknown_f
        ../../gcc-trunk/gcc/fortran/resolve.cc:3039
0xa47ff0 resolve_function
        ../../gcc-trunk/gcc/fortran/resolve.cc:3396
0xa46df9 gfc_resolve_expr(gfc_expr*)
        ../../gcc-trunk/gcc/fortran/resolve.cc:7526
0xa5bc46 gfc_resolve_code(gfc_code*, gfc_namespace*)
        ../../gcc-trunk/gcc/fortran/resolve.cc:12619
0xa5d0b2 gfc_resolve_blocks(gfc_code*, gfc_namespace*)
        ../../gcc-trunk/gcc/fortran/resolve.cc:11432
0xa5bbfe gfc_resolve_code(gfc_code*, gfc_namespace*)
        ../../gcc-trunk/gcc/fortran/resolve.cc:12609
0xa5ec88 resolve_codes
        ../../gcc-trunk/gcc/fortran/resolve.cc:18463
0xa4080b gfc_resolve(gfc_namespace*)
        ../../gcc-trunk/gcc/fortran/resolve.cc:18498
0xa26806 resolve_all_program_units
        ../../gcc-trunk/gcc/fortran/parse.cc:7034
0xa26ffd gfc_parse_file()
        ../../gcc-trunk/gcc/fortran/parse.cc:7290
0xa8f6df gfc_be_parse_file
        ../../gcc-trunk/gcc/fortran/f95-lang.cc:241

[Bug fortran/113412] ATAN(Y,X) does not check arguments and generates wrong error message.

[kargls at comcast dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113412

--- Comment #5 from kargls at comcast dot net ---
(In reply to anlauf from comment #4)
> (In reply to kargls from comment #3)
> > Created attachment 57109 [details]
> > patch
> > 
> > The attached patch has been regtested.  There were no regression.
> 
> Steve,
> 
> I just tried your patch.  While it fixes comment#0, it misses:
> 
>   print *, atan(1.d0,1.0)
> end
> 

Ugh.  I forgot literal constants don't have symtrees or names. :(


    gfc_error ("%qs argument of %qs intrinsic at %L must be the same type "
                "and kind as %qs", (*ap)->next->expr->symtree->name, name,
                &(*ap)->next->expr->where, (*ap)->expr->symtree->name);


The pointers to expr->symtree is NULL.  This new patch catches your example.

diff --git a/gcc/fortran/intrinsic.cc b/gcc/fortran/intrinsic.cc
index c35f2bdd183..a8a92874583 100644
--- a/gcc/fortran/intrinsic.cc
+++ b/gcc/fortran/intrinsic.cc
@@ -4371,7 +4371,19 @@ sort_actual (const char *name, gfc_actual_arglist **ap,
     goto do_sort;

 whoops:
-  gfc_error ("Too many arguments in call to %qs at %L", name, where);
+  if ((gfc_option.allow_std & GFC_STD_F2008) != 0
+      && strcmp(name, "atan") == 0)
+    {
+      if ((*ap)->expr->symtree == NULL || (*ap)->next->expr->symtree == NULL)
+       gfc_error ("Arguments of %qs intrinsic at %L must have the same "
+                  "type and kind", name, &(*ap)->expr->where);
+      else
+       gfc_error ("%qs argument of %qs intrinsic at %L must be the same "
+                  "type and kind as %qs", (*ap)->next->expr->symtree->name,
+                  name, &(*ap)->next->expr->where,
(*ap)->expr->symtree->name);
+    }
+  else
+    gfc_error ("Too many arguments in call to %qs at %L", name, where);
   return false;

 keywords:

[Bug fortran/113412] ATAN(Y,X) does not check arguments and generates wrong error message.

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113412

--- Comment #6 from anlauf at gcc dot gnu.org ---
(In reply to kargls from comment #5)
> The pointers to expr->symtree is NULL.  This new patch catches your example.

It does, but behaves weird for some other cases.  Try:

program main
  complex :: c = 1.
  complex, parameter :: z = 1.
  print *, atan(c,c)
  print *, atan(z,z)
end

This gives now:

pr113412.f90:4:18:

    4 |   print *, atan(c,c)
      |                  1
Error: 'c' argument of 'atan' intrinsic at (1) must be the same type and kind
as 'c'
pr113412.f90:5:18:

    5 |   print *, atan(z,z)
      |                  1
Error: 'z' argument of 'atan' intrinsic at (1) must be the same type and kind
as 'z'


I wonder whether we can reuse existing checks for atan2 for the 2-argument
version of atan.

I tried the following:

diff --git a/gcc/fortran/intrinsic.cc b/gcc/fortran/intrinsic.cc
index c35f2bdd183..261d4229139 100644
--- a/gcc/fortran/intrinsic.cc
+++ b/gcc/fortran/intrinsic.cc
@@ -4370,6 +4370,11 @@ sort_actual (const char *name, gfc_actual_arglist **ap,
   if (a == NULL)
     goto do_sort;

+  if ((gfc_option.allow_std & GFC_STD_F2008) != 0
+      && strcmp(name, "atan") == 0
+      && !gfc_check_atan_2 (actual->expr, actual->next->expr))
+    return false;
+
 whoops:
   gfc_error ("Too many arguments in call to %qs at %L", name, where);
   return false;


This is indeed sort of hackish and produces for testcase:

program main
  complex :: c = 1.
  print *, atan (c,c)
  print *, atan2(c,c)
end

pr113412.f90:3:17:

    3 |   print *, atan (c,c)
      |                 1
Error: 'x' argument of 'atan' intrinsic at (1) must be REAL
pr113412.f90:4:17:

    4 |   print *, atan2(c,c)
      |                 1
Error: 'y' argument of 'atan2' intrinsic at (1) must be REAL


Note that the name of the formal argument is now wrong, probably because
the association of actuals with formals is missing.

[Bug fortran/113412] ATAN(Y,X) does not check arguments and generates wrong error message.

[kargls at comcast dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113412

--- Comment #7 from kargls at comcast dot net ---
(In reply to anlauf from comment #6)
> (In reply to kargls from comment #5)
> > The pointers to expr->symtree is NULL.  This new patch catches your example.
> 
> It does, but behaves weird for some other cases.  Try:
> 
> program main
>   complex :: c = 1.
>   complex, parameter :: z = 1.
>   print *, atan(c,c)
>   print *, atan(z,z)
> end
> 
> This gives now:
> 
> pr113412.f90:4:18:
> 
>     4 |   print *, atan(c,c)
>       |                  1
> Error: 'c' argument of 'atan' intrinsic at (1) must be the same type and
> kind as 'c'
> pr113412.f90:5:18:
> 
>     5 |   print *, atan(z,z)
>       |                  1
> Error: 'z' argument of 'atan' intrinsic at (1) must be the same type and
> kind as 'z'
>

Looks like I'll need to look at a more robust testcase and look
at (*ap)->expr and (*ap)->next->expr to catch the individual
issues.  I won't have time to work on this for at least 2 weeks.

> I wonder whether we can reuse existing checks for atan2 for the 2-argument
> version of atan.
> 
> I tried the following:
> 
> diff --git a/gcc/fortran/intrinsic.cc b/gcc/fortran/intrinsic.cc
> index c35f2bdd183..261d4229139 100644
> --- a/gcc/fortran/intrinsic.cc
> +++ b/gcc/fortran/intrinsic.cc
> @@ -4370,6 +4370,11 @@ sort_actual (const char *name, gfc_actual_arglist
> **ap,
>    if (a == NULL)
>      goto do_sort;
>  
> +  if ((gfc_option.allow_std & GFC_STD_F2008) != 0
> +      && strcmp(name, "atan") == 0
> +      && !gfc_check_atan_2 (actual->expr, actual->next->expr))
> +    return false;
> +

I tried a similar patch in comment #2, but with (*ap)->expr
and (*ap)->next->expr.  I don't remember why this did not
work.  Perhaps, using actual->expr and actual->next->expr
sidesteps whatever I ran into.

> This is indeed sort of hackish and produces for testcase:
> 
> program main
>   complex :: c = 1.
>   print *, atan (c,c)
>   print *, atan2(c,c)
> end
> 
> pr113412.f90:3:17:
> 
>     3 |   print *, atan (c,c)
>       |                 1
> Error: 'x' argument of 'atan' intrinsic at (1) must be REAL
> pr113412.f90:4:17:
> 
>     4 |   print *, atan2(c,c)
>       |                 1
> Error: 'y' argument of 'atan2' intrinsic at (1) must be REAL
> 
> Note that the name of the formal argument is now wrong, probably because
> the association of actuals with formals is missing.

gfc_check_atan_2 reports errors with dummy argument names.  actual->expr
could be a literal-constant, a variable, or expression.  So a name may not
be available.

I need to look at the standard again.  For atan(x), x can be real or complex.
gfc_check_atan is invoked for this check.  For atan(y,x), x and y must be with
real, and the result is the same as atan2(y,x).  

If you want to put this aside until I can return to gfortran hacking, that
fine with me.  If you want to take a stab at refining the error messages in
sort_actual(), I'm fine with that too.