Re: [Tinycc-devel] Tinycc bugs/feedback

[Greg Haerr]

: > 3. The preprocessor directive #error is used in a couple of
: > places.  Tcc doesn't recognize it at all, and the #if/#endif
: > processing
: > nesting gets screwed up.  This caused some havoc.  In one
: > case the #error was terminated by a \ with more text on the
: > next line.  Solution: //#error
:
: Strange because #error should be well supported.

OK - I've finally debugged this one. gcc accepts it, tcc does not.
The following program will syntax error:

#if 0
#error get latest version at //http:microwindows.org
#endif

The // in the #error directive screws up tcc's #if count...

Shouldn't #error display until EOL when the compiler see's it?

> 2. Programs in MSDOS/Windows CRLF text format
> won't compile.  (preprocessor chokes on CR, it seems)

: Arg. I'll fix the parser to handle '\r' as space. Maybe it would be
interesting
to be slightly different from the ANSI standard to accept \n or \r\n as line
feed (for '\' at end of line for example).

Is it legal to convert \r to whitespace or should it be totally ignored?
TCC 0.9.10 won't compile MSDOS-text programs.
This may need to be tested when \ CR LF are the last three chars
of a line...  I had a line like the following for instance...
#error this is a long error message \
line

> 6. When tcc is used as a linker and passed several .o and
> then some .a files,  it appears that the .a symbols aren't searched
> twice for symbols that are required.  (works with gcc).  I'm not
> sure if there's a topological sort occuring before using the .a
> symbols.
> I'm still looking into this one.

: Can you explain more ?

Basically, tcc doesn't find symbols it should when used as a linker
and passed several .o and .a files.  It spits out [varied]
"Symbol not found" error messages, and the programs don't
link.  This is the case for the entire checked-in CVS microwindows:
I can't get tcc to generate but one codefile.  I was thinking this
was because the .a symbols may need sorting or multiple
passes.

: Note the TinyCC does not generate good code. Main goal are simplicity and
speed.
In the futur I may update the code generator so that even if the code is not a
lot more optimized it is smaller.

That's OK - I am impressed with the small executable size though -
I'll look into this a bit more.

One more question - what do you think about being able to
implement alloca?  That would be a big help!  Currently, I've
turned off that option but it would be a useful addition.

Regards,

Greg