This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix PR c/7622
Gabriel Dos Reis wrote:
>
> Philippe Trebuchet <Philippe.Trebuchet@sophia.inria.fr> writes:
>
> | Gabriel Dos Reis wrote:
> | >
> | > Eric Botcazou <ebotcazou@libertysurf.fr> writes:
> | >
> | > | The faulty definition of the nested bar() should be flagged earlier during
> | > | parsing I think (see c-decl.c:finish_decl).
> |
> | I think it cannot be flagged by that time because it is just a forward
> | nested declare I beleive that genrtl_scope_stmt is the right time to
> | check everything is in place.
>
> Since we're in function-at-a-time mode, after the definition of the
> enclosing function, one has enought information to diagnose that
> ill-formed construct.
>
Yes, isn't that moment handled in genrtl_scope_stmt?
> [...]
>
> | By the way what do you think about adding a warning
> | saying that gcc just forget the definition in
> | toplev.c:rest_of_compilation instead. do you think it is a good idea?
>
> Please, DON'T do that.
why?
>
> | > yeah. Actually, by the time we get to emitting function definitions
> | > we should already be in state to do so, i.e. no error, every
> | > required definition seen, etc. If we keep that invariant, then the
> | > check is unncessary. Said differently, the check is just papering
> | > over the root of the problem.
> | >
> | > | name than the original one, by using the "alias" attribute. But, as Richard
> | > | pointed out, the "alias" attribute is a definition, not a declaration. So we
> | > | should again flag the error earlier.
> | >
> | > 100% agreed.
> | >
> |
> | I understand this point, but as there is no mangement of asm symbols it
>
> Seeing whether a nested function is missing a definition requires no
> asm symbol management.
right, here I was speaking about alias symbol who are asm symbols sorry
for not beeing clear
--
Philippe