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: [RFC] Fix for PR58201


Jan Hubicka <hubicka@ucw.cz> wrote:
>> On 09/04/2013 06:04 PM, Jan Hubicka wrote:
>> > this is third fallout of my change to remove
>DECL_ARGUMENTS/DECL_RESULT for functions w/o
>> > bodies I did not really anticipate.
>> [...]
>> > I would like to basically ask if it seems to make sense to go this
>route and
>> > try to get rid of those declarations.
>> 
>> I'm currently working on a new target, ptx, which uses a
>> pseudo-assembler where functions (even extern ones) need to be
>declared
>> with their arguments and return types. With my current code I have to
>> look at DECL_ARGUMENTS fairly late in the compilation. I'm not quite
>> sure yet whether the change to delete them will break the backend.
>
>How do you support K&R functions here?  My basic idea was that
>TYPE_ARG_TYPES
>should give enough information about external function calling
>convention
>anyone will ever need. I would hope that this will be sufficient for
>your
>use, too, despite the fact you no longer have parameter names at hand
>and you also lose info about external inline K&R-style delcared
>functions
>that has been optimized out.
>
>If not that indeed, you will not see DECL_ARGUMENTS for external
>function
>anytime after cgraph_remove_unreachable_functions is called.

In fact it has to work because of indirect calls and how we now handle gimple call abi via gimple_call_fntype.

Richard.

>Honza



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