Re: [libgfortran, patch] PR88052 Format contravening constraint C1002 permitted

Hi Jerry, I had originally created this patch in 2018 and we did not get back to it. This results in more restrictive runtime behavior. I will go through the front-end code with another patch to catch this at compile time. Changelog and new test case. See attached patch. OK for trunk Yes, O

Re: [PATCH, v2] Fortran: implement F2018 intrinsic OUT_OF_RANGE [PR115788]

Hi Harald, Thanks for pointing this out!  I've also added a few gcc_unreachable() to prevent other potential false positives, see attached. Just a couple of documentation nits: The documentation says INTEGER or REAL only, but it also works (as an extension) for UNSIGNED. Also, OUT_OF_RANGE is

Re: [PATCH] fortran: Bump MOD_VERSION to "16" [PR118337]

Am 08.01.25 um 19:18 schrieb Steve Kargl: While working on f_c_string(), it never occurred to me that the version number should have been bumped. Thanks for the sleuthing you've done so far. Same for me! Best regards Thomas

Re: [PATCH] Fortran: implement F2018 intrinsic OUT_OF_RANGE [PR115788]

Hello Harald, Regtested on x86_64-pc-linux-gnu. OK for mainline? I just started to run a bootstrap on cfarm120 (because it is the only machine I can lay my hands on where I can run "make -j128" without disturbing anybody :-) and I got ../../trunk/gcc/fortran/trans-intrinsic.cc: In function ‘

Re: [PATCH] Fortran: Added support for locality specs in DO CONCURRENT (Fortran 2018/23)

Am 11.01.25 um 18:32 schrieb Jerry D: The attached patch is the latest clean build and test run I can come up with. I completely cannot understand why moving the forall_iterator from the sub-structure 'concur' back to where it was at the 'ext' sub- structure of typedef struct gfc_code. 'ext' is

[patch, fortran, committed] Fix union member access

-g40754a3b9bef83bf4da0675fcb378e8cd1675602 . Best regards Thomas Author: Thomas Koenig Date: Sun Jan 12 13:05:25 2025 +0100 Fix union member access for EXEC_INQUIRE. gcc/fortran/ChangeLog: PR fortran/118432 * frontend-passes.cc (doloop_code): Select correct member

Re: Failure on 14 branch

Hi Jerry, Is anyone else seeing this? Running /home/jerry/dev/gcc14/gcc/testsuite/gfortran.dg/dg.exp ... FAIL: gfortran.dg/bind-c-contiguous-1.f90   -O3 -fomit-frame-pointer - funroll-loops -fpeel-loops -ftracer -finline-functions  (internal compiler error: Segmentation fault) FAIL: gfortran.d

[patch, fortran] Dump all symbol attributes with -fdump-fortran-original

Hell world, after finding that an attribute I was looking for was not in the -fdump-fortran-original dump, I started putting in attributes and didn't stop until I had them all (or so I hope :-) It should be easier to read than looking at the symbol attributes in a debugging session, and could ho

Re: [patch, fortran] Dump all symbol attributes with -fdump-fortran-original

Hi Manfred, @@ -868,6 +870,8 @@ show_attr (symbol_attribute *attr, const char * module) fputs (" IN-NAMELIST", dumpfile); if (attr->in_common) fputs (" IN-COMMON", dumpfile); + if (attr->in_equivalence) +fputs (" IN_EQUIVALENDE", dumpfile); s/IN_/IN-/ s/ENDE/ENCE/ Two typ

Re: [patch, fortran] Dump all symbol attributes with -fdump-fortran-original

Hi Harald, there is one irregularity here (partial lower case instead of consistently upper case: +  if (attr->oacc_declare_copyin) +    fputs (" OACC-DECLARE-copyin", dumpfile); Otherwise this is OK. Thanks for catching this! Committed with the fix as r15-6840-gf4fa0b7d493a4ba217d989d3df75

Re: PING **(6./7.): [patch, Fortran] -fc-prototypes fixes.

Am 16.01.25 um 01:50 schrieb Jerry D: Yes I think this is OK, a definite improvement. Committed as r15-6967. Thanks for the review! Best regards Thomas

Re: [PATCH] libfortran: fix conversion of UNSIGNED(kind=16) to decimal in output [PR118406]

Hello Harald, the conversion of (unsigned) integers to decimal in output was designed to be efficient up to INTEGER(kind=16) and did not handle values larger than roughly (10^19 * 2^64). The attached obvious patch fixes this. Regtested on x86_64-pc-linux-gnu.  OK for mainline? OK. Thanks a

Re: [patch, Fortran] -fc-prototypes fixes.

Am 09.01.25 um 14:45 schrieb Andre Vehreschild: You forgot to add the patch! Sent two minutes later :-) https://gcc.gnu.org/pipermail/fortran/2025-January/061540.html

Re: [Patch] Fortran: Fix location_t in gfc_get_extern_function_decl; support 'omp dispatch interop'

Hi Tobias, Comments, remarks, suggestions? I assume you regression-tested (you didn't say). Otherwise, I regard the common Fortran code as obvious - and the OpenMP part covered by my (co)maintainership. Regarding the Fortran part: - fndecl = build_decl (input_location, + fndecl = build_

[patch, Fortran] -fc-prototypes fixes.

Hello world, This patch fixes and reorganizes dumping C prototypes. It makes the following changes: - BIND(C) types are now always output before any global symbols - CFI_cdesc_t is issued for assumed shape and assumed rank arguments. - BIND(C,NAME="...") entities were no

Re: [patch, Fortran] -fc-prototypes fixes.

Am 09.01.25 um 14:34 schrieb Thomas Koenig: This patch fixes and reorganizes dumping C prototypes. And here is the "five seconds later, I realized I had forgotten to attach the patch" e-mail... diff --git a/gcc/fortran/dump-parse-tree.cc b/gcc/fortran/dump-parse-tree.cc index 8

PING **(6./7.): [patch, Fortran] -fc-prototypes fixes.

Am 09.01.25 um 14:36 schrieb Thomas Koenig: Am 09.01.25 um 14:34 schrieb Thomas Koenig: This patch fixes and reorganizes dumping C prototypes. And here is the "five seconds later, I realized I had forgotten to attach the patch" e-mail... ... with the original text: Hello world,

[Patch, Fortran] Fix PR 24878, checking actual arguments against global symbols

Hello world, this fixes a rather old PR from 2005, where a subroutine could be passed and called as a function. This patch checks for that, also for the reverse, and for wrong types of functions. I expect that this will find a few bugs in dusty deck code... Regression-tested. OK for trunk? Be

Re: [Patch, Fortran] Fix PR 24878, checking actual arguments against global symbols

Am 08.02.25 um 22:46 schrieb Harald Anlauf: looks good, just two minor comments: +  actual_name = act_sym->name ? act_sym->name : act_sym->name; Why not just +  actual_name = act_sym->name; ? That was a leftover from a previous commit. +  gfc_error ("Type mismatch pa

RFC: Bugzilla keyword "interp" where it is not clear if a program is standard-conforming or not

Hello world, looking at a few Fortran bug reports, I found some cases where it was not clear if the program in question was standard-conforming or not. I would propose to add a keyword for that, tentatively called "interp". Comments? Suggestions for a different name? Should I just go ahead and

[patch, Fortran, committed] Fix PR 118845

Hello world, I just committed the fix for PR 11845 as obvious and simple, as r15-7552-gfd00010ba21c04bddb20aef52f62de5636075067 . Fix PR 118884, Lapack build failure. The fix for PR 118845 introduced new checks, which in turn exposed a case where the typespec information on a symbol generated s

Re: [PATCH] Fortran: passing of derived type to VALUE, OPTIONAL dummy argument [PR118080]

Hello Harald, the attached patch fixes inconsistent handling of passing derived type actual arguments to scalar dummies with VALUE,OPTIONAL attribute. As suggested by Tobias, we should consistently pass a hidden boolean flag that indicates the presence or absence of the actual, similar to the ca

Re: 7/7 [Fortran, Patch, Coarray, PR107635] Remove deprecated coarray routines

Am 14.02.25 um 19:19 schrieb Jerry D: I think this is good to commit. (all 7 parts) I think so too, with one caveat... Does anyone else have any comments? This patch series (of necessity) introduces ABI changes. What will happen with user code compiled against the old interface? I guess

[patch, fortran, committed] Remove duplicate output of save attribute

Hello world, I just committed the attached patch as obvious, simple and having no user impact), as r15-7575. Previously, a dump looked like attributes: (VARIABLE IMPLICIT-SAVE BIND(C) SAVE-IMPLICIT) and now it is attributes: (VARIABLE IMPLICIT-SAVE BIND(C)) Best regards Thom

[patch, Fortran] Fix PR 118862, overwide shft

Hello world, this patch is a variation of Jakub's patch in the PR, which avoids overflow on the mask used for exponentiation and fixes unsigned HOST_WIDE_INT. I tried testing this on a POWER machine, but --with-build-config=bootstrap-ubsan fails bootstrap there. Regression-tested. OK for trunk?

Re: [Patch] Fortran: Store OpenMP's 'declare variant' in module file [PR115271]

Hi Tobias, Attached is a long overdue bug fix, given that OpenMP's declare variant is supported in gfortran sincer12-4409-g724ee5a0093da4 (Oct 2021). (and in C/C++ since r10-3744-g94e7f906ca5c73, Oct 2019). While 'omp declare simd' was already handled in the .mod file, 'declare variant' was no

Re: [patch, changes.html] UNSIGNED, -fc-prototypes*, -Wexternal-interface-mismatch

Hi Paul, It looks good to me. Thanks for the patch. Thanks! I just added one word, "modular", and committed it. Best regards Thomas

Re: [COMMITTED] libgfortran/intrinsics: Fix build for targets with int32_t=long int

Hi Paul, By the way, the standard just specifies integer for 'dim' in reduce, which I take to mean it should be default_integer_kind. Hmm... I'm not sure that this is actually the case; I believe it can actually be any integer kind, although anything larger than default integer would be kind o

[Patch, Fortran] C prototypes for functions returning C function pointers

Hello world, the attached patch handles dumping prototypes for C functions returning function pointers. For the test case MODULE test USE, INTRINSIC :: ISO_C_BINDING CONTAINS FUNCTION lookup(idx) BIND(C) type(C_FUNPTR) :: lookup integer(C_INT), VALUE :: idx lookup = C_FUNLO

Re: [Patch, Fortran] C prototypes for functions returning C function pointers

Hi Harald, the attached patch contains a chunk changing resolve.cc that is neither described in the suggested commit message, and it fails to compile here: ../../gcc-trunk/gcc/fortran/resolve.cc: In function 'void check_c_funptr_assign_interface(gfc_expr*, gfc_expr*)': ../../gcc-trunk/gcc/fortr

Re: [Fortran, Patch, PR119349, v1] Fix regression of polymorphic dummy sourced from array constructors.

Am 21.03.25 um 15:34 schrieb Paul Richard Thomas: I am reasonably familiar with the mess that is gfc_conv_procedure_call :-) It's only 2141 lines in a single function and eight levels of conditions / loops! I do not see what could possibly go wrong :-) Best regards Thomas

Re: [Patch, Fortran] C prototypes for functions returning C function pointers

Hello Harald, OK with the above addressed. Both addressed and pushed in https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=737a5760bb24a0a945cc2c916ba452e3f0060c58 Thanks for the review (and for catching the miscellaneous problems on the way)! Best regards Thomas

[patch, changes.html] UNSIGNED, -fc-prototypes*, -Wexternal-interface-mismatch

Hello world, the attached patch, tested with "tidy -e", puts the two parts mentioning UNSSIGNED into a single paragraph, mentions extensions to -fc-prototypes and mentions -Wexternal-interface-mismatch. Comments, suggestions for better wording? If not, I'll probably commit tomorrow. Best regar

Re: [PATCH] Fortran: fix bogus dependency check in ALLOCATE statement [PR60560]

Hi Harald, The solution is to use the auxiliary parameter of gfc_traverse_expr to control whether to descend into character length or not. Regtested on x86_64-pc-linux-gnu.  OK for mainline? Looks good to me. Thanks for the patch! Best regards Thomas

[patch, Fortran] Fix PR 119669

Hello world, the attached patch fixes an ICE by setting the typespec of a dummy argument from a global function if known. plus setting the correct flag. This also removes the corresponding assert. I'm not quite sure that the code with the subroutine attribute can be reached, but I thought better

Re: [patch, Fortran] Fix PR 119669

Am 11.04.25 um 19:15 schrieb Harald Anlauf: There is a duplicate "and and" here: + gfc_error ("Mismatch between subroutine and and " +    "function at %L", &actual->where); OK with this fixed. Ah, yes :-) Thanks for the patch! Commit

Re: [patch, libgfortran] PR119502

Hi Jerry, The attached patch fixes this bug by adding checks for negative unit numbers in CLOSE and OPEN statements. Regression tested on x86_64_linux_gnu. OK for trunk OK. Thanks for the patch! Best regards Thomas

Re: [patch, Fortran] Fix PR 119928, rejects-valid 15/16 regression

Hi Harald, It appears that something is not right and generates wrong code with the check enabled.  Can you have another look? The problem was indeed that generating a formal from an actual arglist is a bad idea when classes are involved.  Fixed in the attached patch.  I think it still makes s

[patch, wwwdocs, committed] Fix option name in gcc15/changes.html

Hello world, I just committed the following patch after noticing that an option name was wrong in the gcc15/changes.html file. diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html index d851a744..b442b8d9 100644 --- a/htdocs/gcc-15/changes.html +++ b/htdocs/gcc-15/changes.html @@

[patch, Fortran] Fix PR 119928, rejects-valid 15/16 regression

Hello world, This patch fixes a case where too much was being checked with -Wexternal-arguments-mismatch with a procedure pointer with an unlimited polymorphic and an INTEGER argument which was inferred from an actual argument.I also found some checks which can trigger false positives, which this

Re: [patch, Fortran] Fix PR 119928, rejects-valid 15/16 regression

Hello Harald, % gfc-16 gcc/testsuite/gfortran.dg/proc_ptr_52.f90 -Wexternal-argument- mismatch && ./a.out STOP 1 It appears that something is not right and generates wrong code with the check enabled.  Can you have another look? I see that too, good catch! Seems like generating formal argu

Re: [patch, Fortran] Fix PR 119928, rejects-valid 15/16 regression

Hi Harald, It appears that something is not right and generates wrong code with the check enabled.  Can you have another look? The problem was indeed that generating a formal from an actual arglist is a bad idea when classes are involved. Fixed in the attached patch. I think it still makes s

Re: 7/7 [Fortran, Patch, Coarray, PR107635] Remove deprecated coarray routines

Am 18.02.25 um 16:00 schrieb Andre Vehreschild: Hi Thomas, This patch series (of necessity) introduces ABI changes. What will happen with user code compiled against the old interface? That depends on the library you are linking against. When using caf_single from gfortran, then you will get

[patch, Fortran] Fix PR 119049 and 119074, external prototypes with different arglists

Hello world, this patch is a bit more complicated than originally envisioned. The problem was that we were not handling external dummy arguments with -fc-prototypes-external. In looking at this, I found that we were not warning about external procedures with different argument lists. This can a

Re: [patch, Fortran] Fix PR 119157, regression with -Wexternal-argument-mismatch

Am 08.03.25 um 20:29 schrieb Steve Kargl: On Sat, Mar 08, 2025 at 01:52:06PM +0100, Thomas Koenig wrote: While looking at the code, I also saw that a member of gfc_symbol introduced with my patch should be a bitfield of width 1. OK for trunk? OK (assuming a successful regression test run

[patch, Fortran] Fix PR 119157, regression with -Wexternal-argument-mismatch

Hello world, the attached patch fixes an ICE regresseion where undo state was not handled properly when generating formal from actual arguments, which occurred under certain conditions with the newly introduced -Wexternal-argument-mismatch option. The fix is simple: When we are generating these

Re: [patch, Fortran] Fix PR 119157, regression with -Wexternal-argument-mismatch

homas commit 9f5b508bc5c16ae11ea385f6031487a518f62c8f (HEAD -> master) Author: Thomas Koenig Date: Sun Mar 9 19:35:06 2025 +0100 Use gfc_commit_symbol() to remove UNDO status instead of new function. This is a cleaner version, removing an unneeded function and making sure that n

Re: [patch, Fortran] Fix PR 119157, regression with -Wexternal-argument-mismatch

Hi Mikael, _symbol *asym = a->expr->symtree->n.sym; You may consider calling gfc_commit_symbol(s) instead at the end of the function body.  It might avoid leaking the old_symbol field in case the function is called more than once or the symbol is already existing (not completely clear wheth

Re: [patch, fortran] Fix PR 119078, putting a procedure in an abstract interface into global namespace

Am 10.03.25 um 22:34 schrieb Harald Anlauf: the patch looks basically fine but I cannot find the testcase. You're right, here it is. Best regards Thomas diff --git a/gcc/fortran/frontend-passes.cc b/gcc/fortran/frontend-passes.cc index 20bf6e127ff..ef9c80147cc 100644 --- a/gcc/fortra

[patch, fortran] Fix PR 119078, putting a procedure in an abstract interface into global namespace

Hello world, the attached patch makes sure that procedures from abstract interfaces and dummy arguments are not put into the global symbol table, and are not checked against global symbols. Regression-tested. OK for trunk? Best regards Thomas Abstract interfaces and dummy arguments ar

Fwd: [GSoC][Fortran – DO CONCURRENT] Interest in 2025 GSoC – Fortran DO CONCURRENT Auto-Parallelization

Dear Chenlu, Thank you for your interest! I have forwarded your e-mail to the gfortran mailing list, where discussion of gfortran takes place. Best regards Thomas Weitergeleitete Nachricht Betreff: [GSoC][Fortran – DO CONCURRENT] Interest in 2025 GSoC – Fortran DO

Re: [PATCH] Fortran: reject SAVE of a COMMON in a BLOCK construct [PR119199]

Hi Harald, Regtested on x86_64-pc-linux-gnu.  OK for mainline? Looks good to me. Thanks for the patch! Best regards Thomas

Re: [patch, fortran] Fix PR 119078, putting a procedure in an abstract interface into global namespace

Am 11.03.25 um 10:22 schrieb Andre Vehreschild: Hi Thomas, looks good to me as well. Thanks for the patch. Committed as r15-7964. Thanks Harald and Andre! Best regards Thomas

Re: [patch, Fortran] Fix PR 119049 and 119074, external prototypes with different arglists

Hi Andre, while the patch looks ok to me, why did you not choose to generate a "22.7.2 Variable-Length Parameter Lists" https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Variable-Number-of-Arguments.html when the arguments differ? Then its the callee responsibility to figure stuff

Re: Regression? Re: [patch, fortran] Fix PR 119078, putting a procedure in an abstract interface into global namespace

Hi Andre, FAIL: gfortran.dg/binding_label_tests_26b.f90 -O (test for errors, line 8) FAIL: gfortran.dg/binding_label_tests_26b.f90 -O (test for errors, line 9) When I revert your patch and test again, above fails do not occur. Could you please investigate, if I am right? Jep, I missed

Re: Regression? Re: [patch, fortran] Fix PR 119078, putting a procedure in an abstract interface into global namespace

Am 12.03.25 um 18:33 schrieb Thomas Koenig: The test case should stay, but I will remove the dg-error directives. Fix committed as obvious and simple as r15-8006 . Thanks for the heads-up! Best regards Thomas

Re: [patch, Fortran] Fix PR 118845

Hi Jerry, This is OK. Pushed as r15-7509. Thanks for the review! It would be good to get confirmation that the lapack builds now.  I use to be set up here to do that, but dont have it at the moment. It checked the original test case, that passed. But yes, a Lapack tester would be nice.

[patch, Fortran] Fix PR 118845

Hello world, this was an interesting regression. It came from my recent patch, where an assert was triggered because a procedure artificial dummy argument generated for a global symbol did not have the information if if was a function or a subroutine. Fixed by adding the information in gfc_get_

Re: [patch, Fortran] Fix PR 118862, overwide shft

Am 17.02.25 um 05:53 schrieb Steve Kargl: On Sun, Feb 16, 2025 at 09:36:20AM +0100, Thomas Koenig wrote: this patch is a variation of Jakub's patch in the PR, which avoids overflow on the mask used for exponentiation and fixes unsigned HOST_WIDE_INT. I tried testing this on a POWER ma

[patch, Fortran, doc, committed] PR 118159, defunct website

Hello world, I just committed Andrew's patch from the PR as obvious as r15-7557-gbf84e5e64662f8f0fdebfc0212e32bfca678f9eb . Best regards Thomas Remove defunct web site for site of Fortran preprocessor. gcc/fortran/ChangeLog: PR fortran/118159 * invoke.

Re: [Fortran, Patch, PR118789, v1] Fix associate to void*

Hi Andre, Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Looks good to me. Thanks for the patch! Best regards Thomas

Re: [PATCH] fortran: Fix debug info for unsigned(kind=1) and unsigned(kind=4) [PR120193]

Hi Jakub, The following patch uses a variant of the character(kind=4) type for unsigned(kind=4) and a distinct type based on character(kind=1) type for unsigned(kind=1). The reason for the latter is that unsigned_char_type_node has TYPE_STRING_FLAG set on it, so it has DW_AT_encoding DW_ATE_uns

Re: [PATCH] libfortran: Readd 15 accidentally removed libgfortran symbols [PR120152]

Hi Jakub, The r15-4124-gc0002a675a92e76d change seems to have accidentally dropped 5 sourcefiles from i_maxloc1_c, which resulted in dropping 15 GFORTRAN_8 symbols on x86_64 and 6 on i686. The following patch adds it back, so that we export those symbols again, fixing the ABI problem. Bootstra

Re: [PATCH] libfortran: Add 5 missing UNSIGNED symbols [PR120153]

Hi Jakub, While looking at PR120152, I have noticed that libgfortran.so doesn't export 5 *m16* symbols I would have expected that should be exported. This is caused by 2 issues, one filename was forgotten to be added in r15-4124 to i_maxloc1_c (guess because generated/maxloc1_16_i16.c was kept i

Re: [PATCH] libfortran: Fix up maxval/maxloc for UNSIGNED [PR120158]

Hi Jakub, Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk and 15.2? OK. Thanks for catching and fixing this! Best regards Thomas König

Re: [parch, fortran] Fix PR 120163, 15/16 regression

Am 10.05.25 um 20:32 schrieb Harald Anlauf: Hi Thomas! Am 10.05.25 um 11:42 schrieb Thomas Koenig: This bug was another case of generating a formal arglist from an actual one where we should not have done so.  The fix is straightforward:  If we have resolved the formal arglist, we should not

Re: Testing for prototypes generated from Fortran

Hi Harald, Hi Thomas, On 5/11/25 10:34, Thomas Koenig via Gcc wrote: As PR120139 has shown (again), it is too easy to create regressions for dumping C prototypes from Fortran.  The main problem is that there is currently no test in the testsuite. for something along this variant you can

Re: [PATCH, fortran] Fix simple typo in libgfortran

Hi Yuao, first, good to have you on board! As I am relatively new to submitting patches via mailing lists, I would like to send a very simple patch primarily to familiarize myself with the correct procedure. I have reviewed the contribution guidelines on the GCC website and have tried to fol

[parch, fortran] Fix PR 120163, 15/16 regression

This bug was another case of generating a formal arglist from an actual one where we should not have done so. The fix is straightforward: If we have resolved the formal arglist, we should not generare a new one. OK for trunk and backport to gcc 15? Best regards Thomas Do not genera

Testing for prototypes generated from Fortran

As PR120139 has shown (again), it is too easy to create regressions for dumping C prototypes from Fortran. The main problem is that there is currently no test in the testsuite. So, what to do? I see several possibilities: 1a) Change the relevant options so that they optionally create a file (s

[patch, Fortran] Fix 15/16 regression when non-interoperable types were dumped

Hello world, the attached patch fixes a 15/16 regression and should be fairly self-explanatory. Regarding testing: I'm not sure I am up to the task of hacking dejagnu to do this. I am now running local tests, which is better than nothing (I guess). Regression-testing: Passed, though this does n

[patch, Fortran] Fix PR 120139, missing asterisk on prototype with -fc-prototypes

Hello world, this fixes the other regression which crept in with gfortran. Again, regression-tested, plus the local testing script is attached. Ok for trunk and gcc-15? Best regards Thomas Fix explicit arrays with non-constant size for -fc-prototypes. gcc/fortran/ChangeLog:

Re: [patch, Fortran] Fix PR 120139, missing asterisk on prototype with -fc-prototypes

Hi Paul, Same remark as for PR120107! LGTM for both branches. Committed both patches. Thanks for the reviews! Best regards Thomas

Re: [patch] Fix PR libfortran/95177, ctype.h functions should not be called with char arguments

On 17.12.21 00:34, FX via Fortran wrote: unrelated PS: I’ve been thinking aloud and benchmarking faster integer I/O for libgfortran at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98076 Comments are welcome on the proposed design, I think the current proposal is a low-hanging fruit (not risky,

Re: [patch] Fix libfortran/98507, handling of timezone near year boundaries

Hi FX, DATE_AND_TIME can return incorrect values for non-UTC timezones, near the new year, when the local time and UTC time are in different years. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98507 Attached patch fixes the issue by correcting the logic to account for that wrapping of “day

Re: [patch, Fortran] Make REAL(KIND=16) detection more robust

Hi FX, I am not sure the logic is correct for POWER (old style) where we have a 16-byte long double made up from two 8-byte doubles, which is not __float128 (IFmode), see https://gcc.gnu.org/pipermail/fortran/2021-November/056912.html I have a proposal: Since I am currently trying to unravel th

Re: [patch, Fortran] IEEE support for aarch64-apple-darwin

Hi FX, Since support for target aarch64-apple-darwin has been submitted for review, it’s time to submit the Fortran part, i.e. enabling IEEE support on that target. The patch has been in use now for several months, in a developer branch shipped by some distros on macOS (including Homebrew).

Re: [patch, Fortran] Make REAL(KIND=16) detection more robust

Hi FX, I’m not opposed, but I’d really like to get this into the current branch. It is a much less invasive change than the power-ieee128 work. The only case I changed is the case where there is a kind 16, and there is a long double, but the long double is neither kind 10 neither kind 16. I

Re: [PATCH] Simplify integer output-related functions in libgfortran

First merry Christmas to all! Bootstrapped and regtested on x86_64-pc-linux-gnu. OK to commit? OK. Thanks for the (preliminary) patch!

Re: [PATCH] Make integer output faster in libgfortran

Hi FX, The patch has been bootstrapped and regtested on two 64-bit targets: aarch64-apple-darwin21 (development branch) and x86_64-pc-gnu-linux. I would like it to be tested on a 32-bit target without 128-bit integer type. Does someone have access to that? There are two possibilities: Eithe

Re: [PATCH] Make integer output faster in libgfortran

Hi fX, right now I don’t have a Linux system with 32-bit support. I’ll see how I can connect to gcc45, but if someone who is already set up to do can fire a quick regtest, that would be great;) I tested this on x86_64-pc-linux-gnu with make -k -j8 check-fortran RUNTESTFLAGS="--target_board=

Re: [PATCH] Make integer output faster in libgfortran

Hi FX, (We could also do something like that for a 32-bit system, but that is another kettle of fish). We probably wouldn’t get a speed-up that big. Even on 32-bit targets (at least common ones), the 64-bit type and its operations (notably division) are implemented via CPU instructions, not l

Re: [power-ieee128] libgfortran: Small progress on the library side

Hi Jakub, Ok for power-ieee128 branch? OK. Thanks for stepping up! I am a little distracted right now, but I think I will also continue working on this for a bit. Best regards Thomas

Re: [power-ieee128] gfortran, v2: Introduce gfc_type_abi_kind

Hi Jakub, Actually playing with that (e.g. for matmul) revealed a brown paper bag bug in the previous patch, fixed thusly: OK. Thanks a lot! Best regards Thomas

[power-iee128] How to specify linker flags

Hi Michael, If you are building libraries that contain modules with multiple long double types, you must use the '-mno-gnu-attribute'. We also use the '-Wno-psabi' option, which silences the warning that you are switching long double types (if glibc is not 2.34 or newer). We may need to tweak

Re: [power-iee128] How to specify linker flags

On 02.01.22 23:58, Thomas Koenig wrote: Hi Michael, If you are building libraries that contain modules with multiple long double types, you must use the '-mno-gnu-attribute'.  We also use the '-Wno-psabi' option, which silences the warning that you are switching long dou

[patch, power-ieee128, committed] Make the library functions compile correctly

Hello world, the attached patch lets the library compile correctly, as far as I have been able to determine. Committed to the branch. Best regards Thomas Make sure the Fortran specifics have real(kind=16). This brings the library to compile with all specific functions. It also correc

Re: [power-iee128] libgfortran: Use -mno-gnu-attribute in libgfortran

Hi Jakub, On Mon, Jan 03, 2022 at 11:33:32AM +0100, Jakub Jelinek wrote: The idea behind this is that libstdc++ is written such that it can handle both IBM extended and IEEE quad long double, so its object files are compatible with both. Now tested on powerpc64le-linux (and together with the

Re: [power-ieee128] libquadmath: Use -mno-gnu-attribute in libquadmath

On 03.01.22 16:24, Jakub Jelinek via Fortran wrote: Ok for power-ieee128? OK. Thanks! Best regards Thomas

Re: [power-ieee128] libgfortran: -mabi=ieeelongdouble I/O

Hi Jakub, So, either we'd need to add e.g. preprocessing support for gfortran.map or some other way how to make certain symbols appear conditionally at different symbol versions, or another option would be to choose different symbol names for those for the powerpc64le-linux cases (e.g._gfortra

Re: [power-ieee128] libgfortran: -mabi=ieeelongdouble I/O

On 03.01.22 17:26, Jakub Jelinek wrote: so we could similarly have something like: #if !(defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ && __SIZEOF_LONG_DOUBLE__ == 16) _gfortran_transfer_complex128; _gfortran_transfer_complex128_write; #endif ... #if !(defined(

Re: [power-ieee128] libgfortran, fortran: -mabi=ieeelongdouble I/O

Hi Jakub, clearly there is still work to fix (but seems e.g. most of the lto tests are related to the gnu attributes stuff:( ). This is looking better than what I expected. Apart from LTO, I expect that a couple of files still do not have the correct flags set when compiling, or maybe some t

Re: [power-ieee128] libgfortran: -mabi=ieeelongdouble I/O fix

On 04.01.22 14:41, Jakub Jelinek via Fortran wrote: Ok for power-ieee128? OK.

Re: [power-ieee128] fortran, libgfortran: Assorted -mabi=ieeelongdouble I/O fixes

On 04.01.22 15:23, Jakub Jelinek via Fortran wrote: Ok for power-ieee128? Also OK. Best regards Thomas

Re: [power-ieee128] fortran, libgfortran: Add remaining missing *_r17 symbols

Hi Jakub, Following patch adds remaining missing *_r17 entrypoints, so that we have 91 *_r16 and 91 *_r17 entrypoints (and 24 *_c16 and 24 *_c17). This fixes: FAIL: gfortran.dg/dec_math.f90 -O0 execution test FAIL: gfortran.dg/dec_math.f90 -O1 execution test FAIL: gfortran.dg/dec_math.f90

Re: [power-ieee128] fortran, libgfortran: Assorted -mabi=ieeelongdouble I/O fixes

Hi Jakub, This test FAILs because f951: Error: '-mabi=ieeelongdouble' requires full ISA 2.06 support compiler exited with status 1 FAIL: gfortran.dg/pr47614.f -O0 (test for excess errors) As powerpc64le* only supports -mcpu=power8 and newer, I think we shouldn't be testing with that option.

Re: [power-ieee128] RFH: LTO broken

On 06.01.22 06:00, Michael Meissner via Fortran wrote: I pushed the patch to the branch. Test results are looking quite good right now. What is still missing is the conversion for unformatted I/O, both ways. I'll start doing some stuff on it. Just one question: What are functions that I can

Re: [power-ieee128] OPEN CONV

On 07.01.22 10:22, Jakub Jelinek wrote: On Thu, Jan 06, 2022 at 09:01:54PM +0100, Thomas Koenig wrote: On 06.01.22 06:00, Michael Meissner via Fortran wrote: What is still missing is the conversion for unformatted I/O, both ways. I'll start doing some stuff on it. Just one question:

Re: [power-ieee128] RFH: LTO broken

Hi Jakub, 00251038 06ad0015 R_PPC64_JMP_SLOT __cabsieee128 + 0 All these should for POWER_IEEE128 use atan2q@QUADMATH_1.0 etc. So, seems all these come from f951 compiled sources. For user code, I think the agreement was if you want to use successfull

Re: [power-ieee128] RFH: LTO broken

Hi Jakub, So, the following patch adds -fbuilding-libgfortran option and uses it together with TARGET_GLIBC_M* checks to decide whether to use libquadmath APIs (for the IEEE quad kind=16 if -fbuilding-libgfortran and not glibc or glibc is older than 2.32) or glibc 2.32 APIs (otherwise). This

<    1   2   3   4   >