This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Issue with sub-object __builtin_object_size
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Ulrich Weigand <uweigand at de dot ibm dot com>
- Cc: jason at redhat dot com, gcc at gcc dot gnu dot org
- Date: Mon, 15 Sep 2014 17:32:14 +0200
- Subject: Re: Issue with sub-object __builtin_object_size
- Authentication-results: sourceware.org; auth=none
- References: <20140610175002 dot GI19001 at tucnak dot redhat dot com> <201409151521 dot s8FFLoNw026684 at d06av02 dot portsmouth dot uk dot ibm dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Mon, Sep 15, 2014 at 05:21:50PM +0200, Ulrich Weigand wrote:
> > The thing is that the C++ FE transforms this kind of cast to
> > &((struct Pollfd *) &myfd)->D.2233
> > so for middle-end where __builtin_object_size is evaluated this
> > is like:
> > struct Pollfd { struct pollfd something; };
> > struct Pollfd myfd[10];
> > int test (void)
> > {
> > return __builtin_object_size (&myfd[0].something, 1);
> > }
> > and returning 8 in that case is completely correct.
> > So the question is why instead of a simple cast it created
> > ADDR_EXPR of a FIELD_DECL instead.
>
> Sorry for the long delay, I finally found time to look into this
> problem again. This behavior of the C++ front-end seems to trace
> back to a deliberate change by Jason here:
> https://gcc.gnu.org/ml/gcc-patches/2004-04/msg02000.html
>
> "This patch changes the representation to b.<A base field>.i,
> which is more friendly to alias analysis."
>
> It still seems the effect of this on __builtin_object_size is
> surprising and probably not what was intended. I'm not sure
> whether the front-end or the middle-end is more "at fault" here.
>
> Thoughts?
I'm afraid there is nothing the middle-end can do here.
It could try to ignore DECL_ARTIFICIAL fields, but that would still
mean &myfd[0] rather than what has been written in the source, which would
still give you smaller size than you are expecting.
Jakub