On Fri, Dec 13, 2024 at 03:09:57PM -0800, Steve Kargl wrote:
> On Fri, Dec 13, 2024 at 10:54:03PM +0100, Mikael Morin wrote:
> > Le 13/12/2024 à 21:55, Steve Kargl a écrit :
> > > On Mon, Dec 09, 2024 at 06:39:19PM -0800, Steve Kargl wrote:
> > > >
> > > > I've an almost complete implementation of
On Fri, Dec 13, 2024 at 10:54:03PM +0100, Mikael Morin wrote:
> Le 13/12/2024 à 21:55, Steve Kargl a écrit :
> > On Mon, Dec 09, 2024 at 06:39:19PM -0800, Steve Kargl wrote:
> > >
> > > I've an almost complete implementation of F_C_STRING,
> > > but need a bit of insight on the inlining that I'm
>
Le 13/12/2024 à 21:55, Steve Kargl a écrit :
On Mon, Dec 09, 2024 at 06:39:19PM -0800, Steve Kargl wrote:
I've an almost complete implementation of F_C_STRING,
but need a bit of insight on the inlining that I'm
trying to implement. In pseudo-code, F_C_STRING is
case 1. f_c_string(string)
On Mon, Dec 09, 2024 at 06:39:19PM -0800, Steve Kargl wrote:
>
> I've an almost complete implementation of F_C_STRING,
> but need a bit of insight on the inlining that I'm
> trying to implement. In pseudo-code, F_C_STRING is
>
> case 1. f_c_string(string) = trim(string) // c_null_
Hi Andre,
while the patch works with the reduced testcase, it runs into the
newly added gcc_assert() when trying the original testcase in the PR.
I also wonder if this use of gcc_assert() is a good idea or good style:
+ gcc_assert (gfc_resolve_expr (tgt_expr));
Since gcc_assert is a macro
Hi all,
attached patch fixes deep-copying (or rather its former absence) for
allocatable components of derived types having cyclic dependencies.
Regtested ok on x86_64-pc-linux-gnu / F41. Ok for mainline?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
From 4721060d14920
Hi all,
attached patch fixes an reject-valid of an array constructor in an associate by
resolving the array constructor before parsing the associate-block. I am not
100% sure, if that is the right place to do this. But given, that there is
already a special casing before the patch, I just propose
