Joseph Myers writes:
> I've tested and committed the first patch.
Great, thanks!
> The second one introduces some test failures:
>
> [...]
>
> Could you investigate those and send versions of the second and third
> patches that don't introduce any test regressions?
I've also found a more
On Wed, 22 Jul 2020, Asher Gordon via Gcc-patches wrote:
> Hello Joseph, Martin,
>
> Asher Gordon writes:
>
> > Joseph Myers writes:
> >
> >> I don't see you in the FSF copyright assignment list; could you
> >> complete
> >>
Hello,
Jeff Law writes:
>> Is there any reason my patches haven't been applied yet? Is there
>> anything else I need to do?
> No, nothing you really need to do. We're backed up more than usual,
> but yours is definitely in the queue.
It's been a while. Any chance of getting my patch applied
Hi Jeff,
Jeff Law writes:
> On Mon, 2020-08-03 at 14:47 -0400, Asher Gordon via Gcc-patches wrote:
>> Is there any reason my patches haven't been applied yet? Is there
>> anything else I need to do?
> No, nothing you really need to do. We're backed up more than usual, but
> yours is
>
On Mon, 2020-08-03 at 14:47 -0400, Asher Gordon via Gcc-patches wrote:
> Hello,
>
> Asher Gordon writes:
>
> > My copyright assignment finally got finished, so you should be able to
> > apply my patches now.
>
> Is there any reason my patches haven't been applied yet? Is there
> anything else
Joseph Myers writes:
> These patches are on my list for review as and when I get time, if no-one
> else gets to them first. I don't believe there is anything else you need
> to do at present.
Ah, that's fine. I just wanted to make sure you haven't forgotten about
it. :-)
Thanks,
Asher
--
On Mon, 3 Aug 2020, Asher Gordon via Gcc-patches wrote:
> Hello,
>
> Asher Gordon writes:
>
> > My copyright assignment finally got finished, so you should be able to
> > apply my patches now.
>
> Is there any reason my patches haven't been applied yet? Is there
> anything else I need to do?
Hello,
Asher Gordon writes:
> My copyright assignment finally got finished, so you should be able to
> apply my patches now.
Is there any reason my patches haven't been applied yet? Is there
anything else I need to do?
Thanks,
Asher
--
eek, not another one...
Seems ever developer and
Hello Joseph, Martin,
Asher Gordon writes:
> Joseph Myers writes:
>
>> I don't see you in the FSF copyright assignment list; could you
>> complete
>> https://git.savannah.gnu.org/cgit/gnulib.git/plain/doc/Copyright/request-assign.future
>> (unless you're already covered by an employer
Joseph Myers writes:
> I think both the patches in this discussion (special { 0 } handling
> and the new warning option) generally look good.
I also wrote another small patch, which you might have missed since it's
buried in the discussion here:
I think both the patches in this discussion (special { 0 } handling and
the new warning option) generally look good. I don't see you in the FSF
copyright assignment list; could you complete
https://git.savannah.gnu.org/cgit/gnulib.git/plain/doc/Copyright/request-assign.future
(unless you're
On Wed, 24 Jun 2020, Asher Gordon via Gcc-patches wrote:
> I see. So perhaps this isn't the best way to go about implementing
> attribute locations. What do you think would be a better way? Perhaps
> using a DECL_MINIMAL for attributes?
In general, too many things in GCC have the static type
Martin Sebor writes:
> I have no experience with changing tree nodes but I wouldn't be
> surprised if there were assumptions baked into code that made it
> a non-trivial exercise.
>
> There's also lots of sharing of data in GCC so I'm not sure it
> makes sense for an identifier to have an
On 6/24/20 2:15 PM, Asher Gordon wrote:
Hi Martin,
Asher Gordon writes:
Martin Sebor writes:
Unfortunately, attributes don't have locations (yet).
Hmm, well maybe I could implement that. I'm not very familiar with the
GCC source (this is my first patch), but I'll see if I can figure it
Hi Martin,
Asher Gordon writes:
> Martin Sebor writes:
>
>> Unfortunately, attributes don't have locations (yet).
>
> Hmm, well maybe I could implement that. I'm not very familiar with the
> GCC source (this is my first patch), but I'll see if I can figure it
> out. It would probably be useful
Hi Martin,
Thanks for your help.
Martin Sebor writes:
> This can be a little confusing and I don't work with the front end
> stuff often enough to remember it so I always have to look it up.
> There's a TYPE_DECL that corresponds to the definition of the type
> that for user-defined types has
On 6/14/20 11:05 AM, Asher Gordon wrote:
Hello,
Asher Gordon writes:
I also added a note after the warning showing where the field was
defined in the structure, like this:
inform (DECL_SOURCE_LOCATION (info.field),
"in definition of %qT", constructor_type);
However, I
Hi,
Any chance of this patch getting applied soon?
Asher Gordon writes:
> Actually, it would be ideal to point to the attribute itself, so a
> note something like the following could be produced:
>
> test.c:4:22: note: ‘designated_init’ attribute applied here
> 4 | struct
Hello,
Asher Gordon writes:
> I also added a note after the warning showing where the field was
> defined in the structure, like this:
>
> inform (DECL_SOURCE_LOCATION (info.field),
> "in definition of %qT", constructor_type);
>
> However, I think it would be preferable to point
Martin Sebor writes:
> On 6/8/20 7:07 PM, Asher Gordon wrote:
>>
>> OK, these will be easy to fix. Should my other patch¹ (which implements
>> -Wuniversal-initializer) also have PR c/95379?
>
> I'm sure that would be fine but since it's a separate enhancement
> it doesn't need to. It's up to
On 6/8/20 7:07 PM, Asher Gordon wrote:
Hi Martin,
Thanks for your helpful comments.
Martin Sebor writes:
As an aside, the bug number should be referenced in the change
message so that when the patch is committed it's automatically
reflected in the bug entry. The contrib/mklog.py script
Hi Martin,
Thanks for your helpful comments.
Martin Sebor writes:
> As an aside, the bug number should be referenced in the change
> message so that when the patch is committed it's automatically
> reflected in the bug entry. The contrib/mklog.py script should
> do that automatically based on
0445fba96ee9030feb00ebec893f8dfed153b12d Mon Sep 17 00:00:00 2001
From: Asher Gordon
Date: Wed, 3 Jun 2020 17:20:08 -0400
Subject: [PATCH] Treat { 0 } specially for structs with the designated_init
attribute.
Closes #95379.
I think the idea behind this change is fine. I just have a few
minor comments
] Treat { 0 } specially for structs with the designated_init
attribute.
Closes #95379.
gcc/ChangeLog:
* doc/extend.texi: Document { 0 } as a special case for the
designated_init attribute.
gcc/c/ChangeLog:
* c-typeck.c (struct location_list): New type.
(struct initializer_stack): Add
Asher Gordon writes:
> Also note that this patch does not implement a -Wno-designated-init
> flag, but that shouldn't be too hard to implement.
Sorry, I meant -Wno-universal-initializer, not -Wno-designated-init.
Asher
--
Vimes grunted. "Where there are policemen there's crime, sergeant,
Closes #95379.
gcc/ChangeLog:
* doc/extend.texi: Document { 0 } as a special case for the
designated_init attribute.
gcc/c/ChangeLog:
* c-typeck.c (struct location_list): New type.
(struct initializer_stack): Add positional_init_locs for
26 matches
Mail list logo
