This is the mail archive of the gcc-patches@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: [patch i386]:Ensure intrinsic functions are declared "C"


On 05/12/2010 11:10 AM, Richard Guenther wrote:
On Wed, May 12, 2010 at 5:07 PM, Jason Merrill<jason@redhat.com> wrote:
You'd only get an ODR violation if you have a class/enum/inline/template
defined in multiple translation units that uses the intrinsics but sometimes
sees the definitions in xmmintrin and sometimes not.

Can you show us a testcase that shows an example of the conflict?

a.h:


inline __m128 myfn (__m128 m) { ...code that uses intrinsics... }

a.C:

#include <windowsheader.h>
#include "a.h"

void f ()
{
  ...myfn(...
}

b.C:

#include <xmmintrin.h>
#include "a.h"

void g ()
{
  ...myfn(...
}

-----------

So in both a.C and b.C myfn is using intrinsics. But in a.C it's using the external definitions, and in b.C it's using the inline definitions from xmmintrin.h. I wouldn't expect this to be a problem in practice (surely the semantics are the same either way), but technically myfn would violate the ODR.

Of course, if a.h included xmmintrin.h itself so that it doesn't rely on being included after something else that provides the declarations it needs, this couldn't happen.

I don't think this issue is significant compared to the problem of people not being able to include both xmmintrin.h and the relevant windows header in the same translation unit.

Jason


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