On 08/28/18 04:55, Jeff Law wrote:
> On 08/23/2018 08:48 AM, Bernd Edlinger wrote:
>> On 08/23/18 16:24, Jeff Law wrote:
>>>>
>>>> Yes, and which one was the earlier, more controversial patch from me?
>>>
>>> https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01800.html
>>>
>>>
>>> Which is the issue I'm working through right now :-)
>>>
>>
>> Okay, please note that a re-based patch is here:
>>
>> https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01005.html
>>
>> and if you want, you can split that patch in two parts:
>>
>> first:
>> 86711 fix:
>> 2018-08-17 Bernd Edlinger <bernd.edlin...@hotmail.de>
>>
>> PR middle-end/86711
>> * expr.c (string_constant): Don't return truncated string literals.
>>
>> * gcc.c-torture/execute/pr86711.c: New test.
> Note that while this fixes your pr86711.c, it doesn't fix the larger set
> of tests Martin has created for the issues in pr86711.
>
> Sigh.
> jeff
>
Hmm. which test do you mean?
I just looked at the tests from part1/6.
there I found test cases memchr-1.c, pr86714.c, strlenopt-56.c
test them against trunk from yesterday (only build stage1):
$ svn info
Path: .
Working Copy Root Path: /home/ed/gnu/gcc-trunk
URL: svn+ssh://edlin...@gcc.gnu.org/svn/gcc/trunk
Relative URL: ^/trunk
Repository Root: svn+ssh://edlin...@gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 263893
Node Kind: directory
Schedule: normal
Last Changed Author: jakub
Last Changed Rev: 263891
Last Changed Date: 2018-08-27 20:36:23 +0200 (Mon, 27 Aug 2018)
memchr-1.c fail
pr86714.c fail
strlenopt-56.c pass
I don't know what this test case is trying to test, sorry.
What is obvious about it:
static const wchar_t wsx[] = L"\x12345678";
static const wchar_t ws4[] = L"\x00123456\x12005678\x12340078\x12345600";
This will be one more failed test case on AIX, given it uses -Wall.
Now I apply my pr86711 patch (only expr.c changed):
result
memchr-1.c pass
pr86714.c pass
When I tested that previously pr86714.c was failed, when only
the first part was applied. Now it passes, everything depends
on not really well defined semantics, you know.
pr86714.c tests specifically what happens at tree-ssa-forwprop.c
when TREE_STRING_LENGTH is trusted, but when I debug it again, it
appears to be fixed because this prevents it attempt the wrong folding:
else if (compare_tree_int (TYPE_SIZE_UNIT (TREE_TYPE (init)),
TREE_STRING_LENGTH (init)) < 0)
return NULL_TREE;
So my guess is, maybe it failed for a different reason, last week.
Bernd.
