Re: [Patch, Fortran] Bug 109105 - Error-prone format string building in resolve.cc

On 8/6/24 1:31 PM, Harald Anlauf wrote: Hi Jerry, this is OK for mainline. I have no reservations against a backport after a waiting period. If Roland is fine with it and nobody else objects, 14-branch might be ok. Thanks for the patch! Harald Thankd for the review! Pushed Jerry

Re: [PATCH 0/8] fortran: Inline MINLOC/MAXLOC without DIM argument [PR90608]

Hi Mikael and Harald, - inline expansion is inhibited at -Os.  But wouldn't it be good if   we make this expansion also dependent on -ffrontend-optimize?   (This was the case for rank-1 before your patch). The original idea was to have -ffrontend-optimize as a check if anything went wrong wi

Re: [Patch, Fortran] Bug 109105 - Error-prone format string building in resolve.cc

Hi Jerry, this is OK for mainline. I have no reservations against a backport after a waiting period. If Roland is fine with it and nobody else objects, 14-branch might be ok. Thanks for the patch! Harald Am 06.08.24 um 21:52 schrieb Jerry D: Hi all, The attached patch changes all the snprin

Re: [PATCH 0/8] fortran: Inline MINLOC/MAXLOC without DIM argument [PR90608]

Hi Mikael, thanks for this nice set of patches! I've played around a bit, and it seems to look good. I have only minor comments left (besides the nan issue raised): - inline expansion is inhibited at -Os. But wouldn't it be good if we make this expansion also dependent on -ffrontend-optimiz

[Patch, Fortran] Bug 109105 - Error-prone format string building in resolve.cc

Hi all, The attached patch changes all the snprintf calls to regular gfc_error calls to cleanup translation. I introduced a simple macro to facilitate doing the checks that were being done in the bad_op code section. From the description for the call to gfc_extend_expr interfaces are mentio