Re: CSE deletes valid REG_EQUAL?
On 17/11/20 02:12, Jeff Law wrote:
Removing all REG_EQUAL notes for regs that become dead anywhere
That's not what it does.
seems to just be a thinko? All pseudos are dead somewhere! (Yeah okay,
infinite loops, but other than that.)
Yea, but the code which wipes the notes probably has no sense of where
in the RTL stream the note is valid and where it is not. So it does the
fairly dumb thing and just ends up wiping them all away because as you
noted, most pseudos have a death somewhere.
It shouldn't wipe all of them. It doesn't look at all REG_EQUAL notes
in the function; it looks at the notes one insn at a time, and wipes the
REG_EQUAL notes for registers that are dead _at that insn_. See how the
loop uses DF_INSN_EQ_USES:
for (use_rec = DF_INSN_EQ_USES (insn); *use_rec; use_rec++)
{
df_ref use = *use_rec;
if (DF_REF_REGNO (use) > FIRST_PSEUDO_REGISTER
&& (DF_REF_FLAGS (use) & DF_REF_IN_NOTE)
&& ! bitmap_bit_p (live, DF_REF_REGNO (use)))
{
deleted = true;
break;
}
}
and it is called as
df_kill_notes (insn, live);
One might argue that the code is OK as-is, but just needs to be run
later. After cse2 would be the most logical location since CSE is
probably the heaviest user of the notes. But I'd worry that the
problems referenced in c#2 of bz51505 could crop up in other contexts
than just combine.
Yeah, it was a design decision of DF to ignore REG_EQUAL/REG_EQUIV notes
when computing liveness and adding REG_DEAD notes[1]. Unfortunately
this all predates my involvement in DF and I'm also unfamiliar with how
REG_DEAD and REG_EQUAL notes interacted in flow.c times. But it's very
unlikely that after ~10 years there aren't more places with the same
issue that PR51505 worked around.
Paolo
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51505#c3
Git commit "Author: [...] via Gcc-patches " (was: [gcc r11-5068] Update documentation for spec files)
Hi! (As discussed before...), in 2020, email doesn't work anymore the way it did years ago... ;-/ (Let's please *not* discuss this here.) So we're now dealing with emails with "From: [...] via Gcc-patches ", etc. ... which occasionally then ends up in Git commit author: On 2020-11-17T00:15:36+, Jeff Law via Gcc-cvs wrote: > https://gcc.gnu.org/g:a019766f996f57e53a8d1a9e72033e1e1487a150 > > commit r11-5068-ga019766f996f57e53a8d1a9e72033e1e1487a150 > Author: Armin Brauns via Gcc-patches Should we have a Git commit hook to catch that (and similar variants)? (This is not to blame Jeff, of course; it's very easy to not notice that.) Grüße Thomas - Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter
Re: Git commit "Author: [...] via Gcc-patches " (was: [gcc r11-5068] Update documentation for spec files)
On Tue, 17 Nov 2020 at 09:29, Thomas Schwinge wrote: > > Hi! > > (As discussed before...), in 2020, email doesn't work anymore the way it > did years ago... ;-/ (Let's please *not* discuss this here.) > > So we're now dealing with emails with "From: [...] via Gcc-patches > ", etc. > > ... which occasionally then ends up in Git commit author: > > On 2020-11-17T00:15:36+, Jeff Law via Gcc-cvs wrote: > > https://gcc.gnu.org/g:a019766f996f57e53a8d1a9e72033e1e1487a150 > > > > commit r11-5068-ga019766f996f57e53a8d1a9e72033e1e1487a150 > > Author: Armin Brauns via Gcc-patches > > Should we have a Git commit hook to catch that (and similar variants)? Good idea. We should use the tools to help here.
Re: Git commit "Author: [...] via Gcc-patches " (was: [gcc r11-5068] Update documentation for spec files)
On 11/17/20 2:26 AM, Thomas Schwinge wrote: > Hi! > > (As discussed before...), in 2020, email doesn't work anymore the way it > did years ago... ;-/ (Let's please *not* discuss this here.) > > So we're now dealing with emails with "From: [...] via Gcc-patches > ", etc. > > ... which occasionally then ends up in Git commit author: > > On 2020-11-17T00:15:36+, Jeff Law via Gcc-cvs wrote: >> https://gcc.gnu.org/g:a019766f996f57e53a8d1a9e72033e1e1487a150 >> >> commit r11-5068-ga019766f996f57e53a8d1a9e72033e1e1487a150 >> Author: Armin Brauns via Gcc-patches > Should we have a Git commit hook to catch that (and similar variants)? > > > (This is not to blame Jeff, of course; it's very easy to not notice > that.) Yea. I keep having to remember which header to pull the author from. I strongly suspected one or more had slipped through. jeff
The encoding of GCC's stderr
As far as I can tell, GCC's diagnostic output on stderr is a mixture of bytes from various different places in our internal representation: - filenames - format strings from diagnostic messages (potentially translated via .po files) - identifiers - quoted source code - fix-it hints - labels As noted in https://gcc.gnu.org/onlinedocs/cpp/Character-sets.html source files can be in any character set, specified by -finput-charset=, and libcpp converts that to the "source character set", Unicode, encoding it internally as UTF-8. String and character constants are then converted to the execution character set (defaulting to UTF-8-encoded Unicode). In many places we use identifier_to_locale to convert from the "internal encoding" to the locale character set, falling back to converting non-ASCII characters to UCNs. I suspect that there are numerous places where we're not doing that, but ought to be. The only test coverage I could find for -finput-charset is gcc.dg/ucnid-16-utf8.c, which has a latin1-encoded source file, and verifies that a latin-1 encoded variable name becomes UTF-8 encoded in the resulting .s file. I shudder to imagine a DejaGnu test for a source encoding that's not a superset of ASCII (e.g. UCS-4) - how would the dg directives be handled? I wonder if DejaGnu can support tests in which the compiler's locale is overridden with environment variables (and thus having e.g. non-ASCII/non-UTF-8 output). What is the intended encoding of GCC's stderr? In gcc_init_libintl we call: #if defined HAVE_LANGINFO_CODESET locale_encoding = nl_langinfo (CODESET); if (locale_encoding != NULL && (!strcasecmp (locale_encoding, "utf-8") || !strcasecmp (locale_encoding, "utf8"))) locale_utf8 = true; #endif so presumably stderr ought to be nl_langinfo (CODESET). We use the above to potentially use the UTF-8 encoding of U+2018 and U+2019 for open/close quotes, falling back to ASCII for these. As far as I can tell, we currently: - blithely accept and emit filenames as bytes (I don't think we make any attempt to enforce that they're any particular encoding) - emit format strings in whatever encoding gettext gives us - emit identifiers as char * from IDENTIFIER_POINTER, calling identifier_to_locale on them in many places, but I suspect we're missing some - blithely emit quoted source code as raw bytes (this is PR other/93067, which has an old patch attached; presumably the source ought to be emitted to stderr in the locale encoding) - fix-it hints can contain identifiers as char * from IDENTIFIER_POINTERs, which is likely UTF-8; I think I'm failing to call identifier_to_locale on them - labels can contain type names, which are likely UTF-8, and I'm probably failing to call identifier_to_locale on them So I think our current policy is: - we assume filenames are encoded in the locale encoding, and pass them through as bytes with no encode/decode - we emit to stderr in the locale encoding (but there are likely bugs where we don't re-encode from UTF-8 to the locale encoding) Does this sound correct? My motivation here is the discussion in [1] and [2] of supporting Emacs via an alternative output format for machine-readable fix-it hints, which has made me realize that I didn't understand our current approach to encodings as well as I would like. Hope this is constructive Dave [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25987 [2] https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559105.html
Re: The encoding of GCC's stderr
On Tue, Nov 17, 2020 at 12:01 PM David Malcolm via Gcc wrote: > > As far as I can tell, GCC's diagnostic output on stderr is a mixture of > bytes from various different places in our internal representation: > - filenames > - format strings from diagnostic messages (potentially translated via > .po files) > - identifiers > - quoted source code > - fix-it hints > - labels > > As noted in https://gcc.gnu.org/onlinedocs/cpp/Character-sets.html > source files can be in any character set, specified by -finput-charset=, and > libcpp converts that to the "source character set", Unicode, encoding it > internally as UTF-8. String and character constants are then converted to > the execution character set (defaulting to UTF-8-encoded Unicode). In many > places we use identifier_to_locale to convert from the "internal encoding" to > the locale character set, falling back to converting non-ASCII characters to > UCNs. I suspect that there are numerous places where we're not doing that, > but ought to be. > > The only test coverage I could find for -finput-charset is > gcc.dg/ucnid-16-utf8.c, which has a latin1-encoded source file, and > verifies that a latin-1 encoded variable name becomes UTF-8 encoded in > the resulting .s file. I shudder to imagine a DejaGnu test for a > source encoding that's not a superset of ASCII (e.g. UCS-4) - how would > the dg directives be handled? I wonder if DejaGnu can support tests in > which the compiler's locale is overridden with environment variables > (and thus having e.g. non-ASCII/non-UTF-8 output). > > What is the intended encoding of GCC's stderr? I don't really have the context to comment much on this, since I just know what I tried to figure out while adding the support for UTF-8 identifiers initially, but I thought I would note a few things that I have come across which are relevant. One thing is that you actually can't use -finput-charset with an encoding that is not a superset of ASCII. I was confused by this and filed PR92987 about it (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92987), but Joseph explained that this is expected. Another random tidbit, it's actually hard to test some of this stuff with dejagnu because TCL does some silent conversion without telling you. In particular, if it sees command output that looks like latin1, it will convert it to UTF-8 behind the scenes before presenting it to you, irrespective of the current locale. I ran across that when constructing the test cases for the patch attached to PR93067 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93067#c0) and had to find some random encoding that satisfied both properties (superset of ASCII, not looking like latin1) to use for that test. > > In gcc_init_libintl we call: > > #if defined HAVE_LANGINFO_CODESET > locale_encoding = nl_langinfo (CODESET); > if (locale_encoding != NULL > && (!strcasecmp (locale_encoding, "utf-8") > || !strcasecmp (locale_encoding, "utf8"))) > locale_utf8 = true; > #endif > > so presumably stderr ought to be nl_langinfo (CODESET). > > We use the above to potentially use the UTF-8 encoding of U+2018 and > U+2019 for open/close quotes, falling back to ASCII for these. > > As far as I can tell, we currently: > - blithely accept and emit filenames as bytes (I don't think we make > any attempt to enforce that they're any particular encoding) > - emit format strings in whatever encoding gettext gives us > - emit identifiers as char * from IDENTIFIER_POINTER, calling > identifier_to_locale on them in many places, but I suspect we're > missing some > - blithely emit quoted source code as raw bytes (this is PR > other/93067, which has an old patch attached; presumably the source > ought to be emitted to stderr in the locale encoding) When I was first trying to understand this stuff for supporting UTF-8 identifiers, I discussed some of this with Joseph as well here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224#c28 . I would agree there are two missing conversions... source should be converted to UTF-8 when read for diagnostics (PR93067, that patch btw, I have updated it so it's no longer old...), and also, it should be converted to the current locale when output. This second part is a bit involved though, because we presumably do not want to disturb the alignment of labels and such. So it would seem that in case a given character cannot be output, it should be converted to as many '?' characters as needed to fill out the display width, or something like this. Presumably the most common, if not only practical, case, would be UTF-8 source, being processed in an ASCII locale... currently the user will get UTF-8 anyway. But it can be done in general too. I could work on this if you like... would be good to finalize the PR93067 patch first probably. Should I prepare it and post here? I had left it on the PR for feedback because I wasn't sure if the approach was OK or not for how I implemented it. > - fix-it hints can contain identifiers a
Re: Git commit "Author: [...] via Gcc-patches " (was: [gcc r11-5068] Update documentation for spec files)
On Tue, 17 Nov 2020, Thomas Schwinge wrote: > Should we have a Git commit hook to catch that (and similar variants)? I've added a check for gcc-patc...@gcc.gnu.org (or libstd...@gcc.gnu.org or fort...@gcc.gnu.org) as author email address in our commit_checker hook (in ~gccadmin/hooks-bin). (Checking a few specific email addresses seems a bit simpler than a more general rule of rejecting any @gcc.gnu.org address that matches that of a mailing list other than gccad...@gcc.gnu.org.) -- Joseph S. Myers jos...@codesourcery.com
Re: The encoding of GCC's stderr
On Tue, 17 Nov 2020, David Malcolm via Gcc wrote: > What is the intended encoding of GCC's stderr? The locale encoding. > - blithely accept and emit filenames as bytes (I don't think we make > any attempt to enforce that they're any particular encoding) File names that aren't in the locale encoding aren't expected to work very well in general (but some applications such as "ls" try to be careful about handling arbitrary file names). > - emit format strings in whatever encoding gettext gives us It's gettext's responsibility to handle translation from the character set of the compiled message catalog to the locale character set if necessary. > - emit identifiers as char * from IDENTIFIER_POINTER, calling > identifier_to_locale on them in many places, but I suspect we're > missing some Use of %qE in format strings for identifiers, rather than using IDENTIFIER_POINTER manually, is generally a good idea where possible to get this to happen automatically. > So I think our current policy is: > - we assume filenames are encoded in the locale encoding, and pass them > through as bytes with no encode/decode > - we emit to stderr in the locale encoding (but there are likely bugs > where we don't re-encode from UTF-8 to the locale encoding) > > Does this sound correct? Yes. -- Joseph S. Myers jos...@codesourcery.com
Re: The encoding of GCC's stderr
On Tue, 17 Nov 2020, Lewis Hyatt via Gcc wrote: > I also just wanted to ask... in case we have a general system to > always convert diagnostics output to the current locale, would this > make identifier_to_locale() no longer necessary in most cases? That Format strings come from the message catalog in the locale character set (translated by gettext as needed). So GCC mustn't do any further translation on the format strings for diagnostics - but does need to translate anything else from its internal representation that's not in the locale character set, such as identifiers. -- Joseph S. Myers jos...@codesourcery.com
Re: Re: typeof and operands in named address spaces
On Mon, Nov 16, 2020 at 3:11 AM Peter Zijlstra wrote: > > XXX: I've only verified the below actually compiles, I've not verified > the generated code is actually 'correct'. Well, it was mainly the arm64 code generation for load-acquire and store-release that wanted this - so it's really the generated code that matters. Will, can you check? Because: > +#define __unqual_typeof(type) typeof( (typeof(type))type ) that's certainly a much nicer version than the existing pre-processor expansion from hell. Linus
Re: Re: typeof and operands in named address spaces
On Tue, Nov 17, 2020 at 11:13:52AM -0800, Linus Torvalds wrote: > > +#define __unqual_typeof(type) typeof( (typeof(type))type ) > that's certainly a much nicer version than the existing pre-processor > expansion from hell. It would need to be typeof( (typeof(type)) (type) ) to not be that constrained on what kind of expressions it accepts as arguments. Anyway, it won't work with array types at least, int a[10]; typeof ((typeof (a)) (a)) b; is an error (in both gcc and clang), while typeof (a) b; will work (but not drop the qualifiers). Don't know if the kernel cares or not. Jakub
Re: Re: typeof and operands in named address spaces
On Tue, Nov 17, 2020 at 11:25 AM Jakub Jelinek wrote: > > It would need to be typeof( (typeof(type)) (type) ) to not be that > constrained on what kind of expressions it accepts as arguments. Yup. > Anyway, it won't work with array types at least, > int a[10]; > typeof ((typeof (a)) (a)) b; > is an error (in both gcc and clang), while typeof (a) b; will work > (but not drop the qualifiers). Don't know if the kernel cares or not. Well, the kernel already doesn't allow that, because our existing horror only handles simple integer scalar types. So that macro is a clear improvement - if it actually works (local testing says it does, but who knows about random compiler versions etc) Linus
Re: Re: typeof and operands in named address spaces
On Tue, Nov 17, 2020 at 11:13 AM Linus Torvalds
wrote:
>
> > +#define __unqual_typeof(type) typeof( (typeof(type))type )
>
> that's certainly a much nicer version than the existing pre-processor
> expansion from hell.
Oh, and sparse doesn't handle this, and doesn't remove any qualifiers
for the above. And so this horror-test-case fails:
#define __unqual_typeof(type) typeof( (typeof(type))(type) )
int *function(volatile int x)
{
extern __unqual_typeof(x) y;
return &y;
}
with
t.c:6:17: warning: incorrect type in return expression (different modifiers)
t.c:6:17:expected int *
t.c:6:17:got int volatile *
t.c:3:5: warning: symbol 'function' was not declared. Should it be static?
adding Luc and the sparse mailing list to the participants list.
But it does work with both gcc and clang for me.
For Luc, quoting some earlier emails:
> > lvalue conversion drops qualifers in C. In GCC, this is not
> > implemented correctly as it is unobservable in standard C
> > (but it using typeof).
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97702
> >
> > A have a working patch in preparation to change this. Then you
> > could use
> >
> > typeof( ((void)0, x) )
on another thing that fails with sparse. But since gcc gets that wrong
too and it only works with clang, that's not so relevant for the
kernel.
Luc - same test-case as above, just
#define __unqual_typeof(x) typeof( ((void)0, (x)) )
instead.
Linus
Re: Re: typeof and operands in named address spaces
On Tue, Nov 17, 2020 at 11:31:57AM -0800, Linus Torvalds wrote: > On Tue, Nov 17, 2020 at 11:25 AM Jakub Jelinek wrote: > > > > It would need to be typeof( (typeof(type)) (type) ) to not be that > > constrained on what kind of expressions it accepts as arguments. > > Yup. > > > Anyway, it won't work with array types at least, > > int a[10]; > > typeof ((typeof (a)) (a)) b; > > is an error (in both gcc and clang), while typeof (a) b; will work > > (but not drop the qualifiers). Don't know if the kernel cares or not. > > Well, the kernel already doesn't allow that, because our existing > horror only handles simple integer scalar types. > > So that macro is a clear improvement - if it actually works (local > testing says it does, but who knows about random compiler versions > etc) I'll give it a go now, although if it works I honestly won't know whether to laugh or cry. Will
Re: Re: typeof and operands in named address spaces
Am Dienstag, den 17.11.2020, 11:31 -0800 schrieb Linus Torvalds: > On Tue, Nov 17, 2020 at 11:25 AM Jakub Jelinek wrote: > > > > It would need to be typeof( (typeof(type)) (type) ) to not be that > > constrained on what kind of expressions it accepts as arguments. > > Yup. > > > Anyway, it won't work with array types at least, > > int a[10]; > > typeof ((typeof (a)) (a)) b; > > is an error (in both gcc and clang), while typeof (a) b; will work > > (but not drop the qualifiers). Don't know if the kernel cares or not. > > Well, the kernel already doesn't allow that, because our existing > horror only handles simple integer scalar types. > > So that macro is a clear improvement - if it actually works (local > testing says it does, but who knows about random compiler versions > etc) Well, the version that also works for other types (except multi-dim arrays) is slightly more complicated ;-) https://godbolt.org/z/KTKqon Best, Martin
Re: Re: typeof and operands in named address spaces
On Tue, Nov 17, 2020 at 09:10:53PM +, Will Deacon wrote: > On Tue, Nov 17, 2020 at 11:31:57AM -0800, Linus Torvalds wrote: > > On Tue, Nov 17, 2020 at 11:25 AM Jakub Jelinek wrote: > > > > > > It would need to be typeof( (typeof(type)) (type) ) to not be that > > > constrained on what kind of expressions it accepts as arguments. > > > > Yup. > > > > > Anyway, it won't work with array types at least, > > > int a[10]; > > > typeof ((typeof (a)) (a)) b; > > > is an error (in both gcc and clang), while typeof (a) b; will work > > > (but not drop the qualifiers). Don't know if the kernel cares or not. > > > > Well, the kernel already doesn't allow that, because our existing > > horror only handles simple integer scalar types. > > > > So that macro is a clear improvement - if it actually works (local > > testing says it does, but who knows about random compiler versions > > etc) > > I'll give it a go now, although if it works I honestly won't know whether > to laugh or cry. GCC 9 and Clang 11 both seem to generate decent code for aarch64 defconfig with: #define __unqual_scalar_typeof(x) typeof( (typeof(x)) (x)) replacing the current monstrosity. allnoconfig and allmodconfig build fine too. However, GCC 4.9.0 goes mad and starts spilling to the stack when dealing with a pointer to volatile, as though we were just using typeof(). I tried GCC 5.4.0 and that looks ok, so I think if anybody cares about the potential performance regression with 4.9 then perhaps they should consider upgrading their toolchain. In other words, let's do it. Will
Ping(3): [PATCH v4] : Add nitems()
Hi,
Do you think the patch is ready,
or is there anything else I should do before merging it?
Thanks,
Alex
On 9/28/20 9:12 PM, Alejandro Colomar wrote:
> 'nitems()' calculates the length of an array in number of items.
> It is safe: if a pointer is passed to the macro (or function, in C++),
> the compilation is broken due to:
> - In >= C11: _Static_assert()
> - In C89, C99: Negative anonymous bitfield
> - In C++: The template requires an array
>
> Some BSDs already provide a macro nitems() in ,
> although it usually doesn't provide safety against pointers.
>
> This patch uses the same name for compatibility reasons,
> and to be the least disruptive with existing code.
>
> This patch also adds some other macros, which are required by 'nitems()':
>
> __is_same_type(a, b):
> Returns non-zero if the two input arguments are of the same type.
>
> __is_array(arr):
> Returns non-zero if the input argument is of an array type.
>
> __must_be(expr, msg):
> Allows using _Static_assert() everywhere an expression can be used.
> It evaluates '(int)0' or breaks the compilation.
>
> __must_be_array(arr):
> It evaluates to '(int)0' if the argument is of an array type.
> Else, it breaks compilation.
>
> __nitems(arr):
> It implements the basic sizeof division needed to calculate the array length.
>
>
> P.S.: I'd like to put this patch in the public domain.
>
> Signed-off-by: Alejandro Colomar
> ---
>
> A few changes since v3:
>
> - Macros don't need reserved names in their parameters,
> so I simplified those names.
>
> - I fixed some wrong indentation levels.
>
> - Renamed __array_len() to __nitems() for consistency.
>
>
> misc/sys/param.h | 47 +++
> 1 file changed, 47 insertions(+)
>
> diff --git a/misc/sys/param.h b/misc/sys/param.h
> index d7c319b157..08d4093961 100644
> --- a/misc/sys/param.h
> +++ b/misc/sys/param.h
> @@ -102,5 +102,52 @@
> #define MIN(a,b) (((a)<(b))?(a):(b))
> #define MAX(a,b) (((a)>(b))?(a):(b))
>
> +/* Macros related to the types of variables */
> +#define __is_same_type(a, b)
> \
> + __builtin_types_compatible_p(__typeof__(a), __typeof__(b))
> +#define __is_array(arr) (!__is_same_type((arr), &(arr)[0]))
> +
> +/* Macros for embedding _Static_assert() in expressions */
> +#if __STDC_VERSION__ >= 201112L
> +# define __must_be(expr, msg) (
> \
> +0 * (int)sizeof(
> \
> + struct {
> \
> +_Static_assert((expr), msg);
> \
> +char _ISO_C_forbids_a_struct_with_no_members;
> \
> + }
> \
> +)
> \
> +)
> +#else
> +# define __must_be(expr, msg) (
> \
> +0 * (int)sizeof(
> \
> + struct {
> \
> +int : (-!(expr));
> \
> +char _ISO_C_forbids_a_struct_with_no_members;
> \
> + }
> \
> +)
> \
> +)
> +#endif
> +#define __must_be_array(arr) __must_be(__is_array(arr), "Must be an array!")
> +
> +/* Macros for array sizes */
> +#if defined(__cplusplus)
> +# if __cplusplus >= 201103L
> +template
> + constexpr inline std::size_t
> + nitems(const _Tp(&)[_Len]) __THROW
> + {
> +return _Len;
> + }
> +# else /* __cplusplus < 201103L */
> +template
> + char
> + (&__nitems_chararr(const _Tp(&)[_Len]))[_Len];
> +# define nitems(arr)(sizeof(__nitems_chararr(arr)))
> +# endif /* __cplusplus < 201103L */
> +#else /* !defined(__cplusplus) */
> +# define __nitems(arr) (sizeof((arr)) / sizeof((arr)[0]))
> +# define nitems(arr) (__nitems(arr) + __must_be_array(arr))
> +#endif /* !defined(__cplusplus) */
> +
>
> #endif /* sys/param.h */
>
Re: Ping(3): [PATCH v4] : Add nitems()
I've asked the WG14 reflector why N2529 (and N2530, though that one's not relevant to this feature) doesn't seem to have made it onto a meeting agenda yet, when there have been two WG14 meetings since that proposal was made and a third one coming up. -- Joseph S. Myers jos...@codesourcery.com
Re: Ping(3): [PATCH v4] : Add nitems()
Hi Joseph, On 11/17/20 11:44 PM, Joseph Myers wrote: > I've asked the WG14 reflector why N2529 (and N2530, though that one's not > relevant to this feature) doesn't seem to have made it onto a meeting > agenda yet, when there have been two WG14 meetings since that proposal was > made and a third one coming up. > Nice! Please update me on any feedback you receive. So glibc will basically hold this patch at least until the WG answers to that, right? Thanks, Alex
Re: Ping(3): [PATCH v4] : Add nitems()
On Tue, 17 Nov 2020, Alejandro Colomar via Libc-alpha wrote: > Nice! > Please update me on any feedback you receive. Apparently the author is planning new versions of those papers so WG14 discussion is waiting for those. > So glibc will basically hold this patch > at least until the WG answers to that, right? I think that whether C2x gets an array-size feature of some kind is relevant to whether such a feature goes in glibc and what it looks like in glibc, but the fact that it will be considered in WG14 doesn't rule out glibc considering such a feature without waiting for WG14. -- Joseph S. Myers jos...@codesourcery.com
