Re: [PATCH,Fortran 1/2] Add uop/name helpers
On Fri, Oct 29, 2021 at 01:52:58AM +0200, Bernhard Reutner-Fischer wrote:
> From: Bernhard Reutner-Fischer
>
> Introduce a helper to construct a user operator from a name and the
> reverse operation, i.e. a helper to construct a name from a user
> operator.
>
> Cc: Jakub Jelinek
>
> gcc/fortran/ChangeLog:
>
> 2017-10-29 Bernhard Reutner-Fischer
>
> * gfortran.h (gfc_get_uop_from_name, gfc_get_name_from_uop): Declare.
> * symbol.c (gfc_get_uop_from_name, gfc_get_name_from_uop): Define.
> * module.c (load_omp_udrs): Use them.
> ---
> gcc/fortran/gfortran.h | 2 ++
> gcc/fortran/module.c | 21 +++--
> gcc/fortran/symbol.c | 21 +
> 3 files changed, 26 insertions(+), 18 deletions(-)
>
> diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
> index 9378b4b8a24..afe9f2354ee 100644
> --- a/gcc/fortran/gfortran.h
> +++ b/gcc/fortran/gfortran.h
> @@ -3399,6 +3399,8 @@ void gfc_delete_symtree (gfc_symtree **, const char *);
> gfc_symtree *gfc_get_unique_symtree (gfc_namespace *);
> gfc_user_op *gfc_get_uop (const char *);
> gfc_user_op *gfc_find_uop (const char *, gfc_namespace *);
> +const char *gfc_get_uop_from_name (const char*);
> +const char *gfc_get_name_from_uop (const char*);
Formatting, space between char and *.
> --- a/gcc/fortran/symbol.c
> +++ b/gcc/fortran/symbol.c
> @@ -3044,6 +3044,27 @@ gfc_find_uop (const char *name, gfc_namespace *ns)
>return (st == NULL) ? NULL : st->n.uop;
> }
>
> +/* Given a name return a string usable as user operator name. */
> +const char *
> +gfc_get_uop_from_name (const char* name) {
Formatting, space before * rather than after it, { should go on next line.
Similarly later.
But most importantly, I really don't like these helpers at all, they
unnecessarily allocate memory of the remaining duration of compilation,
and the second one even uses heap for temporary.
Can't you just fix the real bug and keep the code as it was otherwise
(with XALLOCAVEC etc.)?
And, there should be a testcase...
Jakub
[PATCH] Fortran: adjust column sizes in intrinsic.texi
Hi,
in intrinsic.texi, a lot of tables wrap lines when watching the
resulting info file in a 80char terminal.
Adjust the @columnfractions items to fit screen. Some minor white space
changes are added as well to help saving space.
Signed-off-by Manfred Schwarb
[Note: I do not have commit access]
--- gcc/gcc/fortran/intrinsic.texi.orig 2021-09-18 03:19:23.645913785 +0200
+++ gcc/gcc/fortran/intrinsic.texi.1 2021-10-29 14:24:46.102169856 +0200
@@ -461,7 +461,7 @@ end program test_abs
@end smallexample
@item @emph{Specific names}:
-@multitable @columnfractions .20 .20 .20 .25
+@multitable @columnfractions .20 .23 .20 .33
@headitem Name@tab Argument@tab Return type @tab Standard
@item @code{ABS(A)} @tab @code{REAL(4) A}@tab @code{REAL(4)}@tab Fortran 77 and later
@item @code{CABS(A)} @tab @code{COMPLEX(4) A} @tab @code{REAL(4)}@tab Fortran 77 and later
@@ -626,7 +626,7 @@ end program test_acos
@end smallexample
@item @emph{Specific names}:
-@multitable @columnfractions .20 .20 .20 .25
+@multitable @columnfractions .20 .23 .20 .33
@headitem Name@tab Argument @tab Return type @tab Standard
@item @code{ACOS(X)} @tab @code{REAL(4) X} @tab @code{REAL(4)} @tab Fortran 77 and later
@item @code{DACOS(X)} @tab @code{REAL(8) X} @tab @code{REAL(8)} @tab Fortran 77 and later
@@ -685,7 +685,7 @@ end program test_acosd
@end smallexample
@item @emph{Specific names}:
-@multitable @columnfractions .20 .20 .20 .25
+@multitable @columnfractions .20 .23 .20 .33
@headitem Name@tab Argument @tab Return type @tab Standard
@item @code{ACOSD(X)} @tab @code{REAL(4) X} @tab @code{REAL(4)} @tab GNU extension
@item @code{DACOSD(X)} @tab @code{REAL(8) X} @tab @code{REAL(8)} @tab GNU extension
@@ -741,7 +741,7 @@ END PROGRAM
@end smallexample
@item @emph{Specific names}:
-@multitable @columnfractions .20 .20 .20 .25
+@multitable @columnfractions .20 .23 .20 .33
@headitem Name @tab Argument @tab Return type @tab Standard
@item @code{DACOSH(X)} @tab @code{REAL(8) X} @tab @code{REAL(8)}@tab GNU extension
@end multitable
@@ -890,7 +890,7 @@ end program test_aimag
@end smallexample
@item @emph{Specific names}:
-@multitable @columnfractions .20 .20 .20 .25
+@multitable @columnfractions .20 .23 .20 .33
@headitem Name @tab Argument@tab Return type @tab Standard
@item @code{AIMAG(Z)}@tab @code{COMPLEX Z}@tab @code{REAL} @tab Fortran 77 and later
@item @code{DIMAG(Z)}@tab @code{COMPLEX(8) Z} @tab @code{REAL(8)} @tab GNU extension
@@ -950,7 +950,7 @@ end program test_aint
@end smallexample
@item @emph{Specific names}:
-@multitable @columnfractions .20 .20 .20 .25
+@multitable @columnfractions .20 .23 .20 .33
@headitem Name @tab Argument @tab Return type @tab Standard
@item @code{AINT(A)} @tab @code{REAL(4) A} @tab @code{REAL(4)} @tab Fortran 77 and later
@item @code{DINT(A)} @tab @code{REAL(8) A} @tab @code{REAL(8)} @tab Fortran 77 and later
@@ -1230,7 +1230,7 @@ end program test_anint
@end smallexample
@item @emph{Specific names}:
-@multitable @columnfractions .20 .20 .20 .25
+@multitable @columnfractions .20 .23 .20 .33
@headitem Name@tab Argument @tab Return type @tab Standard
@item @code{ANINT(A)} @tab @code{REAL(4) A} @tab @code{REAL(4)} @tab Fortran 77 and later
@item @code{DNINT(A)} @tab @code{REAL(8) A} @tab @code{REAL(8)} @tab Fortran 77 and later
@@ -1346,7 +1346,7 @@ end program test_asin
@end smallexample
@item @emph{Specific names}:
-@multitable @columnfractions .20 .20 .20 .25
+@multitable @columnfractions .20 .23 .20 .33
@headitem Name@tab Argument @tab Return type @tab Standard
@item @code{ASIN(X)} @tab @code{REAL(4) X} @tab @code{REAL(4)}@tab Fortran 77 and later
@item @code{DASIN(X)} @tab @code{REAL(8) X} @tab @code{REAL(8)}@tab Fortran 77 and later
@@ -1405,7 +1405,7 @@ end program test_asind
@end smallexample
@item @emph{Specific names}:
-@multitable @columnfractions .20 .20 .20 .25
+@multitable @columnfractions .20 .23 .20 .33
@headitem Name@tab Argument @tab Return type @tab Standard
@item @code{ASIND(X)} @tab @code{REAL(4) X} @tab @code{REAL(4)}@tab GNU extension
@item @code{DASIND(X)} @tab @code{REAL(8) X} @tab @code{REAL(8)}@tab GNU extension
@@ -1461,7 +1461,7 @@ END PROGRAM
@end smallexample
@item @emph{Specific names}:
-@multitable @columnfractions .20 .20 .20 .25
+@multitable @columnfractions .20 .23 .20 .33
@headitem Name @tab Argument @tab Return type @tab Standard
@item @code{DASINH(X)} @tab @code{REAL(8) X} @tab @code{REAL(8)}@tab GNU extension.
@end multitable
@@ -1597,7 +1597,7 @@ end program test_atan
@end smallexample
@item @emph{Specific names}:
-@multitable @columnfractions .20 .20 .20 .25
+@multitable @column
[PATCH] Fortran: adjust error message for SHORT and LONG intrinsics
Hi,
on 2019-07-23, support for SHORT and LONG intrinsics were removed be Steve
Kargl by
adding an error message in check.c. However, the error message
Error: 'long' intrinsic subprogram at (1) has been deprecated
is misleading, as support has been disabled by this patch.
Adjust the error message. This error message does not appear in the testsuite
AFAIK.
Signed-off-by Manfred Schwarb
[Note: I do not have commit access]
--- gcc/gcc/fortran/check.c.orig 2021-10-15 02:20:28.825876592 +0200
+++ gcc/gcc/fortran/check.c 2021-10-29 14:44:51.771512312 +0200
@@ -3240,7 +3240,7 @@ gfc_check_intconv (gfc_expr *x)
if (strcmp (gfc_current_intrinsic, "short") == 0
|| strcmp (gfc_current_intrinsic, "long") == 0)
{
- gfc_error ("%qs intrinsic subprogram at %L has been deprecated. "
+ gfc_error ("%qs intrinsic subprogram at %L has been removed. "
"Use INT intrinsic subprogram.", gfc_current_intrinsic,
&x->where);
return false;
[PATCH] Fortran: Remove documentation for SHORT and LONG intrinics
Hi,
on 2019-07-23, support for SHORT and LONG intrinsics was removed be Steve Kargl
by
adding an error message in check.c. As far as I can see code support is still
there, though.
Remove documentation for these intrinsics.
Signed-off-by Manfred Schwarb
[Note: I do not have commit access]
--- gcc/gcc/fortran/intrinsic.texi.1 2021-10-29 14:24:46.102169856 +0200
+++ gcc/gcc/fortran/intrinsic.texi.2 2021-10-29 15:08:38.302188947 +0200
@@ -221,7 +221,6 @@ Some basic guidelines for editing this d
* @code{LOG10}: LOG10, Base 10 logarithm function
* @code{LOG_GAMMA}: LOG_GAMMA, Logarithm of the Gamma function
* @code{LOGICAL}: LOGICAL, Convert to logical type
-* @code{LONG}: LONG, Convert to integer type
* @code{LSHIFT}:LSHIFT,Left shift bits
* @code{LSTAT}: LSTAT, Get file status
* @code{LTIME}: LTIME, Convert time to local time info
@@ -8372,7 +8371,6 @@ end program
@node INT2
@section @code{INT2} --- Convert to 16-bit integer type
@fnindex INT2
-@fnindex SHORT
@cindex conversion, to integer
@table @asis
@@ -8381,8 +8379,6 @@ Convert to a @code{KIND=2} integer type.
standard @code{INT} intrinsic with an optional argument of
@code{KIND=2}, and is only included for backwards compatibility.
-The @code{SHORT} intrinsic is equivalent to @code{INT2}.
-
@item @emph{Standard}:
GNU extension
@@ -8403,8 +8399,7 @@ The return value is a @code{INTEGER(2)}
@item @emph{See also}:
@ref{INT}, @gol
-@ref{INT8}, @gol
-@ref{LONG}
+@ref{INT8}
@end table
@@ -8440,8 +8435,7 @@ The return value is a @code{INTEGER(8)}
@item @emph{See also}:
@ref{INT}, @gol
-@ref{INT2}, @gol
-@ref{LONG}
+@ref{INT2}
@end table
@@ -9848,44 +9842,6 @@ kind corresponding to @var{KIND}, or of
@end table
-
-@node LONG
-@section @code{LONG} --- Convert to integer type
-@fnindex LONG
-@cindex conversion, to integer
-
-@table @asis
-@item @emph{Description}:
-Convert to a @code{KIND=4} integer type, which is the same size as a C
-@code{long} integer. This is equivalent to the standard @code{INT}
-intrinsic with an optional argument of @code{KIND=4}, and is only
-included for backwards compatibility.
-
-@item @emph{Standard}:
-GNU extension
-
-@item @emph{Class}:
-Elemental function
-
-@item @emph{Syntax}:
-@code{RESULT = LONG(A)}
-
-@item @emph{Arguments}:
-@multitable @columnfractions .15 .70
-@item @var{A}@tab Shall be of type @code{INTEGER},
-@code{REAL}, or @code{COMPLEX}.
-@end multitable
-
-@item @emph{Return value}:
-The return value is a @code{INTEGER(4)} variable.
-
-@item @emph{See also}:
-@ref{INT}, @gol
-@ref{INT2}, @gol
-@ref{INT8}
-@end table
-
-
@node LSHIFT
@section @code{LSHIFT} --- Left shift bits
[PATCH] Fortran: Correct documentation for REAL intrinsic
Hi,
documentation for REAL intrinsic is slightly wrong. Fix it.
Patch is done on top of the column adjustment patch.
Signed-off-by Manfred Schwarb
[Note: I do not have commit access]
--- gcc/gcc/fortran/intrinsic.texi.2 2021-10-29 15:08:38.302188947 +0200
+++ gcc/gcc/fortran/intrinsic.texi 2021-10-29 15:14:57.111458299 +0200
@@ -12251,12 +12255,12 @@ end program test_real
@item @emph{Specific names}:
@multitable @columnfractions .20 .23 .20 .33
@headitem Name @tab Argument @tab Return type @tab Standard
-@item @code{FLOAT(A)} @tab @code{INTEGER(4)} @tab @code{REAL(4)} @tab GNU extension
+@item @code{FLOAT(A)} @tab @code{INTEGER(4)} @tab @code{REAL(4)} @tab Fortran 77 and later
@item @code{DFLOAT(A)} @tab @code{INTEGER(4)} @tab @code{REAL(8)} @tab GNU extension
-@item @code{FLOATI(A)} @tab @code{INTEGER(2)} @tab @code{REAL(4)} @tab GNU extension
-@item @code{FLOATJ(A)} @tab @code{INTEGER(4)} @tab @code{REAL(4)} @tab GNU extension
-@item @code{FLOATK(A)} @tab @code{INTEGER(8)} @tab @code{REAL(4)} @tab GNU extension
-@item @code{SNGL(A)} @tab @code{INTEGER(8)} @tab @code{REAL(4)} @tab GNU extension
+@item @code{FLOATI(A)} @tab @code{INTEGER(2)} @tab @code{REAL(4)} @tab GNU extension (-fdec)
+@item @code{FLOATJ(A)} @tab @code{INTEGER(4)} @tab @code{REAL(4)} @tab GNU extension (-fdec)
+@item @code{FLOATK(A)} @tab @code{INTEGER(8)} @tab @code{REAL(4)} @tab GNU extension (-fdec)
+@item @code{SNGL(A)} @tab @code{REAL(8)} @tab @code{REAL(4)} @tab Fortran 77 and later
@end multitable
[PATCH] Fortran: recognize Gerhard Steinmetz
Hi, there were really a lot of test cases provided by Gerhard Steinmetz lately. Although I'm not really in the position to suggest this, I would appreciate it, if one could recognize him by adding an entry to gfortran.texi. As e.g. in the proposed patch. Such a patch should probably be signed-off my someone of the inner circle and not by me ;-) Cheers, Manfred --- gcc/gcc/fortran/gfortran.texi.orig 2021-05-31 03:23:30.069163688 +0200 +++ gcc/gcc/fortran/gfortran.texi 2021-10-29 15:21:39.309279615 +0200 @@ -5888,6 +5888,7 @@ GNU Fortran project: @item Dominique d'Humi@`eres @item Kate Hedstrom @item Erik Schnetter +@item Gerhard Steinmetz @item Joost VandeVondele @end itemize
Re: [PATCH,FORTRAN 28/29] Free type-bound procedure structs
Looks good and simple. Proceed. Thanks Jerry On 10/28/21 5:05 PM, Bernhard Reutner-Fischer via Fortran wrote: ping [Rebased, re-regtested cleanly. Ok for trunk?] On Wed, 5 Sep 2018 14:57:31 + Bernhard Reutner-Fischer wrote: From: Bernhard Reutner-Fischer compiling gfortran.dg/typebound_proc_31.f90 leaked the type-bound structs: 56 bytes in 1 blocks are definitely lost. at 0x4C2CC05: calloc (vg_replace_malloc.c:711) by 0x151EA90: xcalloc (xmalloc.c:162) by 0x8E3E4F: gfc_get_typebound_proc(gfc_typebound_proc*) (symbol.c:4945) by 0x84C095: match_procedure_in_type (decl.c:10486) by 0x84C095: gfc_match_procedure() (decl.c:6696) ... gcc/fortran/ChangeLog: 2017-12-06 Bernhard Reutner-Fischer * symbol.c (free_tb_tree): Free type-bound procedure struct. (gfc_get_typebound_proc): Use explicit memcpy for clarity. --- gcc/fortran/symbol.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/gcc/fortran/symbol.c b/gcc/fortran/symbol.c index 53c760a6c38..cde34c67482 100644 --- a/gcc/fortran/symbol.c +++ b/gcc/fortran/symbol.c @@ -3845,7 +3845,7 @@ free_tb_tree (gfc_symtree *t) /* TODO: Free type-bound procedure structs themselves; probably needs some sort of ref-counting mechanism. */ - + free (t->n.tb); free (t); } @@ -5052,7 +5052,7 @@ gfc_get_typebound_proc (gfc_typebound_proc *tb0) result = XCNEW (gfc_typebound_proc); if (tb0) -*result = *tb0; +memcpy (result, tb0, sizeof (gfc_typebound_proc));; result->error = 1; latest_undo_chgset->tbps.safe_push (result);
Re: [PATCH,FORTRAN 28/29] Free type-bound procedure structs
On Fri, 29 Oct 2021 07:54:21 -0700 Jerry D wrote: > Looks good and simple. Proceed. Thanks Committed as 7883a7f07c1ad9c8aaccc5bbd96e0ae1fa230c89 Thanks! Maybe somebody could eyeball and ACK "Fix memory leak in finalization wrappers" https://gcc.gnu.org/pipermail/fortran/2021-October/056838.html We were generating (and emitting to modules) finalization wrapper needlessly, i.e. even when they were not called for. This 1) leaked like shown in the initial submission and 2) polluted module files with unwarranted (wrong) mention of finalization wrappers even when compiling without any coarray stuff. E.g. a modified udr10.f90 (from libgomp) has the following diff in the module which illustrates the positive side-effect of the fix: -26 'array' '' '' 25 ((VARIABLE INOUT UNKNOWN-PROC UNKNOWN UNKNOWN 0 0 -ARTIFICIAL DIMENSION CONTIGUOUS DUMMY) () (DERIVED 3 0 0 0 DERIVED ()) 0 -0 () (0 0 ASSUMED_RANK) 0 () () () 0 0) -27 'byte_stride' '' '' 25 ((VARIABLE UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN -UNKNOWN 0 0 ARTIFICIAL VALUE DUMMY) () (INTEGER 8 0 0 0 INTEGER ()) 0 0 -() () 0 () () () 0 0) -28 'fini_coarray' '' '' 25 ((VARIABLE UNKNOWN-INTENT UNKNOWN-PROC -UNKNOWN UNKNOWN 0 0 ARTIFICIAL VALUE DUMMY) () (LOGICAL 1 0 0 0 LOGICAL -()) 0 0 () () 0 () () () 0 0) thanks,
Re: [PATCH,Fortran 1/2] Add uop/name helpers
On Fri, 29 Oct 2021 13:13:52 +0200
Jakub Jelinek wrote:
> On Fri, Oct 29, 2021 at 01:52:58AM +0200, Bernhard Reutner-Fischer wrote:
> > From: Bernhard Reutner-Fischer
> >
> > Introduce a helper to construct a user operator from a name and the
> > reverse operation, i.e. a helper to construct a name from a user
> > operator.
> >
> > Cc: Jakub Jelinek
> >
> > gcc/fortran/ChangeLog:
> >
> > 2017-10-29 Bernhard Reutner-Fischer
> >
> > * gfortran.h (gfc_get_uop_from_name, gfc_get_name_from_uop): Declare.
> > * symbol.c (gfc_get_uop_from_name, gfc_get_name_from_uop): Define.
> > * module.c (load_omp_udrs): Use them.
> > ---
> > gcc/fortran/gfortran.h | 2 ++
> > gcc/fortran/module.c | 21 +++--
> > gcc/fortran/symbol.c | 21 +
> > 3 files changed, 26 insertions(+), 18 deletions(-)
> >
> > diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
> > index 9378b4b8a24..afe9f2354ee 100644
> > --- a/gcc/fortran/gfortran.h
> > +++ b/gcc/fortran/gfortran.h
> > @@ -3399,6 +3399,8 @@ void gfc_delete_symtree (gfc_symtree **, const char
> > *);
> > gfc_symtree *gfc_get_unique_symtree (gfc_namespace *);
> > gfc_user_op *gfc_get_uop (const char *);
> > gfc_user_op *gfc_find_uop (const char *, gfc_namespace *);
> > +const char *gfc_get_uop_from_name (const char*);
> > +const char *gfc_get_name_from_uop (const char*);
>
> Formatting, space between char and *.
>
> > --- a/gcc/fortran/symbol.c
> > +++ b/gcc/fortran/symbol.c
> > @@ -3044,6 +3044,27 @@ gfc_find_uop (const char *name, gfc_namespace *ns)
> >return (st == NULL) ? NULL : st->n.uop;
> > }
> >
> > +/* Given a name return a string usable as user operator name. */
> > +const char *
> > +gfc_get_uop_from_name (const char* name) {
>
> Formatting, space before * rather than after it, { should go on next line.
> Similarly later.
Fixed the formatting. Sorry for my sloppiness..
>
> But most importantly, I really don't like these helpers at all, they
> unnecessarily allocate memory of the remaining duration of compilation,
> and the second one even uses heap for temporary.
Where do they allocate memory that remains during the rest of
compilation?
If we end up emitting the thing, then we will have it put into the
stringpool anyway, so how's that bad? I did delete the allocated buffer
after ht_lookup_with_hash copied the content so the temporary buffer in
gfc_get_name_from_uop does not leak AFAICS.
I can easily switch the second one to use XALLOCAVEC if you'd accept
that? Ok?
> Can't you just fix the real bug and keep the code as it was otherwise
> (with XALLOCAVEC etc.)?
> And, there should be a testcase...
I tried to construct a testcase yesterday but failed.
I took udr10.f90 and experimented with not using a derived type
(because DERIVED || CLASS bypasses the failure to lookup st).
I tried to move the module out to its own source to no avail and gave up
late at night.
Unrelated note:
One thing that looked odd to my untrained eyes was in e.g. udr10.f90
where you write:
!$omp parallel do reduction(+:j) reduction(.localadd.:k)
do i = 1, 100
j = j .localadd. dl(i)
k = k + dl(i * 2)
which may of course be correct (even if + would be implemented by e.g.
a twice_i procedure (and not addme like the user operator) but i'd have
assumed the reduction oper to match the target var in the region, like
!$omp parallel do reduction(.localadd.:j) reduction(+:k)
But i admittedly know nothing about openmp syntax so it's certainly fine
as written?
PS: you have at least
declare-simd-3.f90:! { dg-do compile { target { lp64 && { ! lp64 } } } }
declare-target-2.f90:! { dg-do compile { target { lp64 && { ! lp64 } } } }
and i think later on
! { dg-do compile { target skip-all-targets } }
was added, presumably for this very purpose.
thanks,
missing simplify of CAF get_team [was: Re: [PATCH,Fortran 0/7] delete some unused decls, make static]
On Mon, 25 Oct 2021 00:30:16 +0200 Bernhard Reutner-Fischer wrote: > - delete unused gfc_simplify_get_team or wire it up in intrinsics, > get_team handling (instead of the NULL..) > > Anyone who does coarrays might want to fill in the missing get_team() > simplify and add an appropriate test. JFTR this is now https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103001 CAF get_team() seems to have other issues according to bugzilla so this one surely is just cosmetics. thanks,
Re: [PATCH] PR fortran/99853 - ICE: Cannot convert 'LOGICAL(4)' to 'INTEGER(8)' (etc.)
On Thu, 28 Oct 2021 23:03:05 +0200 Harald Anlauf via Fortran wrote: > Dear Fortranners, > > the original fix by Steve was lingering in the PR. > > We did ICE in situations where in a SELECT CASE a kind conversion > was deemed necessary, but it did involve different types. > The check gfc_convert_type_warn () was invoked with arguments > requesting to generate an internal error. A regular gfc_error > is good enough here. > > Regtested on x86_64-pc-linux-gnu. OK? Sounds plausible but i cannot approve it. PS: git commit --author 'Steve Kargl ' would give Steve due credit i suppose. Or throw in --amend if you applied it already to your local tree (e.g rebase -i and reword the message, then git commit --amend --author ...). HTH. > > Thanks, also to Steve, thanks, > > Harald > > > Fortran: generate regular error on invalid conversions of CASE expressions > > gcc/fortran/ChangeLog: > > PR fortran/99853 > * resolve.c (resolve_select): Generate regular gfc_error on > invalid conversions instead of an gfc_internal_error. > > gcc/testsuite/ChangeLog: > > PR fortran/99853 > * gfortran.dg/pr99853.f90: New test. >
Re: [PATCH,FORTRAN 01/29] gdbinit: break on gfc_internal_error
ping On Wed, 5 Sep 2018 14:57:04 + Bernhard Reutner-Fischer wrote: > From: Bernhard Reutner-Fischer > > Aids debugging the fortran FE. > > gcc/ChangeLog: > > 2017-11-12 Bernhard Reutner-Fischer > > * gdbinit.in: Break on gfc_internal_error. > --- > gcc/gdbinit.in | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/gcc/gdbinit.in b/gcc/gdbinit.in > index 4db977f0bab..ac4d7c42e21 100644 > --- a/gcc/gdbinit.in > +++ b/gcc/gdbinit.in > @@ -227,6 +227,7 @@ b fancy_abort > > # Put a breakpoint on internal_error to help with debugging ICEs. > b internal_error > +b gfc_internal_error > > set complaints 0 > # Don't let abort actually run, as it will make
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes (work in progress patches)
Hi Michael, I tried this out on the one POWER machine where I can get something installed :-) It runs Ubuntu 20.04, but does not appear to have the right glibc version; it has $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 20.04.1 LTS Release:20.04 Codename: focal $ ldd --version ldd (Ubuntu GLIBC 2.31-0ubuntu9.1) 2.31 Configure was ./trunk/configure --prefix=$HOME --enable-languages=c,c++,fortran --with-advance-toolchain=at15.0 --with-native-system-header-dir=/opt/at15.0/include --with-long-double-format=ieee and the error message msgfmt -o fr.mo ../../../../trunk/libstdc++-v3/po/fr.po msgfmt: /lib/powerpc64le-linux-gnu/libm.so.6: version `GLIBC_2.32' not found (required by /home/ig25/trunk-bin/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6) msgfmt: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /home/ig25/trunk-bin/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6) msgfmt: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /home/ig25/trunk-bin/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6) msgfmt: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /home/ig25/trunk-bin/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6) msgfmt: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /home/ig25/trunk-bin/./gcc/libgcc_s.so.1) and so on. Since gcc135 is also too old, that exhausts my possibilities at testing. Any hints on how best to proceed? Best regards Thomas
Re: [PATCH] Fortran: adjust column sizes in intrinsic.texi
Hi Manfred, Am 29.10.21 um 16:05 schrieb Manfred Schwarb via Fortran: Hi, in intrinsic.texi, a lot of tables wrap lines when watching the resulting info file in a 80char terminal. Adjust the @columnfractions items to fit screen. Some minor white space changes are added as well to help saving space. the patch looks fine. However, could you please provide a properly formatted patch that applies using git patch and a ChangeLog entry? Thanks, Harald Signed-off-by Manfred Schwarb [Note: I do not have commit access]
Re: [PATCH] Fortran: adjust error message for SHORT and LONG intrinsics
Hi Manfred, Am 29.10.21 um 16:12 schrieb Manfred Schwarb via Fortran: Hi, on 2019-07-23, support for SHORT and LONG intrinsics were removed be Steve Kargl by adding an error message in check.c. However, the error message Error: 'long' intrinsic subprogram at (1) has been deprecated is misleading, as support has been disabled by this patch. Adjust the error message. This error message does not appear in the testsuite AFAIK. the patch looks fine. A testcase checking the error message is missing, as well as a ChangeLog entry. Thanks, Harald Signed-off-by Manfred Schwarb [Note: I do not have commit access]
Re: [PATCH] Fortran: Remove documentation for SHORT and LONG intrinics
Hi Manfred, Am 29.10.21 um 16:13 schrieb Manfred Schwarb via Gcc-patches: Hi, on 2019-07-23, support for SHORT and LONG intrinsics was removed be Steve Kargl by adding an error message in check.c. As far as I can see code support is still there, though. Remove documentation for these intrinsics. could you please provide a formatted patch that applies using git apply? And a ChangeLog entry? Thanks, Harald Signed-off-by Manfred Schwarb [Note: I do not have commit access]
Re: [PATCH] Fortran: recognize Gerhard Steinmetz
Hi Manfred, Am 29.10.21 um 16:33 schrieb Manfred Schwarb via Fortran: Hi, there were really a lot of test cases provided by Gerhard Steinmetz lately. Although I'm not really in the position to suggest this, I would appreciate it, if one could recognize him by adding an entry to gfortran.texi. As e.g. in the proposed patch. Such a patch should probably be signed-off my someone of the inner circle and not by me ;-) well, this is sth. close to obvious to everybody. ;-) Anyway, a ChangeLog entry would be nice. Harald Cheers, Manfred
Re: [PATCH] Fortran: Correct documentation for REAL intrinsic
Hi Manfred, Am 29.10.21 um 16:18 schrieb Manfred Schwarb via Gcc-patches: Hi, documentation for REAL intrinsic is slightly wrong. Fix it. Patch is done on top of the column adjustment patch. the patch looks fine, but it would help a lot to have a ChangeLog entry. Thanks, Harald Signed-off-by Manfred Schwarb [Note: I do not have commit access]
Re: [PATCH,FORTRAN 28/29] Free type-bound procedure structs
On Fri, 29 Oct 2021 21:36:26 +0200
Harald Anlauf via Gcc-patches wrote:
> Dear Bernhard, all,
>
> Am 29.10.21 um 02:05 schrieb Bernhard Reutner-Fischer via Gcc-patches:
>
> >> diff --git a/gcc/fortran/symbol.c b/gcc/fortran/symbol.c
> >> index 53c760a6c38..cde34c67482 100644
> >> --- a/gcc/fortran/symbol.c
> >> +++ b/gcc/fortran/symbol.c
>
> >> @@ -5052,7 +5052,7 @@ gfc_get_typebound_proc (gfc_typebound_proc *tb0)
> >>
> >> result = XCNEW (gfc_typebound_proc);
> >> if (tb0)
> >> -*result = *tb0;
> >> +memcpy (result, tb0, sizeof (gfc_typebound_proc));;
> >> result->error = 1;
> >>
> >> latest_undo_chgset->tbps.safe_push (result);
> >
> >
>
> please forgive me, but frankly speaking, I don't like this change.
>
> It seems to serve no obvious purpose other than obfuscating the code
> and defeating the compiler's ability to detect type mismatches.
mhm okay.
IIRC these are folded to memcpy early on and in some projects with
certain optimization levels results in an unobvious call to memcpy
(which poses trouble if you want to avoid relocations at all cost which
this might trigger if pulling in memcpy unexpectedly).
f951 of course is not in the camp to bother much about this so i admit
the change might stem from a tinfoil-hat moment of mine and might not
be appropriate here.
Although i don't buy the argument of the possibility of papering over
type-mismatches in this particular case (the incoming arg is typed
gfc_typebound_proc*, the result is typed gfc_typebound_proc*, the
allocation is casted to gfc_typebound_proc*) we can certainly revert
that hunk if folks prefer.
>
> I would not have OKed that part of the patch.
For reference:
gcc/fortran/symbol.c
gfc_typebound_proc*
gfc_get_typebound_proc (gfc_typebound_proc *tb0)
{
gfc_typebound_proc *result;
result = XCNEW (gfc_typebound_proc);
if (tb0)
memcpy (result, tb0, sizeof (gfc_typebound_proc));
result->error = 1;
latest_undo_chgset->tbps.safe_push (result);
return result;
}
And i did
-*result = *tb0;
+memcpy (result, tb0, sizeof (gfc_typebound_proc));
>
> Harald
>
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes (work in progress patches)
Michael, On Thu, 28 Oct 2021 23:36:20 -0400 Michael Meissner via Fortran wrote: ISTM the second @defmac FORTRAN_USE_LONG_DOUBLE in tm.texi.in should be FORTRAN_USE_FLOAT128 thanks,
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes (work in progress patches)
On Fri, Oct 29, 2021 at 09:07:38PM +0200, Thomas Koenig wrote: > Hi Michael, > > I tried this out on the one POWER machine where I can get something > installed :-) It runs Ubuntu 20.04, but does not appear to have the > right glibc version; it has > > $ lsb_release -a > No LSB modules are available. > Distributor ID: Ubuntu > Description:Ubuntu 20.04.1 LTS > Release:20.04 > Codename: focal > $ ldd --version > ldd (Ubuntu GLIBC 2.31-0ubuntu9.1) 2.31 > > Configure was > > ./trunk/configure --prefix=$HOME --enable-languages=c,c++,fortran > --with-advance-toolchain=at15.0 > --with-native-system-header-dir=/opt/at15.0/include > --with-long-double-format=ieee > > and the error message > > msgfmt -o fr.mo ../../../../trunk/libstdc++-v3/po/fr.po > msgfmt: /lib/powerpc64le-linux-gnu/libm.so.6: version `GLIBC_2.32' not found > (required by > /home/ig25/trunk-bin/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6) > msgfmt: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.33' not found > (required by > /home/ig25/trunk-bin/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6) > msgfmt: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.34' not found > (required by > /home/ig25/trunk-bin/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6) > msgfmt: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.32' not found > (required by > /home/ig25/trunk-bin/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6) > msgfmt: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.34' not found > (required by /home/ig25/trunk-bin/./gcc/libgcc_s.so.1) > > and so on. > > Since gcc135 is also too old, that exhausts my possibilities at testing. > > Any hints on how best to proceed? > > Best regards As I've delved into it, it looks glibc 2.34 is really only needed for switching long double over to IEEE 128-bit, since it has all of the F128 functions that would be needed. That is because Fortran uses the 'q' names which are in libquadmath (that should be built). I built the original version with: --prefix=/home/meissner/fsf-install-ppc64le/fortran-orig \ --enable-languages=c,c++,fortran \ --disable-plugin \ --enable-checking \ --enable-stage1-checking \ --enable-gnu-indirect-function \ --disable-libgomp \ --enable-decimal-float \ --enable-secureplt \ --enable-threads=posix \ --enable-__cxa_atexit \ --with-long-double-128 \ --with-long-double-format=ibm \ --with-cpu=power9 \ --with-as=/opt/at12.0/bin/as \ --with-ld=/opt/at12.0/bin/ld \ --with-gnu-as=/opt/at12.0/bin/as \ --with-gnu-ld=/opt/at12.0/bin/ld \ --with-gmp=/home/meissner/tools-compiler/ppc64le \ --with-mpfr=/home/meissner/tools-compiler/ppc64le \ --with-mpc=/home/meissner/tools-compiler/ppc64le \ --without-ppl \ --without-cloog \ --without-isl I needed to build my own version of mpfs, mpc, and gmp. I built them without shared libraries, because I get messages like you get. I have a new version of the patch that makes new target hooks to allow the backend to specify KIND numbers for types. I choose kind=16 to always be IEEE 128-bit, and kind=15 to be long double if long double is IBM (since I discovered yesterday, Fortran needs to be able to deal with long double). I'm in the middle of the build an on internal IBM system, and I will start the build on gcc135 shortly. -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email: meiss...@linux.ibm.com
Re: [PATCH,Fortran 1/2] Add uop/name helpers
On Fri, 29 Oct 2021 19:15:13 +0200
Bernhard Reutner-Fischer wrote:
> > But most importantly, I really don't like these helpers at all, they
> > unnecessarily allocate memory of the remaining duration of compilation,
> > and the second one even uses heap for temporary.
> I can easily switch the second one to use XALLOCAVEC if you'd accept
> that? Ok?
const char *
gfc_get_name_from_uop (const char *name)
{
gcc_assert (name[0] == '.');
const size_t len = strlen (name) - 1;
gcc_assert (len > 1);
gcc_assert (name[len] == '.');
const char *ret = gfc_get_string ("%.*s", len - 1, name + 1);
return ret;
}
if that's deemed portable enough nowadays? There seem to be preexisting
users in the tree so should be ok.
We can make these checking asserts or remove them altogether of course.
Would that be acceptable?
thanks,
>
> > Can't you just fix the real bug and keep the code as it was otherwise
> > (with XALLOCAVEC etc.)?
> > And, there should be a testcase...
>
> I tried to construct a testcase yesterday but failed.
> I took udr10.f90 and experimented with not using a derived type
> (because DERIVED || CLASS bypasses the failure to lookup st).
> I tried to move the module out to its own source to no avail and gave up
> late at night.
>
> Unrelated note:
> One thing that looked odd to my untrained eyes was in e.g. udr10.f90
> where you write:
> !$omp parallel do reduction(+:j) reduction(.localadd.:k)
> do i = 1, 100
> j = j .localadd. dl(i)
> k = k + dl(i * 2)
>
> which may of course be correct (even if + would be implemented by e.g.
> a twice_i procedure (and not addme like the user operator) but i'd have
> assumed the reduction oper to match the target var in the region, like
> !$omp parallel do reduction(.localadd.:j) reduction(+:k)
> But i admittedly know nothing about openmp syntax so it's certainly fine
> as written?
>
> PS: you have at least
> declare-simd-3.f90:! { dg-do compile { target { lp64 && { ! lp64 } } } }
> declare-target-2.f90:! { dg-do compile { target { lp64 && { ! lp64 } } } }
>
> and i think later on
> ! { dg-do compile { target skip-all-targets } }
> was added, presumably for this very purpose.
>
> thanks,
Re: [PATCH,FORTRAN 01/29] gdbinit: break on gfc_internal_error
Looks OK. Cheers On 10/29/21 11:58 AM, Bernhard Reutner-Fischer via Fortran wrote: ping On Wed, 5 Sep 2018 14:57:04 + Bernhard Reutner-Fischer wrote: From: Bernhard Reutner-Fischer Aids debugging the fortran FE. gcc/ChangeLog: 2017-11-12 Bernhard Reutner-Fischer * gdbinit.in: Break on gfc_internal_error. --- gcc/gdbinit.in | 1 + 1 file changed, 1 insertion(+) diff --git a/gcc/gdbinit.in b/gcc/gdbinit.in index 4db977f0bab..ac4d7c42e21 100644 --- a/gcc/gdbinit.in +++ b/gcc/gdbinit.in @@ -227,6 +227,7 @@ b fancy_abort # Put a breakpoint on internal_error to help with debugging ICEs. b internal_error +b gfc_internal_error set complaints 0 # Don't let abort actually run, as it will make
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes (work in progress patches)
On Fri, Oct 29, 2021 at 11:21:33PM +0200, Bernhard Reutner-Fischer wrote: > Michael, > > On Thu, 28 Oct 2021 23:36:20 -0400 > Michael Meissner via Fortran wrote: > > ISTM the second > @defmac FORTRAN_USE_LONG_DOUBLE > in tm.texi.in should be FORTRAN_USE_FLOAT128 Thanks. I had noticed that afterwards. Note, the next patches will delete those macros, because I discovered it was unworkable. -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email: meiss...@linux.ibm.com
Re: [PATCH] Fortran: adjust column sizes in intrinsic.texi
Am 29.10.21 um 21:44 schrieb Harald Anlauf via Fortran:
> Hi Manfred,
>
> Am 29.10.21 um 16:05 schrieb Manfred Schwarb via Fortran:
>> Hi,
>>
>> in intrinsic.texi, a lot of tables wrap lines when watching the
>> resulting info file in a 80char terminal.
>>
>> Adjust the @columnfractions items to fit screen. Some minor white space
>> changes are added as well to help saving space.
>
> the patch looks fine. However, could you please provide a properly
> formatted patch that applies using git patch and a ChangeLog entry?
>
Sorry, forgot the changelog entry, I added it to the patch now.
> Thanks,
> Harald
>
>> Signed-off-by Manfred Schwarb
>>
>>
>> [Note: I do not have commit access]
>>
>
>
2021-10-30 Manfred Schwarb
gcc/fortran/ChangeLog:
* intrinsic.texi: Adjust @columnfractions commands to improve
appearance for narrow 80 character terminals.
--- a/gcc/fortran/intrinsic.texi
+++ b/gcc/fortran/intrinsic.texi
@@ -461,7 +461,7 @@ end program test_abs
@end smallexample
@item @emph{Specific names}:
-@multitable @columnfractions .20 .20 .20 .25
+@multitable @columnfractions .20 .23 .20 .33
@headitem Name@tab Argument@tab Return type @tab Standard
@item @code{ABS(A)} @tab @code{REAL(4) A}@tab @code{REAL(4)}@tab Fortran 77 and later
@item @code{CABS(A)} @tab @code{COMPLEX(4) A} @tab @code{REAL(4)}@tab Fortran 77 and later
@@ -626,7 +626,7 @@ end program test_acos
@end smallexample
@item @emph{Specific names}:
-@multitable @columnfractions .20 .20 .20 .25
+@multitable @columnfractions .20 .23 .20 .33
@headitem Name@tab Argument @tab Return type @tab Standard
@item @code{ACOS(X)} @tab @code{REAL(4) X} @tab @code{REAL(4)} @tab Fortran 77 and later
@item @code{DACOS(X)} @tab @code{REAL(8) X} @tab @code{REAL(8)} @tab Fortran 77 and later
@@ -685,7 +685,7 @@ end program test_acosd
@end smallexample
@item @emph{Specific names}:
-@multitable @columnfractions .20 .20 .20 .25
+@multitable @columnfractions .20 .23 .20 .33
@headitem Name@tab Argument @tab Return type @tab Standard
@item @code{ACOSD(X)} @tab @code{REAL(4) X} @tab @code{REAL(4)} @tab GNU extension
@item @code{DACOSD(X)} @tab @code{REAL(8) X} @tab @code{REAL(8)} @tab GNU extension
@@ -741,7 +741,7 @@ END PROGRAM
@end smallexample
@item @emph{Specific names}:
-@multitable @columnfractions .20 .20 .20 .25
+@multitable @columnfractions .20 .23 .20 .33
@headitem Name @tab Argument @tab Return type @tab Standard
@item @code{DACOSH(X)} @tab @code{REAL(8) X} @tab @code{REAL(8)}@tab GNU extension
@end multitable
@@ -890,7 +890,7 @@ end program test_aimag
@end smallexample
@item @emph{Specific names}:
-@multitable @columnfractions .20 .20 .20 .25
+@multitable @columnfractions .20 .23 .20 .33
@headitem Name @tab Argument@tab Return type @tab Standard
@item @code{AIMAG(Z)}@tab @code{COMPLEX Z}@tab @code{REAL} @tab Fortran 77 and later
@item @code{DIMAG(Z)}@tab @code{COMPLEX(8) Z} @tab @code{REAL(8)} @tab GNU extension
@@ -950,7 +950,7 @@ end program test_aint
@end smallexample
@item @emph{Specific names}:
-@multitable @columnfractions .20 .20 .20 .25
+@multitable @columnfractions .20 .23 .20 .33
@headitem Name @tab Argument @tab Return type @tab Standard
@item @code{AINT(A)} @tab @code{REAL(4) A} @tab @code{REAL(4)} @tab Fortran 77 and later
@item @code{DINT(A)} @tab @code{REAL(8) A} @tab @code{REAL(8)} @tab Fortran 77 and later
@@ -1230,7 +1230,7 @@ end program test_anint
@end smallexample
@item @emph{Specific names}:
-@multitable @columnfractions .20 .20 .20 .25
+@multitable @columnfractions .20 .23 .20 .33
@headitem Name@tab Argument @tab Return type @tab Standard
@item @code{ANINT(A)} @tab @code{REAL(4) A} @tab @code{REAL(4)} @tab Fortran 77 and later
@item @code{DNINT(A)} @tab @code{REAL(8) A} @tab @code{REAL(8)} @tab Fortran 77 and later
@@ -1346,7 +1346,7 @@ end program test_asin
@end smallexample
@item @emph{Specific names}:
-@multitable @columnfractions .20 .20 .20 .25
+@multitable @columnfractions .20 .23 .20 .33
@headitem Name@tab Argument @tab Return type @tab Standard
@item @code{ASIN(X)} @tab @code{REAL(4) X} @tab @code{REAL(4)}@tab Fortran 77 and later
@item @code{DASIN(X)} @tab @code{REAL(8) X} @tab @code{REAL(8)}@tab Fortran 77 and later
@@ -1405,7 +1405,7 @@ end program test_asind
@end smallexample
@item @emph{Specific names}:
-@multitable @columnfractions .20 .20 .20 .25
+@multitable @columnfractions .20 .23 .20 .33
@headitem Name@tab Argument @tab Return type @tab Standard
@item @code{ASIND(X)} @tab @code{REAL(4) X} @tab @code{REAL(4)}@tab GNU extension
@item @code{DASIND(X)} @tab @code{REAL(8) X} @tab @code{REAL(8)}@tab GNU extension
@@ -1461,7 +1461,7 @@ END PROGRAM
@end smallexam
Re: [PATCH] Fortran: adjust error message for SHORT and LONG intrinsics
Am 29.10.21 um 21:51 schrieb Harald Anlauf via Fortran:
> Hi Manfred,
>
> Am 29.10.21 um 16:12 schrieb Manfred Schwarb via Fortran:
>> Hi,
>>
>> on 2019-07-23, support for SHORT and LONG intrinsics were removed be Steve
>> Kargl by
>> adding an error message in check.c. However, the error message
>>Error: 'long' intrinsic subprogram at (1) has been deprecated
>> is misleading, as support has been disabled by this patch.
>>
>> Adjust the error message. This error message does not appear in the
>> testsuite AFAIK.
>
> the patch looks fine. A testcase checking the error message is missing,
> as well as a ChangeLog entry.
Sorry, forgot the changelog entry, I added it to the patch now.
Testcase was missing already before, but I added a trivial test to the patch
for completeness.
>
> Thanks,
> Harald
>
>> Signed-off-by Manfred Schwarb
>>
>>
>> [Note: I do not have commit access]
>>
>
>
2021-10-30 Manfred Schwarb
gcc/fortran/ChangeLog:
* check.c (gfc_check_intconv): Change error message.
gcc/testsuite/ChangeLog:
* gfortran.dg/intrinsic_short-long.f90: New test.
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -3240,7 +3240,7 @@ gfc_check_intconv (gfc_expr *x)
if (strcmp (gfc_current_intrinsic, "short") == 0
|| strcmp (gfc_current_intrinsic, "long") == 0)
{
- gfc_error ("%qs intrinsic subprogram at %L has been deprecated. "
+ gfc_error ("%qs intrinsic subprogram at %L has been removed. "
"Use INT intrinsic subprogram.", gfc_current_intrinsic,
&x->where);
return false;
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/intrinsic_short-long.f90
@@ -0,0 +1,11 @@
+! { dg-do compile }
+!
+! Checking for removal of SHORT and LONG intrinsics.
+!
+ real,parameter :: a=3.1415927
+ integer :: i
+
+ i=SHORT(a) ! { dg-error "has been removed" }
+ i=LONG(a) ! { dg-error "has been removed" }
+
+ end
Re: [PATCH] Fortran: Remove documentation for SHORT and LONG intrinics
Am 29.10.21 um 21:52 schrieb Harald Anlauf via Fortran:
> Hi Manfred,
>
> Am 29.10.21 um 16:13 schrieb Manfred Schwarb via Gcc-patches:
>> Hi,
>>
>> on 2019-07-23, support for SHORT and LONG intrinsics was removed be Steve
>> Kargl by
>> adding an error message in check.c. As far as I can see code support is
>> still there, though.
>>
>> Remove documentation for these intrinsics.
>
> could you please provide a formatted patch that applies using git apply?
> And a ChangeLog entry?
Sorry, forgot the changelog entry, I added it to the patch now.
>
> Thanks,
> Harald
>
>> Signed-off-by Manfred Schwarb
>>
>>
>> [Note: I do not have commit access]
>>
>
>
2021-10-30 Manfred Schwarb
gcc/fortran/ChangeLog:
* intrinsic.texi: Remove entries for SHORT and LONG intrinsics.
--- a/gcc/fortran/intrinsic.texi
+++ b/gcc/fortran/intrinsic.texi
@@ -221,7 +221,6 @@ Some basic guidelines for editing this d
* @code{LOG10}: LOG10, Base 10 logarithm function
* @code{LOG_GAMMA}: LOG_GAMMA, Logarithm of the Gamma function
* @code{LOGICAL}: LOGICAL, Convert to logical type
-* @code{LONG}: LONG, Convert to integer type
* @code{LSHIFT}:LSHIFT,Left shift bits
* @code{LSTAT}: LSTAT, Get file status
* @code{LTIME}: LTIME, Convert time to local time info
@@ -8372,7 +8371,6 @@ end program
@node INT2
@section @code{INT2} --- Convert to 16-bit integer type
@fnindex INT2
-@fnindex SHORT
@cindex conversion, to integer
@table @asis
@@ -8381,8 +8379,6 @@ Convert to a @code{KIND=2} integer type.
standard @code{INT} intrinsic with an optional argument of
@code{KIND=2}, and is only included for backwards compatibility.
-The @code{SHORT} intrinsic is equivalent to @code{INT2}.
-
@item @emph{Standard}:
GNU extension
@@ -8403,8 +8399,7 @@ The return value is a @code{INTEGER(2)}
@item @emph{See also}:
@ref{INT}, @gol
-@ref{INT8}, @gol
-@ref{LONG}
+@ref{INT8}
@end table
@@ -8440,8 +8435,7 @@ The return value is a @code{INTEGER(8)}
@item @emph{See also}:
@ref{INT}, @gol
-@ref{INT2}, @gol
-@ref{LONG}
+@ref{INT2}
@end table
@@ -9848,44 +9842,6 @@ kind corresponding to @var{KIND}, or of
@end table
-
-@node LONG
-@section @code{LONG} --- Convert to integer type
-@fnindex LONG
-@cindex conversion, to integer
-
-@table @asis
-@item @emph{Description}:
-Convert to a @code{KIND=4} integer type, which is the same size as a C
-@code{long} integer. This is equivalent to the standard @code{INT}
-intrinsic with an optional argument of @code{KIND=4}, and is only
-included for backwards compatibility.
-
-@item @emph{Standard}:
-GNU extension
-
-@item @emph{Class}:
-Elemental function
-
-@item @emph{Syntax}:
-@code{RESULT = LONG(A)}
-
-@item @emph{Arguments}:
-@multitable @columnfractions .15 .70
-@item @var{A}@tab Shall be of type @code{INTEGER},
-@code{REAL}, or @code{COMPLEX}.
-@end multitable
-
-@item @emph{Return value}:
-The return value is a @code{INTEGER(4)} variable.
-
-@item @emph{See also}:
-@ref{INT}, @gol
-@ref{INT2}, @gol
-@ref{INT8}
-@end table
-
-
@node LSHIFT
@section @code{LSHIFT} --- Left shift bits
Re: [PATCH] Fortran: Correct documentation for REAL intrinsic
Am 29.10.21 um 21:56 schrieb Harald Anlauf via Fortran:
> Hi Manfred,
>
> Am 29.10.21 um 16:18 schrieb Manfred Schwarb via Gcc-patches:
>> Hi,
>>
>> documentation for REAL intrinsic is slightly wrong. Fix it.
>> Patch is done on top of the column adjustment patch.
>
> the patch looks fine, but it would help a lot to have a ChangeLog entry.
Sorry, forgot the changelog entry, I added it to the patch now.
>
> Thanks,
> Harald
>
>> Signed-off-by Manfred Schwarb
>>
>>
>> [Note: I do not have commit access]
>>
>
>
2021-10-30 Manfred Schwarb
gcc/fortran/ChangeLog:
* intrinsic.texi (REAL): Fix entries in Specific names table.
--- a/gcc/fortran/intrinsic.texi
+++ b/gcc/fortran/intrinsic.texi
@@ -12251,12 +12255,12 @@ end program test_real
@item @emph{Specific names}:
@multitable @columnfractions .20 .23 .20 .33
@headitem Name @tab Argument @tab Return type @tab Standard
-@item @code{FLOAT(A)} @tab @code{INTEGER(4)} @tab @code{REAL(4)} @tab GNU extension
+@item @code{FLOAT(A)} @tab @code{INTEGER(4)} @tab @code{REAL(4)} @tab Fortran 77 and later
@item @code{DFLOAT(A)} @tab @code{INTEGER(4)} @tab @code{REAL(8)} @tab GNU extension
-@item @code{FLOATI(A)} @tab @code{INTEGER(2)} @tab @code{REAL(4)} @tab GNU extension
-@item @code{FLOATJ(A)} @tab @code{INTEGER(4)} @tab @code{REAL(4)} @tab GNU extension
-@item @code{FLOATK(A)} @tab @code{INTEGER(8)} @tab @code{REAL(4)} @tab GNU extension
-@item @code{SNGL(A)} @tab @code{INTEGER(8)} @tab @code{REAL(4)} @tab GNU extension
+@item @code{FLOATI(A)} @tab @code{INTEGER(2)} @tab @code{REAL(4)} @tab GNU extension (-fdec)
+@item @code{FLOATJ(A)} @tab @code{INTEGER(4)} @tab @code{REAL(4)} @tab GNU extension (-fdec)
+@item @code{FLOATK(A)} @tab @code{INTEGER(8)} @tab @code{REAL(4)} @tab GNU extension (-fdec)
+@item @code{SNGL(A)} @tab @code{REAL(8)} @tab @code{REAL(4)} @tab Fortran 77 and later
@end multitable
Re: [PATCH] Fortran: recognize Gerhard Steinmetz
Am 29.10.21 um 21:58 schrieb Harald Anlauf via Fortran: > Hi Manfred, > > Am 29.10.21 um 16:33 schrieb Manfred Schwarb via Fortran: >> Hi, >> there were really a lot of test cases provided by Gerhard Steinmetz lately. >> Although I'm not really in the position to suggest this, >> I would appreciate it, if one could recognize him by adding an entry to >> gfortran.texi. >> >> As e.g. in the proposed patch. Such a patch should probably be signed-off my >> someone of >> the inner circle and not by me ;-) > > well, this is sth. close to obvious to everybody. ;-) > Anyway, a ChangeLog entry would be nice. I would feel more comfortable if such a patch would origin from somebody else, not from me, actually. > > Harald > >> Cheers, >> Manfred >> > >
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes (2nd patch)
This patch replaces the first patch.
Instead of disallowing long double and only dealing with float128 types, this
patch tries to accommodate the two.
It adds target hooks so the back end can overwrite the kind number for types.
I made the IBM long double type use KIND=15 instead of KIND=16, and Float128
uses KIND=16 as we've discussed. The tests for long double are still
failing, so I suspect we will need some way of signalling about the long double
which uses a funky kind (king=15).
Again, this patch may be completely wild and crazy, as I don't really grok the
Fortran internals. But perhaps it will help somebody to take the concepts and
come up with a more workable solution.
Note, the fleshing out of full F128 support is only partially done. I
discovered that we don't have a complete set of FLOAT128 built-in functions
defined, so I couldn't just add code to DO_DEFINE_MATH_BUILTIN to make every
math function have the float128 counterpart declared. Note, that code is
probably not used right now, since the float128 support uses the 'q' functions
in libquadmath. Too fully utilize the f128 functions, you will need glibc 2.34
or later.
> From 80d617264d80eb86806aecb2db5f37adb9b37ff6 Mon Sep 17 00:00:00 2001
> From: Michael Meissner
> Date: Fri, 29 Oct 2021 18:35:42 -0400
> Subject: [PATCH] Second patch for PowerPC Fortran KIND=16.
This replaces the first patch, and it is a work in progress. This patch
adds three target hooks to allow the backend to control the fortran KIND
numbers. I have modified the PowerPC back end so that KIND==16 is always
IEEE 128-bit on systems support IEEE 128-bit, and KIND=15 is the long
double type if long double is IBM 128-bit.
gcc/
2021-10-29 Michael Meissner
* config/rs6000/rs6000.c (TARGET_FORTRAN_REAL_KIND_NUMBER): Set
target hook.
(TARGET_FORTRAN_REAL_KIND_TYPE): Likewise.
(TARGET_FORTRAN_REAL_KIND_FLOAT128_P): Likewise.
(rs6000_fortran_real_kind_number): New target hook.
(rs6000_fortran_real_kind_type): Likewise.
(rs6000_fortran_real_kind_float128_p): Likewise.
* target.def (fortran_real_kind_number): New target hook.
(fortran_real_kind_type): Likewise.
(fortran_real_kind_float128_p): Likewise.
* targhooks.c (default_fortran_real_kind_number): New default
target hooks for Fortran kind support.
(default_fortran_real_kind_type): Likewise.
(default_fortran_real_kind_float128_p): Likewise.
* targhooks.h (default_fortran_real_kind_number): New
declaration.
(default_fortran_real_kind_type): Likewise.
(default_fortran_real_kind_float128_p): Likewise.
* tree.h (complex_float128_type_node): New define.
* doc/tm.texi.in (TARGET_FORTRAN_REAL_KIND_*): Document new target
hooks.
* doc/tm.texi: Regenerate.
gcc/fortran/
2021-10-29 Michael Meissner
* f95-lang.c (gfc_init_builtin_functions): Flesh out more Float128
support.
* trans-types.c (gfc_init_kinds): Add support for using target
hooks to allow the backend to control KIND numbers.
(gfc_build_real_type): Likewise.
(gfc_build_complex_type): Add support for complex Float128.
---
gcc/config/rs6000/rs6000.c | 101 +
gcc/doc/tm.texi| 17 +++
gcc/doc/tm.texi.in | 6 +++
gcc/fortran/f95-lang.c | 28 ++
gcc/fortran/trans-types.c | 32
gcc/target.def | 22 +++-
gcc/targhooks.c| 37 ++
gcc/targhooks.h| 3 ++
gcc/tree.h | 2 +
9 files changed, 236 insertions(+), 12 deletions(-)
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 22f5d701908..70595e58ac2 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -1787,6 +1787,15 @@ static const struct attribute_spec
rs6000_attribute_table[] =
#undef TARGET_INVALID_CONVERSION
#define TARGET_INVALID_CONVERSION rs6000_invalid_conversion
+
+#undef TARGET_FORTRAN_REAL_KIND_NUMBER
+#define TARGET_FORTRAN_REAL_KIND_NUMBER rs6000_fortran_real_kind_number
+
+#undef TARGET_FORTRAN_REAL_KIND_TYPE
+#define TARGET_FORTRAN_REAL_KIND_TYPE rs6000_fortran_real_kind_type
+
+#undef TARGET_FORTRAN_REAL_KIND_FLOAT128_P
+#define TARGET_FORTRAN_REAL_KIND_FLOAT128_P rs6000_fortran_real_kind_float128_p
/* Processor table. */
@@ -28376,6 +28385,98 @@ rs6000_globalize_decl_name (FILE * stream, tree decl)
}
#endif
+
+
+/* PowerPC support for Fortran KIND support. Given a MODE, return a kind
+ number to be used for real modes. If we support IEEE 128-bit, make KIND=16
+ always be IEEE 128-bit, and make KIND=15 be the IBM 128-bit double-double
+ format. */
+
+static int
+rs6000_fortran_real_kind_number (machine_mode mode)
+{
+ if (TARGET_FLOAT128_TYPE)
+{
+ /* If long double is IEEE 128-bit, return 16 for long double and 15 for
+__ibm128,
