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 serio
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 so
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
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
--
R
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 their
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 assignmen
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:
https://gcc.gnu.org/pipermail/gcc-patches/2020-Jun
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 associa
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 a
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 __attribut
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 to
As Martin Sebor points out, the ChangeLog entries should not be included
in the patch. So I have removed those. I also made some changes to this
patch that were necessary because of changes to the other patch.
See the patch below:
From 676b6436835434f89c8511cd68e89947c32f11c6 Mon Sep 17 00:00:00 2
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 you
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
Hello,
I accidentally used Init(1) for the option instead of Init(0). The
correction is as follows:
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 15bbb8e69f7..8bfa28e5f6c 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -1192,7 +1192,7 @@ C ObjC C++ ObjC++ LTO LangEnabledBy
gcc/ChangeLog:
* doc/invoke.texi: Document -Wuniversal-initializer.
gcc/c-family/ChangeLog:
* c.opt: Add -Wuniversal-initializer
gcc/c/ChangeLog:
* c-typeck.c (pop_init_level): Don't suppress warnings about { 0 }
if warn_zero_init.
gcc/testsuite/ChangeLog:
Hello,
I accidentally wrote 'free(loc)' instead of 'free (loc)'. Please see the
fixed patch attached below (contrib/check_GNU_style.sh says it's OK
now):
From 0445fba96ee9030feb00ebec893f8dfed153b12d Mon Sep 17 00:00:00 2001
From: Asher Gordon
Date: Wed, 3 Jun 2020 17:20:08 -0400
Subject: [PATCH]
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,
rem
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
-Wdesignated-init
20 matches
Mail list logo
