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

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

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 not. It is eas

Re: [Fortran, Patch, PR107143, v1] Fix gimplification error in forall' pointer remapping

Hi Harald and Jerry, thanks for taking the time to read my false assumptions ;-) The assumption that v1%n(n:m, m:n) => v2%n(m:n, n:m) is valid in a pointer remapping is wrong. (F2018 §10.2.2.3 paragraph 9). The rhs is neither simply contiguous nor of rank one and therefore rejected. I spent some

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

Dear all, the attached patch fixes a bogus error due to a cyclic dependency that is found because gfc_traverse_expr also descends into the length type of character variables. If the length is determined by the variable declaration (e.g. assumed-length), it is pre-determined and cannot be relevan

Fwd: GCC GSoC 2025: Call for project ideas and mentors

Chenlu, You appear to be quite knowledgeable. It would be great to have you do this. I am forwarding additional information. Our most knowledgeable person in the DO_CONCURRENT area is probably Tobias (copied on this email). I certainly cannot speak for Tobias. I do think the gfortran team cou

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

Hi Thomas, Thomas Koenig wrote: 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, 'de

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

I wonder why sometimes my line breaks are preserved and at other times all eaten. Next try ... Tobias Burnus wrote: Hi Thomas, Thomas Koenig wrote: Just one question - as this will change the module file, will we still be compatible with reading gfortran 8 to gfortran 14-written module file

[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