Essentially we are just fiddling with the visibility of the symbol now.
If that is the only real problem, it is simple to avoid.
I prepared a patch exposing __max_align_t into the c99 || c++ namespace.
It's better to avoid exposing it to c89 as long long int could not be
supported.
http://netbsd.
1. Indeed, "_t" is reserved namespace by posix but the reality is that a lot of
3rd party
code uses it because it is a useful convention to identify typedefs. To wit:
$ fgrep -r _t /usr/src/external/bsd/ntp/dist | fgrep typedef | wc -l
446
I am picking ntp because it had a conflict
_t is a reserved namespace and nothing 3rd party (at least POSIX) should
use it.
We checked with Michal and building larger chunks of pkgsrc code had no
negative effect with exposed max_align_t.
I was responsible for bypassing the max_align_t libc++ definition and
reusing our homegrown from stdde
I've been following this discussion and it seems that:
1. upstream is not interested making the library support < c++11
2. finding the correct "max_align_t" is not obvious, but the library wants to
3. "max_align_t" should not be exposed to < c++11
Given the above constraints, the simplest solutio
On 09.03.2020 18:09, Joerg Sonnenberger wrote:
> On Mon, Mar 09, 2020 at 01:16:58PM +0100, Kamil Rytarowski wrote:
>> Upstream libc++ maintainers are against patching libc++.
>
> I'm buffled how you are arriving at this conclusion. Let me reiterate:
> STOP MESSING UP THE TREE.
>
> Joerg
>
I'm s
On 10.03.2020 00:07, Greg Troxel wrote:
> Kamil Rytarowski writes:
>
>> On 09.03.2020 20:05, Martin Husemann wrote:
>>> This is pretty stupid, but IMHO no big deal. We can
>>>
>> [...]
>>> - just not support (i.e. #error) on older C++ standard compiles
>>
>> There are still many programs in pkgs
Kamil Rytarowski writes:
> On 09.03.2020 20:05, Martin Husemann wrote:
>> This is pretty stupid, but IMHO no big deal. We can
>>
> [...]
>> - just not support (i.e. #error) on older C++ standard compiles
>
> There are still many programs in pkgsrc that set older C++ release. Some
> of them are
We gotta obey the namespace; perhaps use __max_align_t in the headers and only
expose the real typedef for c++ > 98 or whatever.
christos
> On Mar 9, 2020, at 5:44 PM, Kamil Rytarowski wrote:
>
> On 09.03.2020 20:05, Martin Husemann wrote:
>> This is pretty stupid, but IMHO no big deal. We ca
On 09.03.2020 20:05, Martin Husemann wrote:
> This is pretty stupid, but IMHO no big deal. We can
>
[...]
> - just not support (i.e. #error) on older C++ standard compiles
There are still many programs in pkgsrc that set older C++ release. Some
of them are hard to upgrade.
$ git grep c++03|wc -
Michał Górny writes:
> Given that Clang defaults to C++14 nowadays, I suppose it could be fixed
> by finding old -std= and replacing it.
I am not really following the issue, but I don't understand why what the
default C++ sublanguage is matters. It would seem that behavior should
be correct for
On Mon, Mar 09, 2020 at 08:28:58PM +0100, Michał Górny wrote:
> To be honest, this is NetBSD-specific problem. Upstream has a fallback
> for other platforms but it was explicitly disabled on NetBSD (Kamil or
> Joerg will probably know why).
No, it is not a NetBSD-specific problem. Guys, please st
On Mon, Mar 09, 2020 at 08:28:58PM +0100, Micha? Górny wrote:
> ATF-C++ forces -std=gnu++98. We could remove that but then we fail
> on deprecated auto_ptr use.
We should fix that, independently of the issue at hand.
Martin
On Mon, 2020-03-09 at 20:05 +0100, Martin Husemann wrote:
> On Mon, Mar 09, 2020 at 02:49:23PM -0400, Greg Troxel wrote:
> > I am not really following the issue, but I don't understand why what the
> > default C++ sublanguage is matters. It would seem that behavior should
> > be correct for any --
On Mon, Mar 09, 2020 at 08:05:41PM +0100, Martin Husemann wrote:
> On Mon, Mar 09, 2020 at 02:49:23PM -0400, Greg Troxel wrote:
> > I am not really following the issue, but I don't understand why what the
> > default C++ sublanguage is matters. It would seem that behavior should
> > be correct for
On Mon, Mar 09, 2020 at 02:49:23PM -0400, Greg Troxel wrote:
> I am not really following the issue, but I don't understand why what the
> default C++ sublanguage is matters. It would seem that behavior should
> be correct for any --std passed to compilers, per that sublanguages's
> specification,
On Mon, 2020-03-09 at 13:23 +0100, Martin Husemann wrote:
> Stupid question: if that libc+++ is only designed to be C++11 and newer,
> in what real world scenarios does it require exposing max_align_t?
>
> For sure you can easily compile the libc++.so* itself with proper standard
> flags passed to
On Mon, Mar 09, 2020 at 01:16:58PM +0100, Kamil Rytarowski wrote:
> Upstream libc++ maintainers are against patching libc++.
I'm buffled how you are arriving at this conclusion. Let me reiterate:
STOP MESSING UP THE TREE.
Joerg
On Mon, 9 Mar 2020 13:16:58 +0100
Kamil Rytarowski wrote:
> Today unexposed max_align_t is the only blocker for importing modern
> libc++. We worked with Michal for over a year on making it working well
> and passing tests on NetBSD.
>
> I request to expose max_align_t to at least all C++ versio
On 26.02.2020 23:47, Kamil Rytarowski wrote:
> On 26.02.2020 14:49, Joerg Sonnenberger wrote:
>> On Wed, Feb 26, 2020 at 12:37:06PM +0100, Kamil Rytarowski wrote:
>>> I propose to expose max_align_t unconditionally to C and C++ namespaces.
>>>
>>> It was introduced in C11/C++11, but in practice it
Stupid question: if that libc+++ is only designed to be C++11 and newer,
in what real world scenarios does it require exposing max_align_t?
For sure you can easily compile the libc++.so* itself with proper standard
flags passed to the compiler, so it must be something else - or I'm missing
somethi
On 26.02.2020 14:49, Joerg Sonnenberger wrote:
> On Wed, Feb 26, 2020 at 12:37:06PM +0100, Kamil Rytarowski wrote:
>> I propose to expose max_align_t unconditionally to C and C++ namespaces.
>>
>> It was introduced in C11/C++11, but in practice it is used in C++ code
>> that formally builds in the
On Wed, Feb 26, 2020 at 02:00:08PM +0100, Michał Górny wrote:
> While we're already touching this, I wonder if we should extend it to
> cover alignment for AVX types. In particular __m512i requires 512-bit
> alignment while our max_align_t currently has 128-bit alignment
> on amd64.
We do not gua
On Wed, Feb 26, 2020 at 12:37:06PM +0100, Kamil Rytarowski wrote:
> I propose to expose max_align_t unconditionally to C and C++ namespaces.
>
> It was introduced in C11/C++11, but in practice it is used in C++ code
> that formally builds in the C++03/older mode (llvm libc++ expects it
> unconditi
On 26.02.2020 14:00, Michał Górny wrote:
> On Wed, 2020-02-26 at 12:37 +0100, Kamil Rytarowski wrote:
>> I propose to expose max_align_t unconditionally to C and C++ namespaces.
>>
>> It was introduced in C11/C++11, but in practice it is used in C++ code
>> that formally builds in the C++03/older m
On Wed, 2020-02-26 at 12:37 +0100, Kamil Rytarowski wrote:
> I propose to expose max_align_t unconditionally to C and C++ namespaces.
>
> It was introduced in C11/C++11, but in practice it is used in C++ code
> that formally builds in the C++03/older mode (llvm libc++ expects it
> unconditionally)
25 matches
Mail list logo
