On Sat, Jun 5, 2010 at 10:49 PM, Andrew Pinski <pins...@gmail.com> wrote:
> On Sat, Jun 5, 2010 at 3:10 AM, Richard Guenther
> <richard.guent...@gmail.com> wrote:
>> On Fri, Jun 4, 2010 at 11:39 PM, Andrew Pinski <pins...@gmail.com> wrote:
>>> On Tue, Jun 1, 2010 at 12:21 PM, Artem Shinkarov
>>> <artyom.shinkar...@gmail.com> wrote:
>>>
>>> + error_at (loc, "index value is out of bound");
>>>
>>> That is wrong. The Cell C/C++ language document says out of bounds
>>> accesses are undefined (that is at runtime).
>>
>> I think we should implement whatever OpenCL specs and disregard
>> whatever the (dead) Cell C/C++ language docs say. The project is
>> to improve GCCs generic vector facility, not to implement the Cell
>> language spec.
>
> Except it makes no sense that:
> int f(void)
> {
> vector int t;
> return t[55];
> }
> is rejected but
>
> int f(void)
> {
> vector int t;
> const int tt = 55;
> return t[tt];
> }
> is accepted in C but rejected in C++.
>
> This is why OpenCL spec is not very good here really and not
> consistent with the rest of the C/C++ standard. In fact I would say
> we should treat it as the same as arrays out of bounds where it is
> just undefined at runtime rather than an error. This is what the Cell
> C/C++ language spec is trying to do rather than something more
> specific to vectors. The Cell C/C++ specifications was trying to be
> as close to what the current C/C++ standard says about out of bounds
> accesses rather than making up different rules.
Sure - we can simply emit a warning here if you prefer.
Richard.
> Thanks,
> Andrew Pinski
>
