This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Add a character size parameter to c_strlen/get_range_strlen

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?
>>> Which is the issue I'm working through right now :-)
>> Okay, please note that a re-based patch is here:
>> and if you want, you can split that patch in two parts:
>> first:
>> 86711 fix:
>> 2018-08-17  Bernd Edlinger  <>
>>           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://
Relative URL: ^/trunk
Repository Root: svn+ssh://
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):

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]