Re: (C++) mangling vector types
On Thu, Nov 12, 2009 at 5:57 PM, Mark Mitchell m...@codesourcery.com 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 with the advent of the Intel AVX extension. 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 version 4. How is mangling orthogonal to the ABI? -- Gaby
Re: (C++) mangling vector types
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 version 4. How is mangling orthogonal to the ABI? It's certainly possible to have ABIv2-with-vector-change and ABIv2-without. I never claimed that they were the same ABI. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: (C++) mangling vector types
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 ❖
Re: (C++) mangling vector types
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 to the current ABI v3. b) Take over -fabi-version=3 and bump the template arg change to v4. c) Use -fabi-version=2.1. d) Use a separate flag to control vector mangling. I vote for [^cd]. I have no preference between v3 and v4, but a separate flag seems weird, as does injecting a version number in between 2 and 3. r~
Re: (C++) mangling vector types
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 sizes. 3) Switch to the new mangling I vote for 2. Does anyone know of another relevant compiler? What does it do? For instance, if someone can hand me a test case, I could check how ARM's compilers mangle it (or don't). -- Daniel Jacobowitz CodeSourcery
Re: (C++) mangling vector types
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 alias with the old mangling, old external references will resolve to somthing, so code that only uses one vector size will continue to work; if newer code uses multiple vector sizes then references in old code may resolve to the wrong one, but that seems unavoidable. I suppose that is the best solution, as a partial rebuild of an old code base should continue to work in all cases, and all new code will also work fine. Jason
Re: (C++) mangling vector types
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, so code that only uses one vector size will continue to work; Really? How'd you create code with the new compiler and older libraries which only provide definitions for the old names? If I'm not missing anything then using a 2.1 ABI version makes sense since it is upward compatible, other than other ABI breakages. -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
Re: (C++) mangling vector types
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 (SSE, Altivec) and use the new mangling for other vector sizes. 3) Switch to the new mangling I vote for 2. Does anyone know of another relevant compiler? What does it do? For instance, if someone can hand me a test case, I could check how ARM's compilers mangle it (or don't). It seems clear to me that on ARM, generic vectors corresponding to NEON vector types should be mangled the same as the corresponding NEON types (whose mangling is specified in AAPCS), even when NEON is disabled, just as they follow AAPCS for argument passing and return (including when the VFP ABI is enabled and VFP but not NEON is supported). (Since generic vectors may have other combinations of element type and size than those supported by NEON and listed in AAPCS, the general issue does still apply on ARM for such other generic types.) -- Joseph S. Myers jos...@codesourcery.com
Re: (C++) mangling vector types
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, old external references will resolve to somthing, so code that only uses one vector size will continue to work; Really? How'd you create code with the new compiler and older libraries which only provide definitions for the old names? Ah, good point. That would require some sort of really weak definition. Jason
Re: (C++) mangling vector types
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 I vote for 2. Me too. Never break backwards compatibility unless really necessary. We might want to note these special cases in the actual ABI document, since my impression is that most other compilers are trying to follow G++. 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, seems odd to me; there's nothing particularly more or less different about this change then other mangling changes, as far as I can tell. It's another case where we've discovered an inability to implement the full language with the current scheme, and have therefore been forced to make a change. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: (C++) mangling vector types
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, seems odd to me; there's nothing particularly more or less different about this change then other mangling changes, as far as I can tell. It's another case where we've discovered an inability to implement the full language with the current scheme, and have therefore been forced to make a change. 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 template arg change. Jason
Re: (C++) mangling vector types
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 emit a weak alias with the old mangling, old external references will resolve to somthing, so code that only uses one vector size will continue to work; Really? How'd you create code with the new compiler and older libraries which only provide definitions for the old names? Ah, good point. That would require some sort of really weak definition. Jason :) Wow, that'd be probably the first time ever windows platform semantics would turn out to support C++ better than ELF semantics! (We have 'really weak' definitions, in fact it's the only kind we have...) cheers, DaveK
Re: (C++) mangling vector types
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 template arg change. 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 space, rather than just a numerical version. That sounds theoretically right to me, but awfully complicated in practice. Do we have another libstdc++ ABI change coming? I'd suggest doing this as -fabi-version=4, and making that the default at that point. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: (C++) mangling vector types
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 space, rather than just a numerical version. 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. That sounds theoretically right to me, but awfully complicated in practice. Do we have another libstdc++ ABI change coming? I'd suggest doing this as -fabi-version=4, and making that the default at that point. We do; once C++0x is finalized we will need to switch to non-refcounted strings and support constant time list.size(). But I believe the plan is to manage that transition with namespace versioning so that old and new code can continue to coexist as long as they aren't actually trying to share affected data structures. Jason
Re: (C++) mangling vector types
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. (Presumably 4 would contain both the change in 3 and the change in 2.1, so the ordering becomes sensible from that point forward again.) Do we have another libstdc++ ABI change coming? I'd suggest doing this as -fabi-version=4, and making that the default at that point. We do; once C++0x is finalized we will need to switch to non-refcounted strings and support constant time list.size(). But I believe the plan is to manage that transition with namespace versioning so that old and new code can continue to coexist as long as they aren't actually trying to share affected data structures. 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.) Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: (C++) mangling vector types
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 thinking, but perhaps it does make sense to make that change with the C++0x library deployment; the impact should be pretty limited. I'm surprised to see that EDG doesn't mimic this bug in G++ compatibility mode; in fact, they get mangle22.C wrong in a different way. The symbol should be _Z1g2CBIL_Z3foocEE -fabi-version=2 gives _Z1g2CBILZ3foocEE and EDG 4.1 gives _Z1g2CBIXL_Z3foocEEE (extra X/E around the name even though it's an expr-primary). Jason
Re: (C++) mangling vector types
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, but perhaps it does make sense to make that change with the C++0x library deployment; the impact should be pretty limited. I'd also expect that on embedded systems (even embedded GNU/Linux systems) people won't want the compatibility stuff in libstdc++. There's not much benefit in backwards compatibility if you're building everything for your new device, and a lot of benefit in making your binaries smaller. 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 case. I guess another option is -fabi-version=implement-c++-for-petes-sake which means use the ABI that implements as much of the language as possible. That would be your version 2.1, but arguably more logically coherent in that it would be expected to move in the future if/when we find another feature we can't implement due to current mangling issues. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: (C++) mangling vector types
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 case. 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. I guess another option is -fabi-version=implement-c++-for-petes-sake which means use the ABI that implements as much of the language as possible. That would be your version 2.1, but arguably more logically coherent in that it would be expected to move in the future if/when we find another feature we can't implement due to current mangling issues. That seems useful, but I would also want a way to specify a particular revision. Jason
Re: (C++) mangling vector types
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 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 version 4. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
