public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
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.


  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).