RE: Lower zeroing array assignment to memset for allocatable arrays
> -Original Message- > From: Harald Anlauf > Sent: Tuesday, July 16, 2024 12:06 AM > To: Prathamesh Kulkarni ; gcc- > patc...@gcc.gnu.org; fortran@gcc.gnu.org > Subject: Re: Lower zeroing array assignment to memset for allocatable > arrays > > External email: Use caution opening links or attachments > > > Hi Prathamesh! > > Am 15.07.24 um 15:07 schrieb Prathamesh Kulkarni: > >> -Original Message- > >> From: Harald Anlauf > >> I agree that it is reasonable to defer the handling of arrays as > >> components of derived types, and recommend to do the following: > >> > >> - replace "&& gfc_is_simply_contiguous (expr, true, false))" in > your > >> last patch by "&& gfc_is_simply_contiguous (expr, false, > false))", > >> as that would also allow to treat > >> > >> z(:,::1,:) = 0 > >> > >> as contiguous if z is allocatable or a contiguous pointer. > >> > >> - open a PR in bugzilla to track the missed-optimization for > >> the cases we discussed here, and link the discussion in the ML. > > Done: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115935 > >> > >> Your patch then will be OK for mainline. > > Thanks, does the attached version look OK ? > > Bootstrapped+tested on aarch64-linux-gnu, x86_64-linux-gnu. > > This is now OK. > > Thanks for the patch! Thanks, committed to trunk in: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=616627245fb06106f7c5bc4a36784acc8ec166f0 Thanks, Prathamesh > > Harald > > > Thanks, > > Prathamesh >
Re: [Patch, fortran] PR84868 - [11/12/13/14/15 Regression] ICE in gfc_conv_descriptor_offset, at fortran/trans-array.c:208
Hi Harald, Pushed as r15-2072. I will wait a few days before backporting but I would be surprised if there are any problems simply because the bug prevented the code patch from doing anything than ICE. In answer to some of your latest points: > > >> Can we prevent the export of this artificial symbol? > The export of this symbol is needed for interface mapping. Without it, the original bug would reappear. If such len_trim calls are made outside of specification expressions, the symbols are not exported as you verify with either the parse tree dump or direct inspection of the module files from the testcases. > > + char name[2*GFC_MAX_SYMBOL_LEN + 10]; > ^^ this has to be 12 now > > Good spot - thanks for this and all the other help on getting the patch right. Regards Paul
Re: [Patch, fortran] PR84868 - [11/12/13/14/15 Regression] ICE in gfc_conv_descriptor_offset, at fortran/trans-array.c:208
Hi Paul, Am 16.07.24 um 18:35 schrieb Paul Richard Thomas: In answer to some of your latest points: Can we prevent the export of this artificial symbol? The export of this symbol is needed for interface mapping. Without it, the original bug would reappear. If such len_trim calls are made outside of specification expressions, the symbols are not exported as you verify with either the parse tree dump or direct inspection of the module files from the testcases. I was under the impression that an interface that is not visible at the top level of the module does not need to be exported. And a contained procedure would satisfy that, or doesn't it? The ICE I saw is actually a pre-existing issue reported by Gerhard: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100273 Cheers, Harald
