now (fix-diag-vaend.diff) :)
Have fun,
Michael.From 6471ec0a2bd523edd4bbc79277a33d0b853940fa Mon Sep 17 00:00:00 2001
From: Michael Matz m...@suse.de
Date: Sat, 14 Apr 2012 23:50:21 +0200
Subject: [PATCH 1/9] Fix conversion in a?0:ptr.
(cond ? 0 : ptr)-member wasn't handled correctly. If one arm
Hi,
On Sat, 21 Apr 2012, grischka wrote:
I can now build current GCC (well, r186469 plus a modification, see below)
with tinycc on x86_64 (all language frontends written in C, i.e. c, c++,
objc, objc++ and fortran), and that so built GCC is able to compile all its
own target libraries.
If
Hi,
On Thu, 10 May 2012, grischka wrote:
[1] See commit 27a428cd0fae475d7377e1dbe218c064ee217d85
Basically /usr/bin/env tcc -run will try to find tcc -run which is then
obviously not found. Should we go back to the solution proposed in [2] or
do you have another idea?
Why not use just
Hi,
On Thu, 3 May 2012, arn...@skeeve.com wrote:
The one remaining test failure seems to be related to handling NaN
floating point values. Here is the diff of the test results.
NaN handling was totally hosed for x86_64. Update your checkout of mob
branch, I fixed it.
I've added an
Hi,
On Mon, 14 May 2012, Karl Skomski wrote:
Hi,
I discovered tinycc some days ago but only today I discovered the
current development repository: http://repo.or.cz/w/tinycc.git It's
not that easy to find the most-updated tinycc repository.
I thought maybe it would be nice to switch the
Hi,
On Sun, 27 May 2012, Rick Hodgin wrote:
Didier,
You're able to take the code and modify that requirement. It seems
straight-forward enough that TinyCC is (in memory at compile-time)
determining the target size, regardless of the storage size, and using
that for the storage size in
Hi,
On Sun, 27 May 2012, Michael Matz wrote:
If one changes anything at all then it only makes sense to change it so
as to be layout compatible with GCC. A third layout (GCC, TCC-old,
TCC-new) wouldn't help. Although the rules of GCC are relatively
obscure and complex in corner cases
Hi,
On Thu, 31 May 2012, Thomas Preud'homme wrote:
I've just received a bug report [1] about overflow occuring with
R_X86_64_PC32 relocations when a library is compiled with tcc.
Yep, shared libraries on x86-64 don't work correctly with TCC. It emits
non-PIC code, which is fine for x86,
Hi,
On Sat, 9 Jun 2012, g...@sdf.org wrote:
d = malloc (s);
If this returns a pointer with upper 32 bits set (which depends on malloc
size, fragmentation and moon phase) ...
d[0] = 10.0;
i = d[0] f ();
... those are lost in the caller-save/restore code for the address of d[0]
Hi,
On Sun, 10 Jun 2012, Daniel Glöckner wrote:
On Sun, Jun 10, 2012 at 09:15:52AM +0200, Michael Matz wrote:
Thomas: as you were last fiddling with arm, you might want to check
if the test works on it. The other alloca testcase is #ifdef'ed on
i386 and x86_64, but that only makes sense
Hi,
On Sun, 10 Jun 2012, Daniel Glöckner wrote:
Compiler generated calls have been chosen to allow the use of
libgcc_s.so.1 on ARM EABI and OABI. It is needed for divisions, 64-bit
shifts, and some floating point conversion. One day we might also
support devices without floating point
Hi,
On Mon, 27 Aug 2012, grischka wrote:
Can you at least commit the change that makes tcc_relocate_ex() global?
Yes, perhaps at least. You wrote:
... but fixing my code to match the current definition
of tcc_relocate() was out of the question (the surrounding code manages the
lifetime
Hi,
On Wed, 29 Aug 2012, grischka wrote:
What about this: Keep the 0.9.25 declaration of tcc_relocate, which was:
Sure. Keep tcc_relocate with its current signature.
/* copy code into memory passed in by the caller and do all relocations
(needed before using tcc_get_symbol()).
Hi,
On Wed, 16 Jan 2013, Thomas Preud'homme wrote:
$ cat long_long.c
#include stdio.h
int main(void)
{
char *p = NULL;
p -= 0x7042;
/* from pointer to integer types */
printf(%d %d %ld %ld %lld %lld\n,
(int)p, (unsigned int)p,
Hi,
On Thu, 31 Jan 2013, Vincent Lefevre wrote:
In such a case, a default: at the end with an assertion failure
would have been better.
No. An assertion only makes sense to make sure about what we aren't
entirely sure. In this case we are sure (that default never happens).
You
Hello Christian,
Am 16.02.2013 12:04, schrieb Christian Jullien:
tcc_define_symbol(s, __STDC_VERSION__, 199901L);
This define pretends it is ISO/IEC 9899:1999 (E)
Strictly speaking that's optimistic, because it also depends on the C
library on which tcc has no influence (some embedded
Am 16.02.2013 20:16, schrieb Christian Jullien:
Thank you Michael,
I'm really sorry, my intention was not that someone tried to debug this
silly program.
The purpose of this small program was to illustrate that I don't know what C
version tcc is supposed to implement, with which feature.
I
Am 17.02.2013 19:46, schrieb Thomas Preud'homme:
Le samedi 16 février 2013 21:17:32, Michael Matz a écrit :
__STDC_HOSTED__ : not set (incorrectly, it should probably be set to 1
given that tcc assumes a normal main() and that the
rest of the provided
Hi,
[resent because my work email is not subscribed here :-/]
On Thu, 9 Jan 2014, Thomas Preud'homme wrote:
That's because GCC doesn't have any problem. The problem is in TinyCC. I
was compiling mksh with TinyCC (I called it tcc in my initial mail) and
it gave me linker error about
Hi,
[bah, resent again because of suse.de not being the subscribed address
here :-/ ]
On Thu, 9 Jan 2014, Thomas Preud'homme wrote:
Oh I see. I compiled with --with-libgcc and gcc doesn't provide __va_*
like libtcc1 does. So I guess either libgcc should not be proposed for
x86-64 systems
Hi,
On Thu, 9 Jan 2014, Keren Tan wrote:
I just submitted a tentative patch to the mob branch about mmap. When
selinux is enabled, tccrun.c uses mmap to hold the dynamically generated
code/data. It is backed by a randomly named file under /tmp directory.
My patch is to use an anonymous file
Hi,
On Sat, 11 Jan 2014, Michael Matz wrote:
I just submitted a tentative patch to the mob branch about mmap. When
selinux is enabled, tccrun.c uses mmap to hold the dynamically
generated code/data. It is backed by a randomly named file under /tmp
directory. My patch is to use an anonymous
Hi,
On Sat, 11 Jan 2014, Vincent Lefevre wrote:
On 2014-01-11 22:39:28 +0800, Thomas Preud'homme wrote:
Can you try a git bisect to see what commit introduced this bug?
The last two commits.
Fixed in mob.
ciao,
Michael.
___
Tinycc-devel
Hi,
On Sun, 12 Jan 2014, Vincent Lefevre wrote:
There's still a bug related to signed zero support.
I think I've fixed that now on mob [1]. In particular +x is regarded as
no-op for floating point types (for integer types it's still x+0 so that
the promotions still happen automatically).
Hi,
On Sun, 12 Jan 2014, Vincent Lefevre wrote:
On 2014-01-12 04:59:06 +0100, Michael Matz wrote:
I think I've fixed that now on mob [1]. In particular +x is regarded as
no-op for floating point types (for integer types it's still x+0 so that the
promotions still happen automatically
Hi,
On Mon, 10 Mar 2014, Christian Jullien wrote:
Yes I fully agree that tcc should, by default, be a gcc compiled program.
Also, as Patrick said, having tcc bootstrapped by itself has the following
advantages:
- it proves tcc is complete
- it proves tcc does not use gcc extensions, or
Hi,
On Wed, 26 Mar 2014, Domingo Alvarez Duarte wrote:
On my commit
It would be easier if you wrote your reasons for doing things in mails,
not only in commit messages, it makes quoting much harder. Anyway, in the
commit message you wrote:
I found the problem it was because CValue
Hi,
On Fri, 28 Mar 2014, Domingo Alvarez Duarte wrote:
It's simple remove the zeroing CValues and try make clean, make and
make test you'll see that on linux 32 bits and linux 64 bits and you'll
I see no errors on x86_64, I do see these errors on i386:
--
-Test C99 VLA 5 (bounds
Hi,
On Sat, 29 Mar 2014, grischka wrote:
Thomas Preudhomme wrote:
Le 2014-03-15 20:10, mobi phil a écrit :
Hi,
get_tok_str is called in several places with second parameter NULL,
though inside members (thus dereferencing NULL) is possible.
Probably this combination bad never happens, but
Hi,
On Sat, 29 Mar 2014, Domingo Alvarez Duarte wrote:
How do you propose to solve this specific problem ?
ST_FUNC void vset(TCCState* tcc_state, CType *type, int r, int v)
{
CValue cval;
memset(cval, 0, sizeof(CValue));
cval.i = v; //, here is the main bug that mix with
Hi,
On Sat, 29 Mar 2014, Domingo Alvarez Duarte wrote:
It's not better to have two different functions/entry points, one for when
we have/need a CValue and other without it ?
Yes, that could be reasonable. OTOH to avoid code duplication the one
without taking a CValue would be internally
Hi,
On Sat, 29 Mar 2014, Domingo Alvarez Duarte wrote:
Thanks for pointing it and show an example to test !
Now going back to the original problem the original tcc implementation leaks
memory on:
void *__va_copy(struct __va_list_struct *src)
{
struct __va_list_struct *dest =
Hi,
On Sat, 29 Mar 2014, Domingo Alvarez Duarte wrote:
Ok now I understand your point, here is the minimal program that I was using
to trace it:
int main() {
int x;
static void *label_return = lbl_return;
//printf(label_return = %p\n, label_return);
goto *label_return; // here segfault on
Hi,
I just pushed some things [1] to mob that make shared libs on x86-64 linux
sort of working (well, in my little tests). It's not 100% conformant to
the ABI yet, but hey, its late here :) i386 could now use some cleanups
as well (so that it really generates PIC code, not that unsharing
Hi,
On Mon, 31 Mar 2014, Aharon Robbins wrote:
Testing appreciated (hi Arnold :) ).
This has certainly improved things; two tests that used to fail now
pass, although two more continue to fail. If you want to test yourself,
here's the recipe:
git clone
Hi,
On Thu, 3 Apr 2014, Domingo Alvarez Duarte wrote:
I propose to remove bounds check from tests/build till we have a good
solution/implementation to it.
Why should we? The checks are for features that are supposed to work.
They did work once. They don't anymore. That's a regression.
Hello Ramsay,
On Thu, 3 Apr 2014, Ramsay Jones wrote:
After commit ea2805f (shared libs: Build libtcc1.a with -fPIC, 02-04-2014),
this now fails like so:
Fixed with 2024c445. Indeed PIC input wasn't handled correctly in
connection with -run (emitting a real ELF executable worked). So the
Hi,
On Fri, 4 Apr 2014, Vincent Lefevre wrote:
Actually I just fixed a similar error for gawk (libtcc1.a containing non-PIC
code), which has exactly that symptom ('abort' and _PC32 reloc overflowing).
So it's worth a new try with mob branch.
This doesn't change anything in MPFR:
Hi,
On Fri, 4 Apr 2014, grischka wrote:
Question apropos:
On linux x86_64 there is still the ugly
runtime_plt_and_got
hack which is a replacement for PLT in the tcc -run case
to forward 32bit calls to extern libraries.
On win64 the same problem is solved by building the IAT
(import
Hi,
On Fri, 4 Apr 2014, Michael Matz wrote:
Yes, that's something on my TODO. Theoretically having
runtime_plt_and_got makes code emission a tiny bit faster because having
a proper PLT and GOT also for -run means first creating and second
applying intermediate relocations (the _GLOB_DAT
Hi,
On Sun, 6 Apr 2014, Domingo Alvarez Duarte wrote:
Ok I can see in the next commit that this is removed completely !
Yep, I was trying to separate cleanups from implementing features also for
the commits, makes bisecting a tad easier. (And of course removing chunks
of dead code without
Hello Thomas,
On Wed, 9 Apr 2014, Thomas Preud'homme wrote:
I have a patch to build a single cross-compiler by using --targetcpu but
given the potential of breakage of the build script I prefer to post it
here for now and ask you to try building tcc with it, either natively or
all the
Hi,
On Sat, 12 Apr 2014, Christian Jullien wrote:
No comments about this issue?
It shouldn't be a new warning. The code in question (libtcc1.c,
ldouble_long type, the __fixunsxfdi function, and the definition of
LDOUBLE_SIZE for ARM) hasn't changed in ages.
In fact, this warning is a
Hi,
On Sat, 12 Apr 2014, Austin English wrote:
I recently revisited compiling Wine with TinyCC. I've got some patches for
wine for that, but my current blocker is a lack of support for hidden
symbols on tcc:
Even with that fixed I'll predict some more blockers for wine. It's not
exactly
Hi,
On Sun, 13 Apr 2014, Austin English wrote:
I expected that wine wouldn't immediately work, I'm doing it for the
curiosity factor.
Okay :)
The next problem is:
make[1]: Entering directory `/home/austin/src/wine-tcc/dlls/acledit'
/home/austin/tcc/bin/i386-linux-gnu-tcc -m32 -c -I. -I.
Hello,
okay, are the last commits to mob from jiang meant as joke or vandalism?
* 32bit code generation is hosed already in the testsuite,
* gawk doesn't work anymore even for x86_64,
* arm codegen is broken already in the testsuite (adding an internal
compiler error)
* they contain ugly
Hi,
On Sun, 22 Jun 2014, David Mertens wrote:
Hey jiang,
For each of these three patches, please explain the following:
1) When run with the version of tcc without your patch, what behavior do you
get? What does the C99 spec tell us we should get?
2) How does the proposed patch alter the
Hi,
On Sun, 22 Jun 2014, jiang wrote:
This is my patch (see Annex)
tcc result is correct
-- 254 / 30 / 126
That's not the correct result. If you think it is the probably because
you're confused by the semantics of assignments as rvalue.
I guess gcc mvc repeated use of the register, so
Hi,
On Sun, 22 Jun 2014, David Mertens wrote:
Sorry, I decided to give more than 20 hours for folks to weigh in, and then
time got away from me. I'll revert jiang's changes with a push some time
around June 23 (tomorrow), 9:00PM New York time.
By the way, if the instructions at
Hi,
On Sat, 28 Jun 2014, Thomas Preud'homme wrote:
In three weeks will be the GNU Tools Cauldron. I'm going to attend it
(it will be my first time) and I was wondering if some of you would come
there. I noticed some familiar names when joining the GCC community so I
guess some of you will
On Fri, 27 Jun 2014, Markus Bergholz wrote:
Make it clear where “mexPrintf” is defined and why it is not
effective.
mexPrintf is defined in /usr/include/octave-3.8.1/octave/mexproto.h afaiu.
That's a declaration, not a definition. The definition comes from some
Octave
Hi,
On Tue, 9 Sep 2014, Thomas Preud'homme wrote:
1) You added the support for R_ARM_GLOB_DAT and R_ARM_JUMP_SLOT
relocations but the computation you added ignore the possible addend at
*ptr by doing a simple assignment. Is that normal? Did I miss something?
This is per the ABI. The
Hi,
On Thu, 18 Sep 2014, Michael Matz wrote:
Now obviously I bungled something regarding all that on ARM and will
have to look at the details. Let me first try to reproduce and I'll
come back.
Hmm, current git TCC works for me on ARMv7 in a qemu-simulated chroot. I
do have to configure
Am 07.01.2015 um 04:14 schrieb Sergey Korshunoff:
After applying a disable DTEST patch to allow make test to pass a
broken tests...
./configure --cc=tcc; make; make install; make test
tcc -o tcctest.cc tcctest.c -I.. -I.. -w -DTCC_TARGET_I386
-std=gnu99 -O0 -fno-omit-frame-pointer
tcc:
Am 07.01.2015 um 11:22 schrieb Sergey Korshunoff:
I'm agree. But what to do with the described bug? How to fix it?
cd tcc-source
./configure --cc=tcc; make; make install; make test
tcc -o tcctest.cc tcctest.c -I.. -I.. -w -DTCC_TARGET_I386
-std=gnu99 -O0 -fno-omit-frame-pointer
tcc: error:
Hi,
On Mon, 9 Mar 2015, Edmund Grimley Evans wrote:
Michael Matz matz@frakked.de:
And some more fixes for more tests in 73_arm64, namely stdarg
passing of structs passed in purely integer registers. structs
passed in fp regs or mixed int/fp regs are unfortunately not
consecutive
Hi,
On Mon, 2 Mar 2015, Sergey Korshunoff wrote:
What stuff to change globally do you have in mind?
For example, a compiler defines are currently embeded inside a tcc. If
such defines will be placed inside a configuration file then it will be
possible to select a tcc behavior without tcc
Hi,
On Mon, 9 Mar 2015, Michael Matz wrote:
Same issue with x86_64 and RPi arm32
I just pushed something that helps x86_64 to not segfault this test.
It still exposes other bugs in parameter passing there, but doesn't
segfault anymore.
And some more fixes for more tests in 73_arm64
Hi,
On Sun, 8 Mar 2015, Edmund Grimley Evans wrote:
lib/armeabi.c uses UTF-8.
RELICENSING, arm-gen.c and i386-asm.c use ISO-8859-1.
Changelog uses a mixture. Yuck!
The script in the commit message converts every line that isn't valid
UTF-8 from ISO-8859-1 to UTF-8.
I'm attaching the
Hi,
On Thu, 26 Feb 2015, Christian Jullien wrote:
Same issue with x86_64 and RPi arm32
I just pushed something that helps x86_64 to not segfault this test. It
still exposes other bugs in parameter passing there, but doesn't segfault
anymore. On arm32 (but in qemu, not real hardware) I
Hi,
On Mon, 9 Mar 2015, Sergey Korshunoff wrote:
This behavior may depend on the gdb version. I use a rhide v1.5 for
debuggin (i386, Linux). A gdb version embedded in it is 6.1.1
This version is more than ten years old.
And which version of the gdb you use?
Various ones, 7.3, 7.5.50,
Hi,
On Sun, 29 Mar 2015, Sergey Korshunoff wrote:
struct A
{
struct B {
int f1;
int f2;
};
};
int main()
{
struct A a;
a.f1 = 16;
a.f2 = 32;
}
A tcc compiler must not accept this program because a struct B is only
a type declaration and not a
Hi,
On Fri, 20 Feb 2015, Edmund Grimley Evans wrote:
Does this look all right?
Do you have a testcase? I'll agree that there's possibly something fishy,
but the change doesn't look 100% right.
... looksy looksy ...
Hmm, maybe I trace your path how you found this :) When trying to use
Hi,
On Sat, 21 Feb 2015, Edmund Grimley Evans wrote:
Michael Matz matz@frakked.de:
I don't like this. tccgen.c should become _less_ dependend on the
TARGET defines, not more. Hence either VT_REF has a purpose and it
might make sense to use it in more backends, or it hasn't and should
Hi,
On Sun, 22 Feb 2015, Edmund Grimley Evans wrote:
The only disadvantage that I can think of is that certain
expressions which would cause GCC to warn that value computed is
not used would not get optimised.
I think the conversion to rvalue might not actually have to emit
code, in which
Hi,
On Fri, 20 Feb 2015, Edmund Grimley Evans wrote:
VT_REF is not mentioned in the documentation and seems to be used only
for x86_64. Also, it seems to be the same thing as VT_LLOCAL, really.
This could be a first step towards removing it altogether.
Commit message:
Make it explicit
Hi,
On Sun, 22 Feb 2015, Edmund Grimley Evans wrote:
I've done roughly that. However, I included both fixes for
VT_LLOCAL/'.', but with both disabled. Also, I omitted the VT_REF patch,
of course.
New diff attached, with updated README.arm64.
Just for demonstration, this is what I meant
Hi,
On Sun, 22 Feb 2015, Edmund Grimley Evans wrote:
That's excellent. Many thanks. When do you sleep, by the way? :-)
Roughly when you asked this question :)
- merge my local uncommitted stuff or at least stash it somehow
(I've implemented HFAs and have started doing va_list)
- rebase my
c2274760caed058d53a94e161c34ea7ea49bfdca Mon Sep 17 00:00:00 2001
From: Michael Matz m...@suse.de
Date: Sun, 22 Feb 2015 05:59:06 +0100
Subject: [PATCH] aarch64: Fix -run.
This adds some more support for properly transfering some
offsets over the different stages of a relocations life.
Still not at all psABI compliant and DSOs
Hello Edmund,
On Tue, 17 Feb 2015, Edmund Grimley Evans wrote:
With TCC the addend is zero! Apparently TCC is putting the offset is
in the data section:
readelf -x .data t1.gcc.o
0x
readelf -x .data t1.tcc.o
0x 1000
Hi,
On Thu, 19 Feb 2015, Naper Hamza wrote:
Hello , I wanna know if tcc have a global config , where we can change some
stuff , if not why not implementing one ?
That's not how compilers traditionally work, it would be a layering
violation. What options are active for a compilation is
Hi,
On Fri, 20 Feb 2015, Edmund Grimley Evans wrote:
extern void f(void);
g() { void (*ptr)(void) = f; ptr(); }
Here there will be a GOT slot allocated for 'f'. The initialization of
'ptr' will load from that GOT slot. So even though direct calls to 'f'
can (and will be, when 'f' is
Hi,
On Mon, 13 Apr 2015, Thomas Preud'homme wrote:
exporting _all_ global symbols from an executable always, only symbols
actually undefined in shared libs and provided by the executable are
exported (included as defined in .dynsym). That's the purpose of
bind_libs_dynsyms.
It
Hi,
On Wed, 15 Apr 2015, Thomas Preud'homme wrote:
Nope. Try it for yourself:
Huh, indeed. IMHO that's inconsistent with the symbol resolution
behaviour of GNU ld (only looking in level0 libs for symbols, not in those
DT_NEEDED by them, unless --copy-dt-needed-entries is active), but
Hello Thomas,
On Sun, 12 Apr 2015, Thomas Preud'homme wrote:
I was a bit puzzled because I saw symbols are resolved when a file is
loaded that define them (in tcc_load_object_file). The reason this
doesn't happen here is that the symbol is provided by libc.so.6 and the
function that loads
Hi,
On Thu, 2 Apr 2015, Sergey Korshunoff wrote:
Thanks. Very interesting. Then a patch must contain a -fms-extensions
option too.
Or we just declare this to be a non-issue. Accepting invalid source is
IMHO acceptable in the scope of TCC (at least if the fix would be too
involved).
Ciao,
Hi,
On Thu, 21 May 2015, Thomas Preud'homme wrote:
On May 18, 2015 11:17:35 PM GMT+08:00, Sergey Korshunoff sey...@gmail.com
wrote:
tries comparing the output of readelf -a for an hello world program
but there are too many
differences and I didn't spot anything obvious
there is no
Hi,
On Wed, 1 Jul 2015, Aharon Robbins wrote:
Hi.
The current mob on x86_64 no longer compiles gawk correctly. The
generated executable does a stunning job of failing the test suite,
dumping core multiple times.
wget http://ftp.gnu.org/gnu/gawk/gawk-4.1.3.tar.gz # latest release
Hi,
On Mon, 27 Jul 2015, gus knight wrote:
On Mon, Jul 27, 2015 at 12:48 PM, Christian JULLIEN eli...@orange.fr wrote:
Hi Gus,
This is a good idea. If you do so, I also suggest an arch directory that
contains subdirectories for all supported archives
I wound up going with one dir per
Hello gus or Augustin,
while I appreciate more people working on tinycc, why do you think the
best thing to do as the very first commits would be source code
reformattings and reorganizations? Look at what damage you've done:
@@ -204,7 +204,7 @@ void C67_g(int c)
#endif
ind1 = ind + 4;
Hi,
On Sun, 25 Oct 2015, Sergey Korshunoff wrote:
> Hi! Commented out a tcc_error_noabort("'%s' defined twice"... on mob
> gcc-3.4.6 don't give such error by default
> example file1.c
> char __version_303_;
> void func1() {}
> example file2.c
> char __version_303_;
> void
Hi,
On Thu, 29 Oct 2015, grischka wrote:
> Michael Matz wrote:
> > ... In C it's not allowed to have two definitions of the same non-static
> > symbol, simple as that. It's not only for when initialized with different
> > values or the like; it's undefined no matter what
Hi,
On Thu, 10 Sep 2015, Jared Maddox wrote:
> Does anyone remember if this is supposed to currently work? Is there
> some sort of caveat, such as requiring a linker flag or script?
No, it's simply not implemented, and even hacks aren't working. The
ctor/dtor attributes aren't implemented,
Hi,
On Tue, 15 Dec 2015, Vincent Lefevre wrote:
With glibc 2.21 (Debian/unstable on x86_64), on any code compiled by
tcc segfaults. This occurs with both old tcc (tcc
0.9.27~git20140923.9d7fb33-3 Debian package) and mob. I wonder whether
this is a bug in tcc or in the glibc.
According to
Hi,
On Thu, 17 Dec 2015, Aharon Robbins wrote:
TCC on x86_64 is broken (again) when used to create .so files. I like
to use it for gawk development since it's fast.
Unfortunately, all the shared library stuff no longer works.
This can be reproduced using the current version:
wget
Hi,
On Sat, 19 Dec 2015, Jeremy Kvurr wrote:
Hello. I know about the existance of the -g option in the tcc, but I don't
know how to enable a source-level debugging using this debug info. I tried
to run the tcc-generated program with winedbg, but he hasn't recognised the
symbols it seems. And I
Hi,
On Mon, 6 Jun 2016, Steffen Nurpmeso wrote:
> Bäh!
> Take this one, please, the other one deleted an option.
> Ciao!
I think this leaks memory when opath contains a string already. pbuf is
allocated memory, you free the opath, copy pbuf into npath, but then leak
pbuf itself (it's not
Hi,
On Sat, 4 Jun 2016, David Mertens wrote:
Nice. I am not very familiar with this part of tcc, but I noticed the
use of ':' as a path separator. Is this the path separator used across
all platforms?
Yes. On all those that support DT_RPATH or DT_RUNPATH, which is an
ELFism ...
In
Hi,
On Thu, 2 Jun 2016, Steffen Nurpmeso wrote:
Well, have i yet asked this? I think no...
It's like that for a long time, ever since i use tcc(1) (autumn
last year):
?0[steffen@wales tmp]$ cat t.c
#include
int main(void){
char *x = realpath(".", NULL);
return (x != NULL) ? 0 :
Hi,
On Fri, 11 Mar 2016, Michael Matz wrote:
This whole thing also points out some deficiencies of tcc to emit error
messages. For instance it accepts the initialization
void f(void) {
struct w q = {"bugs", { 'c' } };
}
(and sets ref->c to 1), even though this is
Hi,
On Thu, 10 Mar 2016, Мельников Алексей wrote:
--> Urgs. Are you really using digraphs in any production code?
--> (Yes, tcc tries to support c99, but, well, I mean, digraphs? Seriously? If
you use EBCDIC you have more serious problems with tcc I guess, and if you don't,
why use
Hi,
On Fri, 11 Mar 2016, Michael Matz wrote:
it's now "size += -1 * 4 + 1" (i.e. +=3).
-=3 of course, but you got the idea :)
So, I think it's more correct to special case the ref->c == -1 case only
(don't adjust size in that case), instead of playing +-1 tricks (as in,
i
Hi,
On Sat, 12 Mar 2016, arn...@skeeve.com wrote:
First, the bug can't be as MAJOR as the subject wants to make us
believe. After all it wasn't noticed since the last $MANY years.
The bug caused me to push bad code to gawk's repo.
I assumed something like that. It still doesn't make the
Hi,
On Sat, 12 Mar 2016, Daniel Glöckner wrote:
The issue isn't just the lack of diagnostic - what kind of erroneous
code is being generated in this case?
Let's see what the final C11 draft (N1570) says about this issue:
Section 6.8.4.2 paragraph 3:
The expression of each case label shall
Hi,
On Fri, 11 Mar 2016, Amine Najahi wrote:
> Perhaps surprisingly, correcting this bug is quite costly. Here is a
> tentative patch. I find it messy but working with dynamic data and
> passing the cases to the block function are necessary to handle an
> "unlimited number" of cases and
Hi,
On Wed, 9 Mar 2016, Henry Kroll wrote:
I created a + 1 patch that seems to work, but I need to run more tests
before committing.
=
diff --git a/tccgen.c b/tccgen.c
index 3cd28ed..270d11c 100644
--- a/tccgen.c
+++ b/tccgen.c
@@ -5847,7
Hi,
On Sun, 13 Mar 2016, arn...@skeeve.com wrote:
> Whoever it was that posted the note about the standard requiring a
> diagnostic was right on target.
It was me ...
> This is too fundamental a mistake not to diagnose.
... making a concious decision to conditionally disagree with you
Hi,
On Wed, 6 Apr 2016, Vladimir Vissoultchev wrote:
https://github.com/wqweto/tinycc/commit/0691b7630b89bf3de5f7691802cb923bd7c1
fd99
Thanks, please push to mob. (It would be easier to review if you'd
include the patch in plain text in your email. I for instance use a
console based MUA,
Hi,
welcome to TCC development :)
On Mon, 14 Mar 2016, Vladimir Vissoultchev wrote:
> A symbol is one or more characters chosen from the set of all letters
(both upper and lower case), digits and the three characters _.$. No
> symbol may begin with a digit. Case is significant. There is no
Hi,
On Thu, 17 Mar 2016, Vladimir Vissoultchev wrote:
> About the TOK_DOTS saga -- yes, the original code was using PEEKC
> canonically, I'm not sure about the unget hack it implemented though.
It is, as the comment written next to it explained.
I fixed the parsing of ..\n. now in mob with a
1 - 100 of 514 matches
Mail list logo
