From: Martin Sebor <msebor@gmail.com>
To: gcc-patches <gcc-patches@gcc.gnu.org>, Jeff Law <law@redhat.com>
Subject: [PING][PATCH] improve validation of attribute arguments (PR c/78666)
Date: Thu, 16 Jul 2020 16:53:08 -0600 [thread overview]
Message-ID: <472bac11-ecc0-4507-eba0-e7248e732d5b@gmail.com> (raw)
In-Reply-To: <7bd10461-bc28-c889-d42e-9088cd3794dd@gmail.com>
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549686.html
(Jeff, I forgot to mention this patch when we spoke earlier today.)
On 7/8/20 6:01 PM, Martin Sebor wrote:
> GCC has gotten better at detecting conflicts between various
> attributes but it still doesn't do a perfect job of detecting
> similar problems due to mismatches between contradictory
> arguments to the same attribute. For example,
>
> __attribute ((alloc_size (1))) void* allocate (size_t, size_t);
>
> followed by
>
> __attribute ((alloc_size (2))) void* allocate (size_t, size_t);
>
> is accepted with the former overriding the latter in calls to
> the function. Similar problem exists with a few other attributes
> that take arguments.
>
> The attached change adds a new utility function that checks for
> such mismatches and issues warnings. It also adds calls to it
> to detect the problem in attributes alloc_align, alloc_size, and
> section. This isn't meant to be a comprehensive fix but rather
> a starting point for one.
>
> Tested on x86_64-linux.
>
> Martin
>
> PS I ran into this again while debugging some unrelated changes
> and wondering about the behavior in similar situations to mine.
> Since the behavior seemed clearly suboptimal I figured I might
> as well fix it.
>
> PPS The improved checking triggers warnings in a few calls to
> __builtin_has_attribute due to apparent conflicts. I've xfailed
> those in the test since it's a known issue with some existing
> attributes that should be fixed at some point. Valid uses of
> the built-in shouldn't trigger diagnostics except for completely
> nonsensical arguments. Unfortunately, the line between valid
> and completely nonsensical is a blurry one (GCC either issues
> errors, or -Wattributes, or silently ignores some cases
> altogether, such as those that are the subject of this patch)
> and there is no internal mechanism to control the response.
next prev parent reply other threads:[~2020-07-16 22:53 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-09 0:01 [PATCH] " Martin Sebor
2020-07-16 22:53 ` Martin Sebor [this message]
2020-07-26 17:41 ` [PING 2][PATCH] " Martin Sebor
2020-08-10 16:50 ` [PING 3][PATCH] " Martin Sebor
2020-08-20 21:00 ` [PATCH] " Aldy Hernandez
2020-08-20 23:37 ` Martin Sebor
2020-08-24 10:59 ` Aldy Hernandez
2020-08-24 16:45 ` Martin Sebor
2020-08-25 5:51 ` Aldy Hernandez
2020-09-09 21:44 ` [PING][PATCH] " Martin Sebor
2020-09-15 23:15 ` Joseph Myers
2020-09-16 20:25 ` Martin Sebor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=472bac11-ecc0-4507-eba0-e7248e732d5b@gmail.com \
--to=msebor@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=law@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).