https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120304
--- Comment #5 from Joseph S. Myers ---
I agree that it's best not to support legacy __float128 for new architectures;
if there are any remaining issues with libgcobol using long double / _Float128,
those should be fixed instead.
float128-mul-u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120304
--- Comment #4 from Jakub Jelinek ---
But of course then it needs to be mangled differently from long double and
_Float128 too.
Itanium ABI documents e for long double, g for __float128 and DF128_ for
_Float128,
not really sure if g isn't alread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120304
--- Comment #3 from Jakub Jelinek ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Rainer Orth from comment #0)
> > * I initially tried aliasing __float128 to _Float128, but that broke the
> > libstdc++ build:
>
> Libstdc++ co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120304
--- Comment #2 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #1)
> In C++ the _FloatN types have special rules that prevent some implicit
> conversions, which would break existing code that uses __float128 and
> expects it t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120304
--- Comment #1 from Jonathan Wakely ---
(In reply to Rainer Orth from comment #0)
> * I initially tried aliasing __float128 to _Float128, but that broke the
> libstdc++ build:
Libstdc++ could be changed to handle it, but I don't think we want
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120304
Eric Botcazou changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
