Re: [PATCH] Fortran/OpenMP: event handle in task detach cannot be a coarray [PR104131]

On 24 October 2023 21:25:01 CEST, Harald Anlauf wrote: >Dear all, > >the attached simple patch adds a forgotten check that an event handle >cannot be a coarray. This case appears to have been overlooked in the >original fix for this PR. > >I intend to commit as obvious within 24h unless there are

Re: [PATCH] Fortran: use name of array component in runtime error message [PR30802]

On 28 January 2024 22:43:37 CET, Steve Kargl wrote: >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 g

Re: [PATCH] Fortran: Mark internal symbols as artificial [PR88009,PR68800]

On 29 January 2024 22:06:04 CET, Harald Anlauf wrote: >Am 29.01.24 um 21:45 schrieb Bernhard Reutner-Fischer: >> On Wed, 17 Nov 2021 21:32:14 +0100 >> Harald Anlauf wrote: >> >>> Do you have testcases/reproducers demonstrating that the patch actually >>> fixes the issues you're describing? >> >

Re: [PATCH, v2] Fix fortran/PR114024

On 23 February 2024 22:15:17 CET, 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? LGTM cheers > >Cheers, >Harald

Re: [patch, libgfortran] Part 2: PR105456 Child I/O does not propage iostat

On 29 February 2024 23:28:44 CET, Jerry D wrote: >On 2/29/24 12:56 PM, Steve Kargl wrote: >> On Thu, Feb 29, 2024 at 10:28:19AM -0800, Jerry D wrote: >>> On 2/29/24 10:13 AM, Steve Kargl wrote: On Thu, Feb 29, 2024 at 09:36:43AM -0800, Jerry D wrote: > On 2/29/24 1:47 AM, Bernhard Reutner

Re: [patch, libgfortran] Part 2: PR105456 Child I/O does not propage iostat

On 5 March 2024 04:15:12 CET, Jerry D wrote: > >Attached is the revised patch using the already available string_len_trim >function. > >This hunk is only executed if a user has not passed an iostat or iomsg >variable in the parent I/O statement and an error is triggered which >terminates execu

Re: Can't link assembly routines

On 13 March 2024 19:43:27 CET, Steve Kargl wrote: >On Wed, Mar 13, 2024 at 12:05:16PM +, Ken Woolridge wrote: >> >> When I attempt to link my test program (FF.F90) which calls UPPER_CASE (an >> assembly routine) I get the following error: >> >> C:/Program >> Files/GCC/bin/../lib/gcc/i686-

Re: Mattermost discussion on PR98426

On 27 April 2024 16:11:32 CEST, Jerry D wrote: > >I found these (and several more) patches dated around 2018. > >https://gcc.gnu.org/git/?p=gcc-old.git;a=commitdiff;h=d38e734485cc84ed0eda7f30b16fb62bdb0cb174 IOPARM_type_char2 stands out. I do not remember why, but it looks odd that I had to not

Re: Mattermost discussion on PR98426

On 27 April 2024 22:02:21 CEST, rep.dot@gmail.com wrote: >On 27 April 2024 16:11:32 CEST, Jerry D wrote: > >> >>I found these (and several more) patches dated around 2018. >> >>https://gcc.gnu.org/git/?p=gcc-old.git;a=commitdiff;h=d38e734485cc84ed0eda7f30b16fb62bdb0cb174 > >IOPARM_type_char2 s

Re: [Patch] Fortran: invoke.texi - link to OpenCoarrays.org + mention libcaf_single

On 20 May 2024 02:31:27 CEST, Sandra Loosemore wrote: >On 5/19/24 02:01, Tobias Burnus wrote: >> I noticed that gfortran's coarray support did not link to the >> http://www.opencoarrays.org/ > >> [snip] >> >> diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi >> index 40e8e4a7cdd..78

Re: [PATCH] fortran: Support optional dummy as BACK argument of MINLOC/MAXLOC.

On 22 July 2024 20:53:18 CEST, Mikael Morin wrote: >From: Mikael Morin > >Hello, > >this fixes a null pointer dereference with absent optional dummy passed >as BACK argument of MINLOC/MAXLOC. > >Tested for regression on x86_64-linux. >OK for master? > >-- >8 -- > >Protect the evaluation of BACK w

Re: [PATCH] fortran: Support optional dummy as BACK argument of MINLOC/MAXLOC.

On 27 July 2024 21:11:19 CEST, Mikael Morin wrote: >Le 27/07/2024 à 19:23, rep.dot@gmail.com a écrit : >> On 22 July 2024 20:53:18 CEST, Mikael Morin wrote: >>> From: Mikael Morin >>> >>> Hello, >>> >>> this fixes a null pointer dereference with absent optional dummy passed >>> as BACK arg

Re: [Patch] Fortran: Use OpenACC's acc_on_device builtin, fix OpenMP' __builtin_is_initial_device (was: [Patch]

On 12 October 2024 18:31:41 CEST, Tobias Burnus wrote: >Anyone feeling like reviewing this patch? (Mainly the Fortran side?!?) — Or >should I declare it as OpenMP/(OpenACC) patch and just commit it? > >→ just skimmed briefly again, lgtm >>> Code review, comments, suggestions, remarks? thank

Re: [Patch] Fortran: Use OpenACC's acc_on_device builtin, fix OpenMP' __builtin_is_initial_device (was: [Patch]

Code review, comments, suggestions, remarks? > +static tree +get_builtin_fn (gfc_symbol * sym) +{ + if (!gfc_option.disable_omp_is_initial_device + && flag_openmp && sym->attr.function && sym->ts.type == BT_LOGICAL + && !strcmp (sym->name, "omp_is_initial_device")) +return bu

Re: [Patch] Fortran: Dead-function removal in error.cc (shrinking by 40%)

On 11 October 2024 16:42:44 CEST, David Malcolm wrote: >On Fri, 2024-10-11 at 15:34 +0100, Paul Richard Thomas wrote: >> Hi Tobias, >> >> Good catch! It looks 'obvious' to me too :-) yeah, thanks for the explicit cleanup >> > * I want to move support range-based locations, which is also a >>

Re: Fortran test typebound_operator_7.f03 broken by non-Fortran commit. Confirm anyone?

On 14 October 2024 14:05:36 CEST, Andre Vehreschild wrote: >Hi all, > >please note, that I don't know this bisecting very well, so this may very well >be a wrong blame. During latest regression testing of the Fortran suite I got >typebound_operator_7.f03 failing with: > > >03623fa91ff36ecb9faa3b5

Re: [Patch] Fortran: Use OpenACC's acc_on_device builtin, fix OpenMP' __builtin_is_initial_device

On 14 October 2024 10:23:56 CEST, Thomas Schwinge wrote: >Hi Tobias! > >On 2024-10-13T10:21:01+0200, Tobias Burnus wrote: >> Now pushed as r15-4298-g3269a722b7a036. > >> Tobias Burnus wrote: >>> Anyone feeling like reviewing this patch? > >Yes. But please allow for more than 1 1/2 work days. >

Re: [PATCH v2] gfortran testsuite: Remove unit-files in files having open-statements, PR116701

On 25 September 2024 13:51:07 CEST, Andre Vehreschild wrote: >Hi Hans-Peter, > >preface: I am not a testsuite nor an m4 expert. > >So I may be wrong in arguing that your changes look reasonable. I like the >"automatic" clean-up process very much. So by me, ok for mainline. But you may >want to wai

Re: [PATCH v2] gfortran testsuite: Remove unit-files in files having open-statements, PR116701

>>> +proc fortran-delete-unit-files { src } { >>> + # verbose -log "Found \"$openmatches\"" there's a numeric level. I'd probably put it in 4 (or drop it; IIRC modules cleanup may print'em at 4 or somesuch. Or maybe I also left them commented out, don't know offhand) just as a sidenote, as

Re: [PATCH] gfortran testsuite: Remove unit-files in files having open-statements, PR116701

>Your interpretation of my typo is correct. Along with Andre I like auto >cleanup. On new test cases we try to have them self delete whether they pass >or fail. > so why don't we issue the cleanup then, regardless? >So your changes are ok with me. > >> No. >> >>>

Re: [PATCH] gfortran testsuite: Remove unit-files in files having open-statements, PR116701

On 25 September 2024 22:08:15 CEST, rep.dot@gmail.com wrote: > >>Your interpretation of my typo is correct. Along with Andre I like auto >>cleanup. On new test cases we try to have them self delete whether they pass >>or fail. >> > >so why don't we issue the cleanup then, regardless?

Re: Fwd: [patch, fortran] Matmul and dot_product for unsigned

. > >I have also committed, right now, a fix for the failure of >unsigned_25.f90 on 32-bit systems as obvious. could we maybe walk all sizes, if they fit, according to the preprocessor? > >Best regards >

Re: [PATCH] Fortran: fix front-end GMP memleaks

On 22 December 2024 21:50:41 CET, Harald Anlauf wrote: >Dear all, > >please find attached fixes for GMP memleaks in the gfortran frontend >found when running f951 under valgrind. One of them surfaced when >looking at a testcases that invoved pointer rank remapping. After a >successful gfc_array_