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

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 v3 Fortran] Fix c_float128 and c_float128_complex on targets with 128-bit long double.

On 8/10/21 2:29 AM, Tobias Burnus wrote: [snip] To conclude: I like the code changes (LGTM); the '__float128' -> 'TFmode' comment change also matches the code. However, I think both longer comments need to be updated. OK. I used your wording verbatim for the first one. For the second one,

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

> 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 Fortran] Fix c_float128 and c_float128_complex on targets with 128-bit long double.

On 8/10/21 2:29 AM, Tobias Burnus wrote: [snip] OK.  I now think it's correct that the Fortran front end doesn't support c_float128 and c_float128_complex on this target, but that the code that initializes those constants is still buggy. The reason why it shouldn't support them is that all 3

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

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

Re: [Patch] gfortran: Fix in-build-tree testing [PR101305, PR101660]

Hello, On Tue, 10 Aug 2021, Jakub Jelinek via Gcc-patches wrote: > > +# Place ISO_Fortran_binding.h also under include/ in the build directory > > such > > +# that it can be used for in-built-tree testsuite runs without > > interference of > > +# other files in the build dir - like intrinsic .m

Re: [Patch] gfortran: Fix in-build-tree testing [PR101305, PR101660]

On Tue, Aug 10, 2021 at 04:45:33PM +0200, Tobias Burnus wrote: > --- a/libgfortran/Makefile.am > +++ b/libgfortran/Makefile.am > @@ -1076,6 +1076,9 @@ fpu-target.inc: fpu-target.h $(srcdir)/libgfortran.h > grep '^#define GFC_FPE_' < $(top_srcdir)/../gcc/fortran/libgfortran.h > > $@ || true >

[Patch] gfortran: Fix in-build-tree testing [PR101305, PR101660]

This is a follow up to https://gcc.gnu.org/pipermail/gcc-patches/2021-August/576970.html /https://gcc.gnu.org/r12-2808-g527a1cf32c27a3fbeaf6be7596241570d864cc4c It turned out that -I $specpath/libgfortran caused gfortran

Re: [Patch v2 Fortran] Fix c_float128 and c_float128_complex on targets with 128-bit long double.

Hi! On Tue, Aug 10, 2021 at 10:29:08AM +0200, Tobias Burnus wrote: > On 09.08.21 23:42, Sandra Loosemore wrote: > In terms of Fortran, REAL types do not need to follow IEEE > (there are IEEE intrinsic modules to handle IEEE); thus, REAL(16) > does not need to be an IEEE type – albeit most users im

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

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 TREE_THIS_VOL

Re: [Patch v2 Fortran] Fix c_float128 and c_float128_complex on targets with 128-bit long double.

Hi Sandra, hi all, Let's start reverse – by trying to answer: On 09.08.21 23:42, Sandra Loosemore wrote: ... if (mode_precision != LONG_DOUBLE_TYPE_SIZE && mode_precision == 128) { + /* FIXME: why are we assuming that this type has IEEE + representation? That's implied by a