[cfe-dev] Using both OpenCL and GCC vectors

Renato Golin via cfe-dev cfe-dev at lists.llvm.org
Sat Feb 6 06:40:23 PST 2016


On 6 February 2016 at 01:46, Yung, Douglas
<douglas_yung at playstation.sony.com> wrote:
> The main difference between your example and the one I gave was that both of the types in my original example are types provided by the compiler, and not something that the user created. Because of this issue, a user could create a program which fails to compile using only types provided by the compiler.

The dangers of treating compiler-specific types differently than user
types is that the compiler types can change with time, lose the
similarity and either you now generate broken code, or code that your
users are not expecting.

That was my point about "being smart".

A "smart" compiler can deduce special properties of its internal
implementations, and as long as the users know what that means, the
code is as expected. Once the meaning changes, the compiler is still
being "smart", but in an unexpected way, because the users don't know
it changed, and then for the class of users where the behaviour
changes, the compiler is now "dumb", while for the rest it's still
"smart". Surely you can see that this is a bad situation to be put in.


> For example, consider what would happen if the int and float types had the same mangling. Would it be proper that the compiler would now reject the following code even though float and double are unique types?

Absolutely, yes! The error here is about the final symbol, and if you
can't tell them apart, then why, you have an ambiguity. It's as simple
as that. That's why the standard spends so much space defining
mangling, it IS important to get it right, otherwise linkers wouldn't
know what to do. You don't want to push your "smart" solution all the
way down the linker.

If the types are different, but mangle in the same way, the correct
behaviour here is to either:

1. Mangle them differently, but that will break ABI compatibility and
you'll end up with template implementation explosion of identical
functions.

2. Error out with re-defined symbol, but in a way to identify the
source of the error. (Clang errs here). The user then changes the
source to use the same compiler type.


> Again I agree, but was just referencing this specific vector case when I was suggesting the compiler could be smarter.

Smart is always relative and personal. Compilers need to be correct
and unambiguous.

cheers,
--renato



More information about the cfe-dev mailing list