From: Martin Sebor <msebor@gmail.com>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: Joseph Myers <joseph@codesourcery.com>,
GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: RFC: [PATCH] Add warn_if_not_aligned attribute
Date: Wed, 07 Jun 2017 00:11:00 -0000 [thread overview]
Message-ID: <6c6c268d-a40b-cfa9-574c-ad235f9205b7@gmail.com> (raw)
In-Reply-To: <CAMe9rOrq4c-O3MAHkftFJB2ALH9fbC6n9OJRFgm9m3uQazwSaw@mail.gmail.com>
On 06/06/2017 04:57 PM, H.J. Lu wrote:
> On Tue, Jun 6, 2017 at 10:34 AM, Martin Sebor <msebor@gmail.com> wrote:
>> On 06/06/2017 10:59 AM, H.J. Lu wrote:
>>>
>>> On Tue, Jun 6, 2017 at 9:10 AM, Martin Sebor <msebor@gmail.com> wrote:
>>>>
>>>> On 06/06/2017 10:07 AM, Martin Sebor wrote:
>>>>>
>>>>>
>>>>> On 06/05/2017 11:45 AM, H.J. Lu wrote:
>>>>>>
>>>>>>
>>>>>> On Mon, Jun 5, 2017 at 8:11 AM, Joseph Myers <joseph@codesourcery.com>
>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>> The new attribute needs documentation. Should the test be in
>>>>>>> c-c++-common
>>>>>>
>>>>>>
>>>>>>
>>>>>> This feature does support C++. But C++ compiler issues a slightly
>>>>>> different warning at a different location.
>>>>>>
>>>>>>> or does this feature not support C++?
>>>>>>>
>>>>>>
>>>>>> Here is the updated patch with documentation and a C++ test. This
>>>>>> patch caused a few testsuite failures:
>>>>>>
>>>>>> FAIL: gcc.dg/compat/struct-align-1 c_compat_x_tst.o compile
>>>>>>
>>>>>>
>>>>>>
>>>>>> /export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.dg/compat//struct-align-1.h:169:1:
>>>>>>
>>>>>> warning: alignment 1 of 'struct B2_m_inner_p_outer' is less than 16
>>>>>>
>>>>>> FAIL: g++.dg/torture/pr80334.C -O0 (test for excess errors)
>>>>>>
>>>>>>
>>>>>>
>>>>>> /export/gnu/import/git/sources/gcc/gcc/testsuite/g++.dg/torture/pr80334.C:4:8:
>>>>>>
>>>>>> warning: alignment 1 of 'B' is less than 16
>>>>>>
>>>>>
>>>>> Users often want the ability to control a warning, even when it
>>>>> certainly indicates a bug. I would suggest to add an option to
>>>>> make it possible for this warning as well.
>>>>>
>>>>> Btw., a bug related to some of those this warning is meant to
>>>>> detect is assigning the address of an underaligned object to
>>>>> a pointer of a natively aligned type. Clang has an option
>>>>> to detect this problem: -Waddress-of-packed-member. It might
>>>>> make a nice follow-on enhancement to add support for the same
>>>>> thing. I mention this because I think it would make sense to
>>>>> consider this when choosing the name of the GCC option (i.e.,
>>>>> rather than having two distinct but closely related warnings,
>>>>> have one that detects both of these alignment type of bugs.
>>>>
>>>>
>>>>
>>>> A bug that has some additional context on this is pr 51628.
>>>> A possible name for the new option suggested there is -Wpacked.
>>>>
>>>> Martin
>>>
>>>
>>> Isn't -Waddress-of-packed-member a subset of or the same as
>>> -Wpacked?
>>
>>
>> In Clang it's neither. -Waddress-of-packed-member only triggers
>> when the address of a packed member is taken but not for the cases
>> in bug 53037 (i.e., reducing the alignment of a member). It's
>> also enabled by default, while -Wpacked needs to be specified
>> explicitly (i.e., it's in neither -Wall or -Wextra).
>>
>> FWIW, I don't really have a strong opinion about the names of
>> the options. My input is that the proliferation of fine-grained
>> warning options for closely related problems tends to make it
>> tricky to get their interactions right (both in the compiler
>> and for users). Enabling both/all such options can lead to
>> multiple warnings for what boils down to essentially the same
>> bug in the same expression, overwhelming the user in repetitive
>> diagnostics.
>>
>
> There is already -Wpacked. Should I overload it for this?
I'd say yes if -Wpacked were at least in -Wall. But it's
an opt-in kind of warning that's not even in -Wextra, and
relaxing an explicitly specified alignment seems more like
a bug than just something that might be nice to know about.
I would expect warn_if_not_aligned to trigger a warning even
without -Wall (i.e., as you have it in your patch, but with
an option to control it). That would suggest three levels
of warnings:
1) warn by default (warn_if_not_aligned violation)
2) warn with -Wall (using a type with attribute aligned to
define a member of a packed struct)
3) warn if requested (current -Wpacked)
So one way to deal with it would be to change -Wpacked to
take an argument between 0 and 3, set the default to
correspond to the (1) above, and have -Wall bump it up to
(2).
If the equivalent of -Waddress-of-packed-member were to be
implemented in GCC it would probably be a candidate to add
to the (2) above.(*)
This might be more involved than you envisioned. A slightly
simpler alternative would be to add a different option, say
something like -Walign=N, and have it handle just (1) and
(2) above, leaving -Wpacked unchanged.
Martin
PS [*] On a related note, in the Clang discussion of
-Waddress-of-packed-member they briefly considered reusing
-Wcast-align for the same purpose, but decided against it
because it apparently involves an explicit cast. That
doesn't seem to me like a string enough argument not to
change -Wcast-align to trigger on implicit conversions that
increase alignment. (The option is essentially useless on
most targets so this extension would make it generally
useful.)
next prev parent reply other threads:[~2017-06-07 0:11 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-04 15:52 H.J. Lu
2017-06-05 15:11 ` Joseph Myers
2017-06-05 17:45 ` H.J. Lu
2017-06-06 16:07 ` Martin Sebor
2017-06-06 16:11 ` Martin Sebor
2017-06-06 16:59 ` H.J. Lu
2017-06-06 17:35 ` Martin Sebor
2017-06-06 22:57 ` H.J. Lu
2017-06-07 0:11 ` Martin Sebor [this message]
2017-06-07 13:30 ` H.J. Lu
2017-06-08 17:00 ` H.J. Lu
2017-06-08 19:13 ` Martin Sebor
2017-06-09 13:31 ` H.J. Lu
2017-06-15 15:38 ` Martin Sebor
2017-06-15 15:47 ` H.J. Lu
2017-06-15 17:31 ` Joseph Myers
2017-06-16 11:55 ` H.J. Lu
2017-07-06 15:45 ` Joseph Myers
2017-07-08 13:45 ` H.J. Lu
2017-08-17 14:19 ` Joseph Myers
2017-08-17 16:23 ` H.J. Lu
2017-08-18 1:40 ` Jason Merrill
2017-08-21 12:02 ` Szabolcs Nagy
2017-08-21 12:57 ` H.J. Lu
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=6c6c268d-a40b-cfa9-574c-ad235f9205b7@gmail.com \
--to=msebor@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=hjl.tools@gmail.com \
--cc=joseph@codesourcery.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).