On 08/01/2018 11:21 AM, Martin Sebor wrote:
> On 08/01/2018 04:34 AM, Uros Bizjak wrote:
>> Hello!
>>
>> The testcase fails with:
>>
>> FAIL: g++.dg/pr83239.C -std=gnu++11 scan-tree-dump-not optimized
>> "_ZNSt6vectorIiSaIiEE17_M_default_appendEm"
>> FAIL: g++.dg/pr83239.C -std=gnu++14 scan-tree-dump-not optimized
>> "_ZNSt6vectorIiSaIiEE17_M_default_appendEm"
>>
>> the test depends on _M_default_append to be inlined, so it verifies
>> the inlining with:
>>
>> // Verify that std::vector<T>::_M_default_append() has been inlined
>> // (the absence of warnings depends on it).
>> // { dg-final { scan-tree-dump-not
>> "_ZNSt6vectorIiSaIiEE17_M_default_appendEm" optimized } }
>> // { dg-final { scan-tree-dump-not
>> "_ZNSt6vectorIPvSaIS0_EE17_M_default_appendEm" optimized } }
>>
>> However, this is not the case with the default -finline-limit, so
>> raise it to 500 (the same approach is taken in g++.dg/
>> tree-ssa/copyprop.C).
>>
>> Unfortunately, the fixed testcase exposes some issue with -std=gnu++98:
>>
>> FAIL: g++.dg/pr83239.C -std=gnu++98 (test for excess errors)
>>
>> In function 'void test_loop() [with T = int]':
>> cc1plus: warning: 'void* __builtin_memset(void*, int, long unsigned
>> int)' specified size 18446744073709551608 exceeds maximum object size
>> 9223372036854775807 [-Wstringop-overflow=]
>> In function 'void test_if(std::vector<T>&, int) [with T = long int]':
>> cc1plus: warning: 'void* __builtin_memset(void*, int, long unsigned
>> int)' specified size 18446744073709551600 exceeds maximum object size
>> 9223372036854775807 [-Wstringop-overflow=]
>>
>> 2018-08-01 Uros Bizjak <ubiz...@gmail.com>
>>
>> PR testsuite/86153
>> * g++.dg/pr83239.C (dg-options): Add -finline-limit=500.
>>
>> OK for mainline and gcc-8 branch?
>
> Thanks for spending time on this! I just looked into it
> earlier this week and was going to touch base with Jeff after
> he comes back from PTO later this week to see what to about
> the test and the outstanding warning. In comment #20 on
> pr83239 Jeff said he has a patch for the missed optimization
> that presumably is behind the false positive, so that should
> presumably fix the other part of the problem here.
Yes. It's a relatively simple patch to the VRP bits to evaluate
conditionals -- it extends our ability to detect overflow tests and the
resultant ranges that inputs must take to trigger overflow.
All that really needs to happen is for me to recreate the lost tests and
submit the patch.
jeff
