Bug#973495: mingw-w64-common: Conflicting definition of std::max_align_t with stddef.h of gcc-mingw-w64-i686-posix

2020-11-01 Thread Stephen Kitt
Control: forwarded -1 https://sourceforge.net/p/mingw-w64/bugs/778/

On Sat, 31 Oct 2020 21:10:50 +, Jonathan Wakely 
wrote:
> This is https://sourceforge.net/p/mingw-w64/bugs/778/

and is being discussed on the mailing list:
https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/19d95ae7-cd88-c558-5990-b4e34b75ea69%40users.sourceforge.net/#msg37141563

Regards,

Stephen


pgpapQKWHLhyq.pgp
Description: OpenPGP digital signature


Bug#973495: mingw-w64-common: Conflicting definition of std::max_align_t with stddef.h of gcc-mingw-w64-i686-posix

2020-10-31 Thread Jonathan Wakely

This is https://sourceforge.net/p/mingw-w64/bugs/778/



Bug#973495: mingw-w64-common: Conflicting definition of std::max_align_t with stddef.h of gcc-mingw-w64-i686-posix

2020-10-31 Thread Jonathan Wakely

A minimal reproducer:

#ifdef STDDEF_FIRST
# include 
#endif
#include 
static_assert( alignof(max_align_t) == 16 );


$ x86_64-w64-mingw32-g++ -c max.cc  -m32 && echo ok
ok
$ x86_64-w64-mingw32-g++ -c max.cc  -m32 -DSTDDEF_FIRST && echo ok
max.cc:6:37: error: static assertion failed
6 | static_assert( alignof(max_align_t) == 16 );
  |~^

The problem is that  includes  after
defining __need_wint_t and __need_wchar_t. GCC's  is
included, which immediately does #include_next , which finds
the base mingw , which does almost nothing because
__need_wint_t and __need_wchar_t are defined:

# 29 "/usr/share/mingw-w64/include/stdint.h" 2 3 4

#define __need_wint_t 
#define __need_wchar_t 
#include 

# 32 "/usr/share/mingw-w64/include/stdint.h" 3 4
# 1 "/usr/lib/gcc/i686-w64-mingw32/10-posix/include/stddef.h" 1 3 4
#include_next 
# 1 "/usr/lib/gcc/i686-w64-mingw32/10-posix/include/stddef.h" 3 4
# 1 "/usr/share/mingw-w64/include/stddef.h" 1 3 4

After defining wchar_t and wint_t the mingw  does almost
nothing else, skipping the rest of that header.

We then return to GCC's , which sees that max_align_t has
not been defined yet, and so defines it (using the modern definition
that includes __float128).

When STDDEF_FIRST is defined in the reproducer above,  is
included without defining __need_wint_t and __need_wchar_t, which
means the base mingw  defines everything, not just those two
types. That includes the old definition of max_align_t, without
__float128. GCC's  sees that _GCC_MAX_ALIGN_T has been
defined, so doesn't both to define it again.

So whether you get the old max_align_t from mingw's  or the
new max_align_t from GCC's  depends on whether 
gets included directly or as a side effect of including some other
header.

The simplest solution would be to just add the __float128 member to
max_align_t in the mingw header.



Bug#973495: mingw-w64-common: Conflicting definition of std::max_align_t with stddef.h of gcc-mingw-w64-i686-posix

2020-10-31 Thread Manuel Bilderbeek
Package: mingw-w64-common
Version: 8.0.0-1
Severity: important

Dear Maintainer,

When cross compiling for 32-bit Windows, I noticed that some translation units
had a different value for std::max_align_t than others. It appears that (for
some reason), one included it from:
/usr/share/mingw-w64/include/stddef.h
and another from:
/usr/lib/gcc/i686-w64-mingw32/10-posix/include/stddef.h

These have conflicting definitions, see http://paste.debian.net/1169371/

According to people on #gcc IRC:
 the issue seems to be that one of your stddef headers is old and 
predates the addition of __float128 support, which required increasing the 
alignment of max_align_t

If this is true, then something is wrong with the stddef.h in mingw-w64-common,
as it doesn't include that __float128 support. (But I wonder in the first place
why both mingw-w64-common and gcc-mingw-w64-i686-posix provide a stddef.h,
which apparently both can be found and then have a different definition...!?)

Anyway, this is all not my specialism, but I think it's still important to
report it. Please let me know if you need more information. I'll do my best to
provide it.

Thanks for taking a look at this!

Kind regards,
Manuel

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.8.0-3-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information