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).
Richard.
>
> Thanks,
> Richard
