[Tinycc-devel] Recent patches for the TinyCC 0.9.28 Release Candidate

[Detlef Riekenberg]

Hi TinyCC follower.


The current branch is a release candidate for TinyCC 0.9.28 since some month.

From the active people here, only grischka has the rights to make a release,
and I suggest, that we should help him to be comfortable to make a release by:
* more testing
* add only minimal fixes to the current mob branch to increase stability
* avoid to push any new features for now

I further suggest, that for any patch, which is longer than one or two lines,
the change should be discussed here before pushing.


@grischka
I tested your recent fixes:
The i386-tcc search path works now. Thanks
(I tested with a simple Hello_World for X11 and a simple ppm viewer for X11)


@Eric Raible:
A custom allocator is not a new idea.
TinyCC has already a custom allocator and uses it by default.
How often will it be useful for a libtcc user to force TinyCC
to use an application provided allocator?
You add an overhead for every user of TinyCC for every memory allocation/free.

My additional comments to your patch:
* it is a far to big change for a release candidate
* it needs a lot of testing
* it adds more complexity

#####

@kbkpbot
Yes, there are many things missing for atomic support,
but when i read your patch, i'm not sure,
if the code works with any windows compiler, which is incompatible to gcc.
(I changed my SSD and msvc is not installed yet, so I can't test that now)

Reason: "__attribute__" and "__asm__" are gcc extensions.
Are they supported by MSVC?
(Yes, i saw, that you mostly just moved the code around...)

+#ifndef __TINYC__
+void __atomic_signal_fence(int memorder) 
__attribute__((alias("__tcc_atomic_signal_fence")));


In the meantime, a macro for a fence can help


#####

I suggest to revert both changes (with the cleanup from @Herman)
and wait until @grischka pushes a release.

@grischka, what do you think about reverting everything after your cleanup patch
and then push a release?


--
Bye bye ... Detlef