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.weig...@de.ibm.com
