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
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 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
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
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 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
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, 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, 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 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, 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 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 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: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
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 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
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
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 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
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
20 matches
Mail list logo
