Re: [PATCH] Fortran: fix NULL pointer dereference in gfc_check_dependency [PR108502]

On Mon, Jan 23, 2023 at 10:23:54PM +0100, Harald Anlauf via Fortran wrote: > > the code in the PR demonstrates that dependency checking in the > frontend optimization was not recovering well from invalid code, > leading to a NULL pointer dereference. An easy and really obvious > fix. > > Regtest

Re: [PATCH] Fortran: fix NULL pointer dereference in gfc_check_dependency [PR108502]

Hi Harald, the code in the PR demonstrates that dependency checking in the frontend optimization was not recovering well from invalid code, leading to a NULL pointer dereference. An easy and really obvious fix. Regtested on x86_64-pc-linux-gnu. OK for mainline? Yes indeed (and I would not h

[PATCH] Fortran: fix NULL pointer dereference in gfc_check_dependency [PR108502]

Dear all, the code in the PR demonstrates that dependency checking in the frontend optimization was not recovering well from invalid code, leading to a NULL pointer dereference. An easy and really obvious fix. Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald From d27e1b13ba31

Re: [PATCH] Fortran: avoid ICE on invalid array subscript triplets [PR108501]

On Mon, Jan 23, 2023 at 09:34:59PM +0100, Harald Anlauf via Fortran wrote: > > we did not check array element triplets for validity strictly enough > (i.e. defensively in the case of invalid code), so we could encounter > non-integer constant expressions that were passed to mpz_get_si. > > The at

[PATCH] Fortran: avoid ICE on invalid array subscript triplets [PR108501]

Dear all, we did not check array element triplets for validity strictly enough (i.e. defensively in the case of invalid code), so we could encounter non-integer constant expressions that were passed to mpz_get_si. The attached obvious patch tries to fix all such potential issues in get_expr_stora

Re: git out-of-order commit (was Re: [PATCH] Fortran: Remove unused declaration)

On 1/20/23 18:33, Jason Merrill wrote: > Martin, I wonder about having the hooks reject out-of-order CommitDate > in future? Yes, I would do that. Looking at the last 30K commmits I see just a few violations of the order: UNIXTS hash 1668298622 30d77d49628 1630019619 5889e842ae4 1626967834 3