This is the mail archive of the gcc-patches@gcc.gnu.org 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] Clean up the gimple type verifier [1/2]


Richard Guenther wrote:
> On Fri, 5 Sep 2008, Andrew Haley wrote:
> 
>> Richard Guenther wrote:
>>> On Fri, 5 Sep 2008, Andrew Haley wrote:
>>>
>>>> Tom Tromey wrote:
>>>>>>>>>> "Richard" == Richard Guenther <rguenther@suse.de> writes:
>>>>> Richard> This is a re-post with the changes requested by Diego.  Tom - is the
>>>>> Richard> Java part ok?  The cases in the C/C++ frontend it refers to have been
>>>>> Richard> removed one and a half years ago.
>>>>>
>>>>> It seems ok to me, but I'd like it if Andrew would look at this.
>>>>> Andrew, I quoted the patch in question at the end.
>>>> Hmm.  I have no idea whether this will break binary compatibility.
>>>> We'd have to test i.
>>> Why should it?  It simply causes a function that returns bool (QImode)
>>> to have a RESULT_DECL of type bool (QImode) instead of int (SImode).
>>> Expansion ensures that proper widening is done if the ABI requires it.
>>>
>>> The patch ensures that on the tree level if we for example inline
>>>
>>> bool foo() { return true; }
>>>
>>> we do not get an assignment from int to bool, but from bool to bool.
>> I understand what you're saying, but I thought the old behaviour was to
>> widen the return value.  And some existing CNI code might depend on that.
> 
> FYI the similar treatment in the C++ and C frontends have been removed 
> with
> 
> 2007-07-09  Richard Guenther  <rguenther@suse.de>
> 
>         * decl.c (start_preparsed_function): Do not promote return type.
> 
> 2007-07-09  Richard Guenther  <rguenther@suse.de>
> 
>         * c-decl.c (start_function): Do not promote return type.

I remember, and at the time I complained it broke the ABI, but I was
told "the back ends should do it instead."  To the best of my
knowledge no-one did anything to make the back ends do this where
required, though.

Andrew.


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