This is the mail archive of the gcc@gcc.gnu.org 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


Jakub Jelinek wrote:
> On Tue, Jun 10, 2014 at 07:37:50PM +0200, Ulrich Weigand wrote:
> > the following C++ test case:
> > 
> > struct pollfd
> >   {
> >     int fd;
> >     short int events;
> >     short int revents;
> >   };
> > 
> > struct Pollfd : public pollfd { };
> > 
> > struct Pollfd myfd[10];
> > 
> > int test (void)
> > {
> >   return __builtin_object_size ((struct pollfd *)myfd, 1);
> > }
> > 
> > ends up returning 8 from the "test" routine, not 80.
> 
> 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?

Thanks,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com


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