[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Tinycc-devel] asm labels
From: |
grischka |
Subject: |
Re: [Tinycc-devel] asm labels |
Date: |
Mon, 13 Sep 2010 18:04:11 +0200 |
User-agent: |
Thunderbird 2.0.0.23 (Windows/20090812) |
Thomas Preud'homme wrote:
I don't know why it has been invented for (you could take a look at git log on
glibc to find the commit which introduced this) but in (e)glibc the way they
use it bypass the type checker. That is they declare functions cosl to be cos
and there is no warning if cos is used with an argument long double instead of
double. As preprocessing is done before type checking there is a difference.
As to why it is called asm label it's that it's suppose to change the name
used in the generated asm. Macro substitute at source level whereas asm label
change the name at asm level. I agree it's not what I did in the patch but it
was simpler (and thus much smaller) that way. I don't know how gcc guys did
it.
Sigh, what can we do when gcc decided to have it ;)
Anyway, as to tinycc, I noticed that it fails to compile with NOTALLINONE
defined. So if this is not an "asm-feature" really I'd suggest to move
the two functions "parse_asm_str" and "asm_label_instr" elsewhere (e.g.
to libtcc.c or tccgen.c) and remove CONFIG_TCC_ASM from tccasm.c again.
The idea is that tccasm.c can stay out from compilation on platforms
without asm support.
Do you have a regression test to detect this kind of regression or you just
felt this patch would break compilation with NOTALLIONE ? If you have some
kind of automated test I'm very interested to use it to produce better
patches.
Well, I'm using NOTALLIONE personally (of course, since I've put some
effort to make it work). So I saw it broke and I felt that it could
break on platforms without asm support (e.g. arm) even without NOTALLIONE
because "tccasm.c" wouldn't be included at all.
Maybe we should make "NOTALLIONE" (= compilation from single objects) the
default on the native platform now. ("Makefile" does not yet support it
it for cross compilers).
I don't think it does matter whether it is an asm feature or not. The fact is
it's independant from the asm language so yes it could be moved. And more
other, I don't think CONFIG_TCC_ASM_LABEL is really useful after all as this
code is platform independant. I'll move asm_label_instr and parse_asm_str out
of tccasm.c to put tccasm.c as it was previously. By the way, should I rename
the two functions above to avoid confusion ?
Name new function as you see fit, rename existing function only for
strong reasons ;)
--- grischka