Re: [PATCH, testsuite]: Fix PR 86153, test case g++.dg/pr83239.C fails

[Martin Sebor <msebor at gmail dot com>]

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  <ubizjak@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.

Martin