Re: [RFC] GCC vector extension: binary operators vs. differing signedness
On Thu, Dec 11, 2014 at 4:04 PM, Ulrich Weigand wrote:
> Richard Biener wrote:
>> On Wed, Dec 10, 2014 at 10:09 PM, Ulrich Weigand wrote:
>> > So at the very least, we should bring the documentation in line with the
>> > actual behavior. However, as seen above, that actual behavior is probably
>> > not really useful in any case, at least in C.
>> >
>> >
>> > So I'm wondering whether we should:
>> >
>> > A. Bring C in line with C++ by making the result of a vector binary
>> > operator
>> >use the unsigned type if the two input types differ in signedness?
>> >
>> > and/or
>> >
>> > B. Enforce that both operands to a vector binary operator must have the
>> > same
>> >type (except for opaque vector types) unless -flax-vector-conversions?
>>
>> I suppose the current behavior comes from the idea that C would
>> apply promotion rules to the operands of binary operators. To the extent
>> we can apply the same rules to vector operands we should probably
>> support that. This means that for example
>>
>> 1) promotions that only differ in signedness happen (partly the C frontend
>> behavior)
>> 2) promotions that change the size of the elements and thus the size of
>> the vector happen (probably not a good idea by default)
>> 3) promotions that change the kind of the elements of the vectors
>> (float vs. non-float) happen (probably neither a good idea)
>
> Just to clarify: your 1) is pretty much the same as my A., right?
Yes.
> The difference in behavior between C and C++ seems to originate in different
> implementations in c_common_type vs. cp_common_type:
>
> C has:
>
> /* If one type is a vector type, return that type. (How the usual
> arithmetic conversions apply to the vector types extension is not
> precisely specified.) */
> if (code1 == VECTOR_TYPE)
> return t1;
>
> if (code2 == VECTOR_TYPE)
> return t2;
>
> while C++ has:
>
> if (code1 == VECTOR_TYPE)
> {
> /* When we get here we should have two vectors of the same size.
> Just prefer the unsigned one if present. */
> if (TYPE_UNSIGNED (t1))
> return build_type_attribute_variant (t1, attributes);
> else
> return build_type_attribute_variant (t2, attributes);
> }
>
>
>> I think it's sensible to support 1) by default (also to not regress existing
>> code) but fix it so it applies to C++ as well and accepts both cases
>> in C. And of course fix documentation.
>
> I'm not sure I understand exactly what you mean here. C++ already implements
> the sign promotion rule; just C doesn't. So we could do the same for C as is
> currently done for C++.
Ah, ok. Yes.
> However, if we make that change, there will be some cases that regress: the
> problem is that an expression "x + y" has *one* result type, and some things
> you do with the result will require that type to match precisely (including
> signedness). So *any* change that affects what that result type is will
> regress some code that happened to rely on the precise result type ...
True, but IMHO that's still better. You may want to check the openCL spec
which we tried to follow losely as to what we allow.
So again, implementing your A is ok with me.
Thanks,
Richard.
> Bye,
> Ulrich
>
> --
> Dr. Ulrich Weigand
> GNU/Linux compilers and toolchain
> ulrich.weig...@de.ibm.com
>
RE: Vector modes and the corresponding width integer mode
I don't think it is required. For example, PowerPC port supports V8SImode, but I don't see OImode. Just sometimes it could come handy to have the equal size scalar mode. Cheers, Bingfeng > -Original Message- > From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of > Matthew Fortune > Sent: 11 December 2014 13:27 > To: gcc@gcc.gnu.org > Subject: Vector modes and the corresponding width integer mode > > Hi, > > I'm working on MIPS SIMD support for MSA. Can anyone point me towards > information about the need for an integer mode of equal size to any > supported vector mode? > > I.e. if I support V4SImode is there any core GCC requirement that > TImode is also supported? > > Any guidance is appreciated. The MIPS port already has limited support > for TImode for 64-bit targets which makes it all the more difficult to > figure out if there is a relationship between vector modes and integer > modes. > > Thanks, > Matthew
Re: [RFC] GCC vector extension: binary operators vs. differing signedness
Richard Biener wrote: > On Thu, Dec 11, 2014 at 4:04 PM, Ulrich Weigand wrote: > > However, if we make that change, there will be some cases that regress: the > > problem is that an expression "x + y" has *one* result type, and some things > > you do with the result will require that type to match precisely (including > > signedness). So *any* change that affects what that result type is will > > regress some code that happened to rely on the precise result type ... > > True, but IMHO that's still better. You may want to check the openCL spec > which we tried to follow losely as to what we allow. > > So again, implementing your A is ok with me. Well, the openCL spec says that operations between signed and unsigned vectors are simply prohibited (both openCL 1.2 and openCL 2.0 agree on this, and it matches the behavior of my old openCL compiler ...): 6.1.2 Implicit Conversions: Implicit conversions between built-in vector data types are disallowed. 6.2.6 Usual Arithmetic Conversions: If the operands are of more than one vector type, then an error shall occur. Implicit conversions between vector types are not permitted, per section 6.2.1. 6.3 Operators: All arithmetic operators return result of the same built-in type (integer or floating-point) as the type of the operands, after operand type conversion. After conversion, the following cases are valid: - The two operands are scalars. [...] - One operand is a scalar, and the other is a vector. [...] - The two operands are vectors of the same type. [...] All other cases of implicit conversions are illegal. xlcl error message: 1506-068 (S) Operation between types "__private uint4" and "__private int4" is not allowed. Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain ulrich.weig...@de.ibm.com
GCC 4.8.4 Release Candidate available from gcc.gnu.org
The first release candidate for GCC 4.8.4 is available from ftp://gcc.gnu.org/pub/gcc/snapshots/4.8.4-RC-20141212 and shortly its mirrors. It has been generated from SVN revision 218649. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 4.8.4 at the end of next week.
GCC 4.8.4 Status Report (2014-12-12)
Status == The GCC 4.8.4-rc1 release candidate has been released. The branch is frozen now, all changes require release manager approval until the final release of GCC 4.8.4 which should happen roughly one week after the release candidate. Quality Data Priority # Change from Last Report --- --- P10 +- 0 P2 123 + 28 P36 - 39 --- --- Total 129 - 11 Previous Report === http://gcc.gnu.org/ml/gcc/2014-12/msg00035.html The next report will be sent by me again.
RE: Vector modes and the corresponding width integer mode
Hi Bingfeng, Thanks for commenting. It's reassuring to know that at least some ports do not have the corresponding integer modes. I have now also understood some of the background to the extra integer modes in ARM NEON and as far as I can tell the integer modes represent an opaque view of the registers as required by the ABI but not for anything relating to vectorization. I tried to follow some of the X86 code too but it's a bit too complex to dip into and understand much. I hadn't got to PowerPC yet either. Anyway I've ripped out the TImode handling from our current MSA implementation and it did not immediately blow up. Thanks, Matthew > -Original Message- > From: Bingfeng Mei [mailto:b...@broadcom.com] > Sent: 12 December 2014 11:52 > To: Matthew Fortune; gcc@gcc.gnu.org > Subject: RE: Vector modes and the corresponding width integer mode > > I don't think it is required. For example, PowerPC port supports > V8SImode, but I don't see OImode. Just sometimes it could come handy to > have the equal size scalar mode. > > Cheers, > Bingfeng > > > -Original Message- > > From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf > > Of Matthew Fortune > > Sent: 11 December 2014 13:27 > > To: gcc@gcc.gnu.org > > Subject: Vector modes and the corresponding width integer mode > > > > Hi, > > > > I'm working on MIPS SIMD support for MSA. Can anyone point me towards > > information about the need for an integer mode of equal size to any > > supported vector mode? > > > > I.e. if I support V4SImode is there any core GCC requirement that > > TImode is also supported? > > > > Any guidance is appreciated. The MIPS port already has limited support > > for TImode for 64-bit targets which makes it all the more difficult to > > figure out if there is a relationship between vector modes and integer > > modes. > > > > Thanks, > > Matthew
Re: GCC 4.8.4 Status Report (2014-12-12)
On Fri, Dec 12, 2014 at 7:35 AM, Jakub Jelinek wrote: > Status > == > > The GCC 4.8.4-rc1 release candidate has been released. > The branch is frozen now, all changes require release manager approval > until the final release of GCC 4.8.4 which should happen roughly > one week after the release candidate. > > > Quality Data > > > Priority # Change from Last Report > --- --- > P10 +- 0 > P2 123 + 28 > P36 - 39 > --- --- > Total 129 - 11 > > > Previous Report > === > > http://gcc.gnu.org/ml/gcc/2014-12/msg00035.html > > The next report will be sent by me again. Jakub, GCC 4.8 branch has degraded from 14 libstdc++ failures to 153. This is completely unacceptable and unreleasable in this form. I am opening multiple Bugzilla. I consider all of them P1 blocker regressions. - David
Idea for improvement to g++ - warning
Hello,
I had an idea of a warning g++ might be able to add. The purpose of the
warning is to help prevent bugs. The warning is to occur when you might
destroy an inherited class using the base classes pointer. To illustrate
consider
class base
{
public:
base();
~base();
};
class inherit : public base
{
public:
inherit();
~inherit();
}
Note that the base class's destructor is not virtual.
Creating a derived class from a base class when the base class'
destructor is not virtual could be enough to generate the warning. A
more elaborate version would issue the warning if a pointer to the base
class was assigned the address of a derived class when the base class'
destructor is not virtual (base *b = new inherit()).
Just an idea to consider. I spent a while trying to debug random crashes
in code where the author forgot to mark the destructors as virtual.
Kendrick Hamilton
Re: Idea for improvement to g++ - warning
On 12 December 2014 at 23:38, Kendrick Hamilton wrote:
> Hello,
>
> I had an idea of a warning g++ might be able to add. The purpose of the
> warning is to help prevent bugs. The warning is to occur when you might
> destroy an inherited class using the base classes pointer. To illustrate
> consider
>
> class base
> {
> public:
> base();
> ~base();
> };
>
> class inherit : public base
> {
> public:
> inherit();
> ~inherit();
> }
>
> Note that the base class's destructor is not virtual.
GCC already has -Wnon-virtual-dtor and -Wdelete-non-virtual-dtor warnings.
They don't warn for your example because you have no virtual
functions. It's assumed that if you don't have a polymorphic type then
there is no point in accessing it through a pointer to base.
Re: GCC 4.8.4 Status Report (2014-12-12)
On Fri, Dec 12, 2014 at 04:51:21PM -0500, David Edelsohn wrote: > GCC 4.8 branch has degraded from 14 libstdc++ failures to 153. This On which target, when it has been reported, are the libstdc++ folks aware of that? I see zero regressions on x86_64-linux and i686-linux from a build 14 days ago, compared to a build from early September there is +FAIL: g++.dg/tls/thread_local10.C -std=c++11 (test for excess errors) +UNRESOLVED: g++.dg/tls/thread_local10.C -std=c++11 compilation failed to produce executable but that has been reported and is just a testsuite issue, not compiler or library bug. Jakub
Re: GCC 4.8.4 Status Report (2014-12-12)
On Fri, Dec 12, 2014 at 7:17 PM, Jakub Jelinek wrote: > On Fri, Dec 12, 2014 at 04:51:21PM -0500, David Edelsohn wrote: >> GCC 4.8 branch has degraded from 14 libstdc++ failures to 153. This > > On which target, when it has been reported, are the libstdc++ folks aware of > that? > I see zero regressions on x86_64-linux and i686-linux from a build 14 days > ago, compared to a build from early September there is > +FAIL: g++.dg/tls/thread_local10.C -std=c++11 (test for excess errors) > +UNRESOLVED: g++.dg/tls/thread_local10.C -std=c++11 compilation failed to > produce executable > but that has been reported and is just a testsuite issue, not compiler or > library bug. I think this may be a fixincludes patch that needs to be backported. I'm re-running. Thanks, David
