[Bug middle-end/19779] IBM 128bit long double format is not constant folded.

[Bug middle-end/19779] IBM 128bit long double format is not constant folded.

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19779

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |redi at gcc dot gnu.org

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I think this should be rejects-valid not a missed-optimization enhancement. For
C++20 we reject valid code:

#include <limits>
constexpr long double x = 1.0L + std::numeric_limits<long double>::epsilon();

<stdin>:1:32: error: ‘(1.0e+0l + 4.94065645841246544176568792868221e-324l)’ is
not a constant expression


The code reduces to:

constexpr long double x = 1.0L + __LDBL_EPSILON__;

[Bug middle-end/19779] IBM 128bit long double format is not constant folded.

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19779

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
We do fold it with -ffast-math or -funsafe-math-optimizations.
PR19405 explains the reasons why we can't fold those results that aren't
exactly representable in double double.

[Bug middle-end/19779] IBM 128bit long double format is not constant folded.

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19779

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Yeah, I'm not asking for it to be fixed, just noting here that it affects C++
constant expressions.

[Bug middle-end/19779] IBM 128bit long double format is not constant folded.

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19779

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |liushuyu011 at gmail dot com

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 105578 has been marked as a duplicate of this bug. ***

[Bug middle-end/19779] IBM 128bit long double format is not constant folded.

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19779

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Sebastian at SSpaeth dot de

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 107745 has been marked as a duplicate of this bug. ***

[Bug middle-end/19779] IBM 128bit long double format is not constant folded.

[vital.had at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19779

--- Comment #6 from Sergey Fedorov <vital.had at gmail dot com> ---
(In reply to Andrew Pinski from comment #0)
> This is the new bug for PR 19405. Keeping track of that we no longer
> constant fold long doubles in the 
> IBM 128bit long double format.

What is the current status of the issue?

[Bug middle-end/19779] IBM 128bit long double format is not constant folded.

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19779

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Unlikely to be ever fixed, at least Linux has migrated to IEEE quad long double
on powerpc64le.

[Bug middle-end/19779] IBM 128bit long double format is not constant folded.

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19779

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Sergey Fedorov from comment #6)
> (In reply to Andrew Pinski from comment #0)
> > This is the new bug for PR 19405. Keeping track of that we no longer
> > constant fold long doubles in the 
> > IBM 128bit long double format.
> 
> What is the current status of the issue?

Nothing has changed here that much. Though powerpc64 le is heading towards
doing IEEE 128bit FP by default so this might be much much less of an issue for
most people which means this is more likely never get fixed.

[Bug middle-end/19779] IBM 128bit long double format is not constant folded.

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19779

--- Comment #9 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Sergey Fedorov from comment #6)
> > (In reply to Andrew Pinski from comment #0)
> > > This is the new bug for PR 19405. Keeping track of that we no longer
> > > constant fold long doubles in the 
> > > IBM 128bit long double format.
> > 
> > What is the current status of the issue?
> 
> Nothing has changed here that much. Though powerpc64 le is heading towards
> doing IEEE 128bit FP by default so this might be much much less of an issue
> for most people which means this is more likely never get fixed.

it occasionally causes grief, but so far there's been a work-around; I guess if
someone really wanted to make a patch - they'd have to use MPFR et. al. to do
the work.

[Bug middle-end/19779] IBM 128bit long double format is not constant folded.

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19779

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #9)
> (In reply to Andrew Pinski from comment #8)
> > (In reply to Sergey Fedorov from comment #6)
> > > (In reply to Andrew Pinski from comment #0)
> > > > This is the new bug for PR 19405. Keeping track of that we no longer
> > > > constant fold long doubles in the 
> > > > IBM 128bit long double format.
> > > 
> > > What is the current status of the issue?
> > 
> > Nothing has changed here that much. Though powerpc64 le is heading towards
> > doing IEEE 128bit FP by default so this might be much much less of an issue
> > for most people which means this is more likely never get fixed.
> 
> it occasionally causes grief, but so far there's been a work-around; I guess
> if someone really wanted to make a patch - they'd have to use MPFR et. al.
> to do the work.

MPFR won't really help, after all, it doesn't have any double double arithmetic
support at all.
The problem is that real.cc pretends that IBM double double is a sane floating
point format with 106bit precision, which is not the case.
In GCC, basic floating point operations are performed by performing stuff in
the GCC internal format, which is something with sufficient precision and
exponent range to cover all the sane supported formats including some extra
precision bits and then converting that to the appropriate mode.
That doesn't work for double double, which has precision between 53 to some
thousands bits of precision, so in order to emulate in the compiler basic
floating point, it would need to be handled like it is actually at runtime,
which is hold the REAL_CST/CONST_DOUBLE double double values as a pair of
DFmode values rather than a single real_internal_format value (because the
latter can't express all the double double values), perform whatever
__gcc_qadd/__gcc_qsub/__gcc_qmul/__gcc_qdiv etc. perform at runtime on the
DFmode values, etc.  And then there is a question what to do about emulation of
libm functions - how to map that e.g. to mpfr operations, because what libm
actually does for those is sometimes quite weird and hard to define.

[Bug middle-end/19779] IBM 128bit long double format is not constant folded.

[vital.had at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19779

--- Comment #11 from Sergey Fedorov <vital.had at gmail dot com> ---
(In reply to Jakub Jelinek from comment #7)
> Unlikely to be ever fixed, at least Linux has migrated to IEEE quad long
> double on powerpc64le.

Perhaps several *BSDs and AIX are using IBM format though.

[Bug middle-end/19779] IBM 128bit long double format is not constant folded.

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19779

--- Comment #12 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Then the maintainers or users of those targets should consider contributing a
fix.

[Bug middle-end/19779] IBM 128bit long double format is not constant folded.

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19779

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Nobody is blocking proper double double evaluation support.  But somebody needs
to do the work, spend a few weeks on it and submit that.  I'm just saying that
is highly unlikely.  If somebody was really bothered about that there wouldn't
be 19 years of it being unfixed.  More so in the years when it was the typical
long double on Linux powerpc64le as well.  It is still the usually supported
long double on Linux powerpc64 and powerpc, but those are rarely used these
days.

[Bug middle-end/19779] IBM 128bit long double format is not constant folded.

[steven at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|IBM 128bit long double      |IBM 128bit long double
                   |format is not constant      |format is not constant
                   |foldded.                    |folded.


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19779

[Bug middle-end/19779] IBM 128bit long double format is not constant folded.

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-02-20 14:18:49
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19779