[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Tinycc-devel] Fix signedness of LL shift operators in libtcc1.c (gr
Re: [Tinycc-devel] Fix signedness of LL shift operators in libtcc1.c (grischka-2005-09-25 case_10)
Fri, 4 May 2007 12:05:09 -0400
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
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);
> 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.