[Bug libstdc++/93469] memory header fails to compile with _XOPEN_SOURCE macro defined and -std=c++2a option specified

2020-01-30 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93469

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed|2020-01-27 00:00:00 |2020-01-30
 Ever confirmed|0   |1

--- Comment #10 from Jonathan Wakely  ---
Another interpretation would be that it's simply user error to request a
specific POSIX version and an incompatible C standard. If POSIX:2008 doesn't
define things that C11 requires, you can't combine POSIX:2008 and C11.

And POSIX doesn't define what *anything* means for a C++ program, so arguably
using _XOPEN_SOURCE at all in C++ is undefined. If your POSIX implementation
gives it a useful meaning, great, but if not and the macro breaks your C++
code, don't define the macro.

Either way, how the OS interprets and responds to macros like _XOPEN_SOURCE is
out of libstdc++'s hands. If the OS decides that _XOPEN_SOURCE=600 and C++17
are incompatible, there's only so much libstdc++ can do. Something like this
should work though:

#if __cplusplus >= 201703L && defined(_GLIBCXX_HAVE_ALIGNED_ALLOC)
# if defined __APPLE__ && defined _XOPEN_VERSION
  // see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93469
  extern "C" void* aligned_alloc(size_t, size_t);
# else
  using ::aligned_alloc;
# endif
#endif

Confirming as a bug, because we'll need that for previous releases of macOS
anyway, but please do report this to Apple too.

[Bug libstdc++/93469] memory header fails to compile with _XOPEN_SOURCE macro defined and -std=c++2a option specified

2020-01-30 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93469

--- Comment #9 from Jonathan Wakely  ---
(In reply to Karen from comment #8)
> Thanks for the explanation.
> 
> In fact it doesn't work even for -D_XOPEN_SOURCE=700 as the latest POSIX
> edition doesn't specify the aligned_alloc function.

But it is defined by C11 and C++17, so if you compile with -std=c11 or
-std=c++17 (which will set __STDC_VERSION or __cplusplus respectively) then the
OS should declare aligned_alloc.

> On the other hand I don't observe that _XOPEN_SOURCE affects the __cplusplus
> macro:

I didn't say it changes the value of it, I said it overrides it. Look in
 where the declaration of aligned_alloc is guarded by:

#if (__DARWIN_C_LEVEL >= __DARWIN_C_FULL) && \
((defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112L) || \
 (defined(__cplusplus) && __cplusplus >= 201703L))

This means if _DARWIN_C_LEVEL is below "full" (which happens when
_XOPENS_SOURCE is defined) then aligned_alloc will never be declared, even when
the C or C++ language dialect requires it.

In my not so humble opinion that first && should be || instead, so that
aligned_alloc is declared if the level is "full" or greater, **or** if it's
required by the language standard that is in use.

> One can argue, but this can be considered a libstdc++ issue that it is
> affected by the macro that defines the C functions availability.

But you get exactly the same problem compiling this C program with -std=c11,
where libstdc++ is completely irrelevant and there are no GCC headers used:

#define _XOPEN_SOURCE 600
#include 
int main() { free(aligned_alloc(4, 4)); }

This warns about aligned_alloc being implicitly declared, because the macOS
header fails to declare it.

This is an Apple bug, please report it to radar.

[Bug libstdc++/93469] memory header fails to compile with _XOPEN_SOURCE macro defined and -std=c++2a option specified

2020-01-30 Thread karen.arutyunov at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93469

--- Comment #8 from Karen  ---
Thanks for the explanation.

In fact it doesn't work even for -D_XOPEN_SOURCE=700 as the latest POSIX
edition doesn't specify the aligned_alloc function.

On the other hand I don't observe that _XOPEN_SOURCE affects the __cplusplus
macro:

% cat 

[Bug libstdc++/93469] memory header fails to compile with _XOPEN_SOURCE macro defined and -std=c++2a option specified

2020-01-28 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93469

Jonathan Wakely  changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

--- Comment #7 from Jonathan Wakely  ---
Thanks. This seems to be an Mac OS X feature, not a bug.

Selecting a specific POSIX version overrides the __STDC_VERSION and __cplusplus
values, and so names from newer POSIX standards (like aligned_alloc) are not
available.

IMO that is wrong, but it seems to be an intentional property of the OS X
system headers. Which means that you can't combine -std=c++2a with
-D_XOPEN_SOURCE=500. It produces an impossible combination where names required
to exist by one standard are required to _not_ exist by the other standard.

You could try reporting a radar bug and see if Apple really do consider this
correct behaviour.

[Bug libstdc++/93469] memory header fails to compile with _XOPEN_SOURCE macro defined and -std=c++2a option specified

2020-01-28 Thread karen.arutyunov at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93469

--- Comment #6 from Karen  ---
Sorry, you right.

gcc version 9.2.0 (Homebrew GCC 9.2.0_2)

Target: x86_64-apple-darwin19

Configured with: ../configure --build=x86_64-apple-darwin19
--prefix=/usr/local/Cellar/gcc/9.2.0_2
--libdir=/usr/local/Cellar/gcc/9.2.0_2/lib/gcc/9 --disable-nls
--enable-checking=release --enable-languages=c,c++,objc,obj-c++,fortran
--program-suffix=-9 --with-gmp=/usr/local/opt/gmp
--with-mpfr=/usr/local/opt/mpfr --with-mpc=/usr/local/opt/libmpc
--with-isl=/usr/local/opt/isl --with-system-zlib --with-pkgversion='Homebrew
GCC 9.2.0_2' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues
--disable-multilib --with-native-system-header-dir=/usr/include
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk

[Bug libstdc++/93469] memory header fails to compile with _XOPEN_SOURCE macro defined and -std=c++2a option specified

2020-01-28 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93469

--- Comment #5 from Jonathan Wakely  ---
(In reply to Karen from comment #4)
> Here the additional info:
> 
> GCC version: Apple clang version 11.0.0 (clang-1100.0.33.16)
> Target: x86_64-apple-darwin19.2.0
> Configured with: --prefix=/Library/Developer/CommandLineTools/usr
> --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/
> usr/include/c++/4.2.1

That confirms you're using OS X, but it's not the compiler you're using. For
your case you need to provide the output of 'g++-9 -v' since that's the
compiler you're reporting a bug for.

[Bug libstdc++/93469] memory header fails to compile with _XOPEN_SOURCE macro defined and -std=c++2a option specified

2020-01-28 Thread karen.arutyunov at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93469

--- Comment #4 from Karen  ---
Here the additional info:

GCC version: Apple clang version 11.0.0 (clang-1100.0.33.16)
Target: x86_64-apple-darwin19.2.0
Configured with: --prefix=/Library/Developer/CommandLineTools/usr
--with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/4.2.1

[Bug libstdc++/93469] memory header fails to compile with _XOPEN_SOURCE macro defined and -std=c++2a option specified

2020-01-28 Thread karen.arutyunov at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93469

--- Comment #3 from Karen  ---
Created attachment 47723
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47723=edit
Testcase preprocessed file

[Bug libstdc++/93469] memory header fails to compile with _XOPEN_SOURCE macro defined and -std=c++2a option specified

2020-01-27 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93469

--- Comment #2 from Jonathan Wakely  ---
This is a bug in your libc headers (and I'm guessing you're on OS X). The
aligned_alloc function should be declared for C++17 and later, irrespective of
the _XOPEN_SOURCE value.

[Bug libstdc++/93469] memory header fails to compile with _XOPEN_SOURCE macro defined and -std=c++2a option specified

2020-01-27 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93469

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2020-01-27
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Please provide the rest of the info requested by https://gcc.gnu.org/bugs
(especially the output of gcc -v)