Georg-Johann Lay wrote:
> I'd like to support sibling calls for a target where function args can
> be passed in call-saved registers, namely AVR.
The s390 back-end already has the very same issue. You may want to have
a look at config/s390/s390.c:s390_call_saved_register_used and how it is
used
Dave Korn wrote:
> This is now PR40309. Looks almost trivially easy to fix for anyone familiar
> with the structure of the fortran frontend.
Less so for someone like me who has no real clue about fortran internals,
though. I see there are two places in fortran/parse.c that call
main_program
Dave,
Dave Korn wrote:
> I see there are two places in fortran/parse.c
Side remark: You know that the actual middle-end TREE is only generated
in trans*.c? Thus, all things which happen before like parse.c can be
still remodeled in trans*c.
> that call
> main_program_symbol(): either as a result
Tobias Burnus wrote:
Hi Tobias,
> Hmm, that should not be the case that the middle end gets confused. I
> think there is some merit in printing also the name, e.g., HelloWorld
> rather than MAIN__ in middle end warnings ("unused variable foo in
> HelloWorld"), but otherwise the name given to th
Dave Korn wrote:
> Tobias Burnus wrote:
>> I agree that for "main" the call to "__main()" should happend and thus
>> expand_main_function should be called. I'm not sure in about the exact
>> assumptions of the middle end. In principle, it would be OK if the
>> MAIN__ function would show up as MAIN
Dave Korn wrote:
> Dave Korn wrote:
>> Tobias Burnus wrote:
>
>>> I agree that for "main" the call to "__main()" should happend and thus
>>> expand_main_function should be called. I'm not sure in about the exact
>>> assumptions of the middle end. In principle, it would be OK if the
>>> MAIN__ func
Dave Korn wrote:
>> Wouldn't the simplest thing be to rename the other main function - the
>> initialisation one that is automatically generated by create_main_function()?
>> It could be called anything different we liked, and it's not user-visible,
>> so
>> it ought to not be a problem to rena
Dave Korn wrote:
> Dave Korn wrote:
>> Dave Korn wrote:
>>> Tobias Burnus wrote:
I agree that for "main" the call to "__main()" should happend and thus
expand_main_function should be called. I'm not sure in about the exact
assumptions of the middle end. In principle, it would be OK i
Tobias Burnus wrote:
> I have another idea: Just handle "PROGRAM main" specially by using the
> name "MAIN__". It should be still quite readable in the middle-end
> diagnostics. Furthermore, it matches the assembler name and using "b
> main" one still get something useful - and it is less confusin
