https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69905
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |DUPLICATE
--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to andreas.molzer from comment #7)
> Leaving out the overload for operator""s(long double) will silently break
We provide that overload though. What do you mean?
> valid code. Consider:
>
> #include <chrono>
> int main() {
> using std::chrono_literals;
> auto time = operator""s(0x8000'0000'0000'0000'0000'0000ULL);
> }
>
> According to standard, this should select the overload with unsigned long
> long argument, which does not exist.
No, according to the standard this is ill-formed because the value doesn't fit
in an unsigned long long (assuming 64 bits). GCC accepts it unless you use
-pedantic-errors, but this isn't valid code.
> It will instead silently perform a
> numeric conversion to long double, resulting in loss of accuracy on targets
> where gcc does not use extended 80-bit double. Any other integer arguments,
> which should lead to overload resolution failure, will also be double
> durations albeit with less immediately catastrophic results.
Again, this doesn't silently break valid code, because what you're doing should
be ill-formed according to the standard. So not valid code.
> However, that doesn't mean the long term effects are no issue. Consider
> that the type of time.count() also unexpectedly resolves as long double. Or
> even worse that assigning decltype(time)::max() to unsigned long long is
> undefined behaviour.
>
> It might be more fitting to open the missing declarations as a separately
> tracked bug, improving visibility of the standard issue as well.
Feel free to open a new bug (but this is not the place to report problems in
the standard, see https://cplusplus.github.io/LWG/lwg-active.html#submit_issue
for that).
I'm going to close this one as a dup of Bug 84671 because I don't think there's
any compiler bug here. The original problem was due to the library not handling
digit separators in its UDL operators, which is fixed.
*** This bug has been marked as a duplicate of bug 84671 ***
