[clang] [Clang] Fix __is_array returning true for zero-sized arrays (PR #86652)

jwakely wrote: Last time I checked, neither GCC nor Clang allowed T[0] to match a partial specialization for `is_array` so the extension isn't very well extended :) https://github.com/llvm/llvm-project/pull/86652 ___ cfe-commits mailing list

[clang] [Clang] Fix __is_array returning true for zero-sized arrays (PR #86652)

jwakely wrote: As I've just commented at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114479 the `__is_array` intrinsic exists to optimize `std::is_array` and so should match its existing behaviour. If you want to change the behaviour of `std::is_array` then please do so via an LWG issue,

[clang] [Clang] Fix __is_array returning true for zero-sized arrays (PR #86652)

jwakely wrote: > We don't use the trait currently in libc++ because of this bug and GCC only > added it in trunk (and have the same bug), so probably not. N.B. MSVC used to have the same bug as well, and it affected their `std::is_array` because MSVC auto-replaces `std::is_array::value` with

[clang] Add option -fstdlib-hardening= (PR #78763)

jwakely wrote: > Also, @jwakely it would be nice if this worked with libstdc++ as well in the > future -- it would probably turn on checks like `__GLIBCXX_ASSERT__`. That should be `_GLIBCXX_ASSERTIONS` No other thoughts for now. GCC has `-fhardened` now, which already defines that macro.

Re: How can Autoconf help with the transition to stricter compilation defaults?

On Wed, 16 Nov 2022 at 16:34, Michael Matz wrote: > > Hello, > > On Wed, 16 Nov 2022, Jonathan Wakely wrote: > > > > > Unrelated but I was a bit tempted to ask for throwing in > > > > -Wbuiltin-declaration-mismatch to default -Werror while Clang 16 was at > > > > it, but I suppose we don't want

Re: How can Autoconf help with the transition to stricter compilation defaults?

On Wed, 16 Nov 2022 at 15:59, Michael Matz wrote: > > Hello, > > On Wed, 16 Nov 2022, Sam James wrote: > > > Unrelated but I was a bit tempted to ask for throwing in > > -Wbuiltin-declaration-mismatch to default -Werror while Clang 16 was at > > it, but I suppose we don't want the world to burn

Re: How can Autoconf help with the transition to stricter compilation defaults?

On Tue, 15 Nov 2022 at 19:08, Paul Eggert wrote: > > On 2022-11-15 06:50, Jonathan Wakely wrote: > > Could you clarify what you mean, with a concrete example? Surely as > > long as errors are reported on stderr and the compiler exits with > > non-zero status, that's an acceptable way to report

Re: How can Autoconf help with the transition to stricter compilation defaults?

On Mon, 14 Nov 2022 at 18:15, Paul Eggert wrote: > > On 2022-11-14 04:41, Aaron Ballman wrote: > > it's generally a problem when autoconf relies on invalid > > language constructs > > Autoconf *must* rely on invalid language constructs, if only to test > whether the language constructs work. And

Re: How can Autoconf help with the transition to stricter compilation defaults?

On Thu, 10 Nov 2022 at 17:58, Jonathan Wakely wrote: > > On Thu, 10 Nov 2022 at 17:52, Nick Bowler wrote: > > It saddens me to see so much breakage happening in "modern C", a > > language that has (until now) a long history of new language features > > being carefully introduced to avoid these

Re: How can Autoconf help with the transition to stricter compilation defaults?

On Thu, 10 Nov 2022 at 17:52, Nick Bowler wrote: > It saddens me to see so much breakage happening in "modern C", a > language that has (until now) a long history of new language features > being carefully introduced to avoid these sort of problems. The features were introduced in 1999. Compilers

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

On 11 February 2016 at 12:40, Matthijs van Duin wrote: > You never define "POD for the purposes of layout", and I can only > interpret it as being equivalent to "standard-layout". As Richard pointed out, it's defined in the C++ ABI. ___ cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

On 8 February 2016 at 16:05, H.J. Lu wrote: > My understanding is > > A type that is standard-layout means that it orders and packs its > members in a way that is compatible with C. > > What is the corresponding compatible type in C? An empty structure, such as struct A. One of the requirements

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

On 8 February 2016 at 15:42, H.J. Lu wrote: > On Mon, Feb 8, 2016 at 7:02 AM, Jonathan Wakely wrote: >> On 8 February 2016 at 13:54, H.J. Lu wrote: >>> On Sun, Feb 7, 2016 at 12:52 PM, H.J. Lu wrote: >>> >>>

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

On 8 February 2016 at 13:54, H.J. Lu wrote: > On Sun, Feb 7, 2016 at 12:52 PM, H.J. Lu wrote: > > The standard-layout POD is well defined: > > https://en.wikipedia.org/wiki/C%2B%2B11#Modification_to_the_definition_of_plain_old_data > > Here is the

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

On 8 February 2016 at 18:26, Jonathan Wakely wrote: > On 8 February 2016 at 17:58, H.J. Lu wrote: >> On Mon, Feb 8, 2016 at 7:59 AM, Jonathan Wakely >> wrote: > A type is a standard-layout type, or it isn't. How about "An empty record

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

On 8 February 2016 at 18:31, H.J. Lu wrote: > On Mon, Feb 8, 2016 at 10:30 AM, Jonathan Wakely > wrote: >> On 8 February 2016 at 18:26, Jonathan Wakely wrote: >>> On 8 February 2016 at 17:58, H.J. Lu wrote: On Mon, Feb 8,

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

On 8 February 2016 at 17:58, H.J. Lu wrote: > On Mon, Feb 8, 2016 at 7:59 AM, Jonathan Wakely wrote: A type is a standard-layout type, or it isn't. >>> >>> How about "An empty record is standard-layout Plain Old Data (POD) >>> type and ..."? >> >> That's redundant, all

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

On 8 February 2016 at 19:23, Richard Smith wrote: > "POD for the purpose of layout" is defined in the Itanium C++ ABI here: > > http://mentorembedded.github.io/cxx-abi/abi.html#definitions Thanks. So there's no problem using "POD for the purposes of layout", and the change to "POD for the