Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] predefined ompi_t types break strict-aliasing rules
From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2009-05-05 12:29:42

It took a little longer than expected, but here's the reply from a
friend who works on Apple's C++ compilers (Doug G.; he's previously
posted on this list):

This is more sticky than I expected. My general feeling is that GCC
4.1 is being overly eager in producing this warning: yes, OMPI is
casting from one pointer type or another, where the two pointers to
incomplete types are assumed to never alias. However, it's just a
cast, and you'll never actually be dereferencing these pointers in a
case where there is any problem: once the definitions of
ompi_communicator_t and ompi_predefined_communicator_t are known, we
know they can alias and the compiler will Do The Right Thing (TM).

I don't think it's possible that strict-aliasing could ever result in
a miscompile for communicators, since users can't ever look into their
ompi_communicator_t or ompi_predefined_communicator_t. So, the
explicit cast to (void*) is a reasonable fix to silence the warning.

If you're really paranoid, include the definitions of
ompi_communicator_t and ompi_predefined_communicator_t in mpi.h and
the warning will disappear.

Why does this only happen with GCC 4.1? It *might* be a bug, but it's
more likely to be a "quirk": most of GCC's type-aliasing diagnostics
actually come from the compiler's middle-end, so they're sensitive to
the various optimizations that occur before that pass. Little changes
in the front ends and optimizers can end up affecting which
diagnostics you see. Yuck!

So while icky, I think that your patch might well be the least of
evils. I'll commit. Thanks!

On Apr 30, 2009, at 8:16 AM, Jeff Squyres (jsquyres) wrote:

> On Apr 30, 2009, at 8:07 AM, Number Cruncher wrote:
> > Following the discussion about ABI compatibility and type-punning of
> > non
> > client-visible types, I've attached a patch against 1.3.2 which
> > casts to
> > an opaque (void *) when OMPI_BUILDING is 0.
> >
> > This will prevent the compiler from trying to do any strict-aliasing
> > based optimizations when the definition of the type to cast to is
> > unknown.
> >
> > When builing Open MPI, the (void *) cast is omitted (because of the
> > compiler flag "-DOMPI_BUILDING=1") and the code remains as before.
> >
> > This clears up all warnings for my GCC 4.1 compiler.
> >
> Awesome, thanks!
> I have a request in to a friend who's a C++/compiler guru (he works on
> Apple's next-gen C++ compiler). He promised me an email response to
> my questions about this topic by tomorrow (he was somewhat slammed
> this week).
> --
> Jeff Squyres
> Cisco Systems
> _______________________________________________
> devel mailing list
> devel_at_[hidden]

Jeff Squyres
Cisco Systems