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
>>> +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
>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.
>>
>>>
Hi all,
I finally managed to apply the fixed patch. It still had some stray line break
so check_GNU_style.py wouldn't succeed. But with that fixed I agree to have
only some nonsense bickering of the script.
As to the patch (I have stripped large parts.):
> diff --git a/gcc/fortran/gfortran.h b/g
Hi all and esp. Paul,
the attached patch fixes an ICE with coarrays defined in modules and then used
in submodules. Referencing the variable relied on the curr_module being set in
the gfc_build_qualified_array routine, which it was not. I therefore took the
name from the symbol. I don't know if th
On 9/24/24 5:46 PM, Hans-Peter Nilsson wrote:
Thanks for the review!
Date: Tue, 24 Sep 2024 17:10:27 -0700
Cc: Jerry D
From: Jerry D
On 9/23/24 11:21 PM, Hans-Peter Nilsson wrote:
I hope the inclusion of gfortran-dg.exp in
fortran-torture.exp is not controversial, but there's no
fortran-spec
On 27/12/22 08:33 -0800, H.J. Lu wrote:
On Sun, Dec 25, 2022 at 4:58 PM Steve Kargl via Gcc-patches
wrote:
On Wed, Dec 21, 2022 at 07:27:11PM -0500, Lipeng Zhu via Fortran wrote:
> This patch try to introduce the rwlock and split the read/write to
> unit_root tree and unit_cache with rwlock in
This fixes PR fortran/116829 by making sure that s->value is always
applied to non-allocatable BT_DERIVED intent(out) arguments, no matter
if they are finalizable or not.
Tested on x86_64-pc-linux-gnu (Fedora 40), any feedback is welcome.
gcc/fortran/ChangeLog:
* trans-decl.cc (init_inte
> Date: Wed, 25 Sep 2024 13:51:07 +0200
> From: Andre Vehreschild
> Hi Hans-Peter,
>
> preface: I am not a testsuite nor an m4 expert.
Neither am I. Luckily, this has nothing to do with m4, and
not really that much to do with tcl or dejagnu either, being
just basic code, no language-specific t
I forgot to point out that while having my revenge on the
PR116701, I incidentally discovery that
gfortran.fortran-torture contains tests with dg-directives.
Those are ignored. From "git grep dg-":
compile/pr66352.f90:! { dg-additional-options "-fprofile-generate" }
compile/pr85863.f:! { dg-do co
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 wait for one other ok from some one who has more experience in
the gfort
Hi
now committed the following as r15-3856-gfcff9c3dad4f35 with two
testcase additions (and improved changelog wording).
Tobias Burnus wrote:
OpenMP mandates that when certain clauses are used with 'omp requires'
that in all compilation units this requires clause appears.
Those clauses infl
Le 23/09/2024 à 20:43, Arsen Arsenović a écrit :
Andreas Schwab writes:
It's only about the @opindex. The vast majority have those variable
parts removed from the index entry.
We can probably do both at the same time, either via makeinfos -D option
and some special macro, or by emitting a m
Le 23/09/2024 à 20:37, Andreas Schwab a écrit :
On Sep 23 2024, Mikael Morin wrote:
For options where the variable is not a separate argument, I think it's
preferable to keep the variable.
For example, -ffree-line-length-@var{n} looks better on the index page as
"-ffree-line-length-n" (with th
14 matches
Mail list logo
