https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119332
Robert Dubner <rdubner at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|NEW |RESOLVED
--- Comment #5 from Robert Dubner <rdubner at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #1)
> Confirmed. There were similar issues with -print options which I fixed in
> r15-7952-gc20e24f8e7318b
>
> There's something odd with how the driver works, other frontends do not have
> to special-case this.
Yes. The odd thing is because of, well, COBOL.
Fifty-plus years ago, the creators of C decided to solve the problem of "Where
shall execution start" by using the "int main(...)" function.
COBOL has no such convention.
To make it possible for somebody to just "gcobol foo.cbl" to create an a.out
executable that will just run, by default I look for the first PROGRAM-ID in
foo.cbl and I inject a main() entry point that calls that first PROGRAM-ID.
A developer has full control over whether main() function is injected, where it
is injected, and which PROGRAM-ID it uses as the initial execution point by
using the -main and -nomain switches.
Implementing the default case, and the processing of -main and -nomain led to
the need to keep track of whether there are input files during
lang_specific_driver.