lno-branch vs ptr-to-member

[Dale Johannesen]

On Jun 8, 2004, at 3:32 PM, Andrew Pinski wrote:
>> On Jun 8, 2004, at 12:38 PM, Zdenek Dvorak wrote:
>>
>>>> I'm not familiar enough with ptr-to-member to figure out what it 
>>>> ought
>>>> to be doing,
>>>> but this isn't it.
>>>
>>> neither do I.  From what you describe it seems that chrec_convert
>>> decides that it does not know anything special to do with the
>>> conversion (which
>>> is OK) and just passes it to convert (which seems OK to me), which
>>> probably
>>> should be able to handle it somehow (the other possibility being that
>>> the gimplified code is wrong).
>>
>> OK, I guess we need help from the experts in those areas to tell which
>> of these is true.  I'll try working around it by not trying to do this
>> particular
>> conversion, but I tend to agree that's not the right fix.
>>
>> This is PR 15881.
>
> Calling convert from the middle-end is asking for troubles.  One it 
> creates
> non-gimple, two it prints out error message which is bad for the 
> middle.
> I posted a patch to change all of the convert to fold_convert in 
> tree-scalar-evolution.c
> at <http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00460.html>.  This 
> fixes
> this error as I had changed fold_convert to treat OFFSET_TYPE to be 
> just like
> POINTER_TYPE, see 
> <http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00458.html>.

These patches fix the small example, and the large program it came 
from.  Thanks.

If it is indeed generally true that the middle-end shouldn't call 
convert, I think
the documentation needs improvement.  I found the following (cp/cvt.c) 
particularly
misleading:

    The backend [I suppose it means middle-end?]
    cannot call cp_convert (what was convert) because
    conversions to/from basetypes may involve memory references
    (vbases) and adding or subtracting small values (multiple
    inheritance), but it calls convert from the constant folding code
    on subtrees of already built trees after it has ripped them apart.