Re: BUG #15121: Multiple UBSAN errors

On 19 March 2018 at 22:24, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
>
>
> On 03/19/2018 07:20 PM, Tom Lane wrote:
>> Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)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:
>>
>> *** 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.
>>
>
> Interesting. If I run the tests with "-03" I get the same failures in
> arrays. If I run them with "-O3 -fsanitize=undefined" I don't get any
> failures in arrays, but I get failures in errors, union and alter_table.
>
> I wouldn't expect -fsanitize=undefined to affect the results like this,

No, it's logical as the assembly is instrumented to process e.g.
boundary checking
each time an array is accessed. It explain why compiler can't optimize
as there are
new boundary which can't be crossed.

To be honest, sanitizers should report equal errors for all optimization errors.

Martin

> but if it really is a compiler bug then all bets are off.
>
> regards
>
> --
> Tomas Vondra http://www.2ndQuadrant.com
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services