This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Issue with sub-object __builtin_object_size

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:
> "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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]