Re: [RFC] GCC vector extension: binary operators vs. differing signedness

[Richard Biener]

On Fri, Dec 12, 2014 at 1:08 PM, Ulrich Weigand  wrote:
> 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.

The question is what the fallout is if we reject this by default (I suppose
we accept it with -flax-vector-conversions).  I'm ok with following
OpenCL as well,
that is either solution that makes behavior consistent between C and C++.

Richard.

> Bye,
> Ulrich
>
> --
>   Dr. Ulrich Weigand
>   GNU/Linux compilers and toolchain
>   ulrich.weig...@de.ibm.com
>

Regular darwin builds

[FX]

Hi all,

I’ve set up daily builds and regtests on a darwin box. The results should 
appear directly on gcc-testresults 
(https://gcc.gnu.org/ml/gcc-testresults/current/).
This should, in the future, help track down regressions affecting darwin 
(PIC-related, in particular!).

The hardware is new, the OS is the latest and greatest (x86_64-apple-darwin14), 
and will be updated to keep it that way. However, it’s not very powerful (it’s 
a Mac Mini). Bootstrap (C, C++, Obj-C, Obj-C++, Fortran, Java, LTO) takes about 
2 hours, regtesting both 32 and 64-bit takes a bit over 3 hours.

I plan to schedule it for:

  - daily bootstrap + regtest of trunk
  - weekly bootstrap of latest release branch (currently 4.9)

If you have other ideas, I’m open to suggestions.

FX

trying out openacc 2.0

[Mark Farnell]

Hi,

Has OpenACC 2.0 support been merged into the trunk yet?  If not, then
is it contained in gomp-4_0-branch?

If so, what parameters should I pass to ./configure to enable OpenACC
2.0, and relevant backends such as CUDA, MIC and other GPGPU/manycore
architecture?

Also, I have a feeling that OpenACC 2.0 did NOT make it to gcc 5.0, am
I correct?  If I am correct, then will it be included in gcc 5.1?  If
I am wrong and it is already included into gcc 5.0, then I would
really really like to use it.

In the latter case, will I be able to write OpenACC 2.0 / OpenMP 4.0
code that runs on my nvidia GPU and/or Intel Xeon Phi?

Thanks!

Mark