This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/69881] with gcc-6 of today building gcc-4.9 fails
- From: "redi at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 22 Feb 2016 12:38:30 +0000
- Subject: [Bug libstdc++/69881] with gcc-6 of today building gcc-4.9 fails
- Auto-submitted: auto-generated
- References: <bug-69881-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69881
--- Comment #20 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Bernd Edlinger from comment #19)
> But I am sure that #define __need_offsetof can simply not work.
So don't define that. It's undefined behaviour.
> I am not sure if it can compile at all, because if I try
> there are the same bogus symlinks to missing c/-headers.
>
> But before the build reaches the point where that matters,
> the cstdlib simply includes <stdlib.h> which fails to declare
> std::abort.
>
> Is this c/cstdlib intended for targets that have C++ aware stdlib.h?
Yes.
> When we leave it as it is, everyone will point with the finger
> on us, because it looks like a gcc-bug.
>
> Alternative would be to detect that any of the 6 known
> __need_-defines are present when invoking cstddef and
> give an explicit #error, but this mis-use worked previously.
> Or maybe a #warning would be a compromise?
>
> What do you think?
I think if we do anything then I prefer your original suggestion to just #undef
them.
But I'm not yet convinced we should do anything. This already failed with old
versions of GCC:
// get size_t
#define __need_size_t
#include <cstddef>
// get everything else
#include <cstddef>
std::max_align_t m;