Re: [patch, fortran] Matmul and dot_product for unsigned
On Sun, Sep 8, 2024 at 10:32 PM Thomas Koenig wrote: > > Hello world, > > like the subject says. The patch is gzipped because it is large; > it contains multiple MATMUL library implementations. > > OK for trunk? > > Implement MATMUL and DOT_PRODUCT for unsgigned. Is the library implementation in any way different from the signed one? Iff only multiplication and addition/subtraction are involved the unsigned implementation could implement both variants (the signed one would eventually cause undefinedness with respect to overflow unless built with -fwrapv). That would save code size in libgfortran and eventually icache if mixing uses of both. Richard. > gcc/fortran/ChangeLog: > > * arith.cc (gfc_arith_uminus): Fix warning. > (gfc_arith_minus): Correctly truncate unsigneds. > * check.cc (gfc_check_dot_product): Handle unsigned arguments. > (gfc_check_matmul): Likewise. > * expr.cc (gfc_get_unsigned_expr): New function. > * gfortran.h (gfc_get_unsigned_expr): Add prototype. > * gfortran.texi: Document MATMUL and DOT_PRODUCT for unsigned. > * simplify.cc (compute_dot_product): Handle unsigneds. > > libgfortran/ChangeLog: > > * Makefile.am: Add unsigned MATMUL versions. > * Makefile.in: Regenerate. > * gfortran.map: Add unsigned MATMUL versions.o > * libgfortran.h: Add array types for unsigned. > * m4/iparm.m4: Add UNSIGNED if type is m. > * generated/matmul_m1.c: New file. > * generated/matmul_m16.c: New file. > * generated/matmul_m2.c: New file. > * generated/matmul_m4.c: New file. > * generated/matmul_m8.c: New file. > * generated/matmulavx128_m1.c: New file. > * generated/matmulavx128_m16.c: New file. > * generated/matmulavx128_m2.c: New file. > * generated/matmulavx128_m4.c: New file. > * generated/matmulavx128_m8.c: New file. > > gcc/testsuite/ChangeLog: > > * gfortran.dg/unsigned_25.f90: New test. > * gfortran.dg/unsigned_26.f90: New test.
Re: PRs 88052 and 88190
On Sat, Sep 7, 2024 at 22:26 Steve Kargl wrote: > On Sat, Sep 07, 2024 at 08:17:42PM -0700, Jerry D wrote: > > > I personally would like to see -std=f2023 made the default. I would absolutely love that too. I’ve lost countless hours chasing down issues (in other compilers) that didn’t make standard behavior the default. > Any, and all, extensions would require an explicit option to > accept the non-standard Fortran construct. This would be awesome. > Unfortuantely, the -std=gnu ship sailed years ago. What makes it a closed issue? D >
Re: PRs 88052 and 88190
On Sun, Sep 8, 2024 at 10:37 PM Harald Anlauf wrote:
> The default ("-std=gnu") is IMHO *not* a real standard; it merely
> describes the set of Fortranish-looking stuff (including standard
> stuff) that is handled by gfortran if no -std= is given and then
> gives *no* warning.
>
> A way forward I could imagine is triaging the differences between
> what is accepted by default (i.e. -std=gnu) and the real standard,
> and if we think that extension should for some reason be downgraded
> to -std=legacy, then we do that. (E.g. if it violates a constraint,
> then it is a primary candidate.) That would allow a smooth, although
> slow, transition to better compile-time diagnostics.
>
> That said, having no real (since undefined) gnu standard, would offer
> the option that the runtime should see either -std=legacy being passed,
> or a real -std=f20xy would enforce standard-conforming behavior.
> I currently see no sense in having a special -std=gnu in the runtime:
> either standard (with warning/error), or legacy (silent unless hard
> error). Or does anyone see a point differentiating gnu/legacy here?
Back in the day, IIRC the intention was that std=gnu would include
extensions that are per se not dangerous and do not conflict with
standard semantics. E.g. extra intrinsic procedures. The std=legacy
was for stuff which changes the standard semantics, or is otherwise
error-prone and dangerous. At some point we discussed whether std=gnu
should be split up similar to how the C and C++ frontends do it, with,
say, -std=gnu2003 would mean F2003 + GNU extensions but in the end
that wasn't done as there seemed to be no real demand for such a
thing. There is probably some virtue in being able to distinguish
between "benign" extensions and dangerous ones, though there might be
improvements to be made of how the bitflags are handled and passed to
the runtime.
I can sympathize with the desire to make the standard behavior the
default, but the reality is probably that you'll drown in bug reports
if something like INTEGER*8 becomes a compile-time error by default.
--
Janne Blomqvist
Re: PRs 88052 and 88190
On Mon, Sep 9, 2024 at 10:10 AM Janne Blomqvist
wrote:
>
> On Sun, Sep 8, 2024 at 10:37 PM Harald Anlauf wrote:
> > The default ("-std=gnu") is IMHO *not* a real standard; it merely
> > describes the set of Fortranish-looking stuff (including standard
> > stuff) that is handled by gfortran if no -std= is given and then
> > gives *no* warning.
> >
> > A way forward I could imagine is triaging the differences between
> > what is accepted by default (i.e. -std=gnu) and the real standard,
> > and if we think that extension should for some reason be downgraded
> > to -std=legacy, then we do that. (E.g. if it violates a constraint,
> > then it is a primary candidate.) That would allow a smooth, although
> > slow, transition to better compile-time diagnostics.
> >
> > That said, having no real (since undefined) gnu standard, would offer
> > the option that the runtime should see either -std=legacy being passed,
> > or a real -std=f20xy would enforce standard-conforming behavior.
> > I currently see no sense in having a special -std=gnu in the runtime:
> > either standard (with warning/error), or legacy (silent unless hard
> > error). Or does anyone see a point differentiating gnu/legacy here?
>
> Back in the day, IIRC the intention was that std=gnu would include
> extensions that are per se not dangerous and do not conflict with
> standard semantics. E.g. extra intrinsic procedures. The std=legacy
> was for stuff which changes the standard semantics, or is otherwise
> error-prone and dangerous. At some point we discussed whether std=gnu
> should be split up similar to how the C and C++ frontends do it, with,
> say, -std=gnu2003 would mean F2003 + GNU extensions but in the end
> that wasn't done as there seemed to be no real demand for such a
> thing. There is probably some virtue in being able to distinguish
> between "benign" extensions and dangerous ones, though there might be
> improvements to be made of how the bitflags are handled and passed to
> the runtime.
>
> I can sympathize with the desire to make the standard behavior the
> default, but the reality is probably that you'll drown in bug reports
> if something like INTEGER*8 becomes a compile-time error by default.
The C and C++ frontends use -pedantic and -pedantic-erros for this,
they accept a subset of extensions even with -std=c++20 and only
with -pedantic are strict and give warnings while -pedantic-errors
makes those diagnostics errors.
I would expect -std=legacy to cover extensions that people should avoid
when writing new code and -std=legacy generally be combined with
an old fortran standard (usually even F77 I guess)?
Richard.
> --
> Janne Blomqvist
Re: [patch, fortran] Matmul and dot_product for unsigned
Am 09.09.24 um 09:19 schrieb Richard Biener: Is the library implementation in any way different from the signed one? Iff only multiplication and addition/subtraction are involved the unsigned implementation could implement both variants (the signed one would eventually cause undefinedness with respect to overflow unless built with -fwrapv). That would save code size in libgfortran and eventually icache if mixing uses of both. The versions for signed and unsigned matmul are generated from the same source, so that should work. But it will require some ugly m4 hackery... I'll take a look if I can make it work. Best regards Thomas
Re: PRs 88052 and 88190
On Mon, Sep 09, 2024 at 12:26:53AM -0700, Damian Rouson wrote: > On Sat, Sep 7, 2024 at 22:26 Steve Kargl > wrote: > > > On Sat, Sep 07, 2024 at 08:17:42PM -0700, Jerry D wrote: > > > > > > I personally would like to see -std=f2023 made the default. > > I would absolutely love that too. I’ve lost countless hours chasing down > issues (in other compilers) that didn’t make standard behavior the default. > > > Any, and all, extensions would require an explicit option to > > accept the non-standard Fortran construct. > > This would be awesome. > > > Unfortuantely, the -std=gnu ship sailed years ago. > > What makes it a closed issue? > POLA As Janne mentioned, INTEGER*4 etc would lead to significant traffic in fortran@ and bugzilla about breaking people's code. Back in 2004, when I started contributing to gfortran development, the prevailing thought was "if g77 accepted it, then gfortran should also accept it" for backwards compatibility. Here, 'it' was a large number of vendor extensions. Some have been put behind options such as Cray pointers and DEC Fortran extensions. % grep GFC_STD_GNU gcc/fortran/*.cc | wc -l 340 There are 340 occurences of GFC_STD_GNU that we would need to review to determine what to do (e.g., a new option or put it under the blank -std=legacy). 338 of these occur in the front-end before the red-black trees are translated to tree-ssa and handled to the middle-end. Perhaps, an opportunity for lurkers on the list to get involve with a simple review of the code. Consider, data x/1/ data x/42/ ! <-- Should be an error print *, x end The above compiles without a warning (even if -Wall -Wextra -Wsurprising are used). % gfcx -c -std=f2018 a.f90 a.f90:2:12: 2 |data x/42/ |1 Error: GNU Extension: re-initialization of 'x' at (1) When Thomas introduced the ability to build interfaces, he had to include the -fallow-argument-mismatch option. When I reworked gfortran's BOZ code, I added -fallow-invalid-boz. There were a few annoyed users. They had a choice: use an option to compile their code or fix thier code. Many people chose the former, and now Makefiles all over the internet are enshired with these options. The ship has sailed. I think Harald's response sums up what needs to happen, and I agree with him. Use caution when moving an extension under -std=legacy. A request to add a new extension, which is not on a path to standardization, will likely get little attention. -- Steve
Re: [patch, fortran] Matmul and dot_product for unsigned
> Am 09.09.2024 um 19:09 schrieb Thomas Koenig : > > Am 09.09.24 um 09:19 schrieb Richard Biener: >> Is the library implementation in any way different from the signed >> one? Iff only >> multiplication and addition/subtraction are involved the unsigned >> implementation >> could implement both variants (the signed one would eventually cause >> undefinedness >> with respect to overflow unless built with -fwrapv). That would save code >> size >> in libgfortran and eventually icache if mixing uses of both. > > The versions for signed and unsigned matmul are generated from the > same source, so that should work. > > But it will require some ugly m4 hackery... I'll take a look if > I can make it work. I meant you shouldn’t need new library entry points for unsigned but simply call the signed ones (and switch the signed implementation to use unsigned arithmetic due to the overflow issue). Richard > Best regards > >Thomas
Re: [patch, fortran] Matmul and dot_product for unsigned
Am 09.09.24 um 20:01 schrieb Richard Biener: But it will require some ugly m4 hackery... I'll take a look if I can make it work. > I meant you shouldn’t need new library entry points for unsigned > but simply call the signed ones (and switch the signed implementation > to use unsigned arithmetic due to the overflow issue). That's clear. The evil m4 hackery comes from the way that the files are generated. The file name is passed to m4, which is then parsed with the macros in libgfortran/m4/iparm.m4 , where (among other things) 'i' in the name of the file to be generated is translated to GFC_INTEGER_... in the macros rtype, rtype_name and rtype_code (if that exists). So, I will need to either persudade iparm.m4 to check for the matmul name and redefine the get_typename macro accordingly, or (probably the easier option) to redefine rtype and friends if rtype_name happens to match ^GFC_INTEGER, in matmul.m4. Best regards Thomas
