Richard Biener <richard.guent...@gmail.com> writes:
> On Mon, Oct 31, 2016 at 10:58 AM, Richard Sandiford
> <richard.sandif...@arm.com> wrote:
>> Richard Biener <richard.guent...@gmail.com> writes:
>>> On Mon, Oct 31, 2016 at 10:10 AM, Martin Liška <mli...@suse.cz> wrote:
>>>> On 10/31/2016 01:12 AM, Richard Sandiford wrote:
>>>>> Richard Biener <richard.guent...@gmail.com> writes:
>>>>>> On Thu, Oct 27, 2016 at 5:06 PM, Martin Liška <mli...@suse.cz> wrote:
>>>>>>> On 10/27/2016 03:35 PM, Richard Biener wrote:
>>>>>>>> On Thu, Oct 27, 2016 at 9:41 AM, Martin Liška <mli...@suse.cz> wrote:
>>>>>>>>> Running simple test-case w/o the proper header file causes ICE:
>>>>>>>>> strncmp ("a", "b", -1);
>>>>>>>>>
>>>>>>>>> 0xe74462 tree_to_uhwi(tree_node const*)
>>>>>>>>> ../../gcc/tree.c:7324
>>>>>>>>> 0x90a23f host_size_t_cst_p
>>>>>>>>> ../../gcc/fold-const-call.c:63
>>>>>>>>> 0x90a23f fold_const_call(combined_fn, tree_node*, tree_node*,
>>>>>>>>> tree_node*, tree_node*)
>>>>>>>>> ../../gcc/fold-const-call.c:1512
>>>>>>>>> 0x787b01 fold_builtin_3
>>>>>>>>> ../../gcc/builtins.c:8385
>>>>>>>>> 0x787b01 fold_builtin_n(unsigned int, tree_node*, tree_node**,
>>>>>>>>> int, bool)
>>>>>>>>> ../../gcc/builtins.c:8465
>>>>>>>>> 0x9052b1 fold(tree_node*)
>>>>>>>>> ../../gcc/fold-const.c:11919
>>>>>>>>> 0x6de2bb c_fully_fold_internal
>>>>>>>>> ../../gcc/c/c-fold.c:185
>>>>>>>>> 0x6e1f6b c_fully_fold(tree_node*, bool, bool*)
>>>>>>>>> ../../gcc/c/c-fold.c:90
>>>>>>>>> 0x67cbbf c_process_expr_stmt(unsigned int, tree_node*)
>>>>>>>>> ../../gcc/c/c-typeck.c:10369
>>>>>>>>> 0x67cfbd c_finish_expr_stmt(unsigned int, tree_node*)
>>>>>>>>> ../../gcc/c/c-typeck.c:10414
>>>>>>>>> 0x6cb578 c_parser_statement_after_labels
>>>>>>>>> ../../gcc/c/c-parser.c:5430
>>>>>>>>> 0x6cd333 c_parser_compound_statement_nostart
>>>>>>>>> ../../gcc/c/c-parser.c:4944
>>>>>>>>> 0x6cdbde c_parser_compound_statement
>>>>>>>>> ../../gcc/c/c-parser.c:4777
>>>>>>>>> 0x6c93ac c_parser_declaration_or_fndef
>>>>>>>>> ../../gcc/c/c-parser.c:2176
>>>>>>>>> 0x6d51ab c_parser_external_declaration
>>>>>>>>> ../../gcc/c/c-parser.c:1574
>>>>>>>>> 0x6d5c09 c_parser_translation_unit
>>>>>>>>> ../../gcc/c/c-parser.c:1454
>>>>>>>>> 0x6d5c09 c_parse_file()
>>>>>>>>> ../../gcc/c/c-parser.c:18173
>>>>>>>>> 0x72ffd2 c_common_parse_file()
>>>>>>>>> ../../gcc/c-family/c-opts.c:1087
>>>>>>>>>
>>>>>>>>> Following patch improves the host_size_t_cst_p predicate.
>>>>>>>>>
>>>>>>>>> Patch can bootstrap on ppc64le-redhat-linux and survives
>>>>>>>>> regression tests.
>>>>>>>>>
>>>>>>>>> Ready to be installed?
>>>>>>>>
>>>>>>>> I believe the wi::min_precision (t, UNSIGNED) <= sizeof (size_t) *
>>>>>>>> CHAR_BIT test is now redundant.
>>>>>>>>
>>>>>>>> OTOH it was probably desired to allow -1 here? A little looking back
>>>>>>>> in time should tell.
>>>>>>>
>>>>>>> Ok, it started with r229922, where it was changed from:
>>>>>>>
>>>>>>> if (tree_fits_uhwi_p (len) && p1 && p2)
>>>>>>> {
>>>>>>> const int i = strncmp (p1, p2, tree_to_uhwi (len));
>>>>>>> ...
>>>>>>>
>>>>>>> to current version:
>>>>>>>
>>>>>>> case CFN_BUILT_IN_STRNCMP:
>>>>>>> {
>>>>>>> bool const_size_p = host_size_t_cst_p (arg2, &s2);
>>>>>>>
>>>>>>> Thus I'm suggesting to change to back to it.
>>>>>>>
>>>>>>> Ready to be installed?
>>>>>>
>>>>>> Let's ask Richard.
>>>>>
>>>>> The idea with the:
>>>>>
>>>>> wi::min_precision (t, UNSIGNED) <= sizeof (size_t) * CHAR_BIT
>>>>>
>>>>> test was to stop us attempting 64-bit size_t operations on ILP32 hosts.
>>>>> I think we still want that.
>>>>
>>>> OK, so is the consensus to add tree_fits_uhwi_p predicate to the current
>>>> wi::min_precision check, right?
>>>
>>> Not sure. If we have host_size_t_cst_p then we should have a corresponding
>>> size_t host_size_t (const_tree) and should use those in pairs. Not sure
>>> why we have sth satisfying host_size_t_cst_p but not tree_fits_uhwi_p.
>>
>> It's the other way around: something can satisfy tree_fits_uhwi_p
>> (i.e. fit within a uint64_t) but not fit within the host's size_t.
>> The kind of case I'm thinking of is:
>>
>> strncmp ("fi", "fo", (1L << 32) + 1)
>>
>> for an ILP32 host and LP64 target. There's a danger that by passing
>> the uint64_t value (1L << 32) + 1 to the host's strncmp that we'd
>> truncate it to 1, giving the wrong result.
>
> Yes, but if it passes host_size_t_cst_p why does tree_to_uhwi ICE then?
> (unless we have a > 64bit host size_t).
Because in Martin's test case the length has a signed type.
tree_to_uhwi then treats the argument as -1 to infinite precision
rather than ~(size_t) 0 to infinite precision.
Thanks,
Richard
