Bug 88683 - nan <= inf not accepted as constant expression
Summary: nan <= inf not accepted as constant expression
Status: UNCONFIRMED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 8.2.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: rejects-valid
Depends on:
Blocks:
 
Reported: 2019-01-03 22:15 UTC by Martin Jansche
Modified: 2019-01-07 09:38 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Jansche 2019-01-03 22:15:25 UTC
I am observing a regression between g++-7.4.0 and g++-8.2.0 when compiling the following code:

#include <iostream>
#include <limits>
int main() {
  constexpr double nan = std::numeric_limits<double>::quiet_NaN();
  constexpr double inf = std::numeric_limits<double>::infinity();
  constexpr bool inf_ge_nan = inf >= nan;  // accepted
  std::cout << inf_ge_nan << std::endl;
  constexpr bool nan_le_inf = nan <= inf;  // rejected: not a constant expression
  std::cout << nan_le_inf << std::endl;
  return 0;
}

I have read section 5.19 [expr.const] of the C++11 standard a few times and don't see why the expression (nan <= inf) wouldn't be a constant expression in the above code.

This is especially puzzling as (inf >= nan) is considered a constant expression yet (nan <= inf) is not. At a minimum I would expect (inf >= nan) to be a constant expression iff (nan <= inf) is.

I wouldn't make too much of the observation that this is a regression between 7.4.0 and 8.2.0: I've seen similar issues in g++-7.3.0, but haven't been able to reproduce them in isolation.


Details:

$ /usr/local/stow/gcc-7.4.0/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/usr/local/stow/gcc-7.4.0/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/stow/gcc-7.4.0/libexec/gcc/x86_64-pc-linux-gnu/7.4.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-7.4.0/configure --prefix=/usr/local/stow/gcc-7.4.0
Thread model: posix
gcc version 7.4.0 (GCC) 
$ /usr/local/stow/gcc-8.2.0/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/usr/local/stow/gcc-8.2.0/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/stow/gcc-8.2.0/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-8.2.0/configure --prefix=/usr/local/stow/gcc-8.2.0
Thread model: posix
gcc version 8.2.0 (GCC) 
$ /usr/local/stow/gcc-7.4.0/bin/g++ -std=c++11 -Wall -Wextra nan_le_inf.cc 
$ /usr/local/stow/gcc-8.2.0/bin/g++ -std=c++11 -Wall -Wextra nan_le_inf.cc 
nan_le_inf.cc: In function ‘int main()’:
nan_le_inf.cc:8:35: error: ‘(+QNaN <= +Inf)’ is not a constant expression
   constexpr bool nan_le_inf = nan <= inf;  // rejected: not a constant expression
                               ~~~~^~~~~~
Comment 1 Marc Glisse 2019-01-03 22:52:38 UTC
DUP of PR 88173?
Comment 2 Martin Jansche 2019-01-04 01:59:37 UTC
Yeah, looks definitely related. Details may depend on the ultimate diagnosis. 

Similar observation here that it matters whether NaN appears on the left-hand side vs. right-hand side of a comparison (cf. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88173#c5).

Additional notes:

* When/whether this surfaces depends to some extent on the version of gcc. I first thought it was a simple regression between gcc-7 and gcc-8, but it's more complex than that.

* The title of Bug 88173 could be interpreted to leave open the possibility that this might be a library issue, i.e. std::numeric_limits<>::quiet_NaN() not being declared constexpr. But it's definitely not a library issue.

Anyway, I agree with the recommended disposition as DUP. But I'm new around here and don't know who gets to close this as DUP. Happy to do it myself, just don't want to jump the gun.