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
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 o
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
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++),
> t
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
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'
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
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
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;
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
constr
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
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 catal
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 enco
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). (Ch
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
> .p
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 not
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 occasional
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 o
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+
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
20 matches
Mail list logo
