[cfe-dev] Using both OpenCL and GCC vectors
Yung, Douglas via cfe-dev
cfe-dev at lists.llvm.org
Fri Feb 5 17:46:48 PST 2016
Hi Renato,
> There's a big difference between acting on unambiguous scenarios and
> "being smart". Compilers are generally safer if they don't do the
> latter.
I agree with you here.
> > For example, the compiler could recognize that it is generating the
> > same function when instantiating the second instance of foo and reuse
> > the first one instead of creating another one. This would prevent the
> > creation of two identically mangled names which caused the error seen
> above.
>
> Why is this case more special than any other mangling conflict that
> should correctly be refused?
>
> What if I created a class that behaves *exactly* like a double and had:
>
> foo<double>() {}
> foo<MyDouble>() {}
>
> would you expect the compiler to know what you mean?
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.
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?
foo<int>() {}
foo<double>() {}
I would argue it is not okay, and that is what is happening here with the two vector types.
> > Or perhaps the
> > compiler could be smarter and when it encounters the second
> > instantiation of foo, it would issue an error at that point with a
> useful diagnostic.
>
> That's a much better approach, but "being smart" again, is easy for you
> to assess on your particular case, but harder for the compiler to do
> the right thing (tm) on every case.
Again I agree, but was just referencing this specific vector case when I was suggesting the compiler could be smarter.
Douglas Yung
More information about the cfe-dev
mailing list