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]

Re: -Wstrict-aliasing in 2.95/6?


Martin v. Loewis wrote:
> > Someone said `memcpy' in general doesn't have aliasing problems, and in
> > fact `memcpy' is often the _only_ safe way to access the bit pattern of
> > one type as another.  (The union suggestion is apparently specific
> > to a quirk of GCC's implementation).
> 
> That's because the 'right' memcpy implementation operates on char*.

No real one does though :-)
So as soon as global program optimisation is implemented,
every program in existence will break, yes? :-)

> > So it's Linux' implementation of __constant_memcpy that has an aliasing
> > bug?  I guess that one can be fixed if there's a fix.
> 
> There is no fix. If you use int* to do the copy, you lose because it
> is wrong. If you use char*, you use because it is inefficient.
> 
> People have been trying to use __builtin_memcpy instead. That works
> fine, but the approach dies when it comes to __builtin_memset which is
> only __builtin_bzero.

Gak.  That's terrible.  There isn't any way to write decent memcpy,
image processing etc.?  [-- but please if you respond do it in a
different thread]

> > >#define TCP_IPV4_MATCH(__sk, __cookie, __saddr, __daddr, __ports, __dif)\
> > >        (((*((__u64 *)&((__sk)->daddr)))== (__cookie))  &&              \
> > >         ((*((__u32 *)&((__sk)->dport)))== (__ports))   &&              \
> > >         (!((__sk)->bound_dev_if) || ((__sk)->bound_dev_if == (__dif))))
> [...]
> > Apparently this occurs a lot in the kernel.
> 
> Ok. This is a conversion between different pointer-to-integral-types.
> I forgot: Under the your most recent proposal; would you warn here?

Yes, and only when there's a bug.  Under the proposal, the type-based
aliasing rules are applied to see if the pointer destination types don't
alias:

      - Any conversion from pointer-to-A to pointer-to-B where
        type-based aliasing determines that A and B do not alias.
        (But conversion to/from `void *' never warns).

I also had this, but I've decided against it for this warning, as it is
actually quite a common, legitimate operation:

      - Any conversion from pointer-to-A to/from a non pointer type.

-- Jamie


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