The G++ mangling of SIMD vector types (SSE, Altivec, etc.) is
fundamentally broken as it doesn't currently encode the size of the
vector, only the element type. So overloading of different size vectors
fails. It seems when I implemented this I was modeling the Altivec
__vector qualifier, whic
On 11/12/2009 07:24 AM, Jason Merrill wrote:
c) Use -fabi-version=2.1.
I'd favor this if you can emit aliases with the old names wherever this
is possible and currently done.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
On 11/12/2009 07:24 AM, Jason Merrill wrote:
1) Leave the current mangling as is
2) Leave the current mangling as is for the most common vector size on a
target (SSE, Altivec) and use the new mangling for other vector sizes.
3) Switch to the new mangling
I vote for 2.
a) Add the vector change
On Thu, Nov 12, 2009 at 08:10:13AM -0800, Richard Henderson wrote:
> On 11/12/2009 07:24 AM, Jason Merrill wrote:
> >1) Leave the current mangling as is
> >2) Leave the current mangling as is for the most common vector size on a
> >target (SSE, Altivec) and use the new mangling for other vector siz
On 11/12/2009 11:14 AM, Ulrich Drepper wrote:
On 11/12/2009 07:24 AM, Jason Merrill wrote:
c) Use -fabi-version=2.1.
I'd favor this if you can emit aliases with the old names wherever this
is possible and currently done.
I suppose if we unconditionally use the new mangling and emit a weak
a
On 11/12/2009 08:35 AM, Jason Merrill wrote:
I'd favor this if you can emit aliases with the old names wherever this
is possible and currently done.
I suppose if we unconditionally use the new mangling and emit a weak
alias with the old mangling, old external references will resolve to
somthing
On Thu, 12 Nov 2009, Daniel Jacobowitz wrote:
> On Thu, Nov 12, 2009 at 08:10:13AM -0800, Richard Henderson wrote:
> > On 11/12/2009 07:24 AM, Jason Merrill wrote:
> > >1) Leave the current mangling as is
> > >2) Leave the current mangling as is for the most common vector size on a
> > >target (SS
On 11/12/2009 11:50 AM, Ulrich Drepper wrote:
On 11/12/2009 08:35 AM, Jason Merrill wrote:
I'd favor this if you can emit aliases with the old names wherever this
is possible and currently done.
I suppose if we unconditionally use the new mangling and emit a weak
alias with the old mangling, o
Richard Henderson wrote:
> On 11/12/2009 07:24 AM, Jason Merrill wrote:
>> 1) Leave the current mangling as is
>> 2) Leave the current mangling as is for the most common vector size on a
>> target (SSE, Altivec) and use the new mangling for other vector sizes.
>> 3) Switch to the new mangling
>
>
On 11/12/2009 01:18 PM, Mark Mitchell wrote:
b) Take over -fabi-version=3 and bump the template arg change to v4.
I'm not sure what "take over" means, but I think this change should be
in v4. People might be using v3, and we shouldn't break their world.
Introducing 2.1, or a separate flag, see
Jason Merrill wrote:
> On 11/12/2009 11:50 AM, Ulrich Drepper wrote:
>> On 11/12/2009 08:35 AM, Jason Merrill wrote:
I'd favor this if you can emit aliases with the old names wherever this
is possible and currently done.
>>>
>>> I suppose if we unconditionally use the new mangling and emi
Jason Merrill wrote:
> There is a difference from v3, which is just a correction to match the
> ABI document; it doesn't prevent us from implementing the full language,
> which is why we never bumped the default. So I would like to be able to
> make the vector change without also making the templ
On 11/12/2009 04:32 PM, Mark Mitchell wrote:
I understand the argument, but it sounds overly complicated. Or else
not complicated enough. If we no longer think that a linear progression
of ABI versions is sufficient, then we should have switches for picking
your point in the multi-dimensional s
Jason Merrill wrote:
> I think that a linear progression is sufficient, but I want an
> additional point between 2 and 3 since 2 is the current default and 3
> already has meaning. Thus the 2.1 suggestion.
But, there's no longer a total ordering on ABIs; 3 isn't "bigger than"
2.1 anymore. (Pres
On 11/12/2009 04:48 PM, Mark Mitchell wrote:
So, do you consider ABIv3 there only as a theoretical conformance
option? In other words, not something we're going to make the default
in any forseeable future? (Those aren't meant to be rhetorical
questions -- I'm just asking.)
That has been my t
Jason Merrill wrote:
>> So, do you consider ABIv3 there only as a theoretical conformance
>> option? In other words, not something we're going to make the default
>> in any forseeable future? (Those aren't meant to be rhetorical
>> questions -- I'm just asking.)
>
> That has been my thinking, b
On 11/12/2009 05:19 PM, Mark Mitchell wrote:
So, I still tend to think that the best thing is to put the vector stuff
into v4, and switch that on when we update libstdc++. I think your
suggest is coherent and well-reasoned, but it seems like a lot of
complexity to deal with a template corner cas
Jason Merrill wrote:
> It isn't such a corner case, unfortunately; any code that tries to
> overload on multiple vector sizes (i.e. MMX and SSE vectors) will break.
> See bug 12909 and its duplicates. This is becoming more of a problem
> with the advent of the Intel AVX extension.
This still se
On Thu, Nov 12, 2009 at 5:57 PM, Mark Mitchell wrote:
> Jason Merrill wrote:
>
>> It isn't such a corner case, unfortunately; any code that tries to
>> overload on multiple vector sizes (i.e. MMX and SSE vectors) will break.
>> See bug 12909 and its duplicates. This is becoming more of a problem
Gabriel Dos Reis wrote:
>> This still seems a lot of complexity to me, and I still think inserting
>> a new version between 2 and 3 is odd. If we need the complexity, I
>> think we have to introduce a new orthogonal option for vector mangling,
>> independent of the ABI version, but implied by ABI
20 matches
Mail list logo
