Re: How to debug the forest?

On Tue, Sep 16, 2025 at 10:56 PM Harald Anlauf wrote: > > Hi Mikael, > > > Le 16/09/2025 à 21:07, Harald Anlauf a écrit : > > > Hi All, > > > > > > when trying to debug the gfortran frontend, I often get lost in the > > > forest: too much forest, trees everywhere, leaves, ... > > > > > > OK, serio

Aw: Re: How to debug the forest?

Hi Iain, > > +/* Helper function for looking at TREE_TYPE (node). */ > > +DEBUG_FUNCTION void > > +debug_tree_type (tree node) > > +{ > > + debug_tree (TREE_TYPE (node)); > > +} > > > > This way I can do: > > > > (gdb) call debug_tree_type(tree) > > > > and get more concise output. But the c

Re: [patch, Fortran] Implement -fexternal-blas64, PR 121161

On Tue, Sep 16, 2025 at 10:10:16PM +0200, Thomas Koenig wrote: > Hello world, > > the attached patch implements a new option, -fexternal-blas64, > so people can use 64-bit libraries for external BLAS, like Intel > MKL. > > Regression-tested. OK for trunk? > Thanks. I've read through the patch,

How to debug the forest?

Hi All, when trying to debug the gfortran frontend, I often get lost in the forest: too much forest, trees everywhere, leaves, ... OK, seriously, what is an efficient way to debug under e.g. gdb, when there is code that uses macros on trees, like TREE_TYPE () etc., without losing your sanity? I

Re: How to debug the forest?

Hi Mikael, > Le 16/09/2025 à 21:07, Harald Anlauf a écrit : > > Hi All, > > > > when trying to debug the gfortran frontend, I often get lost in the > > forest: too much forest, trees everywhere, leaves, ... > > > > OK, seriously, what is an efficient way to debug under e.g. gdb, > > when there i

[patch, Fortran] Implement -fexternal-blas64, PR 121161

Hello world, the attached patch implements a new option, -fexternal-blas64, so people can use 64-bit libraries for external BLAS, like Intel MKL. Regression-tested. OK for trunk? Best regards Thomas Implement -fexternal-blas64 option. Libraries like Intel MKL use 64-bit integers in

Re: How to debug the forest?

> On 16 Sep 2025, at 20:07, Harald Anlauf wrote: > > Hi All, > > when trying to debug the gfortran frontend, I often get lost in the > forest: too much forest, trees everywhere, leaves, ... > > OK, seriously, what is an efficient way to debug under e.g. gdb, > when there is code that uses ma

Re: Regenerating *.opt.urls doesn't do anything

Am 15.09.25 um 20:56 schrieb Arsen Arsenović via Gcc: Thomas Koenig via Gcc writes: Hi, I am currently working on a patch which adds an option, and failing in regenerating the gcc/fortran/lang.opt.urls file. I tried make -C gcc html fortran.html d.html make -C gcc regenerate-opt-urls as ad

[Patch] libgomp: Add Fortran version of acc_copyout_finalize_async and acc_delete_finalize_async

I stumbled over the following: GCC misses* two OpenACC 2.5 functions in Fortran but not in C; actually, when looking deeper at it, .texi and .map already contain everything, just the actual implementation (in openacc.f90) and the interface (in openacc.f90 and in openacc_lib.h) were missing. The a

Re: [PATCH] fortran: allow character in conditional expression

Hi Yuao, Tobias Burnus wrote: For BT_DERIVED: (i) The type needs to be the same – or compatible ('SEQUENCE' attribute) I was referring to: "7.5.2.4 Determination of derived types": "Data entities also have the same type if they are declared with reference to different derived-type definition