Re: [Patch] Fortran: Create fresh ts.u.cl for result in gfc_get_symbol_for_expr [PR118441]

2025-01-15 Thread Andre Vehreschild
Hi Tobias, the patch looks reasonable to me. I wouldn't know where to get the "correct" charlen either. In fact I have the same problem at the moment with an array spec. Anyway, one small question: Your testcase does not have a dg-do line. Is this intentional? Thanks for the patch, Andre

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

2025-01-15 Thread Jerry D
On 1/15/25 1:13 PM, Thomas Koenig wrote: 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

[Patch] Fortran: Create fresh ts.u.cl for result in gfc_get_symbol_for_expr [PR118441]

2025-01-15 Thread Tobias Burnus
As shown in the PR, updating the function declaration for _gfortran_pack_char could leak into the character typespec back-end declaration to the the caller by setting the backend declaration of the caller. The problem is that that function returns a character string and in trans-intrinsic.cc, we

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

2025-01-15 Thread Thomas Koenig
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, This patch

[PATCH, committed] Fortran: reject NULL as source-expr in ALLOCATE with SOURCE= or MOLD= [PR71884]

2025-01-15 Thread Harald Anlauf
Dear all, I've committed the attached obvious patch to reject an invalid NULL in ALLOCATE after it was OK'ed in the PR by Steve. Regtested on x86_64-pc-linux-gnu. Pushed as r15-6925-g892304f1fe . Thanks, Harald From 892304f1fe3e808b9f498353c144f1ae0591 Mon Sep 17 00:00:00 2001 From: H