This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] accept all C integer types in function parameters referenced by alloc_align (PR 88363)
- From: Marek Polacek <polacek at redhat dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Martin Sebor <msebor at gmail dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, Jason Merrill <jason at redhat dot com>, Nathan Sidwell <nathan at acm dot org>, Gcc Patch List <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 11 Dec 2018 10:43:24 -0500
- Subject: Re: [PATCH] accept all C integer types in function parameters referenced by alloc_align (PR 88363)
- References: <0f3f1395-adac-8b5f-82e4-e656bf1207fb@gmail.com> <20181211071726.GI12380@tucnak>
On Tue, Dec 11, 2018 at 08:17:26AM +0100, Jakub Jelinek wrote:
> On Mon, Dec 10, 2018 at 04:30:11PM -0700, Martin Sebor wrote:
> > Some of my testing exposed a minor problem in GCC 9's validation
> > of the type of function parameters referred to by attribute
> > positional arguments. Whereas GCC 8 accepts all C integer types,
> > including enumerated types, such as:
> >
> > enum AllocAlign { Align16 = 16, Align32 = 32 };
> >
> > __attribute__ ((alloc_align (1))) void*
> > alloc (size_t, enum AllocAlign)
> >
> > GCC 9 only accepts signed and unsigned integer types. This change
> > (introduced by myself) was unintentional, and a fix for it is in
> > the attached trivial patch. I plan to commit it without approval
> > in the next day or so unless any concerns or suggestions come up.
>
> There is nothing obvious about this, so please don't commit it without
> approval. GCC 8 and older used to accept
I agree that this isn't an obvious change.
> even float or void * or struct arguments and just ignored them.
> I think we need to discuss what types we want to allow without warnings and
> what we should warn.
> As I wrote in the PR, I believe e.g. using alloc_align/alloc_size with
> bool/_Bool is just a clear bug, you can store 0 or 1 in there, but e.g.
> alignment 0 doesn't make sense.
> Enums are on the border line, I'll defer to C/C++ maintainers whether we
> want to include that or not.
For C, I'd allow them (and I think I've made a change to that effect in the
past in the C FE).
Marek