On Wed, May 9, 2012 at 3:41 AM, Marc Glisse <marc.gli...@inria.fr> wrote:
> On Wed, 9 May 2012, Richard Guenther wrote:
>
>> On Wed, May 9, 2012 at 1:24 AM, Gabriel Dos Reis
>> <g...@integrable-solutions.net> wrote:
>>>
>>> On Tue, May 8, 2012 at 5:14 PM, DJ Delorie <d...@redhat.com> wrote:
>>>>
>>>>
>>>> I assume this is a size_t vs int type problem, but the diagnostic
>>>> points to the function declaration, not to an actual binary
>>>> expression, and I can't figure out what it's complaining about:
>>>
>>>
>>> My mailer uses proportional fonts so I can't make sense of the
>>> diagnostics with the carets :-/
>>>
>>>>
>>>> Note: my current patchset is:
>>>>
>>>> Index: libstdc++-v3/include/std/bitset
>>>> ===================================================================
>>>> --- libstdc++-v3/include/std/bitset     (revision 186562)
>>>> +++ libstdc++-v3/include/std/bitset     (working copy)
>>>> @@ -1374,13 +1374,13 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
>>>>       void
>>>>       bitset<_Nb>::
>>>>       _M_copy_from_ptr(const _CharT* __s, size_t __len,
>>>>                       size_t __pos, size_t __n, _CharT __zero, _CharT
>>>> __one)
>>>>       {
>>>>        reset();
>>>> -       const size_t __nbits = std::min(_Nb, std::min(__n, __len -
>>>> __pos));
>>>> +       const size_t __nbits = std::min(_Nb, std::min(__n,
>>>> (size_t)(__len - __pos)));
>>>
>>>
>>> style nits: It should be size_t(__len - __pos), and not (size_t)(__len -
>>> __pos).
>>> Same for the other hunk.  Patch OK with those changes.
>>
>>
>> This looks like a middle-end ICE that is at most worked around by the
>> above
>> change.  So I don't believe we should paper over it like this during
>> stage1.
>
>
> I agree that the ICE should be fixed, but sadly the patch will still be
> necessary because of platforms where size_t is unsigned short (I didn't know
> those existed...)

Well, I suspect AVR might be such platform but I do not seem to have an
ABI document for AVR yet... (hint, hint).

An interesting question is what ptrdiff_t is for such platforms... (I
would expect
short)

> and because std::max is picky about having the same type
> for both arguments (the papers about improving it for C++11 were rejected).
>
> --
> Marc Glisse

Reply via email to