This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: PATCHes to SIMD vector mangling (more c++/12909)
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Jason Merrill <jason at redhat dot com>
- Cc: gcc-patches List <gcc-patches at gcc dot gnu dot org>, Richard Henderson <rth at redhat dot com>, Ulrich Drepper <drepper at redhat dot com>
- Date: Thu, 25 Feb 2010 09:49:19 -0800
- Subject: Re: RFC: PATCHes to SIMD vector mangling (more c++/12909)
- References: <4B857CFF.3070908@redhat.com> <4B85B5AB.7010702@codesourcery.com> <4B86A79F.5010900@redhat.com>
Jason Merrill wrote:
> The problem with not having the first patch is that it means that
> overloading on vectors of different sizes fails with a multiply-defined
> symbol error from the assembler or linker, or even silent wrong code if
> the definitions are weak and in different objects.
Ugh, I see.
> If we don't apply
> the first patch, I'd like to turn on -Wabi by default so that people at
> least get a warning about it.
We're then going to warn about other stuff, not related to this problem.
For that matter, we're going to warn about vector code that doesn't
have multiple overloads, has always worked, and hasn't been changed.
I think we're trying awfully hard, in the context of FSF GCC, to make
this work. I see why this makes complete sense in a workstation/server
Linux distribution compiler, where people are downloading third-party
applications to work with distribution libraries and such.
But, outside that context there's a really simple answer: use the later
version of the ABI. That's always been our answer in the past; we bump
up the default ABI version, and let people who really want
backwards-compatibility use -fabi-version= to go backwards. Even for
folks on an embedded Linux system, who aren't upgrading things over
time, there's no reason not to do that.
I don't like the choices here. We have a useful feature (vector stuff)
that we can't presently use fully because of a mangling problem. We
have a mangling fix, but we don't want to change the default ABI until
libstdc++ is ready to change as well to avoid ABI churn. Your solution
to these problems is to create cruft in the compiler to spare the user.
I think that's probably the right solution, but only up to a point.
I guess my feeling is that we should do the second patch (which you've
cleverly done in a very contained, forward-compatible way in the
compiler), but not change -Wabi.
--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713