(replying to myself)
On Feb 25, 14:01, Tor Arntsen wrote:
D>>Now, can you see how the generated getdate.c file looks like and see why this
D>>causes an error? This works on so many places it seems odd that this
D>>particular platform would create a bad C file from that .y file...
>
TA>It *may* be because the bison version on that irix box is the one that came
TA>with the operating system (1.25), not the freeware version (1.28) which I'm
TA>using on the other (6.5.8) irix box.

Ok I installed the latest bison from freeware.sgi.com, which is version 1.35,
and the problem went away. The somewhat vague conclusion is that bison 1.25
generates a getdate.c file incompatible with gcc 3.3 (the MIPSPro compiler
compiled it just fine!), while bison 1.28 and newer generates a gcc-compatible
getdate.c. Oh well, such is life :-)

Sidenote:
Unlike the 1.28-generated version the 1.35-generated version creates a lot of
noise like this:
/usr/freeware/share/bison/bison.simple:45:6: warning: "YYSTACK_USE_ALLOCA" is no
t defined
/usr/freeware/share/bison/bison.simple:82:6: warning: "YYLSP_NEEDED" is not defi

Looking at bison.simple we find:
#if YYLSP_NEEDED
  /* Similarly for the default location. Let the user run additional
     commands if for instance locations are ranges. */
  yyloc = yylsp[1-yylen];
  YYLLOC_DEFAULT (yyloc, (yylsp - yylen), yylen);
#endif
and so on. Note no #ifdef. The 1.28 version used #ifdefs for the same thing.
Looks like the bison maintainers screwed up.

-Tor
Received on 2004-02-25