Bug 273338 - '#include <cmath>' fails on 14 because of a likely bug with error: expected unqualified-id
Summary: '#include <cmath>' fails on 14 because of a likely bug with error: expected u...
Status: Closed Not A Bug
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-toolchain (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-08-25 06:59 UTC by Yuri Victorovich
Modified: 2023-08-25 08:11 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Yuri Victorovich freebsd_committer freebsd_triage 2023-08-25 06:59:12 UTC
The port math/mpsolve fails to compile on 14 amd64:

libtool: compile:  cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -I../../include -D_REENTRANT -Wall -DMPS_USE_BUILTIN_COMPLEX -DNICE_DEBUG -fno-math-errno -fomit-frame-pointer -D_MPS_PRIVATE -D_THREAD_SAFE -pthread -isystem /usr/local/include -O2 -pipe -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -MT common/parser.lo -MD -MP -MF common/.deps/parser.Tpo -c common/parser.c  -fPIC -DPIC -o common/.libs/parser.o
In file included from common/nroots-polynomial.cpp:11:
In file included from ../../include/mps/mps.h:99:
In file included from ../../include/mps/private/system/memory-file-stream.h:50:
In file included from /usr/include/c++/v1/iostream:43:
In file included from /usr/include/c++/v1/ios:221:
In file included from /usr/include/c++/v1/__locale:18:
In file included from /usr/include/c++/v1/mutex:191:
In file included from /usr/include/c++/v1/__memory/shared_ptr.h:42:
In file included from /usr/include/c++/v1/atomic:2669:
/usr/include/c++/v1/cmath:587:17: error: expected unqualified-id
    return std::isnan(__lcpp_x);
                ^
../../include/mps/types.h:27:3: note: expanded from macro 'isnan'
  (sizeof(x) == sizeof(long double) ? isnan_ld (x) \
  ^
Comment 1 Dimitry Andric freebsd_committer freebsd_triage 2023-08-25 07:41:07 UTC
Looks like their own 'types.h' header is defining a isnan() macro, which conflicts with the one(s) in our headers. I would try commenting this conflicting definition out, and see what happens?
Comment 2 Mark Millard 2023-08-25 07:46:41 UTC
The messages indicate that the syntax after substitution of
the macro is wrong. Showing just the part of the text that
you provided but after substitution:

return std::(sizeof(x) == sizeof(long double) ? isnan_ld (x)

(Not shown is what was on the line(s) after \ so I've only a
prefix of the text to work with.)


mps/types.h is using a macro isnan to override the libc++
definition, producing something that is invalid C++ source
code from what was valid C++ source without the macro
definition.
Comment 3 Yuri Victorovich freebsd_committer freebsd_triage 2023-08-25 08:11:45 UTC
Yes, it is the upstream's fault.
They assume that there is no isnan() and redefine it.