Re: BUG #15121: Multiple UBSAN errors

So it started with GCC's revision r253859.
I'm investigating further.

Martin


On 19 March 2018 at 19:43, Martin Liška <marxin.liska@gmail.com> wrote:
> On 19 March 2018 at 19:20, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
>>> On 03/19/2018 03:28 PM, Martin Liška wrote:
>>>>>> Note that building postgresql with -03, I see some array tests failing.
>>
>>> I'm getting failures in errors, union and alter_table, but none of those
>>> are related to arrays. So, which tests are failing for you and how do
>>> the failures look like?
>>
>> I tried -O3 with gcc 7.3.1 (Fedora 26), and that passes check-world
>> just fine.  Then I tried -O3 with gcc 8.0.1 (prerelease Fedora 28),
>> and indeed that's got some problems.  It looks like array_out fails
>> for multidimensional arrays, because all the diffs look about
>> like this one:
>
> I can confirm it's really caused by -O3 optimization level for the function:
> array_out
>
> If you give me couple of minutes, I will isolate why is that caused.
>
>>
>> *** 106,116 ****
>>     SET c[2:2] = '{"new_word"}'
>>     WHERE array_dims(c) is not null;
>>   SELECT a,b,c FROM arrtest;
>> !        a       |           b           |         c
>> ! ---------------+-----------------------+-------------------
>> !  {16,25,3,4,5} | {{{113,142},{1,147}}} | {}
>> !  {}            | {3,4}                 | {foo,new_word}
>> !  {16,25,23}    | {{3,4},{4,5}}         | {foobar,new_word}
>>   (3 rows)
>>
>>   SELECT a[1:3],
>> --- 106,116 ----
>>     SET c[2:2] = '{"new_word"}'
>>     WHERE array_dims(c) is not null;
>>   SELECT a,b,c FROM arrtest;
>> !        a       |       b       |         c
>> ! ---------------+---------------+-------------------
>> !  {16,25,3,4,5} | {{            | {}
>> !  {}            | {3,4}         | {foo,new_word}
>> !  {16,25,23}    | {{3,4},{4,5}} | {foobar,new_word}
>>   (3 rows)
>>
>>   SELECT a[1:3],
>>
>> Note that 1-D and 2-D arrays print fine, it's only 3-D or deeper
>> that print wrong.  Very odd.  Maybe it's bad code on our part,
>> but I think the odds are at least as good that it's a new gcc bug.
>>
>>                         regards, tom lane