Re: [PATCH] fortran: Fix specification expression check in submodules [PR114475]
On Wed, Mar 27, 2024 at 04:30:42PM +0100, Mikael Morin wrote: > Hell(o), > > it didn't take long for my recent patch for PR111781 to show a regression. > The fix proposed here is actually the one Harald posted in the PR. > I can't imagine a case where it wouldn't do the right thing. > Regression tested on x86_64-pc-linux-gnu. > OK for master? > Yes. Thank you (and Harald) for the quick fix. -- Steve
Re: [PATCH] Fortran: add two small F2023 features
On Tue, Mar 19, 2024 at 04:17:32PM +0100, FX Coudert wrote: > > These two (independent) patches add two tiny Fortran 2023 features: new > ISO_FORTRAN_ENV named constants and SELECTED_LOGICAL_KIND intrinsic. > > Bootstrapped and regtested on x86_64-pc-linux-gnu. > Please review, and let me know if it’s okay to push once we’re back in stage > 1. > (I know it’s not particularly soon, but I don’t want to forget these so I’m > posting them for review) > Both patches look good to me. Thanks. -- Steve
Re: [patch, libgfortran] Part 2: PR105456 Child I/O does not propage iostat
On Tue, Mar 05, 2024 at 08:06:10PM -0800, Jerry D wrote:
> On 3/5/24 1:51 PM, Harald Anlauf wrote:
> > Hi Jerry,
> >
> > on further thought, do we sanitize 'child_iomsg'?
> > We pass it to snprintf as format.
> >
> > Wouldn't a strncpy be sufficient?
> >
> > Harald
> >
> >
>
> Just to be safe I will bump char message[IOMSG_LEN] to char
> message[IOMSG_LEN + 1]
>
> This is like a C string vs a Fortran string length situation. snprintf
> guarantees we don't exceed the child_iomsg_len and null terminates it.
>
> I added 1 to:
> child_iomsg_len = string_len_trim (IOMSG_LEN, child_iomsg) + 1
>
string_len_trim substracts 1 from the passed in argument.
gfc_charlen_type
string_len_trim (gfc_charlen_type len, const CHARTYPE *s)
{
if (len <= 0)
return 0;
const size_t long_len = sizeof (unsigned long);
size_t i = len - 1;
Does this account for the NULL?
--
steve
Re: [patch, libgfortran] Part 2: PR105456 Child I/O does not propage iostat
On Thu, Feb 29, 2024 at 09:36:43AM -0800, Jerry D wrote: > On 2/29/24 1:47 AM, Bernhard Reutner-Fischer wrote: > > > And, just for my own education, the length limitation of iomsg to 255 > > chars is not backed by the standard AFAICS, right? It's just our > > STRERR_MAXSZ? > > Yes, its what we have had for a long lone time. Once you throw an error > things get very processor dependent. I found MSGLEN set to 100 and IOMSG_len > to 256. Nothing magic about it. > There is no restriction on the length for the iomsg-variable that receives the generated error message. In fact, if the iomsg-variable has a deferred-length type parameter, then (re)-allocation to the exact length is expected. F2023 12.11.6 IOMSG= specifier If an error, end-of-file, or end-of-record condition occurs during execution of an input/output statement, iomsg-variable is assigned an explanatory message, as if by intrinsic assignment. If no such condition occurs, the definition status and value of iomsg-variable are unchanged. character(len=23) emsg read(fd,*,iomsg=emsg) Here, the generated iomsg is either truncated to a length of 23 or padded with blanks to a length of 23. character(len=:), allocatable :: emsg read(fd,*,iomsg=emsg) Here, emsg should have the length of whatever error message was generated. HTH -- Steve
Rejects ASSOCIATE and a complex part%ref when target is a function
All,
Consider,
! { dg-do run }
program foo
implicit none
real y
associate (x => log(cmplx(-1,0)))
y = x%im
if (int(100*y)-314 /= 0) stop 1
end associate
end program
% gfcx -c a.f90
a.f90:6:13:
6 | y = x%im
| 1
Error: Symbol 'x' at (1) has no IMPLICIT type
'x' has the type of thi selector, which is COMPLEX.
I have created the following bug report
https://gcc.gnu.org/pipermail/gcc-bugs/2024-February/855452.html
and attached a patch that fixes the problem. The patch has been
regression tested against x86_64-*-freebsd. Please commit.
--
Steve
Re: [PATCH, v2] Fix fortran/PR114024
On Fri, Feb 23, 2024 at 10:15:17PM +0100, Harald Anlauf wrote: > Hi Steve, all, > > here's an updated patch with an enhanced testcase that also > checks MOLD= besides SOURCE=. > > Regtested on x86_64-pc-linux-gnu. Is it OK for mainline? > >From my viewpoint, yes. Thanks for finding a better solution than I had conjured. -- Steve
Re: [PATCH] Fix fortran/PR114024
On Thu, Feb 22, 2024 at 09:22:37PM +0100, Harald Anlauf wrote: > Hi Steve! > > On 2/22/24 01:52, Steve Kargl wrote: > > On Wed, Feb 21, 2024 at 01:42:32PM -0800, Steve Kargl wrote: > > > On Wed, Feb 21, 2024 at 10:20:43PM +0100, Harald Anlauf wrote: > > > > On 2/21/24 22:00, Steve Kargl wrote: > > > > > memleak vs ICE. I think I'll take one over the other. > > > > > Probably need to free code->expr3 before the copy. > > > > > > > > Yep. > > > > > > > > > I tried gfc_replace_expr in an earlier patch. It did not > > > > > work. > > > > I tried freeing code->expr3 before assigning the new expression. > > That leads to > > > > % gfcx -c ~/gcc/gccx/gcc/testsuite/gfortran.dg/allocate_with_source_28.f90 > > pid 69473 comm f951 has trashed its stack, killing > > gfortran: internal compiler error: Illegal instruction signal terminated > > program f951 > > Right. I also don't see what the lifetimes of the expressions are. > > But is the gfc_copy_expr really needed? Wouldn't the following suffice? > > code->expr3 = gfc_get_parentheses (code->expr3); It's been awhile since I use gfc_copy_expr, gfc_replace_expr, etc. I did not try the above. If that works, then we should use that for simplicity. > > If I don't free code->expr3 but simply assign the new > > expression from gfc_get_parentheses(), your example > > now compiles are executes are expected. It now > > allocate_with_source_28.f90. Caveat: I don't know > > how to test the CLASS uu. > > > > > > > > - it still fails on the following code, because the traversal > > > > > > of the refs is incomplete / wrong: > > > > > > > > > > > > program foo > > > > > > implicit none > > > > > > complex :: cmp(3) > > > > > > real, pointer :: pp(:) > > > > > > class(*), allocatable :: uu(:) > > > > > > type t > > > > > > real :: re > > > > > > real :: im > > > > > > end type t > > > > > > type u > > > > > > type(t) :: tt(3) > > > > > > end type u > > > > > > type(u) :: cc > > > > > > > > > > > > cmp = (3.45,6.78) > > > > > > cc% tt% re = cmp% re > > > > > > cc% tt% im = cmp% im > > > > > > allocate (pp, source = cc% tt% im) ! ICE > > > > > > > > > > cc%tt%im isn't a complex-part-ref, so this seems to > > > > > be a different (maybe related) issue. Does the code > > > > > compile with 'source = (cc%tt%im)'? If so, perhaps, > > > > > detecting a component reference and doing the simply > > > > > wrapping with parentheses can be done. > > > > > > > > Yes, that's why I tried to make up the above example. > > > > I think %re and %im are not too special, they work > > > > here pretty much like component refs elsewhere. > > > > > > > > > > I see. The %re and %im complex-part-ref correspond to > > > ref->u.i == INQUIRY_RE and INQUIRY_IM, respectively. > > > A part-ref for a user-defined type doesn't have an > > > INQUIRY_xxx, so we'll need to see if there is a way to > > > easily identify, e.g., cc%tt%re from your testcase. > > > > The attach patch uses ref->type == REF_COMPONENT to deal > > with the above code. > > I actually wanted to draw your attention away from the > real/complex stuff, because that is not really the point. > When do we actually need to enforce the parentheses? This is essentially my concern. I was inserting parentheses only if I determined they were needed (to avoid unnecessary temporary variable). The code paththat enters the else portion of the following if-else-stmt, where a temporary is created. That is, allocate(x, source=z%re) becomes allocate(x, source=(z%re)) and from code generation viewpoint this is tmp = (z%re) allocate(x, sourcer=tmp) deallocate(tmp) > I tried the following, and it seems to work: > > if (code->expr3->expr_type == EXPR_VARIABLE > && is_subref_array (code->expr3)) > code->expr3 = gfc_get_parentheses (code->expr3); > > (Beware: this is not regtested!) > > On the positive side, it not only seems to fix the cases in question, > but also substring references etc., like the following: If the above passes a regression test, then by all means we should use it. I did not consider the substring case. Even if unneeded parentheses are inserted, which may cause generation of a temporary variable, I hope users are not using 'allocate(x,source=z%re)' is some deeply nested crazy loops structure. BTW, my patch and I suspect your improved patch also fixes 'allocate(x,mold=z%re)'. Consider, complex z(3) real, allocatable :: x(:) z = 42 allocate(x, mold=z%re) print *, size(x) end % gfortran13 -o z a.f90 a.f90:9:25: 9 |allocate(x, mold=z%re) | 1 internal compiler error: in retrieve_last_ref, at fortran/trans-array.cc:6070 0x247d7a679 __libc_start1 /usr/src/lib/libc/csu/libc_start1.c:157 % gfcx -o z a.f90 && ./z 3 -- Steve
Re: [PATCH] Fix fortran/PR114024
On Wed, Feb 21, 2024 at 01:42:32PM -0800, Steve Kargl wrote:
> On Wed, Feb 21, 2024 at 10:20:43PM +0100, Harald Anlauf wrote:
> > On 2/21/24 22:00, Steve Kargl wrote:
> > > memleak vs ICE. I think I'll take one over the other.
> > > Probably need to free code->expr3 before the copy.
> >
> > Yep.
> >
> > > I tried gfc_replace_expr in an earlier patch. It did not
> > > work.
I tried freeing code->expr3 before assigning the new expression.
That leads to
% gfcx -c ~/gcc/gccx/gcc/testsuite/gfortran.dg/allocate_with_source_28.f90
pid 69473 comm f951 has trashed its stack, killing
gfortran: internal compiler error: Illegal instruction signal terminated
program f951
If I don't free code->expr3 but simply assign the new
expression from gfc_get_parentheses(), your example
now compiles are executes are expected. It now
allocate_with_source_28.f90. Caveat: I don't know
how to test the CLASS uu.
> > > > - it still fails on the following code, because the traversal
> > > >of the refs is incomplete / wrong:
> > > >
> > > > program foo
> > > > implicit none
> > > > complex :: cmp(3)
> > > > real, pointer :: pp(:)
> > > > class(*), allocatable :: uu(:)
> > > > type t
> > > >real :: re
> > > >real :: im
> > > > end type t
> > > > type u
> > > >type(t) :: tt(3)
> > > > end type u
> > > > type(u) :: cc
> > > >
> > > > cmp = (3.45,6.78)
> > > > cc% tt% re = cmp% re
> > > > cc% tt% im = cmp% im
> > > > allocate (pp, source = cc% tt% im) ! ICE
> > >
> > > cc%tt%im isn't a complex-part-ref, so this seems to
> > > be a different (maybe related) issue. Does the code
> > > compile with 'source = (cc%tt%im)'? If so, perhaps,
> > > detecting a component reference and doing the simply
> > > wrapping with parentheses can be done.
> >
> > Yes, that's why I tried to make up the above example.
> > I think %re and %im are not too special, they work
> > here pretty much like component refs elsewhere.
> >
>
> I see. The %re and %im complex-part-ref correspond to
> ref->u.i == INQUIRY_RE and INQUIRY_IM, respectively.
> A part-ref for a user-defined type doesn't have an
> INQUIRY_xxx, so we'll need to see if there is a way to
> easily identify, e.g., cc%tt%re from your testcase.
The attach patch uses ref->type == REF_COMPONENT to deal
with the above code.
--
Steve
diff --git a/gcc/fortran/trans-stmt.cc b/gcc/fortran/trans-stmt.cc
index 5247d3d39d7..414248fe2e5 100644
--- a/gcc/fortran/trans-stmt.cc
+++ b/gcc/fortran/trans-stmt.cc
@@ -6354,9 +6354,35 @@ gfc_trans_allocate (gfc_code * code, gfc_omp_namelist *omp_allocate)
al = al->next)
vtab_needed = (al->expr->ts.type == BT_CLASS);
+ /* When expr3 is a variable, i.e., a very simple expression, then
+ convert it once here. */
+
gfc_init_se (, NULL);
- /* When expr3 is a variable, i.e., a very simple expression,
- then convert it once here. */
+
+ /* If one has source = z%re or z%im with z a complex array or
+ source = a%b%c where a or b is an array of a derived type, then
+ things can go sideways with the complex-part-refi or part-ref, so
+ wrap the entity in parentheses to force evaluation of an expression.
+ That is, the else-branch in the following if-else-stmt is entered. */
+
+ if (code->expr3->expr_type == EXPR_VARIABLE
+ && code->expr3->ts.type == BT_REAL
+ && code->expr3->ref)
+ {
+ gfc_ref *ref = code->expr3->ref;
+
+ while (ref->next)
+ ref = ref->next;
+
+ if (ref->u.i == INQUIRY_IM || ref->u.i == INQUIRY_RE
+ || ref->type == REF_COMPONENT)
+ {
+ gfc_expr *etmp = gfc_get_parentheses (code->expr3);
+ code->expr3 = gfc_copy_expr (etmp);
+ gfc_free_expr (etmp);
+ }
+ }
+
if (code->expr3->expr_type == EXPR_VARIABLE
|| code->expr3->expr_type == EXPR_ARRAY
|| code->expr3->expr_type == EXPR_CONSTANT)
diff --git a/gcc/testsuite/gfortran.dg/allocate_with_source_27.f90 b/gcc/testsuite/gfortran.dg/allocate_with_source_27.f90
new file mode 100644
index 000..d0f0f3c4a84
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/allocate_with_source_27.f90
@@ -0,0 +1,20 @@
+!
+! { dg-do run }
+!
+! fortran/PR114024
+! https://github.com/fujitsu/compiler-test-suite
+! Modified from Fortran/0093/0093_0130.f90
+!
+program foo
+ implicit none
+ complex :: cmp(3)
+ real, allocatable :: xx(:), yy(:), zz(:)
+ cmp = (3., 6.78)
+ a
Re: [PATCH] Fix fortran/PR114024
On Wed, Feb 21, 2024 at 10:20:43PM +0100, Harald Anlauf wrote: > On 2/21/24 22:00, Steve Kargl wrote: > > Unfortunately, valgrind does not work on AMD FX-8350 cpu. > > Do you mean valgrind does not work at all? > For gcc, you need to configure --enable-valgrind-annotations > to not get bogus warnings. It does not work at all unless one tracks done an obscure patch for valgrind. The FX-8350 has a tbm instruction. Everything on the system would need be compiled with -mno-tbm (or -fno-tbm). % valgrind ./z ... ==88861== Process terminating with default action of signal 4 (SIGILL): dumping core ==88861== Illegal opcode at address 0x4D30D87 ==88861==at 0x4D30D87: ??? (in /lib/libc.so.7) ==88861==by 0x4D213DE: ??? (in /lib/libc.so.7) ==88861==by 0x4D2B935: ??? (in /lib/libc.so.7) ==88861==by 0x4D2C34E: ??? (in /lib/libc.so.7) ==88861==by 0x400AB8C: ??? (in /libexec/ld-elf.so.1) ==88861==by 0x4009828: ??? (in /libexec/ld-elf.so.1) ==88861==by 0x4006AE8: ??? (in /libexec/ld-elf.so.1) > > memleak vs ICE. I think I'll take one over the other. > > Probably need to free code->expr3 before the copy. > > Yep. > > > I tried gfc_replace_expr in an earlier patch. It did not > > work. > > > > > > - it still fails on the following code, because the traversal > > >of the refs is incomplete / wrong: > > > > > > program foo > > > implicit none > > > complex :: cmp(3) > > > real, pointer :: pp(:) > > > class(*), allocatable :: uu(:) > > > type t > > >real :: re > > >real :: im > > > end type t > > > type u > > >type(t) :: tt(3) > > > end type u > > > type(u) :: cc > > > > > > cmp = (3.45,6.78) > > > cc% tt% re = cmp% re > > > cc% tt% im = cmp% im > > > allocate (pp, source = cc% tt% im) ! ICE > > > > cc%tt%im isn't a complex-part-ref, so this seems to > > be a different (maybe related) issue. Does the code > > compile with 'source = (cc%tt%im)'? If so, perhaps, > > detecting a component reference and doing the simply > > wrapping with parentheses can be done. > > Yes, that's why I tried to make up the above example. > I think %re and %im are not too special, they work > here pretty much like component refs elsewhere. > I see. The %re and %im complex-part-ref correspond to ref->u.i == INQUIRY_RE and INQUIRY_IM, respectively. A part-ref for a user-defined type doesn't have an INQUIRY_xxx, so we'll need to see if there is a way to easily identify, e.g., cc%tt%re from your testcase. -- Steve
Re: [PATCH] Fix fortran/PR114024
On Wed, Feb 21, 2024 at 09:28:16PM +0100, Harald Anlauf wrote: > On 2/21/24 20:41, Jerry D wrote: > > On 2/21/24 10:30 AM, Steve Kargl wrote: > > > I have attached a patch to PR114024, see > > > > > > https://gcc.gnu.org/pipermail/gcc-bugs/2024-February/854651.html > > > > > > The patch contains a new testcase and passes regression > > > testing on x86_64-*-freebsd. Could someone castr an eye > > > over the patch and commit it? > > > > > > > Hi Steve, > > > > I looked it over and looks reasonable. I will try to apply it next few > > days and test here. If OK, I will commit. > > > > Jerry > > > > Actually the patch has two issues: > > - a minor one: a new front-end memleak which can be avoided by > using either gfc_replace_expr (see its other uses) > Hint: try valgrind on f951 Unfortunately, valgrind does not work on AMD FX-8350 cpu. memleak vs ICE. I think I'll take one over the other. Probably need to free code->expr3 before the copy. I tried gfc_replace_expr in an earlier patch. It did not work. > - it still fails on the following code, because the traversal > of the refs is incomplete / wrong: > > program foo >implicit none >complex :: cmp(3) >real, pointer :: pp(:) >class(*), allocatable :: uu(:) >type t > real :: re > real :: im >end type t >type u > type(t) :: tt(3) >end type u >type(u) :: cc > >cmp = (3.45,6.78) >cc% tt% re = cmp% re >cc% tt% im = cmp% im >allocate (pp, source = cc% tt% im) ! ICE cc%tt%im isn't a complex-part-ref, so this seems to be a different (maybe related) issue. Does the code compile with 'source = (cc%tt%im)'? If so, perhaps, detecting a component reference and doing the simply wrapping with parentheses can be done. >print *, pp >allocate (uu, source = cc% tt% im) ! ICE Ditto. Not to mention I know nothing about the implementation of CLASS in gfortran. -- Steve
[PATCH] Fix fortran/PR114024
I have attached a patch to PR114024, see https://gcc.gnu.org/pipermail/gcc-bugs/2024-February/854651.html The patch contains a new testcase and passes regression testing on x86_64-*-freebsd. Could someone castr an eye over the patch and commit it? -- Steve
Re: [PATCH] Fortran: fix passing array component to polymorphic argument [PR105658]
On Tue, Feb 20, 2024 at 08:53:37PM +0100, Harald Anlauf wrote: > On 2/19/24 16:19, Peter Hill wrote: > > Hi Harald, > > > > Thanks for your help, please see the updated and signed-off patch below. > > Pushed: https://gcc.gnu.org/g:14ba8d5b87acd5f91ab8b8c02165a0fd53dcc2f2 > Harald, Thanks for taking care of this commit. Peter, welcome to the menagerie. -- Steve
Re: [PATCH] Fortran: fix passing of optional dummies to bind(c) procedures [PR113866]
On Mon, Feb 12, 2024 at 09:57:08PM +0100, Harald Anlauf wrote: > Dear all, > > the attached patch fixes a mis-handling of optional dummy arguments > passed to optional dummy arguments of procedures with the bind(c) > attribute. When those procedures are expecting CFI descriptors, > there is no special treatment like a presence check necessary > that by default passes a NULL pointer as default. > > The testcase tries to exercise various combinations of passing > assumed-length character between bind(c) and non-bind(c), which > apparently was insufficiently covered in the testsuite. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > Yes. Thanks for filling out the more detailed testcase. -- Steve
Re: [patch, libgfortran] PR111022 ES0.0E0 format gave ES0.dE0 output with d too high.
Jerry,
The patch looks good to me, but please give Harald a chance
to comment.
--
steve
On Fri, Feb 02, 2024 at 07:17:55PM -0800, Jerry D wrote:
> On 1/30/24 12:36 PM, Harald Anlauf wrote:
> > Hi Jerry,
> >
> > Am 30.01.24 um 19:15 schrieb Jerry D:
> > > The attached patch attempts to fix the handling of the EN0.0E0 and
> > > ES0.0E0 formatting by correctly calculating the number of digits needed
> > > for the exponents and building those exponents into the float string.
> >
> > while your patch addresses ENw.dE0 and ESw.dE0 formatting,
> > it does not fix Ew.dE0, which can be seen with the following test:
> >
> > write(buffer,"(E0.3E0)") .6660_4
> > print *, buffer
> > write(buffer,"(E0.3)") .6660_4
> > print *, buffer
> >
> > I get even with your patch:
> >
> > 0.666
> > 0.666
> >
> > but would have expected:
> >
> > 0.666E+0 ! F2018 & F2023, table 13.1
> > 0.666E+0 ! F2023, table 13.1
> >
>
> Tha attached file shows the complete revised patch and git log generated by
> using the 'git show' command. I only just discovered that one. (eye roll).
>
> Regressions tested on x86-64. OK for trunk?
>
> Regards,
>
> Jerry
> commit 95c878a97944f952aef226ff0224b2198abfbe0f
> Author: Jerry DeLisle
> Date: Fri Feb 2 18:12:33 2024 -0800
>
> libgfortran: EN0.0E0 and ES0.0E0 format editing.
>
> PR libgfortran/111022
>
> F2018 and F2023 standards added zero width exponents. This required
> additional special handing in the process of building formatted
> floating point strings.
>
> G formatting uses either F or E formatting as documented in
> write_float.def comments. This logic changes the format token from FMT_G
> to FMT_F or FMT_E. The new formatting requirements interfere with this
> process when a FMT_G float string is being built. To avoid this, a new
> component called 'pushed' is added to the fnode structure to save this
> condition. The 'pushed' condition is then used to bypass portions of
> the new ES,E,EN, and D formatting, falling through to the existing
> default formatting which is retained.
>
> libgfortran/ChangeLog:
>
> * io/format.c (get_fnode): Update initialization of fnode.
> (parse_format_list): Initialization.
> * io/format.h (struct fnode): Added the new 'pushed' component.
> * io/write.c (select_buffer): Whitespace.
> (write_real): Whitespace.
> (write_real_w0): Adjust logic for the d == 0 condition.
> * io/write_float.def (determine_precision): Whitespace.
> (build_float_string): Calculate width of ..E0 exponents and
> adjust logic accordingly.
> (build_infnan_string): Whitespace.
> (CALCULATE_EXP): Whitespace.
> (quadmath_snprintf): Whitespace.
> (determine_en_precision): Whitespace.
>
> gcc/testsuite/ChangeLog:
>
> * gfortran.dg/fmt_error_10.f: Show D+0 exponent.
> * gfortran.dg/pr96436_4.f90: Show E+0 exponent.
> * gfortran.dg/pr96436_5.f90: Show E+0 exponent.
> * gfortran.dg/pr111022.f90: New test.
>
> diff --git a/gcc/testsuite/gfortran.dg/fmt_error_10.f
> b/gcc/testsuite/gfortran.dg/fmt_error_10.f
> index 6e1a5f60bea..fc6620a60a6 100644
> --- a/gcc/testsuite/gfortran.dg/fmt_error_10.f
> +++ b/gcc/testsuite/gfortran.dg/fmt_error_10.f
> @@ -18,7 +18,7 @@
>
>str = '(1pd0.15)'
>write (line,str,iostat=istat, iomsg=msg) 1.0d0
> - if (line.ne."1.000") STOP 5
> + if (line.ne."1.000D+0") STOP 5
>read (*,str,iostat=istat, iomsg=msg) x
>if (istat.ne.5006 .or. msg(1:10).ne."Zero width") STOP 6
>if (x.ne.555.25) STOP 7
> diff --git a/gcc/testsuite/gfortran.dg/pr111022.f90
> b/gcc/testsuite/gfortran.dg/pr111022.f90
> new file mode 100644
> index 000..eef55ff5ce0
> --- /dev/null
> +++ b/gcc/testsuite/gfortran.dg/pr111022.f90
> @@ -0,0 +1,72 @@
> +! { dg-do run }
> +program pr111022
> + character(20) :: buffer
> + write(buffer,"(EN0.3E0)") .6660_4
> + if (buffer.ne."666.000E-3") stop 1
> + write(buffer,"(EN0.3E0)") 6.660_4
> + if (buffer.ne."6.660E+0") stop 2
> + write(buffer,"(EN0.3E0)") 66.60_4
> + if (buffer.ne."66.600E+0") stop 3
> + write(buffer,"(EN0.3E0)") 666.0_4
> + if (buffer.ne."666.000E+0") stop 4
> + write(buffer,"(EN0.3E0)") 6660.0_4
> + if (buffer.ne."6.660E+3") stop 5
> + write(buffer,"(EN0.3E0)") 66600.0_4
> + if (buffer.ne."66.600E+3") stop 6
> +
> + write(buffer,"(EN0.0E0)") 666.0_4
> + if (buffer.ne."666.E+0") stop 7
> + write(buffer,"(EN0.0E1)") 666.0_4
> + if (buffer.ne."666.E+0") stop 8
> + write(buffer,"(EN0.0E2)") 666.0_4
> + if (buffer.ne."666.E+00") stop 9
> + write(buffer,"(EN0.0E3)") 666.0_4
> + if (buffer.ne."666.E+000") stop 10
> + write(buffer,"(EN0.0E4)") 666.0_4
> + if (buffer.ne."666.E+") stop 11
> +
Re: [PATCH] Fortran: use name of array component in runtime error message [PR30802]
On Sun, Jan 28, 2024 at 08:56:24PM +0100, Harald Anlauf wrote: > > Am 28.01.24 um 12:39 schrieb Mikael Morin: > > Le 24/01/2024 à 22:39, Harald Anlauf a écrit : > > > Dear all, > > > > > > this patch is actually only a followup fix to generate the proper name > > > of an array reference in derived-type components for the runtime error > > > message generated for the bounds-checking code. Without the proper > > > part ref, not only a user may get confused: I was, too... > > > > > > The testcase is compile-only, as it is only important to check the > > > strings used in the error messages. > > > > > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > > > > > > > the change proper looks good, and is an improvement. But I'm a little > > concerned by the production of references like in the test x1%vv%z which > > could be confusing and is strictly speaking invalid fortran (multiple > > non-scalar components). Did you consider generating x1%vv(?,?)%zz or > > x1%vv(...)%z or similar? > > yes, that seems very reasonable, given that this is what NAG does. > > We also have spurious %_data in some error messages that I'll try > to get rid off. > I haven't looked at the patch, but sometimes (if not always) things like _data are marked with attr.artificial. You might see if this will help with suppressing spurious messages. -- Steve
Re: [Fortran] half-cycle trig functions and atan[d] fixes
On Wed, Jan 24, 2024 at 11:13:05AM +0200, Janne Blomqvist wrote: > On Wed, Jan 24, 2024 at 10:28 AM FX Coudert wrote: > > > Now, if > > > the OS adds cospi() to libm and it's in libm's symbol map, then the > > > cospi() used by gfortran depends on the search order of the loaded > > > libraries. > > > > We only include the fallback math functions in libgfortran when they are > > not available on the system. configure detects what is present in the libc > > being targeted, and conditionally compiles the necessary fallback functions > > (and only them). > > Exactly. However, there is the (corner?) case when libgfortran has > been compiled, and cospi() not found and thus the fallback > implementation is included, and then later libc is updated to a > version that does provide cospi(). I believe in that case which > version gets used is down to the library search order (i.e. the order > that "ldd /path/to/binary" prints the libs), it will use the first > symbol it finds. Also, it's not necessary to do some ifdef tricks > with gfortran.map, if a symbol listed there isn't found in the library > it's just ignored. So the *pi() trig functions can be unconditionally > added there, and then depending on whether the target libm includes > those or not they are then included in the exported symbol list. > > It's possible to override this to look for specific symbol versions > etc., but that probably goes deep into the weeds of target-specific > stuff (e.g. are we looking for cospi@FBSD_1.7, cospi@GLIBC_X.Y.Z, or > something else?). I'm sure you don't wanna go there. > Ah, so that's the part I was missing. I was under the impression that if a symbol appears in a libraries symbol map, then the library had to contain a function by that name. If the loader ignores symbols for a missing function, then yes, I think I can get rid of the indirection via _gfortran_cospi_r4(). It will take a few days for me to redesign this, which shouldn't be too problematic in that GCC is in stage 4 and this is neither a regression or doc fix. Janne, FX, Harald, thanks for taking a peek. -- Steve
Re: [Fortran] half-cycle trig functions and atan[d] fixes
On Tue, Jan 23, 2024 at 01:37:54PM +0200, Janne Blomqvist wrote: > > > - If I get this right, to take one example, the Fortran front-end will emit > > a call to gfortran_acospi_r4(), libgfortran provides this as a wrapper > > calling acospif(), which is called either from libm or from libgfortran. > > This is different from other math library functions, like ACOS() where the > > acosf() call is generated directly from the front-end (and then the > > implementation comes either from libm or from libgfortran). Why not follow > > our usual way of doing things? > > Good point, that's what we've done in c99_functions.c in libgfortran. > We should probably do this so we can skip jumping via libgfortran when > libm implements these directly. > Hopefully, FX sees this as my emails to gmail bounce. I don't see how this can work or I don't understand symbol versioning in libraries. If an OS does not supply cospi() in its libm, then gfortran will fallback to a cospi() in libgfortran. With the indirection I currently implement, cospi() is not in the symbol map of libgfortran and _gfortran_cospi_r4() will use the libgfortran version. Now, if the OS adds cospi() to libm and it's in libm's symbol map, then the cospi() used by gfortran depends on the search order of the loaded libraries. Consider on FreeBSD, I have % nm --dynamic /lib/libm.so.5 | grep cospi 00025b60 T cospi@@FBSD_1.7 00025fe0 T cospif@@FBSD_1.7 0002e230 T cospil@@FBSD_1.7 % nm --dynamic work/lib/libgfortran.so.5 | grep cospi 002b1e60 T _gfortran_acospi_r10@@GFORTRAN_14 002b4590 T _gfortran_acospi_r16@@GFORTRAN_14 002b1d80 T _gfortran_acospi_r4@@GFORTRAN_14 002b1df0 T _gfortran_acospi_r8@@GFORTRAN_14 002b1ea0 T _gfortran_cospi_r10@@GFORTRAN_14 002b46d0 T _gfortran_cospi_r16@@GFORTRAN_14 002b1dc0 T _gfortran_cospi_r4@@GFORTRAN_14 002b1e30 T _gfortran_cospi_r8@@GFORTRAN_14 U cospi@FBSD_1.7 U cospif@FBSD_1.7 U cospil@FBSD_1.7 The FE generates code for _gfortran_cospi_rXX. If FreeBSD adds say acospif() and libgfortran also exported, then how does the linker choose between acospif@@FBSD_1.7 and acospif@@GFORTRAN_14?. -- Steve
Re: [Fortran] half-cycle trig functions and atan[d] fixes
On Tue, Jan 23, 2024 at 01:37:54PM +0200, Janne Blomqvist wrote: > On Tue, Jan 23, 2024 at 11:09 AM FX Coudert wrote: > > > > Hi Steve, > > Hello, long time no see. Time is short and we're all busy with life, but it is nice to see familiar names! > > > Thanks for the patch. I’ll take time to do a proper review, but after a > > first read I had the following questions: > > > > - "an OS's libm may/will contain cospi(), etc.”: do those functions conform > > to any standard? Are there plans to implement them outside FreeBSD at this > > point? > > acospi, asinpi, atan2pi, atanpi, cospi, sinpi, tanpi are all in IEEE > 754-2019, and are slated to be part of C23. I would assume actively > developed libm's will eventually catch up and implement them. > > > - If I get this right, to take one example, the Fortran front-end will emit > > a call to gfortran_acospi_r4(), libgfortran provides this as a wrapper > > calling acospif(), which is called either from libm or from libgfortran. > > This is different from other math library functions, like ACOS() where the > > acosf() call is generated directly from the front-end (and then the > > implementation comes either from libm or from libgfortran). Why not follow > > our usual way of doing things? > > Good point, that's what we've done in c99_functions.c in libgfortran. > We should probably do this so we can skip jumping via libgfortran when > libm implements these directly. > > > - On most targets, cospi() and friends are not available. Therefore, we end > > up doing the fallback (with limited precision as you noted) but with a lot > > of indirection. We could generate that code directly in the front-end, > > couldn’t we? > > The frontend generally doesn't know what the target libm implements, > hence it's better to just generate the call, and if necessary have a > barebones implementation in libgfortran if libm doesn't implement it > properly. > I suppose I could add a gfc_conv_trigpi() to trans-intrinsic.c, which could be used emit the function calls directly. Give me until Saturday to look at the issue. I've finally understood what Harald has been trying to tell me about the MPFR version issue in bugzilla, so I need to revamp simplification. -- Steve
Re: [Fortran] half-cycle trig functions and atan[d] fixes
On Tue, Jan 23, 2024 at 06:40:27AM -0800, Steve Kargl wrote:
> On Tue, Jan 23, 2024 at 10:08:43AM +0100, FX Coudert wrote:
> > Hi Steve,
> >
> > Thanks for the patch. I’ll take time to do a proper review, but
> > after a first read I had the following questions:
> >
> > - "an OS's libm may/will contain cospi(), etc.”: do those functions
> > conform to any standard? Are there plans to implement them outside
> >FreeBSD at this point?
>
> Yes. cospi, sinpi, and tanpi are in IEEE754-2008. These are
> also in ISO/IEC TS 18661-4 along with acospi, asinpi, and atanpi,
> which I believe where merged into C23 (see n3096.pdf). I've
I haven't checked.
> checked if atan2pi is in C23, but it is in F2023.
>
> AFAIK, FreeBSD's libm is the only OS that contains cospi, sinpi,
> and tanpi. The arc functions haven't been written/committed,
> because something like cospi(x) = cos(x) / pi with pi split
> into hi-lo parts is good enough.
Whoops. acospi(x) = acos(x) / pi. The fallback implements this
as acospi(x) = acos(x) * invpihi + acos(x) * invpilo with invpihi
the leading digits(x)/2 bits of 1/pi and invpilo the trailing
digits(x) of 1/pi.
For most libm's, acos(x) with |x| <= 1 have good numerical accuracy
and handle subnormal, |x| > 1, +-inf, and NaN by setting appropriate
exceptions. With FreeBSD and exhaustive testing in the interval, I see
% tlibm acos -f -x 0x1p-9 -X 1 -PED
Interval tested for acosf: [0.00195312,1]
ulp <= 0.5: 96.432% 72803871 | 96.432% 72803871
0.5 < ulp < 0.6: 3.110% 2348017 | 99.542% 75151888
0.6 < ulp < 0.7: 0.419%316134 | 99.961% 75468022
0.7 < ulp < 0.8: 0.039% 29450 | 100.000% 75497472
Max ulp: 0.796035 at 4.99814630e-01
Exhaustive testing of the fallback routine for acospi(x) gives
program foo
implicit none
integer n
real(4) f4, x, xm
real(8) f8, u, v
u = -1
x = scale(1., -9)
do
f4 = acospi(x)
f8 = acospi(real(x,8))
n = exponent(f8)
v = abs(f8 - f4)
v = scale(v, digits(f4) - n)
if (v > u) then
u = v
xm = x
end if
x = nearest(x, 2.)
if (x > 1) exit
end do
print *, u, acospi(xm), acospi(real(xm,8))
end program foo
% gfcx -o z -O a.f90 && ./z
1.9551682807505131 0.337791681 0.33779173955822828
so a max ulp of 1.955. Hopefully, OS libm's will catch up and
provide an implementation that gets the extra 1+ bit of precision.
Admittedly, the fallback routines for cospi(), sinpi(), and
tanpi() could be better, but much slower. For now, I do for
example,
float
cospif (float x)
{
return cosf (x * pihi_f + x * pilo_f);
}
A better routine would be,
/* cospi(x) = cos(pi*x) = cos(pi*n+pi*r) = +-cos(pi*r) with 0 <= r < 1i
and n integer. */
float
cospif (float x)
{
int s;
float ax, n, r;
ax = fabsf(ax);
if (ax > 0x1p23) {
return 1;
} else {
/* FreeBSD uses bit twiddling. See
https://cgit.freebsd.org/src/tree/lib/msun/src/s_cospif.c */
n = floor(ax); /* integer part */
r = ax - n; /* remainder */
s = floor(n/2) * 2 - n == 0 : 1 : -1; /* even n? */
return s * cosf (r * pi);
}
}
> > - On systems where libquadmath is used for _Float128, does
> > libquadmath contain the implementation of the q() variants for
> > those functions?
>
> AFAIK, libquadmath does not have the half-cycle functions. I
> wrote the function trig_fallback2.F90 to deal with REAL(16) (and
> maybe REAL17).
>
> > - If I get this right, to take one example, the Fortran front-end
> > will emit a call to gfortran_acospi_r4(), libgfortran provides this
> > as a wrapper calling acospif(), which is called either from libm
> > or from libgfortran.
>
> Yes, that is correct. I tried to install __builtin_acospif in
> trans-intrinsic to generate a direct call to acospif, but that
> led to many hours/days of frustration. I gave up.
>
> > This is different from other math library functions, like ACOS()
> > where the acosf() call is generated directly from the front-end
> > (and then the implementation comes either from libm or from
> > libgfortran). Why not follow our usual way of doing things?
>
> I gave up on that approach when I got some real obscure error
> about some math function which I did not touch.
>
I tried adding
DEFINE_MATH_BUILTIN_C (COSPI, "cospi", 0)
or
DEFINE_MATH_BUILTIN (COSPI, "cospi", 0)
or
OTHER_BUILTIN (COSPI, "cospi", 1, false) (and variations).
to mathbuiltins.def but this led to some obscure error message
about some other unrelated intrinsic subprogram.
--
Steve
Re: [Fortran] half-cycle trig functions and atan[d] fixes
On Tue, Jan 23, 2024 at 10:08:43AM +0100, FX Coudert wrote: > Hi Steve, > > Thanks for the patch. I’ll take time to do a proper review, but > after a first read I had the following questions: > > - "an OS's libm may/will contain cospi(), etc.”: do those functions > conform to any standard? Are there plans to implement them outside >FreeBSD at this point? Yes. cospi, sinpi, and tanpi are in IEEE754-2008. These are also in ISO/IEC TS 18661-4 along with acospi, asinpi, and atanpi, which I believe where merged into C23 (see n3096.pdf). I've checked if atan2pi is in C23, but it is in F2023. AFAIK, FreeBSD's libm is the only OS that contains cospi, sinpi, and tanpi. The arc functions haven't been written/committed, because something like cospi(x) = cos(x) / pi with pi split into hi-lo parts is good enough. > - On systems where libquadmath is used for _Float128, does > libquadmath contain the implementation of the q() variants for > those functions? AFAIK, libquadmath does not have the half-cycle functions. I wrote the function trig_fallback2.F90 to deal with REAL(16) (and maybe REAL17). > - If I get this right, to take one example, the Fortran front-end > will emit a call to gfortran_acospi_r4(), libgfortran provides this > as a wrapper calling acospif(), which is called either from libm > or from libgfortran. Yes, that is correct. I tried to install __builtin_acospif in trans-intrinsic to generate a direct call to acospif, but that led to many hours/days of frustration. I gave up. > This is different from other math library functions, like ACOS() > where the acosf() call is generated directly from the front-end > (and then the implementation comes either from libm or from > libgfortran). Why not follow our usual way of doing things? I gave up on that approach when I got some real obscure error about some math function which I did not touch. > - On most targets, cospi() and friends are not available. Therefore, > we end up doing the fallback (with limited precision as you noted) > but with a lot of indirection. We could generate that code directly > in the front-end, couldn’t we? The precision of the fallback routines isn't too bad. More later today. Late for a doctor's approintment. -- Steve
[Fortran] half-cycle trig functions and atan[d] fixes
All, I have attached a new patch to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152 which addresses the following issues. PR113152 -- implement half-cycle trigonometric functions PR113412 -- better error message for atan(y,x) PR113413 -- implement atand(y,x) The patch clocks in at 3488 lines, so will not be attached here. There are a few items that may need some explanation. First, some (if not all) of the half-cycle functions are contained in ISO/IEC TS 18661-4, IEEE754-2008, and now Fortran 2023. The patch assumes that an OS's libm may/will contain cospi(), etc. (see for example FreeBSD's libm). If these are not in libm, then fallback routines are provided by libgfortran. The fallback routines have seen limited testing, so your mileage may vary. Second, I have no idea what REAL17 entails; however, I provide untested routines in trigpi_fallback2.F90 where I use REAL(16) in the declarations (yikes). Third, MPFR provides half-cycle functions in version 4.2.0 (and later). For simplicifation, the patch checks for an adequate MPFR version, if an older version is found fallback algorithms are used. These have had limited testing. The patch appears to pass regression testing. Hopefully, someone will find time to test and commit the patch. The remainder is an attempt to write ChangeLog entries. gcc/fortran: * gfortran.h (gfc_isym_id): Add GFC_ISYM_ACOSPI, GFC_ISYM_ASINPI, GFC_ISYM_ATANPI, GFC_ISYM_ATAN2PI, GFC_ISYM_COSPI, GFC_ISYM_SINPI, and GFC_ISYM_TANPI * intrinsic.cc (do_check): Whitespace and typo in comments. (add_functions): Add two-argument form of ATAND. Add half-cycle trigonometric functions ACOSPI, ASINPI, ATANPI, ATAN2PI, COSPI, SINPI, and TANPI. (sort_actual): Generate sensible error messages for two argument versions of ATAN, ATAND, and ATANPI. * intrinsic.h: New prototypes for gfc_simplify_acospi, gfc_simplify_asinpi, gfc_simplify_atanpi, gfc_simplify_atan2pi, gfc_simplify_cospi, gfc_simplify_sinpi, gfc_simplify_tanpi, gfc_resolve_acospi, gfc_resolve_asinpi, gfc_resolve_atanpi, gfc_resolve_atan2pi, gfc_resolve_cospi, gfc_resolve_sinpi, and gfc_resolve_tanpi * intrinsic.texi: Document new functions ACOSPI, ASINPI, ATANPI, ATAN2PI, COSPI, SINPI, and TANPI. Put the ATAN* family of functions in lexigraphical order. * iresolve.cc (gfc_resolve_acospi, gfc_resolve_asinpi, gfc_resolve_atanpi, gfc_resolve_atan2pi, gfc_resolve_cospi, gfc_resolve_sinpi, gfc_resolve_tanpi): New functions. * simplify.cc (gfc_simplify_acospi, gfc_simplify_asinpi, gfc_simplify_atanpi, gfc_simplify_atan2pi, gfc_simplify_cospi, gfc_simplify_sinpi, gfc_simplify_tanpi): New functions. Introduce MPFR_HALF_CYCLE macros to use MPFR half-cycle functions if available. * trans-intrinsic.cc: Declare asinpi, acospi, atanpi, atan2pi, sinpi, cospi, and tanpi as LIB_FUNCTION's. libgfortran: *Makefile.am: New files trigpi.c, trigpi_fallback1.c, and trigpi_fallback2.F90 * configure.ac: Check libm for float, double, and long double functions for asinpi, acospi, atanpi, atan2pi, sinpi, cospi, and tanpi * Makefile.in: Regenerated. * config.h.in: Ditto. * configure: Ditto. * gfortran.map: Add GFORTRAN_14 section to expose the library symbols. * trigpi.c: Fallback implementations of the half-cycle trigonometric functions. * trigpi_fallback1.c: Fallback functions for float, double, and long double routines if libm does provide them. * trigpi_fallback2.F90: REAL(16)/REAL(17?) fallback implementations of the half-cycle trigonometric functions. -- Steve
Re: [PATCH] fortran: Restore current interface info on error [PR111291]
On Fri, Jan 19, 2024 at 06:47:36PM +0100, Mikael Morin wrote: > > I tested this on x86_64-pc-linux-gnu without regression. > There is no new test, as the problem is visible on an > existing test with valgrind or an asan-instrumented compiler. > OK for master? > Yes. After your explanation, the patch looks trivially obvious! :-) Thanks for the patch. -- Steve
Re: [PATCH] Fortran: intrinsic ISHFTC and missing optional argument SIZE [PR67277]
On Sat, Jan 13, 2024 at 10:12:42PM +0100, Harald Anlauf wrote: > > (2) a missing optional argument for SIZE to the ISHFTC intrinsic > shall be equivalent to using BIT_SIZE(I). > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > > As I consider the patch safe, I'd like to backport to 13-branch later. > OK for both trunk and a backport as time permits. -- Steve
Re: [Patch] Fortran: Accept -std=f2023, update line-length for Fortran 2023
On Tue, Jan 02, 2024 at 08:31:15PM +0100, Harald Anlauf wrote: > > we might want to update changes.html to reflect this. How about: > > diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html > index 403feb06..9b16f5e3 100644 > --- a/htdocs/gcc-14/changes.html > +++ b/htdocs/gcc-14/changes.html > @@ -284,6 +284,11 @@ a work-in-progress. > > Fortran > > + The compiler now accepts the -std=f2023 option, which > +has been added in preparation of support of Fortran 2023. This option > +increases the line-length limit for source in free-form to 1, and > +statements may have up to 1 million characters. > + > With the -save-temps option, preprocessed files > with the .fii extension will be generated from > free-form source files such as .F90 and > LGTM. -- Steve
Re: [PATCH] Fortran: update DATE_AND_TIME intrinsic for Fortran 2018 [PR96580]
On Mon, Dec 18, 2023 at 07:11:59PM +0100, Harald Anlauf wrote: > Dear all, > > starting with Fortran 2018, DATE_AND_TIME allowed a non-default > integer VALUES argument. > > While gfortran accepts this silently, this failed at runtime > because the library implementation beyond kind=4 and kind=8 > was missing. > > Futhermore, the standard effectively requires that the integer > kind is at least 2. The attached patch adds several checks, > plus adds checking for the array size to be sufficient, extends > the implementation to the remaining kinds, and corrects several > issues in the related documentation. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > Yes. Thanks for the patch. -- Steve
Re: [PATCH, v3] Fortran: restrictions on integer arguments to SYSTEM_CLOCK [PR112609]
On Wed, Nov 22, 2023 at 10:36:00AM +0100, Mikael Morin wrote: > > OK with this fixed (and the previous comments as you wish), if Steve has no > more comments. > No further comments. Thanks for your patients, Harald. As side note, I found John Reid's "What's new" document where it is noted that there are no new obsolescent or delete features. https://wg5-fortran.org/N2201-N2250/N2212.pdf -- Steve
Re: [PATCH, v2] Fortran: restrictions on integer arguments to SYSTEM_CLOCK [PR112609]
Harald,
Sorry about delayed response. Got side-tracked by Family this weekend.
On Sun, Nov 19, 2023 at 09:46:46PM +0100, Harald Anlauf wrote:
>
> On 11/19/23 01:04, Steve Kargl wrote:
> > On Sat, Nov 18, 2023 at 11:12:55PM +0100, Harald Anlauf wrote:
> > > Regtested on x86_64-pc-linux-gnu. OK for mainline?
> > >
> >
> > Not in its current form.
> >
> > > {
> > > + int first_int_kind = -1;
> > > + bool f2023 = ((gfc_option.allow_std & GFC_STD_F2023) != 0
> > > + && (gfc_option.allow_std & GFC_STD_GNU) == 0);
> > > +
> >
> > If you use the gfc_notify_std(), then you should not need the
> > above check on GFC_STD_GNU as it should include GFC_STD_F2023.
>
> this is actually the question (and problem). For all new features,
> -std=gnu shall include everything allowed by -std=f2023.
Yes.
> Here we have the problem that the testcase is valid F2018 and is
> silently accepted by gfortran-13 for -std=gnu and -std=f2018.
F2023 is the Fortran standard and supercedes previous Fortran standards.
If there is a conflict between the standing standard and an old standard,
then the standing standard should take precedence unless one specifically
uses, for example, -std=f2018.
After 20+ years of contributing to gfortran, I've come to believe
that the default -std= should be the current standard, and -std=gnu
should be deprecated. All GNU extensions should require an option
to active. For example,
write(*,*), 'hello'
end
gfortran12 -o z a.f90
a.f90:1:10:
1 | write(*,*), 'hello'
| 1
Warning: Legacy Extension: Comma before i/o item list at (1)
This should be an error unless the -fallow-write-stmt-comma is used.
The option would simply degrade the error to a warning. Why, you ask?
To encourage people to write standard conforming code. Unfortunately,
that horse has left the barn.
> I prefer to keep it that way also for gfortran-14, and apply the
> new restrictions only for -std=f2023. Do we agree on this?
If gfortran wants to maintain the status quo for 14, then
it should probably remove the -std=f2023 patch and wait for
the branch to 15.
> Now that should happen for -std=gnu -pedantic (-w)?
-pedantic is not a very effective option and should be ignored.
> I have thought some more and came up with the revised attached
> patch, which still has the above condition. It now marks the
> diagnostics as GNU extensions beyond F2023 for -std=f2023.
>
> The mask f2023 in the above form suppresses new warnings even
> for -pedantic; one would normally use -w to suppress them.
>
> Now if you remove the second part of the condition, we will
> regress on testcases system_clock_1.f90 and system_clock_3.f90
> because they would emit GNU extension warnings because the
> testsuite runs with -pedantic.
It seems that the solution is to fix the code in the testsuite.
With -std=f2023 or -std=gnu, the code should error. With
-std=f2018 (or older?), the code should compile.
It's been too long for my memory, doesn't the use of
'{ dg-options "-std=f023" }' supercede the set of predefined options
such as -pedantic?
> The options I see:
>
> - use patch-V1 (although diagnostics are better in V2),
>
> - use patch-V2,
>
> - use patch-V2, but enable -pedantic warnings for previously
> valid code, and adjust the failing testcases
I suppose that this last one is the best option.
>
> - ???
>
> > Elsewhere in the FE, gfortran uses gfc_notify_std() to enforce
> > requirements of a Fortran standard. The above would be
> >
> >if (count->ts.kind < gfc_default_integer_kind
> >&& gfc_notify_std (GFC_STD_F2023, "COUNT argument to
> > SYSTEM_CLOCK "
> > "at %L must have kind of at least default
> > integer",
> > >where))
>
> I tried this first, and it did not do the job.
>
> The logic in gfc_notify_std is:
>
> estd = std & ~gfc_option.allow_std; /* Standard to error about. */
> error = (estd != 0);
> if (error)
> msg = notify_std_msg (estd);
> ...
>
> So for -std=f2023 we get estd=0, error=false, and *NO* error.
> For -std=f2018 we get error=true and an error message.
> This is the opposite of what is needed.
>
> Can you please try yourself?
>
I was afraid you were going to say this. :-) :-)
The holidays draw near. I can probably find the time to
poke at gfortran.
> > Note, gfc_notify_std() should add the 'Fortran 2023: ' string,
> > if not, that should be fixed.
>
> This I did fix.
Thanks.
> > Of course, I seldom provide patches if others don't have a comment
> > then do as you like.
>
> Thanks for your feedback!
No, thank you for continuing to peck away at gfortran issue.
--
steve
Re: [PATCH] Fortran: restrictions on integer arguments to SYSTEM_CLOCK [PR112609]
On Sat, Nov 18, 2023 at 11:12:55PM +0100, Harald Anlauf wrote:
>
> Fortran 2023 added restrictions on integer arguments to SYSTEM_CLOCK.
> The attached patch implements these.
>
> I was struggling with the way we should handle features that are sort-of
> deleted in a new standard, but not described as such in the standard,
> which is why we do not have GFC_STD_F2023_DEL. As -std=gnu should not
> apply this restriction, I came up with the solution in the patch.
> While playing, I hit a gcc_unreachable in notify_std_msg due to a
> missing case, also fixed.
>
> Interestingly, the standard now has a recommendation:
>
> 16.9.202 SYSTEM_CLOCK
>
> It it recommended that all references to SYSTEM_CLOCK use integer
> arguments with a decimal exponent range of at least 18. ...
>
> In case the user chooses integer(4), shall we emit a warning
> e.g. under -pedantic, or some other flag? This is not done
> in the patch, but could be added.
>
> Regtested on x86_64-pc-linux-gnu. OK for mainline?
>
Not in its current form.
> {
> + int first_int_kind = -1;
> + bool f2023 = ((gfc_option.allow_std & GFC_STD_F2023) != 0
> + && (gfc_option.allow_std & GFC_STD_GNU) == 0);
> +
If you use the gfc_notify_std(), then you should not need the
above check on GFC_STD_GNU as it should include GFC_STD_F2023.
>
> + if (f2023 && count->ts.kind < gfc_default_integer_kind)
> + {
> + gfc_error ("Fortran 2023: COUNT argument to SYSTEM_CLOCK "
> + "at %L must have kind of at least default integer",
> + >where);
> + return false;
> + }
Elsewhere in the FE, gfortran uses gfc_notify_std() to enforce
requirements of a Fortran standard. The above would be
if (count->ts.kind < gfc_default_integer_kind
&& gfc_notify_std (GFC_STD_F2023, "COUNT argument to SYSTEM_CLOCK "
"at %L must have kind of at least default integer",
>where))
Note, gfc_notify_std() should add the 'Fortran 2023: ' string,
if not, that should be fixed.
Of course, I seldom provide patches if others don't have a comment
then do as you like.
--
Steve
Re: [PATCH] Fortran: fix issue with multiple references of a procedure pointer [PR97245]
On Fri, Nov 03, 2023 at 07:56:20PM +0100, Harald Anlauf wrote: > Dear all, > > this is a rather weird bug with a very simple fix. If a procedure pointer > is referenced in a CALL, a symbol was created shadowing the original > declaration if it was host-associated. Funnily, this affected only > references of the procedure pointer after the first CALL. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > > Would it be OK to backport this fix to 13-branch? > OK, and yes, you can backport if you want. -- Steve
Re: [Patch, fortran] PR64120
On Tue, Oct 31, 2023 at 02:11:08PM +, Paul Richard Thomas wrote: > I found this 'obvious' fix, while going through PRs assigned to me. > > Regtests. OK for mainline? > Yes. Fell free to backport if you have time and desire. -- Steve
Re: [patch] fortran/intrinsic.texi: Add 'passed by value' to signal handler
On Mon, Oct 16, 2023 at 08:31:20PM +0200, Harald Anlauf wrote:
>
> Am 16.10.23 um 19:11 schrieb Tobias Burnus:
> > Yesterday, someone was confused because the signal handler did not work.
> >
> > It turned out that the created Fortran procedure used as handler used
> > pass by reference - and 'signal' passed the it by value.
> >
> > This patch adds the 'passed by value' to the wording:
> >
> > "@var{HANDLER} to be executed with a single integer argument passed by
> > value"
> >
> > OK for mainline?
>
> I think the patch qualifies as obvious.
>
> While at it, you might consider removing the comment a few lines below
> the place you are changing,
>
> @c TODO: What should the interface of the handler be? Does it take
> arguments?
>
> and enhance the given example by e.g.:
>
> subroutine handler_print (signal_number)
> integer, value :: signal_number
> print *, "In handler_print: received signal number", signal_number
> end subroutine handler_print
>
Good suggestion, Harald. I was composing a similar email
when I saw yours pop into by inbox.
--
Steve
Re: [PATCH] Fortran: improve diagnostic message for COMMON with automatic object [PR32986]
On Wed, Aug 23, 2023 at 09:16:08PM +0200, Harald Anlauf via Fortran wrote: > > here's a simple patch for a very old PR that suggests a more helpful > error message for an automatic object in a COMMON. The patch also > suppresses the less helpful old error message after the new one has > been emitted. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > OK. I leave the decision on backporting to you. -- Steve
Re: [PATCH] Fortran: do not pass hidden character length for TYPE(*) dummy [PR110825]
On Thu, Jul 27, 2023 at 09:39:53PM +0200, Harald Anlauf via Fortran wrote: > Dear all, > > when passing a character actual argument to an assumed-type dummy > (TYPE(*)), we should not pass the character length for that argument, > as otherwise other hidden arguments that are passed as part of the > gfortran ABI will not be interpreted correctly. This is in line > with the current way the procedure decl is generated. > > The attached patch fixes the caller and clarifies the behavior > in the documentation. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > OK. Patch looks small enough that if you are so inclined to backport that's ok as well. Thanks for the quick response. -- Steve
Re: [PATCH, v3] Fortran: diagnose strings of non-constant length in DATA statements [PR68569]
On Wed, Jul 26, 2023 at 09:33:22PM +0200, Harald Anlauf via Fortran wrote: > I am going to get the brown bag for today... This is now the right > corrected patch. > > Sorry for all the noise! > Third times a charm (as the saying goes). Looks good to me. Thanks for the patch. -- Steve
Re: [PATCH] Fortran: intrinsics and deferred-length character arguments [PR95947,PR110658]
On Sun, Jul 16, 2023 at 10:30:59PM +0200, Harald Anlauf via Fortran wrote: > Dear all, > > some intrinsics may return character results with the same > characteristics as their first argument (e.g. PACK, MINVAL, ...). > If the first argument is of deferred-length, we need to derive > the character length of the result from the first argument, like > in the assumed-length case, but we must not handle it as > deferred-length, as that has a different argument passing > convention. > > The attached - almost trivial and obvious - patch fixes that. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > > As this is a rather simple fix for a wrong-code bug, I would > like to backport this at least to 13-branch, unless there > are major concerns. > OK for trunk and backports. -- Steve
Re: [PATCH] Fortran: formal symbol attributes for intrinsic procedures [PR110288]
On Tue, Jul 11, 2023 at 09:39:31PM +0200, Harald Anlauf via Fortran wrote: > Dear all, > > for intrinsic procedures we derive the typespec of the formal symbol > attributes from the actual arguments. This can have an undesired > effect for character actual arguments, as the argument passing > conventions differ for deferred-length (length is passed by reference) > and otherwise (length is passed by value). > > The testcase in the PR nicely demonstrates the issue for > FINDLOC(array,value,...), when either array or value are deferred-length. > > We therefore need take care that we do not copy ts.deferred, but > rather set it to false if the formal argument is neither allocatable > or pointer. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > > This is actually a 11/12/13/14 regression (and I found a potential > "culprit" in 11-development that touched the call chain in question), > so the patch might finally need backporting as far as seems reasonable. > OK. Backports are OK as well. -- Steve
Re: [Patch, fortran] Fix default type bugs in gfortran [PR99139, PR99368]
On Sat, Jul 08, 2023 at 03:23:31PM +0100, Paul Richard Thomas wrote: > The attached patch incorporates two of Steve's "Orphaned Patches" - > https://gcc.gnu.org/pipermail/fortran/2023-June/059423.html Thanks Paul for picking up the pieces I left behind. A few nits below. > They have in common that they both involve faults in use of default > type and that I was the ultimate cause of the bugs. > > The patch regtests with the attached testcases. > > I will commit in the next 24 hours unless there are any objections. > > Paul > > Fortran: Fix default type bugs in gfortran [PR99139, PR99368] > > 2023-07-08 Steve Kargl ka...@gcc.gnu.org. > gcc/fortran > PR fortran/99139 > PR fortran/99368 > * match.cc (gfc_match_namelist): Check for host associated or > defined types before applying default type. > (gfc_match_select_rank): Apply default type to selector of > unlnown type if possible. s/unlnown/unknown > * resolve.cc (resolve_fl_variable): Do not apply local default > initialization to assumed rank entities. > > gcc/testsuite/ > PR fortran/999139 > * gfortran.dg/pr99139.f90 : New test > > PR fortran/99368 > * gfortran.dg/pr99368.f90 : New test > > Fortran: Fix default type bugs in gfortran [PR99139, PR99368] > > 2023-07-08 Steve Kargl ka...@gcc.gnu.org > > gcc/fortran > PR fortran/99139 > PR fortran/99368 > * match.cc (gfc_match_namelist): Check for host associated or > defined types before applying default type. > (gfc_match_select_rank): Apply default type to selector of > unlnown type if possible. s/unlnown/unknown Other than the nits the patch looks fine. -- Steve
Re: [PATCH] Fortran: fixes for procedures with ALLOCATABLE,INTENT(OUT) arguments [PR92178]
On Tue, Jul 04, 2023 at 11:26:26AM +0200, Mikael Morin wrote: > Le 04/07/2023 à 01:56, Steve Kargl a écrit : > > On Mon, Jul 03, 2023 at 10:49:36PM +0200, Harald Anlauf via Fortran wrote: > > > > > > Indeed, this is a nice demonstration. > > > > > > While playing, I was wondering whether the following code is conforming: > > > > > > program p > > >call s ((1)) > > > contains > > >subroutine s (x) > > > integer :: x > > > x = 42 > > >end subroutine > > > end > > > > > > (It crashes with gfortran, but not with any foreign brand tested). > > > > > > > It's not conforming. '(1)' is an expression and it cannot appear > > in a variable definition condition. I am not aware of any numbered > > constraint tha would require a Fortran processor to generate an > > error. > > > > I think you would be right if X had INTENT(OUT) or INTENT(INOUT) attribute. > This is F2023, 15.5.2.4 (no mention of variable definition context here): > > If a dummy argument has INTENT (OUT) or INTENT (INOUT), the actual > > argument shall be definable. > > However, with unspecified intent, I can't find the rule explicitly > forbidding the above example. > I'm tempted to say it is conforming. I thought it was in Sec. 19, but failed to locate any prohibition. The best I can find is 23-007r1.pdf 8.5.10 INTENT attribute pg. 114 (following Note 1) If no INTENT attribute is specified for a dummy argument, its use is subject to the limitations of its effective argument (15.5.2). pg. 115 (within Note 4, so non-normative text) INTENT (INOUT) is not equivalent to omitting the INTENT attribute. The actual argument corresponding to an INTENT (INOUT) dummy argument is always required to be definable, while an actual argument corresponding to a dummy argument without an INTENT attribute need be definable only if the dummy argument is actually redefined. Searching for "definable" does not lead to a prohibition of the form "An expression is not definable." -- Steve
Re: [PATCH] Fortran: fixes for procedures with ALLOCATABLE,INTENT(OUT) arguments [PR92178]
On Mon, Jul 03, 2023 at 10:49:36PM +0200, Harald Anlauf via Fortran wrote: > > Indeed, this is a nice demonstration. > > While playing, I was wondering whether the following code is conforming: > > program p > call s ((1)) > contains > subroutine s (x) > integer :: x > x = 42 > end subroutine > end > > (It crashes with gfortran, but not with any foreign brand tested). > It's not conforming. '(1)' is an expression and it cannot appear in a variable definition condition. I am not aware of any numbered constraint tha would require a Fortran processor to generate an error. -- Steve
Re: PR82943 - Suggested patch to fix
On Thu, Jun 29, 2023 at 10:38:42PM -0500, Alexander Westbrooks via Fortran wrote: > I have finished my testing, and updated my patch and relevant Changelogs. I > added 4 new tests and all the existing tests in the current testsuite > for gfortran passed or failed as expected. Do I need to attach the test > results here? Yes. It helps others also do testing to have one self-contained patch (which I don't know to generate with git and new files :-( ). It may also be a good idea to attach the patch and test cases to the PR in bugzilla so that they don't accidentally get lost. > The platform I tested on was a Docker container running in Docker Desktop, > running the "mcr.microsoft.com/devcontainers/universal:2-linux" image. > > I also made sure that my code changes followed the coding standards. Please > let me know if there is anything else that I need to do. I don't have > write-access to the repository. See the legal link that Harald provided. At one time, one needed to assign copyright to the FSF with a wet-ink signature on some form. Now, I think you just need to attest that you have the right to provide the code to the gcc project. PS: Welcome to the gfortran development world. Don't be put off if there is a delay in getting feedback/review. There are too few contributors and too little time. If a week passes simply ping the mailing list. I'll try to carve out some time to look over your patch this weekend. -- steve > > Thanks, > > Alexander > > On Wed, Jun 28, 2023 at 4:14 PM Harald Anlauf wrote: > > > Hi Alex, > > > > welcome to the gfortran community. It is great that you are trying > > to get actively involved. > > > > You already did quite a few things right: patches shall be sent to > > the gcc-patches ML, but Fortran reviewers usually notice them only > > where they are copied to the fortran ML. > > > > There are some general recommendations on the formatting of C code, > > like indentation, of the patches, and of the commit log entries. > > > > Regarding coding standards, see https://www.gnu.org/prep/standards/ . > > > > Regarding testcases, a recommendation is to have a look at > > existing testcases, e.g. in gcc/testsuite/gfortran.dg/, and then > > decide if the testcase shall test the compile-time or run-time > > behaviour, and add the necessary dejagnu directives. > > > > You should also verify if your patch passes regression testing. > > For changes to gfortran, it is usually sufficient to run > > > > make check-fortran -j > > > > where is the number of parallel tests. > > You would need to report also the platform where you tested on. > > > > There is also a legal issue to consider before non-trivial patches can > > be accepted for incorporation: https://gcc.gnu.org/contribute.html#legal > > > > If your patch is accepted and if you do not have write-access to the > > repository, one of the maintainers will likely take care of it. > > If you become a regular contributor, you will probably want to consider > > getting write access. > > > > Cheers, > > Harald > > > > > > > > On 6/24/23 19:17, Alexander Westbrooks via Gcc-patches wrote: > > > Hello, > > > > > > I am new to the GFortran community. Over the past two weeks I created a > > > patch that should fix PR82943 for GFortran. I have attached it to this > > > email. The patch allows the code below to compile successfully. I am > > > working on creating test cases next, but I am new to the process so it > > may > > > take me some time. After I make test cases, do I email them to you as > > well? > > > Do I need to make a pull-request on github in order to get the patch > > > reviewed? > > > > > > Thank you, > > > > > > Alexander Westbrooks > > > > > > module testmod > > > > > > public :: foo > > > > > > type, public :: tough_lvl_0(a, b) > > > integer, kind :: a = 1 > > > integer, len :: b > > > contains > > > procedure :: foo > > > end type > > > > > > type, public, EXTENDS(tough_lvl_0) :: tough_lvl_1 (c) > > > integer, len :: c > > > contains > > > procedure :: bar > > > end type > > > > > > type, public, EXTENDS(tough_lvl_1) :: tough_lvl_2 (d) > > > integer, len :: d > > > contains > > > procedure :: foobar > > > end type > > > > > > contains > > > subroutine foo(this) > > > class(tough_lvl_0(1,*)), intent(inout) :: this > > > end subroutine > > > > > > subroutine bar(this) > > > class(tough_lvl_1(1,*,*)), intent(inout) :: this > > > end subroutine > > > > > > subroutine foobar(this) > > > class(tough_lvl_2(1,*,*,*)), intent(inout) :: this > > > end subroutine > > > > > > end module > > > > > > PROGRAM testprogram > > > USE testmod > > > > > > TYPE(tough_lvl_0(1,5)) :: test_pdt_0 > > > TYPE(tough_lvl_1(1,5,6)) :: test_pdt_1 > > > TYPE(tough_lvl_2(1,5,6,7)) :: test_pdt_2 > > > > > > CALL test_pdt_0%foo() > > > > > >
Re: [Patch, fortran] PR107900 Select type with intrinsic type inside associate causes ICE / Segmenation fault
On Wed, Jun 21, 2023 at 05:12:22PM +0100, Paul Richard Thomas wrote: > Committed as r14-2022-g577223aebc7acdd31e62b33c1682fe54a622ae27 > > Thanks for the help and the review Harald. Thanks to Steve too for > picking up Neil Carlson's bugs. > It's only natural. You fix bugs in a long desired feature, and people will start to use that feature more. I always look at Neil's bug reports. They're typically concise code snippets and have cross references to the Fortran standard. Unfortunately, I lack the ability to fix them. :( -- Steve
Re: [Patch, fortran] PR107900 Select type with intrinsic type inside associate causes ICE / Segmenation fault
On Sat, Jun 17, 2023 at 10:14:43AM +0100, Paul Richard Thomas via Fortran wrote: > > PS This leaves 89645 and 99065 as the only real blockers to PR87477. > Hate to be the bearer of bad news, but Neil Carlson has added a couple PRs about associate that may not be listed in 87447. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110224 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110033 For the second one, if I suppress the bogus error message, the compiler runs into a new error message. The second error message indicates the associate-name is not an unexpected coarray. I haven't determined how to propagate the information that the selector is a coarray to the associate-name. -- Steve
Re: [PATCH] Fortran: fix passing of zero-sized array arguments to procedures [PR86277]
On Mon, Jun 12, 2023 at 11:12:45PM +0200, Harald Anlauf via Fortran wrote: > Dear all, > > the attached - actually rather small - patch is the result of a > rather intensive session with Mikael in an attempt to fix the > situation that we did not create proper temporaries when passing > zero-sized array arguments to procedures. When the dummy argument > was declared as OPTIONAL, in many cases it was mis-detected as > non-present. This also depended on the type of argument, and > was different for different intrinsic types, notably character, > and derived types, and should explain the rather large ratio of > the size of the provided testcases to the actual fix... > > (What the patch does not address: we still generate too much code > for unneeded temporaries, often two temporaries instead of just > one. I'll open a separate PR to track this.) > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > > If this survives long enough on 14-trunk, would this be eligible > for a backport to 13-branch in time for 13.2? > OK to commit. I've reviewed the bugzilla exchange between Mikael and you, and agree with committing this and opening a new PR to track the unneeded temporaries issue. -- Steve
Orphaned patches
If anyone is so inclined, the patches in the following PR's can be committed and the PR closed. These are patches for gfortran. 69101 91960 95613 99139 99368 99798 100607 103795 103796 104626 105594 101967 101951 104649 106050 106500 107266 107406 107596 This is an opportunity for lurkers in the fortran@ list to grab a patch, apply to the tree, ask questions, and then take the plunge to being someone who can help care for gfortran. -- Steve
Re: [PATCH] Fortran: add Fortran 2018 IEEE_{MIN,MAX} functions
On Thu, Jun 08, 2023 at 12:17:02PM +0200, Thomas Koenig wrote:
> Hi together,
>
> > > On 6/6/23 21:11, FX Coudert via Gcc-patches wrote:
> > > > Hi,
> > > >
> > > > > I cannot see if there is proper support for kind=17 in your patch;
> > > > > at least the libgfortran/ieee/ieee_arithmetic.F90 part does not
> > > > > seem to have any related code.
> > > >
> > > > Can real(kind=17) ever be an IEEE mode? If so, something seriously
> > > > wrong happened, because the IEEE modules have no kind=17 mention in
> > > > them anywhere.
> > > >
> > > > Actually, where is the kind=17 documented?
> > > >
> > > > FX
> > >
> > > I was hoping for Thomas to come forward with some comment, as
> > > he was quite involved in related work.
> > >
> > > There are several threads on IEEE128 for Power on the fortran ML
> > > e.g. around November/December 2021, January 2022.
> > >
> > > I wasn't meaning to block your work, just wondering if the Power
> > > platform needs more attention here.
> > >
> >
> > % cd gcc/gccx/libgfortran
> > % grep HAVE_GFC_REAL_17 ieee/*
> > % troutmask:sgk[219] ls ieee
> > % ieee_arithmetic.F90 ieee_features.F90
> > % ieee_exceptions.F90 ieee_helper.c
> >
> > There are zero hits for REAL(17) in the IEEE code. If REAL(17)
> > is intended to be an IEEE-754 type, then it seems gfortran's
> > support was never added for it. If anyone has access to a
> > power system, it's easy to test
> >
> > program foo
> > use ieee_arithmetic
> > print *, ieee_support_datatype(1.e_17)
> > end program foo
>
> The KIND=17 is a bit of a kludge. It is not visible for
> user programs, they use KIND=16, but this is then translated
> to library calls as if it was KIND=17 if the IEEE 128-bit floats
> are selected:
>
> $ cat ml.f90
> subroutine mm(a)
> real(kind=16), dimension(:,:) :: a
> print *,maxloc(a)
> end subroutine mm
> $ gfortran -S -mabi=ieeelongdouble ml.f90 && grep maxloc ml.s
> bl _gfortran_maxloc0_4_r17
> $ gfortran -S ml.f90 && grep maxloc ml.s
> bl _gfortran_maxloc0_4_r16
>
> On POWER, if IBM long double exists, it is GFC_REAL_16, with GFC_REAL_17
> being IEEE long double. Everywhere else, GFC_REAL_16 is IEEE long
> double.
>
> If POWER gets the flag -mabi=ieeelongdouble, it uses IEEE long doubles.
>
> If it gets the additionalflag -mcpu=power9 or -mcpu=power10, it uses
> the hardware instructions for the arithmetic instead of library calls.
>
(trimming for length)
Thanks for the explanation. As I likely will not use a POWER-based
system, I only loosely followed the discussion. I don't remember
if ibm double-double is REAL(16) or REAL(17). If ieee 128-bit is
REAL(16), then everything should (I believe) be okay.
> There is a virutal POWER machine at OSUL dedicated to the IEEE QP
> gfortran effort. It hasn't been used for some time, but it's still
> active. I just bootstrapped trunk there and ran all the IEEE from the
> testsuite manually, with
>
> $ for a in *.f90; do echo "Testing $a"; gfortran -o $a.exe -fno-range-check
> -mcpu=power9 -mabi=ieeelongdouble -static-libgfortran $a signaling_1_c.c
> signaling_2_c.c ; ./$a.exe ; done 2>&1 | grep -v command-line
> Testing fma_1.f90
These could be misleading. gfortran has pre-processor tokens
for REAL(10) and REAL(16). If __GFC_REAL_16__ isn't defined
the ieee testing is skipped.
% cd gcc/gccx/gcc/fortran/
% grep __GFC_REAL_ *
cpp.cc: cpp_define (cpp_in, "__GFC_REAL_10__=1");
cpp.cc: cpp_define (cpp_in, "__GFC_REAL_16__=1");
invoke.texi:@code{__GFC_REAL_10__}, and @code{__GFC_REAL_16__}.
% more cpp.cc
...
/* Pre-defined macros for non-required REAL kind types. */
for (gfc_real_info *rtype = gfc_real_kinds; rtype->kind != 0; rtype++)
{
if (rtype->kind == 10)
cpp_define (cpp_in, "__GFC_REAL_10__=1");
if (rtype->kind == 16)
cpp_define (cpp_in, "__GFC_REAL_16__=1");
}
...
Should we have a __GFC_REAL_17__?
% cd ../testsuite/gfortran.dg/
% grep __GFC_REAL ieee/*
ieee/dec_math_1.f90: ! Note however that if both __GFC_REAL_10__ and
__GFC_REAL_16__ are defined,
ieee/dec_math_1.f90:#if defined(__GFC_REAL_10__)
ieee/dec_math_1.f90:#elif defined(__GFC_REAL_16__)
ieee/dec_math_1.f90:#ifdef __GFC_REAL_10__
ieee/dec_math_1.f90:#elif defined(__GFC_REAL_16__)
ieee/dec_math_1.f90:#ifdef __GFC_REAL_16__
ieee/dec_math_1.f90:#elif defined(__GFC_REAL_10__)
ieee/ieee_11.F90:#ifdef __GFC_REAL_10__
ieee/ieee_11.F90:#ifdef __GFC_REAL_16__
--
Steve
Re: [PATCH] Fortran: add Fortran 2018 IEEE_{MIN,MAX} functions
On Wed, Jun 07, 2023 at 08:31:35PM +0200, Harald Anlauf via Fortran wrote: > Hi FX, > > On 6/6/23 21:11, FX Coudert via Gcc-patches wrote: > > Hi, > > > > > I cannot see if there is proper support for kind=17 in your patch; > > > at least the libgfortran/ieee/ieee_arithmetic.F90 part does not > > > seem to have any related code. > > > > Can real(kind=17) ever be an IEEE mode? If so, something seriously wrong > > happened, because the IEEE modules have no kind=17 mention in them anywhere. > > > > Actually, where is the kind=17 documented? > > > > FX > > I was hoping for Thomas to come forward with some comment, as > he was quite involved in related work. > > There are several threads on IEEE128 for Power on the fortran ML > e.g. around November/December 2021, January 2022. > > I wasn't meaning to block your work, just wondering if the Power > platform needs more attention here. > % cd gcc/gccx/libgfortran % grep HAVE_GFC_REAL_17 ieee/* % troutmask:sgk[219] ls ieee % ieee_arithmetic.F90 ieee_features.F90 % ieee_exceptions.F90 ieee_helper.c There are zero hits for REAL(17) in the IEEE code. If REAL(17) is intended to be an IEEE-754 type, then it seems gfortran's support was never added for it. If anyone has access to a power system, it's easy to test program foo use ieee_arithmetic print *, ieee_support_datatype(1.e_17) end program foo -- Steve
Re: [PATCH] Fortran: add Fortran 2018 IEEE_{MIN,MAX} functions
On Tue, Jun 06, 2023 at 09:35:26PM +0200, FX Coudert wrote: > Hi Steve, > > I am not subscribed to the list (too little time, sadly), please keep me in > CC of your responses. > Unfortunately, fx is using a gmail account. Emails from my system to @gmail.com users are routinely and silently rejected. > > 1. You added fmin, fmax, and friends. Are these used > >internally by gfortran in support of the IEEE_* > >functions or are these exposed to the user? > > The math builtins are added to the front-end, and use for > code generation. In conv_intrinsic_ieee_minmax(), you can > see we find the right function using things like: > builtin_decl_explicit (BUILT_IN_ISSIGNALING) This answers my question 1. I think the patch can be committed after you've given time for Harald to answer your question about REAL(17). I think isn't important as all of the other ieee testcase would be broken on powerpc. -- Steve
Re: [PATCH] Fortran: add Fortran 2018 IEEE_{MIN,MAX} functions
On Tue, Jun 06, 2023 at 08:51:54AM -0700, Steve Kargl via Fortran wrote: > > Scratch 2. Another scan shows that you moduled the Fortran s/you moduled/you added to > module where interface are built. This will automatically s/interface/interfaces > catch and report the items in 2. Complete lack of coffee. -- Steve
Re: [PATCH] Fortran: add Fortran 2018 IEEE_{MIN,MAX} functions
On Tue, Jun 06, 2023 at 08:43:36AM -0700, Steve Kargl via Fortran wrote: > On Tue, Jun 06, 2023 at 03:19:18PM +0200, FX via Fortran wrote: > > Hi, > > > > This patch adds four IEEE functions from the Fortran 2018 > > standard: IEEE_MIN_NUM, IEEE_MAX_NUM, IEEE_MIN_NUM_MAG, > > and IEEE_MAX_NUM_MAG. > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, both 32 > > and 64-bit. OK to commit? > > > > FX, > > If no one else looks over the patch before the weekend, > I'll give it a deeper look. Two questions after a > quick scan: > > 1. You added fmin, fmax, and friends. Are these used >internally by gfortran in support of the IEEE_* >functions or are these exposed to the user? > > 2. I did not see error handling or conversion, but on a >quick scan I may have missed it. What happens with >IEEE_MAX_NUM(2.0_4, 3.0_8) or IEEE_MAX_NUM(2.0_4, INT(3))? >17.11.17 has > >X shall be of type real. >Y shall be of the same type and kind type parameter as X. > Scratch 2. Another scan shows that you moduled the Fortran module where interface are built. This will automatically catch and report the items in 2. -- Steve
Re: [PATCH] Fortran: add Fortran 2018 IEEE_{MIN,MAX} functions
On Tue, Jun 06, 2023 at 03:19:18PM +0200, FX via Fortran wrote: > Hi, > > This patch adds four IEEE functions from the Fortran 2018 > standard: IEEE_MIN_NUM, IEEE_MAX_NUM, IEEE_MIN_NUM_MAG, > and IEEE_MAX_NUM_MAG. > > Bootstrapped and regtested on x86_64-pc-linux-gnu, both 32 > and 64-bit. OK to commit? > FX, If no one else looks over the patch before the weekend, I'll give it a deeper look. Two questions after a quick scan: 1. You added fmin, fmax, and friends. Are these used internally by gfortran in support of the IEEE_* functions or are these exposed to the user? 2. I did not see error handling or conversion, but on a quick scan I may have missed it. What happens with IEEE_MAX_NUM(2.0_4, 3.0_8) or IEEE_MAX_NUM(2.0_4, INT(3))? 17.11.17 has X shall be of type real. Y shall be of the same type and kind type parameter as X. -- Steve
Re: [Patch, fortran] PR37336 finalization
On Sat, Jun 03, 2023 at 07:50:19AM +0200, Thomas Koenig via Fortran wrote: > Hi Paul, > > > I propose to backport > > r13-6747-gd7caf313525a46f200d7f5db1ba893f853774aee to 12-branch very > > soon. > > Is this something that we usually do? > > While finalization was basically broken before, some people still used > working subsets (or subsets that were broken, and they adapted or > wrote their code accordingly). > > What is the general opinion on that? I'm undecided. > I think a backport that fixes a bug that is a violation of Fortran standard is always okay. A backport of anything else is up to the discretion of the contributor. If pault or you or harald or ... want to backport a patch, after all these years, I think we should trust their judgement. -- Steve
Re: [PATCH] Fortran: CLASS pointer function result in variable definition context [PR109846]
On Sun, May 14, 2023 at 10:04:25PM +0200, Harald Anlauf via Fortran wrote: > > Fortran allows functions in variable definition contexts when the > result variable is a pointer. We already handle this for the > non-CLASS case (in 11+), but the logic that checks the pointer > attribute was looking in the wrong place for the CLASS case. > > Once found, the fix is simple and obvious, see attached patch. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > Yes. As you say, it is obvious once found. Ok to backport after a few days. -- Steve
Re: [Patch, fortran] PR97122 - Spurious FINAL ... must be in the specification part of a MODULE
On Tue, May 09, 2023 at 08:35:00PM +0200, Harald Anlauf wrote: > On 5/9/23 20:29, Steve Kargl via Gcc-patches wrote: > > > > It's not needed. See above. gfc_state_stack->previous is referenced > > a few lines above the if-stmt. The reference will segfault if the > > pointer is NULL. > > > > You're absolutely right. So it is OK as is. Thanks for keeping us honest and the review. -- Steve
Re: [Patch, fortran] PR97122 - Spurious FINAL ... must be in the specification part of a MODULE
On Tue, May 09, 2023 at 08:24:16PM +0200, Harald Anlauf wrote:
> Hi Paul,
>
> On 5/9/23 17:51, Paul Richard Thomas via Gcc-patches wrote:
> > Hi All,
> >
> > Thanks to Steve Kargl for the fix. It caused finalize_8.f03 to fail because
> > this testcase checked that finalizable derived types could not be specified
> > in a submodule. I have replaced the original test with a test of the patch.
> >
> > Thanks also to Malcolm Cohen for guidance on this.
> >
> > OK for trunk?
>
> the patch looks good to me. However:
>
> @@ -11637,8 +11637,9 @@ gfc_match_final_decl (void)
>block = gfc_state_stack->previous->sym;
^
See below.
>gcc_assert (block);
>
> - if (!gfc_state_stack->previous || !gfc_state_stack->previous->previous
> - || gfc_state_stack->previous->previous->state != COMP_MODULE)
> + if (gfc_state_stack->previous->previous
> + && gfc_state_stack->previous->previous->state != COMP_MODULE
> + && gfc_state_stack->previous->previous->state != COMP_SUBMODULE)
> {
>gfc_error ("Derived type declaration with FINAL at %C must be in
> the"
> " specification part of a MODULE");
>
> I am wondering if we should keep the protection against a potential
> NULL pointer dereference (i.e. gfc_state_stack->previous == NULL) for
> possibly invalid code. I have failed to produce a simple testcase,
> but others may have "better" ideas.
It's not needed. See above. gfc_state_stack->previous is referenced
a few lines above the if-stmt. The reference will segfault if the
pointer is NULL.
--
Steve
Re: [patch, fortran] PR109662 Namelist input with comma after name accepted
> Compiler version = GCC version 14.0.0 20230506 (experimental)
> 1-line: > < 666 0
> 2-line/left: > < 666 0
> 2-line/right: > < 666 0
> 1-line: >!< -1 -1
> 2-line/left: >!< -1 0
> 2-line/right: >!< 666 0
> 1-line: >/< -1 0
> 2-line/left: >/< -1 0
> 2-line/right: >/< -1 0
> 1-line: >,< 6665010
> 2-line/left: >,< 6665010
> 2-line/right: >,< 6665010
> 1-line: >;< 666 0
> 2-line/left: >;< 666 0
> 2-line/right: >;< 666 0
> 1-line: tab 666 0
> 2-line/left: tab 666 0
> 2-line/right: tab 666 0
> 1-line: lf 666 0
> 2-line/left: lf 666 0
> 2-line/right: lf 666 0
> 1-line: ret 666 0
> 2-line/left: ret 666 0
> 2-line/right: ret 666 0
>
>
> So there seems to be a consensus that "," and ";" must be rejected,
> and tab is accepted (makes real sense), but already the termination
> character "/" and comment character "!" are treated differently.
> And how do we want to treat lf and ret in internal files with
> -std=f20xx?
>
> Cheers,
> Harald
>
>
> On 5/7/23 19:33, Jerry D via Gcc-patches wrote:
> > On 5/6/23 11:15 AM, Harald Anlauf via Fortran wrote:
> > > Hi Jerry, Steve,
> > >
> > > I think I have to pour a little water into the wine.
> > >
> > > The patch fixes the reported issue only for a comma after
> > > the namelist name, but we still accept a few other illegal
> > > characters, e.g. ';', because:
> > >
> > > #define is_separator(c) (c == '/' || c == ',' || c == '\n' || c == ' ' \
> > > || c == '\t' || c == '\r' || c == ';' || \
> > > (dtp->u.p.namelist_mode && c == '!'))
> > >
> > > We don't want that in standard conformance mode, or do we?
> > >
> > > Cheers,
> > > Harald
> > >
> > > On 5/6/23 06:02, Steve Kargl via Gcc-patches wrote:
> > > > On Fri, May 05, 2023 at 08:41:48PM -0700, Jerry D via Fortran wrote:
> > > > > The attached patch adds a check for the invalid comma and emits a
> > > > > runtime
> > > > > error if -std=f95,f2003,f2018 are specified at compile time.
> > > > >
> > > > > Attached patch includes a new test case.
> > > > >
> > > > > Regression tested on x86_64-linux-gnu.
> > > > >
> > > > > OK for mainline?
> > > > >
> > > >
> > > > Yes. Thanks for the fix. It's been a long time since
> > > > I looked at libgfortran code and couldn't quite determine
> > > > where to start to fix this.
> > > >
> > >
> >
> > As I think back, I don't recall ever seeing a semi-colon used after a
> > NAMELIST name, so I think we should reject it always. The other "soft"
> > blanks we should allow.
> >
> > I will make a another patch on trunk to reject the semi-colon and if no
> > one objects here I will test and push it.
> >
> > Regards,
> >
> > Jerry
> >
> >
> program testnmlread
> use iso_fortran_env, only: compiler_version
> implicit none
> print *,'Compiler version = ',trim(compiler_version())
> call test (" ")
> call test ("!")
> call test ("/")
> call test (",")
> call test (";")
> call test (achar(9), "tab")
> call test (achar(10), "lf")
> call test (achar(13), "ret")
> contains
> subroutine test (c, desc)
> character,intent(in) :: c
> character(*), intent(in), optional :: desc
> character(8) :: d
> character(16) :: line, lines(2)
> integer :: ios
> integer :: n
> namelist/stuff/n
> character(*), parameter :: s1 = "", s2 = " n = 666/"
>
> d = ">" // c // "<"; if (present (desc)) d = desc
> ! Prepare input:
> line = s1 // c // s2
> lines(1) = s1 // c ! Left-adjusted
> lines(2) = s2
> ! Single line input
> n = -1
> read(line,nml=stuff,iostat=ios)
> write(*,*) "1-line: ", trim (d), n, ios
> ! Multi-line input
> n = -1
> read(lines,nml=stuff, iostat=ios)
> write(*,*) "2-line/left: ", trim (d), n, ios
> lines(1) = adjustr (lines(1)) ! Right-adjust first line
> n = -1
> read(lines,nml=stuff, iostat=ios)
> write(*,*) "2-line/right: ", trim (d), n, ios
> end subroutine test
> end program testnmlread
--
Steve
Re: [patch, fortran] PR109662 Namelist input with comma after name accepted
On Fri, May 05, 2023 at 08:41:48PM -0700, Jerry D via Fortran wrote: > The attached patch adds a check for the invalid comma and emits a runtime > error if -std=f95,f2003,f2018 are specified at compile time. > > Attached patch includes a new test case. > > Regression tested on x86_64-linux-gnu. > > OK for mainline? > Yes. Thanks for the fix. It's been a long time since I looked at libgfortran code and couldn't quite determine where to start to fix this. -- Steve
Re: [PATCH] Fortran: function results never have the ALLOCATABLE attribute [PR109500]
On Sat, Apr 22, 2023 at 08:43:53PM +0200, Mikael Morin wrote: > > > OK, let's go with your patch as originally submitted then. > Mikael, thanks for looking at the original patch and suggested an alternative location to attempt to fix the bug. Halrald, thanks for following up on Mikael's suggestion. -- Steve
Re: [PATCH] Fortran: function results never have the ALLOCATABLE attribute [PR109500]
On Sat, Apr 22, 2023 at 05:17:30PM +0200, Mikael Morin wrote: > Le 22/04/2023 à 15:52, Steve Kargl a écrit : > > On Sat, Apr 22, 2023 at 11:25:41AM +0200, Mikael Morin wrote: > > > > > > Le 20/04/2023 à 22:01, Harald Anlauf via Fortran a écrit : > > > > Dear all, > > > > > > > > Fortran 2018 added a clarification that the *result* of a function > > > > whose result *variable* has the ALLOCATABLE attribute is a *value* > > > > that itself does not have the ALLOCATABLE attribute. > > > > > > > > For those interested: there was a thread on the J3 mailing list > > > > some time ago (for links see the PR). > > > > > > > > The patch which implements a related check was co-authored with > > > > Steve and regtested by him. Testcase verified against NAG. > > > > > > > > OK for mainline (gcc-14)? > > > > > > > Looks good in principle, but I think the real fix should be in the > > > gfc_expr_attr function, which copies all the attributes (including > > > allocatable) in the EXPR_FUNCTION case. How would the testsuite react if > > > that attribute was cleared there? Is your patch still needed if > > > gfc_expr_attr is fixed? > > > > You may be correct that something can be done elsewhere. > > I do note that a function result can be allocatable > > (within the funciton body). The issue only arises when > > argument association is done, which is done where Harald > > and I have the patch. Do we know that the function will > > be an actual argument associated with an allocatable > > dummy argument when gfc_expr_attr is invoked? > > > No, there is no context information in gfc_expr_attr, but the result should > not be dependent on context anyway. > > You are probably right that the impact of this bug is limited to the case of > argument association, not as broad as I thought. Yet we should not keep > gfc_expr_attr returning an allocatable attribute for function expressions in > any case. I suspect we're stuck in a catch-22 situation. The symbol is marked as allocatable, function foo() integer, allocatable :: foo foo = 42 !<--- So that this isn't rejected end but when the function is actually referenced in an expression the result is normally used, and symbol is still marked as allocatable. -- Steve
Re: [PATCH] Fortran: function results never have the ALLOCATABLE attribute [PR109500]
On Sat, Apr 22, 2023 at 11:25:41AM +0200, Mikael Morin wrote: > > Le 20/04/2023 à 22:01, Harald Anlauf via Fortran a écrit : > > Dear all, > > > > Fortran 2018 added a clarification that the *result* of a function > > whose result *variable* has the ALLOCATABLE attribute is a *value* > > that itself does not have the ALLOCATABLE attribute. > > > > For those interested: there was a thread on the J3 mailing list > > some time ago (for links see the PR). > > > > The patch which implements a related check was co-authored with > > Steve and regtested by him. Testcase verified against NAG. > > > > OK for mainline (gcc-14)? > > > Looks good in principle, but I think the real fix should be in the > gfc_expr_attr function, which copies all the attributes (including > allocatable) in the EXPR_FUNCTION case. How would the testsuite react if > that attribute was cleared there? Is your patch still needed if > gfc_expr_attr is fixed? You may be correct that something can be done elsewhere. I do note that a function result can be allocatable (within the funciton body). The issue only arises when argument association is done, which is done where Harald and I have the patch. Do we know that the function will be an actual argument associated with an allocatable dummy argument when gfc_expr_attr is invoked? -- Steve
Re: ping Re: [PATCH 3/3] Fortran: Fix mpz and mpfr memory leaks
On Mon, Apr 17, 2023 at 09:47:50PM +0200, Bernhard Reutner-Fischer via Fortran
wrote:
> Ping!
>
> Harald fixed the leak in set_exponent in the meantime.
> As stated in the cover-letter, it was bootstrapped and regtested
> without regression on x86_64-foo-linux.
>
> I consider it obvious, but never the less, OK for trunk (as in gcc-14)
> so far?
See below.
>
> On Mon, 03 Apr 2023 23:42:06 +0200
> Bernhard Reutner-Fischer wrote:
>
> > On 3 April 2023 21:50:49 CEST, Harald Anlauf wrote:
> > >Hi Bernhard,
> > >
> > >there is neither context nor a related PR with a testcase showing
> > >that this patch fixes issues seen there.
> >
> > Yes, i forgot to mention the PR:
> >
> > PR fortran/68800
> >
> > I did not construct individual test cases but it should be obvious that we
> > should not leak these.
> >
> > >
> > >On 4/2/23 17:05, Bernhard Reutner-Fischer via Gcc-patches wrote:
> > >> From: Bernhard Reutner-Fischer
> > >>
> > >> Cc: fort...@gcc.gnu.org
> > >>
> > >> gcc/fortran/ChangeLog:
> > >>
> > >> * array.cc (gfc_ref_dimen_size): Free mpz memory before ICEing.
> > >> * expr.cc (find_array_section): Fix mpz memory leak.
> > >> * simplify.cc (gfc_simplify_reshape): Fix mpz memory leaks in
> > >> error paths.
> > >> (gfc_simplify_set_exponent): Fix mpfr memory leak.
> > >> ---
> > >> gcc/fortran/array.cc| 3 +++
> > >> gcc/fortran/expr.cc | 8
> > >> gcc/fortran/simplify.cc | 7 ++-
> > >> 3 files changed, 13 insertions(+), 5 deletions(-)
> > >>
> > >> diff --git a/gcc/fortran/array.cc b/gcc/fortran/array.cc
> > >> index be5eb8b6a0f..8b1e816a859 100644
> > >> --- a/gcc/fortran/array.cc
> > >> +++ b/gcc/fortran/array.cc
> > >> @@ -2541,6 +2541,9 @@ gfc_ref_dimen_size (gfc_array_ref *ar, int dimen,
> > >> mpz_t *result, mpz_t *end)
> > >> return t;
> > >>
> > >> default:
> > >> + mpz_clear (lower);
> > >> + mpz_clear (stride);
> > >> + mpz_clear (upper);
> > >> gfc_internal_error ("gfc_ref_dimen_size(): Bad dimen_type");
> > >> }
> > >
> > > What is the point of clearing variables before issuing
> > > a gfc_internal_error?
> >
> > To make it obvious that we are aware that we allocated these.
I must admit I agree with Harald on this portion
of the diff. What's the point? There is alot more
allocated than just those 3 mzp_t variables when the
internal error occurs. For example, gfortran does not
walk the namespaces and free those before the ICE.
I suppose silencing valgrind might be sufficient
reason for the clutter. So, ok.
> > >> _exp->where, shape[rank], rank+1);
> > >> + mpz_clear (index);
> > >>return _bad_expr;
> > >> }
These types of changes are 'ok'. IIRC, gfortran
will queue an error, and then forge on trying to
match the code with other matchers. If successful,
the error is tossed, so this would be a memory leak.
--
Steve
Re: [PATCH] Fortran: fix compile-time simplification of SET_EXPONENT [PR109511]
On Fri, Apr 14, 2023 at 09:49:22PM +0200, Harald Anlauf wrote: > > On 4/14/23 21:33, Steve Kargl via Gcc-patches wrote: > > I was wondering about the difference between set_exponent() > > and scale(), and found that set_exponent() talks about IEEE > > values while scale() doesn't. I'm wondering if we should > > add the IEEE special cases to the testsuite. Of particular > > note, I doubt that this is true: > > > > If X is an IEEE NaN, the result is the same NaN. > > > > program foo > > real x, y > > x = 1 > > y = x - x > > x = (x - x) / y > > print '(F4.0,1X,Z8.8)', x, x > > y = set_exponent(x,1) > > print '(F4.0,1X,Z8.8)', y, y > > end program foo > > > > gfcx -o z a.f90 && ./z > > NaN FFC0 > > NaN 7FC0 > > > > Those are not the same NaN. The second is a qNaN. > > The first looks like a qNaN with the sign bit set. > > Until now there was no testing at all of SET_EXPONENT in the testsuite. > It would be really good to have better coverage of compile-time and > runtime behavior of the intrinsics and checking consistency ... ;-) > > I think you have much more experience in that area. (Hint!) > I might have some experience. :-) Unfortunately, I have no time (for at least 4-5 years) to jump down that rabbit hole (as I would try to fix things ;-). However, writing testcases to exercise the intrinsic subprograms is something that the LURKERS here in the mailing list might comtemplate. Any takers? Note returning the 'same Nan" is not special to set_exponent(). At least, fraction() and rrspacing() have "If X is an IEEE NaN, the result is that NaN." Oh, and thanks for your relentless assault on bugs. -- Steve
Re: [PATCH] Fortran: fix compile-time simplification of SET_EXPONENT [PR109511]
On Fri, Apr 14, 2023 at 12:33:18PM -0700, Steve Kargl via Fortran wrote: > >If X is an IEEE NaN, the result is the same NaN. > A better testcase as gfortran will quiet a NaN on assignment. program foo integer i equivalence(i,y) i = int(z'7FC0BEEF',4) ! Add payload to NaN. print '(F4.0,2(1X,Z8.8))', y, y, set_exponent(y,1) end program foo gfortran -o z a.f90 && ./z N 7FC0BEEF 7FC0 -- Steve
Re: [PATCH] Fortran: fix compile-time simplification of SET_EXPONENT [PR109511]
On Fri, Apr 14, 2023 at 08:59:24PM +0200, Harald Anlauf via Fortran wrote: > > the compile-time simplification of intrinsic SET_EXPONENT was > broken since the early days of gfortran for argument X < 1 > (including negative X) and for I < 0. I identified and fixed > several issues in the implementation. The testcase explores > argument space comparing compile-time and runtime results and > is checked against Intel. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > Yes, it is certainly better than the current situation. > This is not a regression, but can lead to wrong code. > Would it be OK to backport to open branches? Sure. Looks simply and fairly specific. I was wondering about the difference between set_exponent() and scale(), and found that set_exponent() talks about IEEE values while scale() doesn't. I'm wondering if we should add the IEEE special cases to the testsuite. Of particular note, I doubt that this is true: If X is an IEEE NaN, the result is the same NaN. program foo real x, y x = 1 y = x - x x = (x - x) / y print '(F4.0,1X,Z8.8)', x, x y = set_exponent(x,1) print '(F4.0,1X,Z8.8)', y, y end program foo gfcx -o z a.f90 && ./z NaN FFC0 NaN 7FC0 Those are not the same NaN. The second is a qNaN. The first looks like a qNaN with the sign bit set. -- Steve
Re: [PATCH] Fix fc-prototypes usage with C_INT64_T and non LP64 Targets.
On Thu, Mar 30, 2023 at 07:39:55PM +0200, Thomas Koenig via Fortran wrote:
> Hi Andrew,
>
> > "long long". This was just an oversight and a missing check.
> >
> > Committed as obvious after a bootstrap/test on x86_64-linux-gnu.
>
> Thanks!
>
> I think this one is obvious enough that it deserves a backport.
> I've cherry-picked this for gcc12, will do gcc11 tomorrow.
>
The patch is incomplete.
module foo
use, intrinsic :: iso_c_binding
implicit none
public :: bar
type, bind(c) :: bar
real(10) a
end type
end module
This yields
typedef struct bar {
long_double a /* WARNING: Converting 'REAL(10)' to interoperable type */;
} bar;
That should be 'long double'.
--
Steve
Re: [patch, Fortran] Enable -fwrapv for -std=legacy
On Fri, Mar 10, 2023 at 07:01:29PM +0100, Richard Biener via Fortran wrote: > > > > Am 10.03.2023 um 18:54 schrieb Thomas Koenig via Fortran > > : > > > > Hello world, here's the patch that was discussed. > > > > Regression-tested. OK for trunk? > > > > Since this appeared only in gcc13, I see no need for a backport. > > I will also document this in the changes file. > > The „problem“ is latent forever, I’m not sure it’s good to > amend the kitchen-sink std=legacy option with -fwrapv since > that has quite some negative effects on optimization. In that case, it would then seem logical to remove whatever patch was added to -O3 that causes the massive regression with rnflow.f90 and add it instead to -Ofast. -Ofast at least hints that is unsafe to use. -- Steve
Re: [Patch, fortran] PR37336 finalization
On Tue, Mar 07, 2023 at 03:58:32PM +0100, Thomas Koenig via Fortran wrote: > Paul, > > first of all, thank you very much indeed for the hard work you put into > this! This is a great step for gfortran. Ditto**2 > > I can hurry this along to get the patch > > into 13-branch or I can wait until 14-branch opens. > > Personally, I think that this fixes so many bugs, and makes > the compiler so much better, that I would prefer having it > in gcc-13. Finalization was only of very limited use before, > and the risk of meaningful regressions (short of a build > failure) is therefore very low. > I agree with Thomas. The main branch is in stage 4, which is regression and documentation fixing mode. I would think the number of bugs fixed by your patch can be argued as fixing regressions. I can set aside some time on Saturday to help with a review (if required). -- Steve
Re: [PATCH] Fortran: fix CLASS attribute handling [PR106856]
On Fri, Mar 03, 2023 at 10:24:07PM +0100, Mikael Morin wrote: > Hello, > > Le 03/03/2023 à 20:57, Steve Kargl via Fortran a écrit : > > On Thu, Mar 02, 2023 at 11:03:48PM +0100, Harald Anlauf via Fortran wrote: > > > - if (attr->class_ok) > > > -/* Class container has already been built. */ > > > + /* Class container has already been built with same name. */ > > > + if (attr->class_ok > > > + && ts->u.derived->components->attr.dimension >= attr->dimension > > > + && ts->u.derived->components->attr.codimension >= attr->codimension > > > + && ts->u.derived->components->attr.class_pointer >= attr->pointer > > > + && ts->u.derived->components->attr.allocatable >= > > > attr->allocatable) > > > > I suppose I'm a bit confused here. dimension, codimension, > > pointer and allocatable are 1-bit bitfields in the attr > > struct. These can have the values 0 and 1, so the above > > conditionals are always true. > > > as I understand it, they aren't if attr has attributes that aren't already > set in the class container's first component. > a >= b == !(a < b) and if a and b are boolean-valued, a < b == !a && b. > Admittedly, I haven't tested the logic like Harald has. > Mikael, thanks for smacking me with the clue stick. I had to do a quick test to see the trees. % cc -o z a.c && ./z a.i = 0, b.i = 0, a.i >= b.i = 1 a.i = 1, b.i = 0, a.i >= b.i = 1 a.i = 1, b.i = 1, a.i >= b.i = 1 a.i = 0, b.i = 1, a.i >= b.i = 0 I was overlooking the last case. So, the above is an all or nothing test. -- steve
Re: [PATCH] Fortran: fix CLASS attribute handling [PR106856]
On Thu, Mar 02, 2023 at 11:03:48PM +0100, Harald Anlauf via Fortran wrote: > - if (attr->class_ok) > -/* Class container has already been built. */ > + /* Class container has already been built with same name. */ > + if (attr->class_ok > + && ts->u.derived->components->attr.dimension >= attr->dimension > + && ts->u.derived->components->attr.codimension >= attr->codimension > + && ts->u.derived->components->attr.class_pointer >= attr->pointer > + && ts->u.derived->components->attr.allocatable >= attr->allocatable) I suppose I'm a bit confused here. dimension, codimension, pointer and allocatable are 1-bit bitfields in the attr struct. These can have the values 0 and 1, so the above conditionals are always true. The rest of the patch looks reasonable. If Tobias has no objections or comments, it's ok to commit once the above is explained. -- Steve
Re: [PATCH, gfortran] Escalate failure when Hollerith constant to real conversion fails [PR103628]
On Thu, Mar 02, 2023 at 01:07:32AM +0100, Bernhard Reutner-Fischer wrote: > On Wed, 1 Mar 2023 07:39:40 -0800 > Steve Kargl via Gcc-patches wrote: > > > In fact, Hollerith should be hidden behind a -fallow-hollerith > > option and added to -std=legacy. > > While i'd be all for that, in my mind this will block off literally all > consultants and quite some scientists unless we error out > with a specific hint to an option that re-enable this. > > So yea, but please forgivingly for the decades to come? > It has already been decades. It seems to me that only way to motivate people to fix their code is to nag. Hollerith is pre-F77 era code. gfortran already provide a warning. The warning should be made into an error, and yes, it can point to -fallow-hollerith. The option would downgrade the error to a warning. The only way to suppress the warning is to suppress all warnings with -w. See -fallow-invalid-boz. % cat > a.f90 program foo! free-form source code is post-f77. real :: b = 4H1234 ! No code, in particular, legacy has print *, b ! initialization expressions. end program foo % gfcx -o z a.f90 a.f90:2:14: 2 |real :: b = 4H1234 | 1 Warning: Extension: Conversion from HOLLERITH to REAL(4) at (1) a.f90:2:18: 2 |real :: b = 4H1234 | 1 Warning: Legacy Extension: Hollerith constant at (1) -- Steve
Re: [PATCH][stage1] Remove conditionals around free()
On Wed, Mar 01, 2023 at 10:28:56PM +0100, Bernhard Reutner-Fischer via Fortran wrote: > libgfortran/caf/single.c |6 ++ > libgfortran/io/async.c |6 ++ > libgfortran/io/format.c |3 +-- > libgfortran/io/transfer.c|6 ++ > libgfortran/io/unix.c|3 +-- The Fortran ones are OK. -- Steve
Re: [PATCH, gfortran] Escalate failure when Hollerith constant to real conversion fails [PR103628]
On Wed, Mar 01, 2023 at 10:40:15AM +0100, Tobias Burnus wrote:
> > --- /dev/null
> > +++ b/gcc/testsuite/gfortran.dg/pr103628.f90
> > @@ -0,0 +1,14 @@
> > +! { dg-do compile { target powerpc*-*-* } }
> > +! { dg-options "-O2 -mabi=ibmlongdouble" }
> > +
> > +! Test to ensure that it reports an "Unclassifiable statement" error
> > +! instead of throwing an ICE when the memory represent of the HOLLERITH
> > +! string is not unique with ibm long double encoding.
> > ...
> > + real(kind = k):: b = 4h1234
This should be rejected with an error message. Hollerith was
deleted from Fortran in Appendix C-1 of the Fortran 77 standard.
The appearance of a Hollerith entity in an initialization
expression has never be conforming.
In fact, Hollerith should be hidden behind a -fallow-hollerith
option and added to -std=legacy.
> diff --git a/gcc/fortran/intrinsic.cc b/gcc/fortran/intrinsic.cc
> index 64821c84543..b60d92a0665 100644
> --- a/gcc/fortran/intrinsic.cc
> +++ b/gcc/fortran/intrinsic.cc
> @@ -27,2 +27,3 @@ along with GCC; see the file COPYING3. If not see
> #include "intrinsic.h"
> +#include "diagnostic.h" /* For errorcount. */
>
> @@ -4622,2 +4623,3 @@ do_simplify (gfc_intrinsic_sym *specific, gfc_expr *e)
>gfc_actual_arglist *arg;
> + int old_errorcount = errorcount;
>
> @@ -4710,3 +4712,7 @@ finish:
>if (result == _bad_expr)
> -return false;
> +{
> + if (errorcount == old_errorcount)
> + gfc_error ("Cannot simplify expression at %L", >where);
> + return false;
> +}
I'm okay with this suggestion.
--
Steve
Re: [PATCH] Fortran: fix corner case of IBITS intrinsic [PR108937]
On Mon, Feb 27, 2023 at 09:54:38PM +0100, Harald Anlauf via Fortran wrote: > > as found by the reporter, the result of the intrinsic IBITS > differed from other compilers (e.g. Intel, NAG) for the corner > case that the LEN argument was equal to BIT_SIZE(I), which is > explicitly allowed by the standard. > > We actually had an inconsistency for this case between > code generated by the frontend and compile-time simplified > expressions. > > The reporter noticed that this is related to a restriction in > gcc that requires that shift widths shall be smaller than the > bit sizes, and we already special case this for ISHFT. > It makes sense to use the same special casing for IBITS. > > Attached patch fixes this and regtests on x86_64-pc-linux-gnu. > > OK for mainline? Yes. Good catch on comparison with simplification, which I failed to consider last night. > This issue has been there for ages. Shall this be backported > or left in release branches as is? As always, backporting is up to you and your bandwidth. Bring the the run-time result and simplification into agreement suggests that a back port is a good thing. -- Steve
Re: Willing to contribute to the project Idea "Fortran – DO CONCURRENT"
On Thu, Feb 23, 2023 at 07:24:26AM -0800, Damian Rouson wrote: > I wonder if a relatively easy starting point would be enabling the > declaration of do concurrent construct variables: > > do concurrent (integer :: i = 1:n) > > It’s a minor convenience and less exciting than adding locality specifiers > but possibly a good first exercise. > > > Damian I've already implemented 95% of the above. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96255 Unfortunately, the last 5% will take me too much time, which I don't have at the moment. Problems arise from the parsing of an iterator is shared by do current, forall, implied-do, and good old do-loops. For the first 3, 'i' is a control variable and is a statement entity (i.e., in the namespace of construct). To do a type spec in one of these cleanly, it would be prudent to either define a namespace for the construct or to use a shadow variable. The shadow variablei, which I was leaning towards, would replace the above with something like do concurrent (integer :: _i = 1:n) '_i' cannot conflict 'i', but this requires walking the execution block of the construct and replacing 'i' with '_i'. Perhaps, starting with the patch in PR96255 would be gentle intro to gfortran hacking. -- Steve
Re: [PATCH] Fortran: reject invalid CHARACTER length of derived type components [PR96024]
On Tue, Feb 21, 2023 at 10:18:58PM +0100, Harald Anlauf via Fortran wrote: > Dear all, > > the attached simple patch detects and rejects CHARACTER components > of derived types whose length specification is non-integer. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > > This PR is also marked as a 10/11/12/13 regression, so I would > like to backport this as far as it seems reasonable. > OK. Backports are fine with me, but give others a chance to comment. Thanks for continuing to pursue the backlog of bug reports. -- Steve
Re: [Patch] Fortran: Avoid SAVE_EXPR for deferred-len char types
On Mon, Feb 20, 2023 at 07:56:14AM +0100, Tobias Burnus wrote: > On 17.02.23 17:27, Steve Kargl wrote: > > On Fri, Feb 17, 2023 at 12:13:52PM +0100, Tobias Burnus wrote: > > > OK for mainline? > > Short version: no. > > Would you mind to write a reasoning beyond only a single word? > > > > subroutine foo(n) > > >integer :: n > > >integer :: array(n*5) > > >integer :: my_len > > >... > > >my_len = 5 > > >block > > > character(len=my_len, kind=4) :: str > > > > > > my_len = 99 > > > print *, len(str) ! still shows 5 - not 99 > > >end block > > > end > > Are you sure about the above comment? > > Yes - for three reasons: > * On the what-feels-right side: It does not make any sense to print > any other value than 5 given that 'str' has been declared with len = 5. > * On the GCC side, the SAVE_EXPR ensures that the length is evaluated > early and then "saved" to ensure its original value is available > * The quoted text from the standard implies that this is what > should happen. Your comment in the above code suggest to me that you expected 99. Of course, the print statement should produce 5 and that is what gfortran does. If your patch only effects deferred character types, why are you including a useless code example. -- steve
Re: [Patch] Fortran: Avoid SAVE_EXPR for deferred-len char types
On Fri, Feb 17, 2023 at 12:13:52PM +0100, Tobias Burnus wrote:
> Short version:
>
> This fixes potential and real bugs related to 'len=:' character variables
> as for the length/byte size an old/saved expression is used instead of
> the current value. - That's fine but not for allocatable/pointer with 'len=:'.
>
>
> Main part of the patch: Strip the SAVE_EXPR from the size expression:
>
> if (len && deferred && TREE_CODE (TYPE_SIZE (type)) == SAVE_EXPR)
> {
> gcc_assert (TREE_CODE (TYPE_SIZE_UNIT (type)) == SAVE_EXPR);
> TYPE_SIZE (type) = TREE_OPERAND (TYPE_SIZE (type), 0);
> TYPE_SIZE_UNIT (type) = TREE_OPERAND (TYPE_SIZE_UNIT (type), 0);
> }
>
>
> OK for mainline?
Short version: no.
>
> * * *
>
> Long version:
>
> BACKGROUND:
>
>
> (A) VLA / EXPLICIT-SIZE ARRAYS + LEN= STRINGS
>
>
> C knows something like VLA (variable length arrays), likewise Fortran
> knows explicit size array and character length where the length/size
> depends on an variable set before the current scoping unit. Examples:
>
> void f(int N)
> {
> int vla[N*5];
> }
>
> subroutine foo(n)
> integer :: n
> integer :: array(n*5)
> integer :: my_len
> ...
> my_len = 5
> block
> character(len=my_len, kind=4) :: str
>
> my_len = 99
> print *, len(str) ! still shows 5 - not 99
> end block
> end
Are you sure about the above comment? At the time
that str is declared, it is given a kind type parameter
of len=5 and kind=4. After changing my_len to 99
the kind type parameter of str does not change.
8.3 Automatic data objects
If a type parameter in a declaration-type-spec or in a char-length
in an entity-decl for a local variable of a subprogram or BLOCK
construct is defined by an expression that is not a constant
expression, the type parameter value is established on entry to a
procedure defined by the subprogram, or on execution of the BLOCK
statement, and is not affected by any redefinition or undefinition
of the variables in the expression during execution of the
procedure or BLOCK construct.
--
steve
Re: [PATCH, committed] Fortran: error recovery on invalid assumed size reference [PR104554]
On Wed, Feb 15, 2023 at 10:28:00PM +0100, Harald Anlauf via Fortran wrote: > Dear all, > > I've committed the attached obvious and trivial patch for a NULL > pointer dereference on behalf of Steve and after regtesting on > x86_64-pc-linux-gnu as r13-6066-ga418129273725fd02e881e6fb5e0877287a1356c > Thanks Harald! -- Steve
Re: [PATCH] fortran: Fix up hash table usage in gfc_trans_use_stmts [PR108451]
On Fri, Feb 03, 2023 at 08:03:36PM +0100, Jakub Jelinek via Fortran wrote: > Hi! > > The first testcase in the PR (which I haven't included in the patch because > it is unclear to me if it is supposed to be valid or not) ICEs since extra > hash table checking has been added recently. The problem is that > gfc_trans_use_stmts does > tree *slot = entry->decls->find_slot_with_hash (rent->use_name, > hash, > INSERT); > if (*slot == NULL) > and later on doesn't store anything into *slot and continues. Another spot > a few lines later correctly clears the slot if it decides not to use the > slot, so the following patch does the same. > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? > Yes. See my comment in the PR about the testcases being invalid Fortran. -- Steve
Re: [PATCH] Fortran: diagnose USE associated symbols in COMMON blocks [PR108453]
On Sat, Jan 28, 2023 at 06:07:50PM +0100, Harald Anlauf via Fortran wrote: > > a USE associated symbol shall not appear in a COMMON block > (F2018:C8121) and needs to be diagnosed. The patch is > fairly obvious. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > > As the PR is marked as a 10/11/12/13 regression, > I plan to backport as appropriate. > Yes. Backports are fine with a clean regression test. Thanks for the patch and your continued attack on bugzilla issues. -- Steve
Re: [PATCH] Fortran: fix ICE in check_host_association [PR108544]
On Wed, Jan 25, 2023 at 10:59:22PM +0100, Harald Anlauf via Fortran wrote: > Dear all, > > the attached patch fixes two issues: first it addresses a NULL pointer > dereference on invalid input, triggered by the provided testcase. > > Second, while analyzing the context of the affected code, I looked into > the testcase for PR96102, and by varying it slightly, i.e. replacing > functions by subroutines I found that we accept invalid code that is > rejected by several other brands tested. To fix this, I removed one > line of a condition that did not seem to make sense to me. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > Yes. I briefly looked at this by simply commenting out the assert, which gives too many odd error messages. Returning 'false' seems to be best. -- Steve
Re: [PATCH] Fortran: fix NULL pointer dereference in gfc_check_dependency [PR108502]
On Mon, Jan 23, 2023 at 10:23:54PM +0100, Harald Anlauf via Fortran wrote: > > the code in the PR demonstrates that dependency checking in the > frontend optimization was not recovering well from invalid code, > leading to a NULL pointer dereference. An easy and really obvious > fix. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > Yes. I agree patch looks obvious once the issue is found. Thanks for the patch. -- Steve
Re: [PATCH] Fortran: avoid ICE on invalid array subscript triplets [PR108501]
On Mon, Jan 23, 2023 at 09:34:59PM +0100, Harald Anlauf via Fortran wrote: > > we did not check array element triplets for validity strictly enough > (i.e. defensively in the case of invalid code), so we could encounter > non-integer constant expressions that were passed to mpz_get_si. > > The attached obvious patch tries to fix all such potential issues > in get_expr_storage_size. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > Yes. Thanks for the patch. -- Steve
Re: [PATCH] libgfortran: Replace mutex with rwlock
On Wed, Dec 21, 2022 at 07:27:11PM -0500, Lipeng Zhu via Fortran wrote: > This patch try to introduce the rwlock and split the read/write to > unit_root tree and unit_cache with rwlock instead of the mutex to > increase CPU efficiency. In the get_gfc_unit function, the percentage > to step into the insert_unit function is around 30%, in most instances, > we can get the unit in the phase of reading the unit_cache or unit_root > tree. So split the read/write phase by rwlock would be an approach to > make it more parallel. > > BTW, the IPC metrics can increase from 0.25 to 2.2 in the Intel > SRP server with 220 cores. The benchmark we used is > https://github.com/rwesson/NEAT > The patch fails bootstrap on x86_64-*-freebsd. gmake[6]: Entering directory '/home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/src/c++17' /bin/sh ../../libtool --tag CXX --tag disable-shared --mode=compile /home/kargl/gcc/obj/./gcc/xgcc -shared-libgcc -B/home/kargl/gcc/obj/./gcc -nostdinc++ -L/home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/src -L/home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/src/.libs -L/home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/libsupc++/.libs -B/home/kargl/work/x86_64-unknown-freebsd14.0/bin/ -B/home/kargl/work/x86_64-unknown-freebsd14.0/lib/ -isystem /home/kargl/work/x86_64-unknown-freebsd14.0/include -isystem /home/kargl/work/x86_64-unknown-freebsd14.0/sys-include -fno-checking -I/home/kargl/gcc/gcc/libstdc++-v3/../libgcc -I/home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/include/x86_64-unknown-freebsd14.0 -I/home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/include -I/home/kargl/gcc/gcc/libstdc++-v3/libsupc++ -std=gnu++17 -nostdinc++ -prefer-pic -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=floating_from_chars.lo -fimplicit-templates -g -O2 -c -o floating_from_chars.lo ../../../../../gcc/libstdc++-v3/src/c++17/floating_from_chars.cc libtool: compile: /home/kargl/gcc/obj/./gcc/xgcc -shared-libgcc -B/home/kargl/gcc/obj/./gcc -nostdinc++ -L/home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/src -L/home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/src/.libs -L/home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/libsupc++/.libs -B/home/kargl/work/x86_64-unknown-freebsd14.0/bin/ -B/home/kargl/work/x86_64-unknown-freebsd14.0/lib/ -isystem /home/kargl/work/x86_64-unknown-freebsd14.0/include -isystem /home/kargl/work/x86_64-unknown-freebsd14.0/sys-include -fno-checking -I/home/kargl/gcc/gcc/libstdc++-v3/../libgcc -I/home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/include/x86_64-unknown-freebsd14.0 -I/home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/include -I/home/kargl/gcc/gcc/libstdc++-v3/libsupc++ -std=gnu++17 -nostdinc++ -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=floating_from_chars.lo -fimplicit-templates -g -O2 -c ../../../../../gcc/libstdc++-v3/src/c++17/floating_from_chars.cc -fPIC -DPIC -D_GLIBCXX_SHARED -o floating_from_chars.o In file included from /home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/include/memory_resource:40, from ../../../../../gcc/libstdc++-v3/src/c++17/floating_from_chars.cc:37: /home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/include/shared_mutex: In function 'int std::__glibcxx_rwlock_rdlock(pthread_rwlock**)': /home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/include/shared_mutex:80:3: error: call of overloaded '__gthrw_pthread_rwlock_rdlock(pthread_rwlock**&)' is ambiguous 80 | _GLIBCXX_GTHRW(rwlock_rdlock) | ^ In file included from /home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/include/x86_64-unknown-freebsd14.0/bits/gthr.h:148, from /home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/include/bits/std_mutex.h:41, from /home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/include/shared_mutex:41: /home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/include/shared_mutex:80:3: note: candidate: 'int std::__gthrw_pthread_rwlock_rdlock(pthread_rwlock**)' 80 | _GLIBCXX_GTHRW(rwlock_rdlock) | ^~ /home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/include/x86_64-unknown-freebsd14.0/bits/gthr-default.h:140:1: note: candidate: 'int __gthrw_pthread_rwlock_rdlock(pthread_rwlock**)' 140 | __gthrw(pthread_rwlock_rdlock) | ^~~ /home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/include/shared_mutex: In function 'int std::__glibcxx_rwlock_tryrdlock(pthread_rwlock**)': /home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/include/shared_mutex:81:3: error: call of overloaded
Re: [PATCH] Fortran: check for invalid uses of statement functions arguments [PR69604]
On Thu, Dec 22, 2022 at 10:13:04PM +0100, Harald Anlauf via Fortran wrote: > > the attached patch adds a check for statement function bodies for > invalid uses of dummy arguments. This fixes an ICE-on invalid. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > Yes. Thanks for the patch. -- Steve
Re: [PATCH] Fortran: a C interoperable function cannot have the CLASS attribute [PR95375]
On Tue, Dec 20, 2022 at 09:40:23PM +0100, Harald Anlauf via Fortran wrote: > > we obviously forgot to extend the C interoperability check of the > type of function results to CLASS variables and thus did not reject > them. Wrong code could lead to an ICE, see testcase by Gerhard. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > Yes. Thanks for the patch. -- Steve
Re: [PATCH] Fortran: improve checking of assumed size array spec [PR102180]
On Mon, Dec 12, 2022 at 08:49:50PM +0100, Harald Anlauf via Fortran wrote:
>
> Committed as r13-4623-gcf5327b89ab610.
>
To be clear, I have no problems with this commit.
But, just a FYI, there is gfc_peek_ascii_char(),
which allows you to look at the next character
without having to keep track of the locus.
> +{
> + locus old_loc = gfc_current_locus;
> + if (gfc_match_char ('*') == MATCH_YES)
gfc_gobble_whitespace (); /* Can't remember if matching up to this
eats whitespace. */
if (gfc_peek_ascii_char () == '*')
> + {
> + /* F2018:R821: "assumed-implied-spec is [ lower-bound : ] *". */
> + gfc_error ("A lower bound must precede colon in "
> + "assumed-size array specification at %L", _loc);
> + return AS_UNKNOWN;
> + }
> + else
> + {
gfc_current_locus = old_loc; /* Is this needed? */
> + return AS_DEFERRED;
> + }
> +}
--
Steve
Re: [PATCH] Fortran: improve checking of assumed size array spec [PR102180]
On Sun, Dec 11, 2022 at 11:33:43PM +0100, Harald Anlauf via Fortran wrote:
> Dear all,
>
> the attached patch improves checking of array specs in two ways:
> - bad assumed size array spec
> - a bad first array element spec may already trigger an error,
> leading to a more consistent behavior
>
> Regtested on x86_64-pc-linux-gnu. OK for mainline?
>
OK with minor nit.
> + /* F2018:R821: "assumed-implied-spec is [ lower-bound : ] *". */
> + if (gfc_match (" : * ") == MATCH_YES)
> +{
> + gfc_error ("A lower bound must precede colon in "
> + "assumed size array specification at %C");
"assumed size" should likely be "assumed-size"
> + return AS_UNKNOWN;
> +}
> +
--
Steve
Re: [PATCH] Fortran: reject bad SIZE argument while simplifying ISHFTC [PR106911]
On Sat, Dec 10, 2022 at 10:14:06PM +0100, Harald Anlauf via Fortran wrote: > Dear all, > > we should not try to simplify ISHFTC if the SIZE argument > is known to be outside the allowed range. It's better to > generate an error by terminating the simplification. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > Yes. Thanks for the patch. -- Steve
Re: [PATCH] Fortran: diagnose and reject duplicate CONTIGUOUS attribute [PR108025]
On Thu, Dec 08, 2022 at 10:59:42PM +0100, Harald Anlauf via Fortran wrote: > Dear all, > > a fairly obvious, or rather trivial fix that appeared while > analyzing another pr and that can be treated independently: > reject duplicate CONTIGUOUS attributes. > > (Intel and NAG reject this, Cray warns that this is non-standard.) > > Regtested on x86_64-pc-linux-gnu. OK for mainline? Yes, thanks for the patch. -- Steve
Re: [PATCH] Fortran: handle zero-sized arrays in ctors with typespec [PR108010]
On Wed, Dec 07, 2022 at 09:57:20PM +0100, Harald Anlauf via Fortran wrote: > Dear all, > > we need to be careful about zero-sized arrays in arithmetic > reductions (unary & binary), as we otherwise may hit a NULL > pointer dereference on valid code. > > The actual fix is straightforward, see attached patch. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > Yes. Thanks for the patch. -- Steve
Re: [PATCH, committed] Fortran: ICE on procedure arguments with non-integer length [PR107707]
On Wed, Nov 16, 2022 at 10:58:18PM +0100, Harald Anlauf via Fortran wrote: > > @Steve: please close PR if you think everything is ok. > Thanks. I'll close the pr. -- Steve
Re: [PATCH] PR target/89125
On Mon, Apr 25, 2022 at 09:26:26AM +0200, Richard Biener wrote: > On Sat, Apr 23, 2022 at 8:40 PM Steve Kargl via Gcc-patches > wrote: > > > > ping. > > I have tested the patch on x86_64-linux and pushed it. > Thanks. -- Steve
Re: [PATCH] PR target/89125
ping.
On Fri, Apr 15, 2022 at 09:23:43AM -0700, Steve Kargl wrote:
> Can someone, anyone, please commit the attach patch, which is
> also attached to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89125
> where one can read the audit trail. The original patch was
> submitted 2 years ago, and required manual intervention due to
> the recent *.c to *.cc rename.
>
> Back story: When GCC is configured and built on non-glibc platforms,
> it seems very little to no effort is made to enumerate the available
> C99 libm functions. It is all or nothing for C99 libm. The patch
> introduces a new function, used on only FreeBSD, to inform gcc that
> it has C99 libm functions (minus a few which clearly GCC does not check
> nor test).
>
> The patch introduces no regression on x86_64-*-freebsd while
> allowing an additional 31 new passes.
>
> === gcc Summary ===
> w/o patch w patch
> # of expected passes175405 175434
> # of unexpected failures1081 1051
> # of unexpected successes 20 20
> # of expected failures 1459 1459
> # of unresolved testcases 10 10
> # of unsupported tests 3252 3252
>
> === g++ Summary ===
> w/o patch w patch
> # of expected passes225338 225341
> # of unexpected failures678676
> # of expected failures 2071 2071
> # of unresolved testcases 11 11
> # of unsupported tests 10353 10353
>
> === gfortran Summary ===
> w/o patch w patch
> # of expected passes65901 65901
> # of unexpected failures12 12
> # of expected failures 272272
> # of unsupported tests 100100
>
>
> 2022-04-15 Steven G. Kargl
>
> PR target/89125
> * config/freebsd.h: Define TARGET_LIBC_HAS_FUNCTION to be
> bsd_libc_has_function.
> * gcc/targhooks.cc(bsd_libc_has_function): New function.
> Expand the supported math functions to inclue C99 libm.
> * gcc/targhooks.h: Prototype for bsd_libc_has_function.
>
> --
> Steve
> diff --git a/gcc/config/freebsd.h b/gcc/config/freebsd.h
> index 28ebcad88d4..d89ee7dfc97 100644
> --- a/gcc/config/freebsd.h
> +++ b/gcc/config/freebsd.h
> @@ -55,7 +55,7 @@ along with GCC; see the file COPYING3. If not see
> #endif
>
> #undef TARGET_LIBC_HAS_FUNCTION
> -#define TARGET_LIBC_HAS_FUNCTION no_c99_libc_has_function
> +#define TARGET_LIBC_HAS_FUNCTION bsd_libc_has_function
>
> /* Use --as-needed -lgcc_s for eh support. */
> #ifdef HAVE_LD_AS_NEEDED
> diff --git a/gcc/targhooks.cc b/gcc/targhooks.cc
> index e22bc66a6c8..ff127763cf2 100644
> --- a/gcc/targhooks.cc
> +++ b/gcc/targhooks.cc
> @@ -1843,6 +1843,20 @@ no_c99_libc_has_function (enum function_class fn_class
> ATTRIBUTE_UNUSED,
>return false;
> }
>
> +/* Assume some c99 functions are present at the runtime including sincos.
> */
> +bool
> +bsd_libc_has_function (enum function_class fn_class,
> +tree type ATTRIBUTE_UNUSED)
> +{
> + if (fn_class == function_c94
> + || fn_class == function_c99_misc
> + || fn_class == function_sincos)
> +return true;
> +
> + return false;
> +}
> +
> +
> tree
> default_builtin_tm_load_store (tree ARG_UNUSED (type))
> {
> diff --git a/gcc/targhooks.h b/gcc/targhooks.h
> index ecfa11287ef..ecce55ebe79 100644
> --- a/gcc/targhooks.h
> +++ b/gcc/targhooks.h
> @@ -212,6 +212,7 @@ extern bool default_libc_has_function (enum
> function_class, tree);
> extern bool default_libc_has_fast_function (int fcode);
> extern bool no_c99_libc_has_function (enum function_class, tree);
> extern bool gnu_libc_has_function (enum function_class, tree);
> +extern bool bsd_libc_has_function (enum function_class, tree);
>
> extern tree default_builtin_tm_load_store (tree);
>
--
Steve
[PATCH] PR target/89125
Can someone, anyone, please commit the attach patch, which is
also attached to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89125
where one can read the audit trail. The original patch was
submitted 2 years ago, and required manual intervention due to
the recent *.c to *.cc rename.
Back story: When GCC is configured and built on non-glibc platforms,
it seems very little to no effort is made to enumerate the available
C99 libm functions. It is all or nothing for C99 libm. The patch
introduces a new function, used on only FreeBSD, to inform gcc that
it has C99 libm functions (minus a few which clearly GCC does not check
nor test).
The patch introduces no regression on x86_64-*-freebsd while
allowing an additional 31 new passes.
=== gcc Summary ===
w/o patch w patch
# of expected passes175405 175434
# of unexpected failures1081 1051
# of unexpected successes 20 20
# of expected failures 1459 1459
# of unresolved testcases 10 10
# of unsupported tests 3252 3252
=== g++ Summary ===
w/o patch w patch
# of expected passes225338 225341
# of unexpected failures678676
# of expected failures 2071 2071
# of unresolved testcases 11 11
# of unsupported tests 10353 10353
=== gfortran Summary ===
w/o patch w patch
# of expected passes65901 65901
# of unexpected failures12 12
# of expected failures 272272
# of unsupported tests 100100
2022-04-15 Steven G. Kargl
PR target/89125
* config/freebsd.h: Define TARGET_LIBC_HAS_FUNCTION to be
bsd_libc_has_function.
* gcc/targhooks.cc(bsd_libc_has_function): New function.
Expand the supported math functions to inclue C99 libm.
* gcc/targhooks.h: Prototype for bsd_libc_has_function.
--
Steve
diff --git a/gcc/config/freebsd.h b/gcc/config/freebsd.h
index 28ebcad88d4..d89ee7dfc97 100644
--- a/gcc/config/freebsd.h
+++ b/gcc/config/freebsd.h
@@ -55,7 +55,7 @@ along with GCC; see the file COPYING3. If not see
#endif
#undef TARGET_LIBC_HAS_FUNCTION
-#define TARGET_LIBC_HAS_FUNCTION no_c99_libc_has_function
+#define TARGET_LIBC_HAS_FUNCTION bsd_libc_has_function
/* Use --as-needed -lgcc_s for eh support. */
#ifdef HAVE_LD_AS_NEEDED
diff --git a/gcc/targhooks.cc b/gcc/targhooks.cc
index e22bc66a6c8..ff127763cf2 100644
--- a/gcc/targhooks.cc
+++ b/gcc/targhooks.cc
@@ -1843,6 +1843,20 @@ no_c99_libc_has_function (enum function_class fn_class ATTRIBUTE_UNUSED,
return false;
}
+/* Assume some c99 functions are present at the runtime including sincos. */
+bool
+bsd_libc_has_function (enum function_class fn_class,
+ tree type ATTRIBUTE_UNUSED)
+{
+ if (fn_class == function_c94
+ || fn_class == function_c99_misc
+ || fn_class == function_sincos)
+return true;
+
+ return false;
+}
+
+
tree
default_builtin_tm_load_store (tree ARG_UNUSED (type))
{
diff --git a/gcc/targhooks.h b/gcc/targhooks.h
index ecfa11287ef..ecce55ebe79 100644
--- a/gcc/targhooks.h
+++ b/gcc/targhooks.h
@@ -212,6 +212,7 @@ extern bool default_libc_has_function (enum function_class, tree);
extern bool default_libc_has_fast_function (int fcode);
extern bool no_c99_libc_has_function (enum function_class, tree);
extern bool gnu_libc_has_function (enum function_class, tree);
+extern bool bsd_libc_has_function (enum function_class, tree);
extern tree default_builtin_tm_load_store (tree);
Re: [PATCH] PR fortran/102917 - PDT type parameters are not restricted to default integer
On Sun, Oct 24, 2021 at 09:00:52PM +0200, Harald Anlauf wrote: > Dear Fortranners, Steve, > > I've created PR 102917 for tracking this issue and packaged > the attached patch. > > Regtested on x86_64-pc-linux-gnu. OK mainline? > Thanks for picking this up. The patch looks good to me, but you may want to have Thomas or Tobias cast a quick glance over it. -- Steve
Re: [Patch, Fortran, backport 2 gcc-11] PR98301 Re: RANDOM_INIT() and coarray Fortran
On Sat, Jun 05, 2021 at 04:04:51PM +0200, Andre Vehreschild wrote: > > I was asked to backport the patch for pr98301 to gcc-11. The patches have > been in mainline for two weeks without any defect reports I could fined. The > patch for mainline applied with a bit of shift cleanly. > > Regstested fine on x86_64/f33. Ok for backport gcc-11? > I think the backport is fine. -- Steve
Re: [Ping^2, Patch, Fortran] PR98301 Re: RANDOM_INIT() and coarray Fortran
On Fri, May 21, 2021 at 10:09:02AM +0200, Andre Vehreschild wrote: > Ping, ping! > > Please find attached a rebased version of the patch for the RANDOM_INIT issue > with coarray Fortran. Nothing changed to the previous version, just rebased to > current master. > > Regtested fine on x86_64-linux/f33. Ok for trunk? > I think you've down your due diligence with 2 pings. I would commit. -- steve
Re: [Ping, Patch, Fortran, Update 2] PR98301 Re: RANDOM_INIT() and coarray Fortran
On Mon, May 03, 2021 at 11:21:10AM +0200, Andre Vehreschild wrote: > Ping! > > Ok for trunk? > > I have looked at other patches, but none was patching any location I have > worked on previously. Therefore I can't return the favor of reviewing any > currently open patches and have to ask for volunteers here. > > - Andre > I doubt I'm allowed to approve a patch, where I wrote a portion of it. However, if no one else steps forward in the next day or two, then I think you should commit. -- Steve
Re: off-by-one buffer overflow patch
On Sat, Mar 27, 2021 at 03:11:05PM -0700, Jerry DeLisle wrote: > Pushed: > > To git+ssh://gcc.gnu.org/git/gcc.git > 651684b462f..01685676a93 master -> master > > Author: Steve Kargl > Date: Sat Mar 27 15:02:16 2021 -0700 > > fortran: Fix off-by-one in buffer sizes. > > gcc/fortran/ChangeLog: > > * misc.c (gfc_typename): Fix off-by-one in buffer sizes. > > Regards, > > Jerry Thanks for committing the patch. -- steve
off-by-one buffer overflow patch
This patch fixes an off-by-one buffer overflow issue.
Please commit.
diff --git a/gcc/fortran/misc.c b/gcc/fortran/misc.c
index 8a96243e80d..3d449ae17fe 100644
--- a/gcc/fortran/misc.c
+++ b/gcc/fortran/misc.c
@@ -124,8 +124,10 @@ gfc_basic_typename (bt type)
const char *
gfc_typename (gfc_typespec *ts, bool for_hash)
{
- static char buffer1[GFC_MAX_SYMBOL_LEN + 7]; /* 7 for "TYPE()" + '\0'. */
- static char buffer2[GFC_MAX_SYMBOL_LEN + 7];
+ /* Need to add sufficient padding for "TYPE()" + '\0', "UNION()" + '\0',
+ or "CLASS()" + '\0'. */
+ static char buffer1[GFC_MAX_SYMBOL_LEN + 8];
+ static char buffer2[GFC_MAX_SYMBOL_LEN + 8];
static int flag = 0;
char *buffer;
gfc_typespec *ts1;
--
Steve
