Re: [PATCH] Fortran: deferred-length character optional dummy arguments [PR93762,PR100651]
Hi Harald, The patch looks OK to me. Probably wait a bit for another opinion, since I’m not that active and I may have missed something. Thanks, FX
Re: [PATCH, v3] Fortran: deferred-length character optional dummy arguments [PR93762,PR100651]
Hi, > this patch extends the previous version by adding further code testing > the presence of an optional deferred-length character argument also > in the function initialization code. This allows to re-enable a > commented-out test in v2. Nice, that sounds logical. > Regtested on x86_64-pc-linux-gnu. OK for mainline? OK. FX
Re: Bug 85836 (F2018) - [meta-bug] Fortran 2018 support
Hi Paul, Thanks for doing that, it is tedious but very useful work for users and developers. How does the Reid list compare to Chivers & Sleightholme? Also, because Chivers & Sleightholme have several versions of their list, am I correct in understanding your reference is https://dl.acm.org/doi/10.1145/3432987.3432991 ? And, do we want to put effort into updating the live version at https://gcc.gnu.org/wiki/Fortran2018Status? (and 2008 and others) Best regards, FX
Re: [PATCH] Fortran: allow NULL() for POINTER, OPTIONAL, CONTIGUOUS dummy [PR111503]
Hi Harald, > here's another fix for the CONTIGUOUS attribute: NULL() should > derive its characteristics from its MOLD argument; otherwise it is > "determined by the entity with which the reference is associated". > (F2018:16.9.144). Looking good to me, but leave 48 hours for someone else to object if they want. Best, FX
[PATCH] libgfortran: avoid duplicate libraries in spec
When gfortran invokes the linker, it reads the linking spec from libgfortran. This ends up doing things like: -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc where you can see that libgcc (both -lgcc and -lgcc_s) is linked in twice. This wasn’t a problem, until the new macOS linker, which gives a warning for this: the warning is innocuous, but having a warning for every time you call gfortran for linking clutters the terminal, and makes all the testsuite fail. And linking twice is superfluous, so removing it will not be a problem. I am the author of the original commit to the spec, in 2010, but honestly I have no memory: I think I vaguely remember saying “better safe than sorry”, but 13 years later it could just be a false memory ;) Anyway, this was tested on x86_64-darwin and x64_86-linux, as well as *-*-solaris2.11 by Rainer. OK to commit? (seems admissible in stage 3 because it fixes regtesting on darwin22 and darwin23). FX libgfortran/ChangeLog: PR libfortran/110651 * libgfortran.spec.in: Remove duplicate libraries. --- libgfortran/libgfortran.spec.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 0001-libgfortran-avoid-duplicate-libraries-in-spec.patch Description: Binary data
Re: libgfortran, ABI, and F2018 enhancements to intrinsics? Opinions wanted
Hi Harald, > If we do not want to break the existing ABI, so that we can > link gfortran-13 and gfortran-14+(?) compiled code, we need > to keep _gfortran_get_command_i4 & friends, and introduce > new library functions that are able to handle the new > requirements. I have been thinking about the large number of intrinsic implementations we have, with their naming conventions (_i4, _i8, etc). The standard seems to go in the direction of allowing more and more kind and type combinations (in general), and our approach dooms us to an explosion of the library in terms of number of functions. I believe this is in part because historically the front-end lowered most intrinsics directly into a function call. But we don’t have to continue doing that, and I would be in favour of limiting as much as we can the number of library functions, and handle the rest in the front-end. For example, we could have one library-side function called _gfortran_f2018_get_environment_variable with fixed integer types (probably int or size_t). Then the conversions are handled in the front-end. FX
Re: [PATCH] libgfortran: avoid duplicate libraries in spec
Hi, > I am getting side notes about people having these issues with gfortran 13. Is > this something that should be backported. I have already backported it in the latest Homebrew package (because we have many users complaining about it). I intend to backport but will wait for a conservative amount of time before doing so. > Apparently it is causing some none gfortran compilations to break, but I do > not know if this is the same issue. Don’t think so. I can have a look if you give me a pointer. FX
Re: libgfortran, ABI, and F2018 enhancements to intrinsics? Opinions wanted
> Likely GFC_INTEGER_8 or int64_t or compatible. We have 32/64bit and > -fdefault-integer-8 to deal with… That’s why I am suggesting either “int” or “size_t”, i.e., a well-defined C type. Means we don’t have to deal with -fdefault-integer. FX
Re: [PATCH] Fortran: bogus warnings with REPEAT intrinsic and -Wconversion-extra [PR96724]
Hi Harald, OK to push, thanks for picking it up! FX
Re: [Fortran] half-cycle trig functions and atan[d] fixes
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? - On systems where libquadmath is used for _Float128, does libquadmath contain the implementation of the q() variants for those functions? - 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? - 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? Best, FX
Re: [Fortran] half-cycle trig functions and atan[d] fixes
Hi, > Hopefully, FX sees this as my emails to gmail bounce. I am seeing this email. > 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). FX
Re: Request to improve docs: Fortran integer ranges vs. machine representation
>> print *, -128_int8 > > This is a unary minus operator with an operand of 128. > gfortran does not have negative integers. To be clear, it’s not gfortran, it’s the standard(s). It’s not exactly true either, because there is a "signed-int-literal-constant” which is allowed in some contexts: - as real part or imaginary part of a complex literal constant - as a data-stmt-constant - in some edit descriptors (DT and P control-edit-desc) This is, for example, legal code (and handled by gfortran as expected): use iso_fortran_env implicit none integer(int8) :: j data j /-128_int8/ print *, j end On the other hand, in your code, -128_int8 cannot be a literal constant, because integer literal constants cannot have a sign in Fortran. As Steve said, “-128_int8” in this context in Fortran is the minus unary operator applied to the integer literal constant 128_int8. We current output this: 4 | j = -128_int8 | 1 Error: Integer too big for its kind at (1). This check can be disabled with the option '-fno-range-check’ I think the only better output we could give is to make it clear what the integer value is, either by underlining it (but we don’t have a framework to do that right now) or by outputting the value in the message (?). Best, FX
Re: Request to improve docs: Fortran integer ranges vs. machine representation
> Interesting example. > > % gfcx -o z a.f90 && ./z > -128 > % gfcx -o z -pedantic a.f90 && ./z > a.f90:5:20: > >5 | data j /-128_int8/ > |1 > Error: Integer too big for its kind at (1). This check can be disabled with > the option ‘-fno-range-check’ That qualifies as a compiler bug, I think. Our documentation for -pedantic states: “Issue warnings for uses of extensions to Fortran.” and "Valid Fortran programs should compile properly with or without this option.” The same is true of the following, which is also valid Fortran since 95 : use iso_fortran_env implicit none complex, parameter :: z = (-128_int8, -128_int8) print *, z end Right now it fails to compile with -pedantic. Or are they illegal because of how the range should be be symmetric? I can’t quite find the language in the standard for that, actually. To me, they’re valid signed-int-literal-constant. FX PS: I’m going to ignore the cases of the P and DT edit descriptors, because they’re not allowed to have a kind value, and therefore the corner cases occur for values too big to be actually relevant to anything.
Re: [PATCH] testsuite, gfortan: Update link flags [PR112862].
> Tested on i686, x86_64, aarch64 Darwin, x86_64, aarch64 Linux, > OK for trunk? Looks good to me. Please leave 48h before pushing for other Fortran maintainers to comment if they see something I missed (in particular the coarrays part). FX
Re: [patch, libgfortran] PR99210 X editing for reading file with encoding='utf-8'
> Regression tested on x86_64 and new test case. > OK for trunk? OK, and thanks! FX
Re: [patch, libgfortran] PR107068 Run-time error when reading logical arrays with a namelist
> OK for trunk? > I think simple enough to backport to 13 as well. OK, but probably best to wait a few weeks before backporting. FX
Re: [patch, libgfortran] Bug 105473 - semicolon allowed when list-directed read integer with decimal='point'
> OK for trunk and later backport to 13? OK. Thanks for the patch! FX
Re: [PATCH]AArch64: xfail modes_1.f90 [PR107071]
Skipping is the right thing to do at this point. OK to push from the Fortran part. FX
[PATCH] Fortran: add two small F2023 features
Hi, 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) FX 0001-Fortran-add-F2023-ISO_FORTRAN_ENV-named-constants.patch Description: Binary data 0002-Fortran-add-SELECTED_LOGICAL_KIND.patch Description: Binary data
Re: [PATCH] Fortran: fix argument checking of intrinsics C_SIZEOF, C_F_POINTER [PR106500]
Hi Harald,
Thanks for the patch.
> + if (attr.function)
> +{
> + gfc_error ("FPTR at %L to C_F_POINTER is a function returning a
> pointer",
> + &fptr->where);
> + return false;
> +}
> +
>if (fptr->rank > 0 && !is_c_interoperable (fptr, &msg, false, true))
> return gfc_notify_std (GFC_STD_F2018, "Noninteroperable array FPTR "
> "at %L to C_F_POINTER: %s", &fptr->where, msg);
In both of these gfc_error(), could we change our error message to say "FPTR
argument” instead of “FPTR”? “FPTR to C_F_POINTER” does not really make sense
to me.
This would be more in line with what the generally do:
> Error: 'x' argument of 'sqrt' intrinsic at (1) must be REAL or COMPLEX
So maybe “FPTR argument to C_F_POINTER at %L” ? That’s much more readable to me.
Otherwise, OK.
FX
Re: [PATCH 0/1] libgfortran: Fix compilation of gf_vsnprintf
> Gentle ping. If this looks good, can someone commit to main (I don't have > commit privileges). This is also something that could be considered for > stable, since it's been around for many years. Thanks for the patch. Pushed as https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=3bd3ca05b519b99b5ea570c10fd80737cd4c6c49 FX
Re: [PATCH] Fortran: ALLOCATE of fixed-length CHARACTER with SOURCE/MOLD [PR113793]
Hi Harald, > Regtested on x86_64-pc-linux-gnu. OK for mainline? Looks good to me. FX
Re: Updated Sourceware infrastructure plans
> I regenerate auto* files from time to time for libgfortran. Regenerating > them has always been very fragile (using --enable-maintainer-mode), > and difficult to get right. I have never found them difficult to regenerate, but if you have only a non maintainer build, it is a pain to have to make a new maintainer build for a minor change. Moreover, our m4 code is particularly painful to use and unreadable. I have been wondering for some time: should we switch to simpler Python scripts? It would also mean that we would have fewer files in the generated/ folder: right now, every time we add new combinations of types, we have a combinatorial explosion of files. $ ls generated/sum_* generated/sum_c10.c generated/sum_c17.c generated/sum_c8.c generated/sum_i16.c generated/sum_i4.c generated/sum_r10.c generated/sum_r17.c generated/sum_r8.c generated/sum_c16.c generated/sum_c4.c generated/sum_i1.c generated/sum_i2.c generated/sum_i8.c generated/sum_r16.c generated/sum_r4.c We could imagine having a single file for all sum intrinsics. How do Fortran maintainers feel about that? FX
Re: [PATCH] libgfortran: Fix up the autoreconf warnings.
> libgfortran/ChangeLog: > * Makefile.am: Use sub-dirs, amend recipies accordingly. > * Makefile.in: Regenerate. Thanks Iain, I’ve tested it both with and without maintainer mode, and regenerated files with no issue. I can also confirm that the many autoreconf warnings that plagued libgfortran are now gone. Push as affd24bfc62203db9f9937c0d6cf8f1f75b80d72 FX
Re: [PATCH] libgfortran: Fix libgfortran.so versioning on Solaris with subdirs
Hi Rainer, > This patch fixes this by allowing for the new structure. > Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11. > > Ok for trunk? OK to push, given it’s localised inside LIBGFOR_USE_SYMVER_SUN. I find it weird though that .libs is harcoded there. If we look at all the lib*/Makefile.am in gcc, the only thing that ever needs to specify .libs is for Solaris versioning. It feels like it should be more generic, as you say (but that’s for longer term). FX
Re: [PATCH, libgfortran] aix: Fix building fat library for AIX
> libgfortran/ChangeLog: > * config/t-aix (all-local, libcaf_single): Explicitly reference > caf/.libs/single.o OK, and sorry for the breakage. FX
Re: [Patch] Fortran: Fix SHAPE for zero-size arrays
Hi Tobias, > That is for https://gcc.gnu.org/PR115150 – a GCC 12/13/14/15 regression, > caused when switching from a libgomp call to inline code and missing the > corner case of zero-size arrays … OK to push, thanks. FX
Re: [Patch] Fortran: invoke.texi - link to OpenCoarrays.org + mention libcaf_single
Hi Tobias, > OK for mainline? Seems reasonable, OK to push in 48 hours unless someone has suggestions related to wording. FX
Re: [wwwdocs][patch] gcc-15/changes.html: Fortran - mention F2023 logical-kind additions
Seems good, thanks Tobias! FX
Re: Fortran compiler
> I am interested in your company's Fortran Compiler. > Is it free? If not, how much for a permanent license? gfortran is free, part of GCC which is open source software. It is provided on your system: - for Windows see there: https://gcc.gnu.org/wiki/GFortranBinaries - for macOS, as part of Homebrew and Macports - for Linux, as part of gcc in your system package management Best regards, FX
Re: powerpc-apple-darwin: round_4.f90 test with IBM long double
Hi, > Furthermore, the test is supposed to use IEEE arithmetic module No, the test does not use the IEEE arithmetic module. FX
Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic
Hi,
The core of the powerpc-FPU manipulation is okay for me. Some comments below.
> --- a/gcc/testsuite/gfortran.dg/ieee/signaling_2_c.c
> +++ b/gcc/testsuite/gfortran.dg/ieee/signaling_2_c.c
> @@ -1,3 +1,11 @@
> +#ifdef __POWERPC__ // No support for issignaling in math.h on Darwin PPC
Two things:
1. I don’t understand why that needs to be added. The companion test in
signaling_2.f90 has:
! { dg-require-effective-target issignaling } */
! The companion C source needs access to the issignaling macro.
Therefore, if the issignaling macro is not available, the test should not even
be run.
2. Maybe this is actually moot. Is the __builtin_issignaling() macro available
on all targets? The test was written before it was added to the middle-end. If
the answer to the previous question is yes, we should simply use it in instead
of the macro.
> +/* There is no consistency re what is to be included in all_invalid.
> + Apple libm has 0x01f80300, Openlibm/FreeBSD/NetBSD has 0x21f80700
> + and OpenBSD has 0x01f80700. In particular, FE_INVALID_SOFT and
> + FE_INVALID are contested. */
> +#define FE_ALL_INVALID 0x01F80700
> +#define FE_NO_INVALID 0xFE07F8FF
> +
> +/* Apple libm has 0xFFF80300 and 0x0007FCFF here. */
> +#define FE_ALL_FLAGS0xFFF80700
> +#define FE_NO_FLAGS 0x0007F8FF
Since it’s a darwin-only file, why not follow Apple libm conventions?
> There is one test which changes from PASS to FAIL (round_4), however I think
> this is not a real regression, and the test in its present form is expected
> to fail.
> See comments in the test code in the source and my post:
> https://gcc.gnu.org/pipermail/fortran/2024-July/060612.html
I agree that round_4.f90 should be added to the dg-skip-if.
But I’d like to understand better what are the other new failures, and why
there arise?
FX
[PATCH, pushed] Fortran: switch test to use issignaling() built-in
Pushed after testing on x86_64-unknown-linux-gnu. The macro may not be present in all libc's, but the built-in is always available. See https://gcc.gnu.org/pipermail/gcc-patches/2024-July/656409.html for context. gcc/testsuite/ChangeLog: * gfortran.dg/ieee/signaling_2.f90: Adjust test. * gfortran.dg/ieee/signaling_2_c.c: Adjust test. 0001-Fortran-switch-test-to-use-issignaling-built-in.patch Description: Binary data
Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic
> This part of the patch is quite old, but from the remaining log it looks I > got an error here: > Now on a second thought, this did not require a fix perhaps. We can drop it. I have addressed this: https://gcc.gnu.org/pipermail/gcc-patches/2024-July/656484.html The test should now be run on all targets, regardless of the issignaling() macro availability. > By the way, do we have some point of comparison from other ppc32 platforms, > Linux or BSD (for the recent gcc master)? You can have a look at testresults here: https://gcc.gnu.org/pipermail/gcc-testresults/ FX
Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic
Can you post an updated version of the patch, following the first round of review? FX
Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic
Hi, > I dropped a change to the test file, since you have fixed it appropriately, > and switched to Apple libm convention for flags, as you have suggested. > Please let me know if I should do anything further to improve it and make it > acceptable for a merge. The patch itself is OK. Please add a ChangeLog entry fitting the GCC format (see prior commits in libgfortran/ for examples). FX
Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic
> Thank you for responding. > I have added a changelog (is this a correct way?). Content seems ok, lines are maybe too long. Check with contrib/gcc-changelog/git_check_commit.py before pushing. Once that is fine, OK to push. FX
Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic
Thanks Sergey, I have pushed the patch at https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=1cfe4a4d0d4447b364815d5e5c889deb2e533669 FX
Re: How to document intrinsics with UNSIGNED arguments...
Hi, >> As UNSIGNED has been booted off the F202Y list, I think calling it >> an extension at this time is fair. > > Looks good to me. And yes, calling it an extension is fair. I apologise, I had missed this piece of information. If UNSIGNED is not on track to becoming a feature in the next standard, is there really high value in implementing it in gfortran? Fortran as a language is moving from a past where it was a nightmare of incompatible extensions, into a more standard-based language. I personally think it is a good evolution. Big extensions (like Cray pointers) have shown in the past how hard they are to maintain in the long term: lots of dark corners that we never get fully right. Just some food for thought, maybe this has been discussed already, and I have missed it. Best, FX
Re: 8.260 STAT example fails if compiled with -std=f2008
Hi,
> My Fortran project is based on -std=f2008. The GNU Fortran (For GCC version
> 15.0.0) manual’s 8.260 STAT example does not link if -std=f2008 is on the
> command line: gfortran -std=f2008 test_stat.f90; ./a.out
> The ld error is “undefined reference to `stat_’”
Our doc (https://gcc.gnu.org/onlinedocs/gfortran/STAT.html) states: "Standard:
GNU extension”
If you compile with -std=f2008 (or any other -std value except gnu or legacy),
the STAT intrinsic is not available. Nor is CTIME. If you compile with -W
-Wall, you will get helpful warnings about this:
test_stat.f90:5:21:
5 | CALL STAT("/etc/passwd", buff, status)
| 1
Warning: The intrinsic 'stat' at (1) is not included in the selected standard
but a GNU Fortran extension and 'stat' will be treated as if declared EXTERNAL.
Use an appropriate '-std=' option or define '-fall-intrinsics' to allow this
intrinsic. [-Wintrinsics-st]
test_stat.f90:5:21: Warning: The intrinsic 'stat' at (1) is not included in the
selected standard but a GNU Fortran extension and 'stat' will be treated as if
declared EXTERNAL. Use an appropriate '-std=' option or define
'-fall-intrinsics' to allow this intrinsic. [-Wintrinsics-std]
test_stat.f90:5:50:
5 | CALL STAT("/etc/passwd", buff, status)
| 1
Warning: The intrinsic 'stat' at (1) is not included in the selected standard
but a GNU Fortran extension and 'stat' will be treated as if declared EXTERNAL.
Use an appropriate '-std=' option or define '-fall-intrinsics' to allow this
intrinsic. [-Wintrinsics-st]
test_stat.f90:16:75:
16 | WRITE (*, FMT="('Last access time:',T30, A19)")
CTIME(buff(9))
|
1
Warning: The intrinsic 'ctime' at (1) is not included in the selected standard
but a GNU Fortran extension and 'ctime' will be treated as if declared
EXTERNAL. Use an appropriate '-std=' option or define '-fall-intrinsics' to
allow this intrinsic. [-Wintrinsics-std]
test_stat.f90:16:75: Warning: The intrinsic 'ctime' at (1) is not included in
the selected standard but a GNU Fortran extension and 'ctime' will be treated
as if declared EXTERNAL. Use an appropriate '-std=' option or define
'-fall-intrinsics' to allow this intrinsic. [-Wintrinsics-std]
test_stat.f90:16:69:
16 | WRITE (*, FMT="('Last access time:',T30, A19)")
CTIME(buff(9))
| 1
Warning: The intrinsic 'ctime' at (1) is not included in the selected standard
but a GNU Fortran extension and 'ctime' will be treated as if declared
EXTERNAL. Use an appropriate '-std=' option or define '-fall-intrinsics' to
allow this intrinsic. [-Wintrinsics-std]
Best,
FX
Re: How to document intrinsics with UNSIGNED arguments...
Hi Thomas, Thanks for the clarification. I really hope that it makes it into the standard, I do not disagree that it is useful, I just really wish we don’t have to maintain long-term a lot of nonstandard (or worse, standard-incompatible) extensions. -std=legacy took a lot of ugly work over the years. But the context, as you explain, is reassuring. And many thanks for the effort of implementation, I know it is far from trivial. Could you post a link to the specification that is currently implemented in gfortran? i.e., if I understand correctly, your proposal + the amendments of the committee. Best, FX
Re: Complex arithmetic in Fortran
> So, I think we could ignore signed zeros (from the Fortran standard > perspective) > > - for complex arithmetic, always > - for real arithmetic, if none of the IEEE modules is USEd That seems like a very backward-incompatible change to introduce :( I might break a lot of existing codes. FX
Re: insight needed on trans-* hacking
Hi Steve, I think it’d be simpler not to create a front-end expression for the c_null_char. Unless I’m mistaken, you only need it as an argument to pass to build_call_expr_loc (input_location, gfor_fndecl_concat_string, …). You can pass a pointer to the constant character, and the length is one. The variable for length would be build_int_cst (gfc_charlen_type_node, 1). For the pointer to the constant character, you would do: tree nulchar = gfc_character1_type_node(gfc_character1_type_node, “nulchar”); gfc_add_modify (&block, nulchar, build_zero_cst (gfc_character1_type_node)); tree pnulchar = gfc_build_addr_expr (NULL_TREE, nulchar); Since the variable in this case is a known constant, there’s probably even a better way. I just don’t remember enough, but others may help? --- Regarding your question, you are right: you want to build the two code blocks (you already have the content), then use: fold_build3_loc (input_location, COND_EXPR, return_type, boolexpression, iftrue, iffalse) You will find some logic like that in gfc_conv_intrinsic_minmaxloc() near the comment "We switch to > or >= depending on the value of the BACK argument”. You create ifblock and elseblock, once you have the code inside them, you make them into trees with gfc_finish_block (becoming ifbody2 and elsebody2). Then: tmp = fold_build3_loc (input_location, COND_EXPR, logical_type_node, back, ifbody2, elsebody2); Hope this helps? Best, FX
Re: insight needed on trans-* hacking
Hi Steve, > I've an almost complete implementation of F_C_STRING, > but need a bit of insight on the inlining that I'm > trying to implement. Maybe I can help. Can you send in your current patch? FX
Re: [patch, libgfortran] Bug 117819 - Formatted READ with BZ in format fails
Hi Jerry, This looks okay to me, but maybe leave 48 hours for others to comment? Best, FX
Re: porting-to update request
Hi, The error message was fixed by Harald in: commit fb132276d173907d575ea61fda3b846a9bc6e456 Author: Harald Anlauf Date: 2025-03-28 20:31:08 +0100 Fortran: fix spelling of flag -fallow-invalid-boz gcc/fortran/ChangeLog: * check.cc (gfc_invalid_boz): Correct spelling of compiler flag in hint to -fallow-invalid-boz. >>> Third, and the main point of this email I guess, is that the >>> porting-to page should mention this: >>> https://www.gnu.org/software/gcc/gcc-10/porting_to.html The changes page for gcc 10 (https://www.gnu.org/software/gcc/gcc-10/changes.html) says: "The handling of a BOZ literal constant has been reworked to provide better conformance to the Fortran 2008 and 2018 standards. In these Fortran standards, a BOZ literal constant is a typeless and kindless entity. As a part of the rework, documented and undocumented extensions to the Fortran standard now emit errors during compilation. Some of these extensions are permitted with the -fallow-invalid-boz option, which degrades the error to a warning and the code is compiled as with older gfortran." BOZ handling was quite inconsistent in early days, and was simplified and clarified. Some cases are indeed no longer accepted, but there was really a lot of weird old code out there. They should be relatively easy to fix. If I am not mistaken, the standard way to write your code: fcn = x * '0100'X is fcn = x * int(z’0100') Best, FX
Re: PING – Re: [Patch] Fortran: Use mpfr_sinu etc. with mpfr 4.2.0+ for degree trigonometric functions [PR120225]
Hi Tobias, > Admittedly, this *PING* is rather early – but as more trigonometric > functions changes are coming, I think it would be useful to agree > that this is a good approach. Patch is OK to push. FX
Re: [PATCH] libfortran: Simplify Makefile logic
Hi, > I am just wondering if the order in Makefile.am as it is now is needed. E.g. > pack_* follows pow_* and some other are not lexicographicaly ordered. Are > there > dependencies that necessitate this? Or could you just sort them, so that > looking up files is easier for humans? I think they don’t matter, but my automake skills are not that great, so I kept the current order. Another improvement I could imagine is, instead of listing files explicitly, we could use some patterns/globing; but I don’t know how well it would work, how to achieve it, and whether it’s considered good practice in gcc’s build machinery generally. I aimed to solve the existing problems, but with minimal disruption. Patch pushed, thanks for the review. FX
[PATCH] libfortran: Simplify Makefile logic
> the patch looks good to me. I only have x86_64, too, therefore I haven't > tested > it (again). There's a lot of repetition in the regenerate.sh file. I hope to > see this "simplified" or rather DRY'ed (Don't repeat yourself - principle) in > the future. Following up on this, here is a new patch that simplifies the Makefile logic a little bit, getting most of the generated files into one big list instead of many independent variables. This is possible for all except matmul, which needs its own special flags. I also include some checking in the regenerate.sh script, to should make sure the list of generated files in the script and in the makefile stay in sync. Tested on x86_64-linux, OK to push? FX 0001-libfortran-Simplify-Makefile-logic.patch Description: Binary data
[PATCH] libfortran: Add script to regenerate source files
Hi, This patch adds a new “regenerate.sh” script in libgfortran/, which is the new mechanism to rebuild all source files in the generated/ folder. It removes this from the Makefile (where it was misusing the maintainer mode, which was not intended for that purpose). The new script is standalone, and it should be run by developers whenever they modify a file in the m4/ directory. It will not be triggered by the Makefile, and must be run manually. It does not modify the timestamps or inodes of generated files, if they are not be modified. The Makefile can later be simplified, but I don’t want to mix all the changes at once, so here’s a first part. If there is agreement, I’ll work on simplifying the Makefile next. Undergoing testing on x86_64-linux, OK to push? FX 0001-libfortran-Add-script-to-regenerate-source-files.patch Description: Binary data
Re: [PATCH] Fortran: add Fortran 2018 IEEE_{MIN,MAX} functions
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
[PATCH] Fortran: add IEEE_QUIET_* and IEEE_SIGNALING_* comparisons
Hi, This is a repost of the patch at https://gcc.gnu.org/pipermail/gcc-patches/2022-September/600887.html which never really got green light, but I stopped pushing because stage 1 was closing and I was out of time. It depends on a middle-end patch adding a type-generic __builtin_iseqsig(), which I posted for review at: https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620801.html Bootstrapped and regtested on x86_64-pc-linux-gnu, OK to commit (once the middle-end patch is accepted)? FX 0002-Fortran-add-IEEE_QUIET_-and-IEEE_SIGNALING_-comparis.patch Description: Binary data
Re: [PATCH] Fortran: add Fortran 2018 IEEE_{MIN,MAX} functions
Hi Steve, I am not subscribed to the list (too little time, sadly), please keep me in CC of your responses. > 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) Those built-ins are not exposed to the user: we don’t need any more GNU-specific intrinsics, methinks. > 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. As you saw, the module built as part of libgfortran deals with that. In the longer term, we would need a revamp of those modules to handle everything as intrinsic modules, which would give us more flexibility, but I never found the time to do this migration :( Best, FX
Re: [PATCH] Fortran: add Fortran 2018 IEEE_{MIN,MAX} functions
> Having a POWER system isn't enough, it also needs the IBM "advance > toolchain", and (at least with current distros, which default to > ibm long double), you need to dance counterclockwise three > times... I mean you need to invoke configure with some special magic Thanks for the frank description, Thomas. To be honest, it reinforces my feeling from when this was originally proposed and added: why are we doing so much extra work for a feature that is used by such a tiny fraction of our user base. FX
Re: [PATCH] Fortran: add IEEE_QUIET_* and IEEE_SIGNALING_* comparisons
Hi Harald, > I just looked at that thread. I guess if you answer Mikael's > questions at > https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601744.html > the patch will be fine. Amended patch, adding the required testing of signalling vs. quiet behaviour. I still need to get an OK on the middle-end part first, but I consider the Fortran part approved. Thanks, FX 0001-Add-__builtin_iseqsig.patch Description: Binary data 0002-Fortran-add-IEEE_QUIET_-and-IEEE_SIGNALING_-comparis.patch Description: Binary data
Re: [PATCH] Fortran: add Fortran 2018 IEEE_{MIN,MAX} functions
Hi Thomas, > 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 Can you check what the IEEE test results are when -mabi=ieeelongdouble is enabled? It’s not even clear to me what the IEEE kinds selected should be, in this case, depending on -mabi=ieeelongdouble > Regarding FX's patch: I am not quite sure that I am > actually testing the right thing if running the testsuite > there, so POWER should not hold up this patch. If it turns > out that POWER needs additonal work on IEEE, we can always > add that later. Actually, it sounds like the situation is: the same target can have two ABIs based on a compile-time flag. That sounds like a job for multilib, i.e., we should compile libgfortran twice, one for each ABI. I am sure this was considered and rejected, do you remember what was the rationale? Thanks, FX
Re: [PATCH] Fortran: add Fortran 2018 IEEE_{MIN,MAX} functions
Given the agreement that the patch is not making things for powerpc worse, and the review by Steve, I have committed as https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=17bccd1d2c0fa1f08e0483c8ed841994a95febb0 Best, FX
Fortran 2008 DATA statement restrictions
Hi, I was looking at our table for Fortran 2008 conformance (https://gcc.gnu.org/wiki/Fortran2008Status) and we really have only a few items missing. One in particular is: "Data statement restrictions lifted”. Quoting the document: > Subscripts and nested implied-do limits in a data statement can be any > constant expression instead of being limited to combinations of constants, > implied-do variables, and intrinsic operations. Unless I misunderstand this quote, I think we have that already. Maybe we always had that? I have run the attached test program, which uses non-trivial constant expressions, and it passes fine. So I plan to add that to our testsuite, and change the wiki. But I would like someone else to confirm: do you understand this the same way I do? Do you have ideas of other ways to test it, tricky expressions, etc? Are there other ways that "Subscripts and nested implied-do limits” may appear in a DATA statement? Thanks, FX data.f90 Description: Binary data
libgfortran: remove support for --enable-intermodule
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109373 I don’t believe it is widely used, and it was removed from everywhere else in gcc. Bootstrapped and regtested on x86_64-pc-linux-gnu. OK to commit? FX 0001-libgfortran-remove-support-for-enable-intermodule.patch Description: Binary data
Re: libgfortran: remove support for --enable-intermodule
> OK, thanks. Committed at https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=ecc96eb5d2a0e5dd93365ef76a58d7f754273934
Re: [PATCH] Fortran: add Fortran 2018 IEEE_{MIN,MAX} functions
Hi, > Running > nohup make -j7 check-fortran > RUNTESTFLAGS="--target_board=unix/-mabi=ieeelongdouble/-mcpu=power9"& > from the gcc subdirectory yielded only a single failure: I dug more into the code and I understand why all tests are running: since db630423a97ec6690a8eb0e5c3cb186c91e3740d and 0c2d6aa1be2ea85e751852834986ae52d58134d3 all IEEE functions manipulating real or complex arguments are actually expanded fully inline (we retain functions in libgfortran for backward compatibility). The only IEEE functions that depend on libgfortran runtime are the “IEEE_SUPPORT_*” functions. FX
Re: Fortran 2008 DATA statement restrictions
Hi, Thanks Harald. I see there are bugs open, but actually not that many, compared to other areas of the compiler :) I think the code I sent was not really covered in the testsuite, so I have committed it (after testing on x86_64-linux). https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=a54c71ccc24874ce79019b51150b3a00b7c785cd Best, FX
