Hi!
My recent gfortran + libgfortran patch apparently broke (some?) aarch64
builds. While it is desirable to use just _Float128 rather than __float128,
we only want to use it (and e.g. define HAVE_FLOAT128) on targets where
_Float128 is supported and long double isn't IEEE quad precision.
Which i
Hi!
My patch apparently left some __float128 uses in libgfortran
that could use _Float128 instead, the following patch changes that.
Ok for trunk?
2022-06-29 Jakub Jelinek
* mk-kinds-h.sh: Change __float128 to _Float128 in a comment.
* acinclude.m4 (LIBGFOR_CHECK_FLOAT128): A
On 29.06.22 14:13, Jakub Jelinek via Fortran wrote:
My recent gfortran + libgfortran patch apparently broke (some?) aarch64
builds. While it is desirable to use just _Float128 rather than __float128,
we only want to use it (and e.g. define HAVE_FLOAT128) on targets where
_Float128 is supported a
On 29.06.22 14:15, Jakub Jelinek via Fortran wrote:
My patch apparently left some __float128 uses in libgfortran
that could use _Float128 instead, the following patch changes that.
Ok for trunk?
LGTM. Thanks!
Tobias
2022-06-29 Jakub Jelinek
* mk-kinds-h.sh: Change __float128 to _F
On 28.06.22 22:36, Harald Anlauf via Gcc-patches wrote:
the simplification of EXTENDS_TYPE_OF() did not handle the
situation that one of its arguments were a CLASS variable
that was improperly declared. NULL pointer dereference.
The fix is obvious. Steve found a similar solution, which
is why
Dear all,
a CLASS entity cannot have the PARAMETER attribute.
This is detected in some situations, but in others
we ICE because we never reach the existing check.
Adding a similar check when handling the declaration
improves error recovery.
The initial patch is by Steve. I adjusted and moved
it
