Dave Korn wrote:
>>> + main_identifier_node = get_identifier ("main");
>>> + ftn_main = build_decl (FUNCTION_DECL, main_identifier_node, tmp);
>>>ftn_main = build_decl (FUNCTION_DECL, get_identifier ("main"), tmp);
>>>
> I just took a second look at this. We surely didn't mean to buil
Jerry DeLisle wrote:
> Tobias Burnus wrote:
>> @@ -3874,6 +3877,8 @@ create_main_function (tree fndecl)
>>tmp = build_function_type_list (integer_type_node, integer_type_node,
>>build_pointer_type (pchar_type_node),
>>NUL
Tobias Burnus wrote:
> Jerry DeLisle wrote:
>> I tested the above on x86-64 Linux. OK to commit.
> Thanks for the review. Committed:
>
> Sendinggcc/fortran/ChangeLog
> Sendinggcc/fortran/trans-decl.c
> Transmitting file data ..
> Committed revision 148035.
>
> Tobias
Thank you
Jerry DeLisle wrote:
> I tested the above on x86-64 Linux. OK to commit.
Thanks for the review. Committed:
Sendinggcc/fortran/ChangeLog
Sendinggcc/fortran/trans-decl.c
Transmitting file data ..
Committed revision 148035.
Tobias
Tobias Burnus wrote:
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 O
Dave Korn wrote:
> 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
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
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
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:
>> 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:
> 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
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,
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
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
Snapshot gcc-4.5-20090528 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20090528/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
15 matches
Mail list logo
