Re: [PATCH][v2] Adjust volatile handling of the operand scanner

2021-08-11 Thread Richard Biener via Gcc-patches
On Wed, 11 Aug 2021, Eric Botcazou wrote: > > So I'm leaning towards leaving build3 alone and fixing up frontends > > as issues pop up. > > FWIW fine with me. OK, so I pushed the original change (reposted below). Bootstrapped / tested on x86_64-unknown-linux-gnu. Richard. >From

Re: [PATCH][v2] Adjust volatile handling of the operand scanner

2021-08-11 Thread Eric Botcazou
> So I'm leaning towards leaving build3 alone and fixing up frontends > as issues pop up. FWIW fine with me. -- Eric Botcazou

Re: [PATCH][v2] Adjust volatile handling of the operand scanner

2021-08-11 Thread Richard Biener via Gcc-patches
On Wed, 11 Aug 2021, Richard Biener wrote: > On Tue, 10 Aug 2021, Eric Botcazou wrote: > > > > The question is whether we instead want to amend build3 to > > > set TREE_THIS_VOLATILE automatically when the FIELD_DECL has > > > it set. At least for the Fortran FE cases the gimplifier > > > fails

Re: [PATCH][v2] Adjust volatile handling of the operand scanner

2021-08-11 Thread Eric Botcazou
> build3 currently does no special processing for the FIELD_DECL operand, > it just sets TREE_THIS_VOLATILE from operand zero for tcc_references. > > The C and C++ frontends have repeated patterns like > > ref = build3 (COMPONENT_REF, subtype, datum, subdatum, >

Re: [PATCH][v2] Adjust volatile handling of the operand scanner

2021-08-11 Thread Richard Biener via Gcc-patches
On Tue, 10 Aug 2021, Eric Botcazou wrote: > > The question is whether we instead want to amend build3 to > > set TREE_THIS_VOLATILE automatically when the FIELD_DECL has > > it set. At least for the Fortran FE cases the gimplifier > > fails to see some volatile references and thus can generate >

Re: [PATCH][v2] Adjust volatile handling of the operand scanner

2021-08-10 Thread Eric Botcazou
> The question is whether we instead want to amend build3 to > set TREE_THIS_VOLATILE automatically when the FIELD_DECL has > it set. At least for the Fortran FE cases the gimplifier > fails to see some volatile references and thus can generate > wrong code which is a latent issue. What do we do

Re: [PATCH][v2] Adjust volatile handling of the operand scanner

2021-08-10 Thread Richard Biener via Gcc-patches
On Tue, Aug 10, 2021 at 1:41 PM Richard Biener via Gcc-patches wrote: > > The GIMPLE SSA operand scanner handles COMPONENT_REFs that are > not marked TREE_THIS_VOLATILE but have a TREE_THIS_VOLATILE > FIELD_DECL as volatile. That's inconsistent in how TREE_THIS_VOLATILE > testing on GENERIC refs

[PATCH][v2] Adjust volatile handling of the operand scanner

2021-08-10 Thread Richard Biener via Gcc-patches
The GIMPLE SSA operand scanner handles COMPONENT_REFs that are not marked TREE_THIS_VOLATILE but have a TREE_THIS_VOLATILE FIELD_DECL as volatile. That's inconsistent in how TREE_THIS_VOLATILE testing on GENERIC refs works which requires operand zero of component references to mirror