Arm hardfloat variant uses a different ABI than arm and uses thus a
different multiarch directory for headers and libraries. This commit
detect whether the system uses the hardfloat variant and configure the
multiarch directory accordingly.
The code for shifts is now similar to code for binary arithmetic operations,
except that only the first argument is considered, as required by the ISO C
standard.
The intent is for 'make test' to pass cleanly on each platform, and thus easier
spotting of regressions. Linux is best supported by most tests running and
passing. Mac OSX passes mosts tests that do not make/link with binary files,
due to lack of mach-o file support.
!!! I have very limited knowledge of Windows platform, and cannot comment why
all tests(1) fail. I have posted to newsgroup asking for someone to test
Windows platform.
On 2012-06-26 15:07:57 +0200, Vincent Lefevre wrote:
> ISO C99 TC3 says: [6.5.7#3] "The integer promotions are performed on
> each of the operands. The type of the result is that of the promoted
> left operand."
I've written a patch (attached). Now the shift problems no longer
occur with the testcase and with GNU MPFR's "make check".
--
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
The tests are taken almost verbatim from the open source project PicoC. It can
be found at https://code.google.com/p/picoc/.
The tests range from very simple/trivial ones to more complicated. My view is
that the more tests the better. Without tests like this I was very reluctant to
make any changes to tcc for the fear of breaking things.
The tests pass on Win32, OSX, Linux x86 and x86_64. One or two tests fail on
each platform due to differences in the runtime library.
Evaluate configure arguments to reproduce autotools behavior. Autotools
actually only expands a few variable and do it at make time but it makes
the change much simpler.
Using /usr/bin/env tcc doesn't work as it was reported. Revert to
using the full path which fails if the user installs tcc in non-default
location. Then again this is just an example.
This reverts commit 27a428cd0f.
I probably broke that myself earlier. In any case parse_args
needs to start with index 0 because it is is used also recursively
to expand the shebang command from scripts such as
#!/usr/local/bin/tcc -run -L/usr/X11R6/lib -lX11
which arrives at tcc as only two argv's
"tcc" "-run -L/usr/X11R6/lib -lX11"
When using gcc compiler (as opposed to llvm) to build 32 bit tcc, compiler flags
-mpreferred-stack-boundary=2, -march=i386 and -falign-functions=2 were being
used. -march is redundant as -m32 is already being used. The other two seem to
be corrupting stack. I am not sure why this is the case, as the explanation of
the flags states that only running code size should be affected, but it does.
I think that is is safe to remove these flags altogether for all compilers and
platforms, especially since they are not being used for 64 bit builds. However
I do not want to apply such wide change without agreement from the people on the
mailing list.
Loads of VT_LLOCAL values (which effectively represent saved
addresses of lvalues) were done in VT_INT type, loosing the upper
32 bits. Needs to be done in VT_PTR type.
* Add multiarch directories for arm and i386
* Fix detection of biarch: /lib64/ld-linux-x86-64.so.2 is mandated by
ABI and is thus always present, even if there is no biarch
* Define CONFIG_LDDIR directly with the right value in case of multiarch
instead of defining it to /lib and then redifining it.
This patch fix 2 bugs in CONFIG_LDDIR usage:
* CONFIG_LDDIR used for 2 purposes
there is confusion between the directory to find libraries, crt* files
and headers and the directory in which the program interpreter is.
These two directories are not related. The latter is specified by the
ABI and should not be configurable while the former depends on the
system (single arch, biarch, multiarch). This end a longstanding issue
with amd64 program interpreter later propagated to other architecture
interpreters.
* If multiarch is in effect, then the library directory should be /lib.
/lib64 denotes biarch architecture, everything which is here would be
in /lib/x86_64-linux-gnu instead.
TCCs make dependency generator is incompatible with the GNU
depcomp script which is widely used. For TCC it has to go over
the output of -MD, (it detects it as ICC compatible), but the
sed commands it uses are confused by tabs in the output, so that
some rewrites aren't done.
Those tabs will then finally confuse make itself when the
generated .d files are included. It reads them as goal commands
(leading tab), and is totally lost then.
Short of changing depcomp (hard because distributed with all kinds
of software), simply emit spaces for -MD.
Sometimes the result of a comparison is not directly used in a jump,
but in arithmetic or further comparisons. If those further things
do a vswap() with the VT_CMP as current top, and then generate
instructions for the new top, this most probably destroys the flags
(e.g. if it's a bitfield load like in the example).
vswap() must do the same like vsetc() and not allow VT_CMP vtops
to be moved down.
This matters when sizeof is directly used in arithmetic,
ala "uintptr_t t; t &= -sizeof(long)" (for alignment). When sizeof
isn't size_t (as it's specified to be) this masking will truncate
the high bits of the uintptr_t object (if uintptr_t is larger than
uint).
This needs to be accepted:
typedef int foo;
void f (void) { foo: return; }
namespaces for labels and types are different. The problem is that
the block parser always tries to find a decl first and that routine
doesn't peek enough to detect this case. Needs some adjustments
to unget_tok() so that we can call it even when we already called
it once, but next() didn't come around restoring the buffer yet.
(It lazily does so not when the buffer becomes empty, but rather
when the next call detects that the buffer is empty, i.e. it requires
two next() calls until the unget buffer gets switched back).
When offsetted addresses of global non-static data are computed
multiple times in the same statement the x86_64 backend uses
gen_gotpcrel with offset, which implements an add insn on the
register given. load() uses the R member of the to-be-loaded
value, which doesn't yet have a reg assigned in all cases.
So use the register we're supposed to load the value into as
that register.
The first loop setting up struct arguments must not remove
elements from the vstack (via vtop--), as gen_reg needs them to
potentially evict some argument still held in registers to stack.
Swapping the arg in question to top (and back to its place) also
simplifies the vstore call itself, as not funny save/restore
or some "non-existing" stack elements need to be done.
Generally for a stack a vop-- operation conceptually clobbers
that element, so further references to it aren't allowed anymore.
Removes a premature optimization of char/short loads
rewriting the source type. It did so also for bitfield
loads, thereby removing all the shifts/maskings.
(cond ? 0 : ptr)->member wasn't handled correctly. If one arm
is a null pointer constant (which also can be a pointer) the result
type is that of the other arm.
- tests/Makefile:
fix commit de54586d5b
This hunk it unrelated to the other changes (which are about MacOSX).
It is not useful and partially wrong. Optional tests are meant to
stay optional, btest would work only for i386
- tcc.h:
fix commit c52d79605a by unknown
The message says it's for MINTW but the patch has obviously
no effect for MINGW (which defines __GNUC__). However the patch
seems useful for MSC which however needs _strto(u)i64 with underscore.
- Makefile:
fix commit 5280293d6b
Do not build tcc.o with -DONE_SOURCE because we finally build tcc
from tcc.o and libtcc.a/so
- remove redunant else branch
- zero-terminate linker_arg
- declare cstr_xxx as PUB_FUNC
(which are functions used in tcc.c but not in the libtcc API.
Useful for a tcc(.exe) that uses the libtcc.(so/dll))
- while at it, export PUB_FUNCs from dll
This reverts commit 1c11b857fe.
On windows, libtcc.c is compiled with ONE_SOURCE and then tcc.c is
linked to it. Thus tcc.c can only use public functions which cstr_* are
not.
elements in linker_arg are used in TCCState structure and must thus not
be freed when option parsing is finished. Declare linker_arg as a global
static variable and free it after tcc_delete has been called on TCCState
structure.
This fix commit 7fb0482a46
ld support arguments to multiple-letter options being passed in two
ways:
* -opt=arg
* -opt arg
libtool generate command line of the second form. This commit add
support for the second form so that libtool works with tcc. The way it
is done is to concatenate all -Wl options into one and then pass it to
set_linker.
Other tests still have issues, currently with weak linking.
One of the primary stumbling blocks on OSX is the lack of support for
mach-o binaries. Therefore all tcc usage on OSX has to be limited to elf
binaries, presumably produced by tcc itself.
Therefore I had to enable building of tiny_libmaker for OSX. Then changed
the make to use tcc and tiny_libmaker to compile the tcclib1.
In order to compile the tests, specifically the parts that use weak linking,
I have had to define MACOSX_DEPLOYMENT_TARGET to 10.2, which seems like a
hack, but extensive searching seems to indicate that this is the only way
to make apple gcc allow weak linking. Using any other value, bigger or smaller
breaks weak linking.
Also added _ANSI_SOURCE define required by some OSX headers, and some cosmetic
gitignore changes. I believe these changes should not impact other platforms.
