Re: [Tinycc-devel] Fix signedness of LL shift operators in libtcc1.c (grischka-2005-09-25 case_10)

[Rob Landley]

On Thursday 03 May 2007 6:49 pm, David A. Wheeler wrote:
> Rob Landley:
> > Ah.  Back to Ken Thompson's original "trusting trust" paper, "where's the 
> > source for this"...
> 
> Yep; that's a topic I'm familiar with :-).  It's not even so much about
> trust, as about bootstrapping in general.  I know you've got a lot of
> experience in bootstrapping too.  

Some of my ex-coworkers at timesys found something funky in toolchain building 
(weird interaction between glibc/gcc) where each was handing off an obect to 
the other that apparently hadn't been built from source in a few years.

The _easy_ way to notice this kind of thing is to cross-compile to a half 
dozen target platforms (ala http://landley.net/code/firmware or what the 
timesys guys were doing). :)

> > Hmmm...  Ideally we'd want it to automatically use this code when tcc was 
> > compiling itself.
> 
> Actually, I don't think that's true; it depends on the user.  If the user
> wants the compilation to run as fast as possible, or wants the code to be as
> small as possible, tcc self-compilation is NOT what you want to do.  And I
> think many people use tcc BECAUSE of its fast compilation and small size.   

A) When you build tcc with itself, you kind of assume that you have achieved 
bootstrapping.

B) When you build tcc with itself, it runs slower than when you built it with 
an optimizing compiler anyway.

C) This is the existing behavior.

tcc.c:    tcc_define_symbol(s, "__TINYC__", NULL);
libtcc1.c:#ifdef __TINYC__
libtcc1.c:#ifdef __TINYC__
libtcc1.c:#ifdef __TINYC__


> If you DO want tcc to be completely self-hosted, and thus don't care about
> the performance hit, THEN you want this code. 

When tcc is completely self hosted, the performance hit is already high enough 
that this is a rounding error, and correctness is more important.

> >  Is that when __TINYC__ is defined?  In which case, an
> > easier (or at least more logical) reproduction sequence would be:
> > ./configure
> > make
> > make install
> 
> Disagree.  I don't want a test routine to FORCE installation somewhere; I
> want to run tests BEFORE I install it :-).  That would also make testing
> easy to get wrong; I have dozens of tcc's running around, and while I'm
> testing tcc I make sure that NO tcc is installed.  That way I can be
> confident that what I _think_ I'm testing is what I'm actually testing. 
> That's why I invoked tcc directly, using "./tcc", in my comment - because
> that I way I don't mess up the installed tcc while I'm testing tcc.      

Understood.  This seems to be what the "make test2" and "make test3" targets 
attempt to achieve (which I didn't add, they've been there), although 
doing -run -run without an -- in there seems a bit iffy...

I'm heading out the door to Austin in a few minutes, and may be offline most 
of this weekend, but I'll try to get this checked in before I go.

Rob