Re: [Tinycc-devel] All known working ports
On Thu, Jan 14, 2021 at 12:17:23PM +0100, Christian Jullien wrote: > macOS | x64 | clang/tcc | Ok (only tcc static) You reported success with dynamic linking on June 21. Why only static this time? Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Tiny c availability
On Thu, Jul 09, 2020 at 10:09:56AM +0200, Christian Jullien wrote: > Many starts with more than one :o) Even the Pirahã appear to agree that many doesn't start before three. > Five BIG projects is not that bad. > > Let me start with few I very often (if not daily) compile: > - OpenLisp (daily) > - bigz (daily) > - gnumake (every major version) > - sqlite (daily - part of OpenLisp build) > - tcc (almost daily) > > They already count for FIVE :o) But you talked about many people, not many projects, and you are only one person, unless of course you have a split personality. :P > What about a page referencing projects that build with tcc? That would also be useful to show what tcc is capable of compiling. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Tiny c availability
On Thu, Jul 09, 2020 at 06:29:11AM +0200, Christian Jullien wrote: > We are many to use it daily as main C compiler for really big projects. It think that's a bit exaggerated. From what I saw on this list you can count the number of people who use it for "really big projects" on one hand. A few people turned to tcc because it can serve as a JIT compiler while being smaller and probably easier to use than LLVM. Many people that choose tcc see no benefit in using a big featureful optimizing proven-in-use toolchain but are happy about every second they don't have to wait for the compiler. I'd be happy to be proven wrong. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] (maybe dumb) licensing question
Hello Karl, On Wed, May 13, 2020 at 07:30:32AM -0700, Karl Yerkes wrote: > i have a project that uses tcc as a library. i "use TCC as a backend for > dynamic code generation" as mentioned here: > https://savannah.nongnu.org/projects/tinycc/. it includes *libtcc.h* and > links statically or dynamically to *libtcc*. what are my licensing options > for my project? for dynamic linking you are free to use any license you want on your code. For static linking, your project must be compatible to the LGPL v2 or later if you target ARM32. Other targets use a more permissive BSD-like license. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Fwd: Re: github
On Wed, Apr 22, 2020 at 10:44:37AM +0200, Robert Hölzl wrote: > I did macOS test with the help of vagrant. > > You can download any OS from their platform: > https://app.vagrantup.com/boxes/search > > and its very convenient as it automates the generation and > integration (ssh connection, shared folders, ...). > And as it is a VM it is 100% macOS (no emulation with its quirks) The thing is that the macOS license AFAIK allows the use only on Apple hardware. There is no "official" macOS VM on Vagrant. All macOS VMs you can find on Vagrant have been provided by users. In another project we are using a machine provided by MacStadium, but OSS projects need regular releases (and a logo) to quality for a free machine. Yes, they should really consider shared hosting for projects that don't need a dedicated machine... Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Questions regarding ARM Thumb code generation
Hi, On Sun, Mar 22, 2020 at 11:26:30AM +, Erlend Sveen wrote: > * The repository I found mentions a licensing issue. I've searched the > mailing list and found that the author of the original ARM codegen does not > want to re-license it. Personally, I don't mind leaving the license as is. > There is no way I will be able to write the thumb code gen from scratch, > so my code will be based on the ARM one and subject to the same issue. Do I > need to worry about this? It would really suck if my code gets dropped due > to relicensing in the future. since I am the one who does not want to relicense the ARM32 backend, I give you and everyone else permission to use my ARM backend code as a template for a backend for another instruction set as long as you release it as open source software under the license found in the RELICENSING file in TinyCC (or the LGPL). To me ARM Thumb is a different instruction set. My intention is not to hinder development of TinyCC. What I want to prevent is that TinyCC gets hidden in closed source products. The LGPL does allow commercial use. People just have to read and follow the license. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Modifying a char pointer initialized by character string literal should cause an error.
Hi, On Fri, Dec 27, 2019 at 10:26:24PM +0800, 瞿兴 wrote: > In section 6.7.8 of the C99 draft document defines : > > If an attempt is made to use pointer variable p to modify the contents of the > array, the behavior is undefined. > > When executing the testcase(in the attachment), tinyc does not report an > error and modify the value of the variable NISLParameter0 successfully Well, "undefined behavior" allows tinycc to do this. > The attachment includes the relevant testcase. IMHO the only thing tinycc should do is to warn that a const char * has been implicitly cast to char * in the initialization of NISLParameter0. Putting string literals into read-only sections is a nice to have. > char *NISLParameter0 = "abcdefghij"; Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] make tcc reentrant
Hi,
On Sat, Dec 07, 2019 at 11:34:11AM +0100, Ulrich Schmidt wrote:
> - The in scenario1 unloved 1 function parameter can be ignored and the
> values stored locally:
> #define LIBPARAM1
> #define VALUE(v) v
> ..
>
> somereturn somefunc(LIBPARAM1 ...) {
> VALUE(count) = 0;
> ...
>
> - in scenario 2 we define the 2 macros different:
> #define LIBPARAM1 TCCState *s1,
> #define VALUE(v) s1->v
We need a macro
#if scenario == 1
#define PASSPARAM1
#else
#define PASSPARAM1 s1,
#endif
Grouping all globals in the TCCState structure might be beneficial
even if we don't switch to those macros, because of the cache locality
Christian wrote about. The VALUE macro in scenario 1 would then be
#define VALUE(v) global_state.v
Btw, has anyone thought about handling TCCState like the context is
handled in the OpenGL API? It has one function to select the context
to use for following operations and the operations themselves don't
have a parameter for the context. If the pointer to the TCCState is
stored in a normal or in a TLS variable is up to us and might even
be a compile time option (that is set to "normal" for compilation
with tcc as long as tcc doesn't know how to generate TLS variables).
Best regards,
Daniel
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Tinycc-devel Digest, Vol 192, Issue 11
On Sat, May 18, 2019 at 10:45:32AM -0700, Ben Hutchinson wrote: > It requires > MinGW to run in Windows (I'm a Windows user), so that means that using GCC > by itself is simply not an option, because it won't run without its MinGW > dependencies. The whole point of MinGW is that it uses the C library that is shipped with Windows. > This makes GCC very bloated (over 100MB in size), and thus > not a viable alternative to TCC. Just compare that to the size of your printer driver. Or the size of your hard disk... And precompiled GCC binaries usually also contain compiler backends and libraries for languages like C++, Objective C, Fortran and Ada. > Also, what is this "ONE_SOURCE=yes" > command line option you talk about in GCC? ONE_SOURCE is a macro in the TinyCC source code. It causes all C files to be compiled as one huge chunk, allowing the compiler optimize a bit more. > The simple solution would be for you (or another developer of TCC) to just > add a command line switch that when used causes TCC to not use the __stkchk > function, and thus remove the requirement for this function to exist, and > also prevent TCC from adding any extra code to the program's main code to > call this function. Let me repeat: Code running on Windows might crash if this function is not called where TinyCC emits a call to it. If you don't need __chkstk, you are not compiling for Windows and should not use a TinyCC that is targetting Windows. TinyCC targetting Linux does not emit calls to __chkstk. On the other hand, you appear to be able to understand C, so it should be easy for you to delete the eight lines from x86_64-gen.c and recompile TinyCC. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] How do I disable all runtime error checks in TCC?
On Wed, May 15, 2019 at 03:50:06PM -0700, Ben Hutchinson wrote: > I would like to make it so it doesn't insert ANY error checking code such > as stack checks, etc, into my program's code. You can tell if it is doing a > stack check because if you use -nostdlib, you can compile some very simple > programs, but if you try more complex programs it will give you the error: > tcc: error: undefined symbol '__chkstk' __chkstk is not for error checking. __chkstk is needed on Windows when the stack frame of a function exceeds 4 kB, because Windows allows the stack to grow only one page at a time. So __chkstk just touches all stack pages needed by the function in the correct order. If you are confident that you don't need __chkstk, you can provide your own dummy implementation. Best regards Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] (no subject)
Hi Andy, On Fri, May 10, 2019 at 07:30:24PM +0300, ANDY TAKKER wrote: > A lot of words are said about compatibility and portability, but GCC > and PCC bring one result, and TCC is completely different. Let's for a second assume that you run that code on an architecture with sizeof(char*) == sizeof(int). Why should TCC generate the same output as GCC and PCC? You attempt to skip the prologue of the function by adding 3 to the address, but the prologue is not standardized. The one used by TCC is different from the one used by GCC. Just compare the output of GCC with -O0 and GCC with -O3 -fomit-frame-pointer. That should also give you different results. And with -O3 GCC might even decide to omit that asm statement because it has no needed outputs, doesn't clobber anything and isn't marked as volatile. > Here is > another interesting link closely related to the TCC. > https://forum.nasm.us/index.php?topic=2524.0 If you have access to the output of that obscure mix of compiler, assembler, and linker, please provide the disassembly of the _start function. > nop jump: Sometimes TCC has to reserve space for an instruction before it knows if it is needed or how long it will be. To fill the gaps, it uses nops. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Porting tcc to Xtensa and running it on the ESP32
Hello Lars, On Thu, Feb 14, 2019 at 05:39:06PM +0100, Lars Hochstetter wrote: > I (newbie) was wondering how difficult it would be to > > 1. port tcc to the Tensilica Xtensa platform one difficulty is that Xtensa processors are very configurable. When someone synthesizes an Xtensa processor, the Tensilica tools generate a bunch of C header files that tell you f.ex. which instructions are enabled, which coprocessors exist and how many registers there are. You might remember that it took some time for GCC to be ported to the ESP8266. That was because it uses the uncommon call0 ABI variant as Espressif did not enable register windows (XCHAL_HAVE_WINDOWS == 0). But if you stick to the ESP32 and don't want to support all Xtensa variants, this should not be a problem. > Point 4 sounds pretty ambiguous - I don't know if I should use the > FreeRTOS port for the ESP32 (tcc could run as a FreeRTOS task and > receive input through e.g. the serial interface) or use an > bare-metal approach. I don't see where FreeRTOS would help you with tcc. Last time I checked, FreeRTOS was only about task management and IPC. On the other hand it takes just a few lines of code to put a bare metal program that does not access peripherals into a FreeRTOS task. RAM might become a problem. I have no idea how much RAM tcc needs. You might want to do some experiments with valgrind --tool=massif before trying to run it on the ESP32. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] TinyCC for bootstrapping (with patches)
On Sun, Jan 13, 2019 at 05:02:38PM +0100, Giovanni Mascellani wrote: > 2) I patched TinyCC so that it can be built by a compiler that does not > support floating point numbers (as is the case for the C compiler in > asmc that builds TinyCC). Basically I import in the TinyCC repository > the code from the Berkeley SoftFloat library[3] and replace each > operation between floating point numbers with the corresponding call to > SoftFloati. I really like the idea of using a library to perform floating point operations and I also like that you made it optional. But it looks like you made the assumption that long double is an 80 bit floating point type. This is only true for x86-32. You have to look at the LDOUBLE_SIZE macro to determine which of float64_t, extFloat80_t, and float128_t to use (For x86-32 it is 12 instead of 10 because of padding). Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] tcc doesn't work on OSX unless used via -run which isn't sufficient for most use cases
Hi, On Sun, Jan 06, 2019 at 07:33:15PM -0800, Timothee Cour wrote: > not appearing in > http://lists.nongnu.org/archive/html/tinycc-devel/2019-01/index.html I got your first mail. Maybe the mail archive is updated every few hours. > so I'm following up here: https://github.com/TinyCC/tinycc/issues/8 > (would rather use github issues if possible, but if you guys prefer > mailing list, fine too) This is an unofficial mirror of the code. I wonder why Vladimir allows Github issues to be created if he does not react to them. > > Is there any plan on supporting OSX? The situation is still the same. OS X uses a completely different file format for its object files and nobody has stepped up to implement it. Do you maybe want to implement it? Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] When is planned to be released the next version of Tcc?
On Sun, Dec 23, 2018 at 11:44:50AM +0100, Barath Aron wrote: > I traced the whole object loading procedure with gdb: > - ARM_EXIDX (section 6) is definitely not loaded, I traced it with gdb. Where did tcc decide to skip ARM_EXIDX? ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Commit 'x86-64: Fix calls via absolute function pointers' makes 07 test fail on ARM
On Sat, Dec 22, 2018 at 11:50:46AM +0100, Daniel Glöckner wrote: > GCC generates a "veener" Of course it's the linker, which is separate from GCC. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Commit 'x86-64: Fix calls via absolute function pointers' makes 07 test fail on ARM
On Thu, Dec 20, 2018 at 08:48:17AM +0100, Christian Jullien wrote:
> * At least on ARM (like RPi), zfunc below fails with something like:
> * +tcc: error: can't relocate value at 1ef93bc,1
> void zfunc()
> {
>((void (*)(void))0) ();
> }
The issue is that TCC does not know how to encode an absolute address
in the BL instruction. BL is always a relative call within +/- 32MB.
GCC generates a "veener" (aka trampoline) during linking if the link
target turns out to be outside of this range. For calls to absolute
addresses this is "LDR PC, [PC, #-4]" followed by the address.
We might also have this problem when we have to link a binary with a
.text section bigger than 32 MB. We could use the same veener in that
case, but if we aim for position independent code, we need one more
instruction: "LDR IP, [PC] ; ADD PC, PC, IP ; .word target - 0f ; 0:"
I have not looked at the code, but I believe it will be difficult to
insert the veeners between sections after the linker has made a plan
at which address to place the sections. We might also need several
iterations since adding veeners might increase the distance for calls
or branches beyond 32MB that were barely within 32MB without veeners.
Best regards,
Daniel
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Build libpng with tcc
On Thu, Jul 12, 2018 at 08:46:54PM +0300, Evgeny Nikonov wrote: > PNGCBAPI is _cdecl or __stdcall > What's wrong? _mingw.h contains only a definition for __cdecl, not for _cdecl. And I guess you either didn't try __stdcall or _mingw.h is not included. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Joining Tiny C Compiler with ItsyBitsy M0 Express
Hello Ulrich, On Fri, Apr 20, 2018 at 06:45:28PM +0200, Ulrich Althöfer wrote: > is it possible to implement the TCC on an awsome microcontroller board? in theory yes, but right now TCC does not support the Thumb instruction set used by Cortex-M ARM cores. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] backtrace() on Linux
Hi Yakov, backtrace() from Glibc calls _Unwind_Backtrace from libgcc_s.so.1 on x86_64. Guess which compiler libgcc_s.so.1 is made for. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Basic register usage
On Tue, Sep 26, 2017 at 07:59:30PM -0400, Charles Lohr wrote: > Is there some way of hinting to TCC "hey, register X contains Y sym" What > functions/data structures would I use in func_prolog to tell TCC about it? No, the gfunc_prolog function in all existing backends stores all parameters that are passed in registers on the stack. The offset in the stack frame is remembered together with the name of the parameter. Remember, TinyCC forgets what is inside the registers after each statement. So after the prolog has been emitted, all parameters must be on the stack. On the other hand, the gfunc_call function will get the parameters on the vtop stack. The r element of each vtop element will tell you if the value is already in a register and which register it is. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Resources/questions for porting?
Forgive me the brevity of my reply, but I should be asleep right now. On Mon, Sep 25, 2017 at 09:16:12PM -0400, Charles Lohr wrote: > To do this, I need to port TCC to xtensa specifically lx6 with no floating > point. It won't be easy to support floating point without floating point registers. TinyCC is not prepared to keep floating point values in integer registers. And you will need a soft float library like libgcc that probably can't be built with TinyCC unless you also implement an assembler. > (1) How does one get involved in coding for the core of TinyCC? Usually by submitting patches. > (2) I could use a C-to-JS compiler for this project. If I did succeed and > it worked well, would you consider it for inclusion considering emscripten > is a bloated mess. If you write it anyway, you might as well ask for inclusion. We keep these C67 and IL backends around, even though I have never heard of anyone using them. > (3) If I do get this xtensa output working, would there be interest for > inclusion in mainline? I'd say yes. > (4) Is there a better community (chat/discord/etc.) for discussing tinyCC? No, this is the best place. > (5) Currently, I am working by pulling from the repo.or.cz and pusing to my > git branch. Is this a reasonable thing to do before I am ready to try to > get into mob? Yes, it is. Please post the patches to the mailing list first. People pushing controverse patches to the mob branch has caused bad blood on the mailing list several times in the past. > (6) An in-depth discussion of what all goes into the -gen and -link files? > I think I've got it mostly figured out with the definitions in > xxx-[link|gen].c in tcc.h. I don't believe there is any documentation. When I wrote the ARM backend, I tried to mimic what the i386 code did. > (7) Register assignments. When I write my prolog and see code generation > requests, they seem to do some very dumb things almost assuming I have zero > registers. I don't understand how the management is supposed to work. It > feels rather muttled. I saw register assignment help in the ARM port, but, > it felt integrally tied into TCC in ways that are difficult to mirror for > xtensa. TinyCC forgets what is inside the registers as soon as it has emitted the code for a statement. There is no optimization across statements (which simplifies creating test cases for bugs btw.). > (8) Rationales behind emitting code directly from the -gen, -link. I.e. > Has anyone ever done a video or presentation on the big WHY. It feels VERY > different from other compilers in that it seems almost directly geared away > from having multiple steps. Which, is fast. But... may be suboptimal? It was done to have a small compiler. TinyCC was born as an IOCCC submission. > (9) Anything that discusses how optimization really goes on. Or is TCC's > approach always "you write slow C code, you get slow C code." It is mostly like that. There is a litte optimization inside expressions and someone once wrote code to not emit dead if/else branches (Did that code get merged?), but that's all that comes to mind right now. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Crutches_for_TCC_inline_Asm
On Fri, Jul 14, 2017 at 10:07:55AM +0300, ANDY TAKKER wrote:
> As I see, there are no good teaches among tinycc-devel.
Yeah, I know, I studied maths and cs, not pedagogy.
> So, let's go on. Next program compiling well, but
> linking bad.
>asm ( "mov %eax, a" );
Linking fails because it expects to find a symbol called "a" but
local variables can not be found in the symbol table.
> The next program compiling well, linking well,
> but brings bad results.
> unsigned int a = 0;
>
> int main()
> {
>
> unsigned int a;
> b:
>asm ( "cpuid" );
>asm ( "rdtsc" );
>asm ( "mov %eax, a" );
> printf("%d\n", a);
> goto b;
> }
You should have guessed by now that it will store the value
in the global variable.
> A big piece of work has been done. But
> who really need this heap of trash:
As I wrote in my last eMail, the TCC inline assembler tries to be
compatible to GCC. If you are unhappy with that, use another
compiler.
Did you read the GCC documentation for the inline assembler syntax?
Did you understand it?
Then you should know that the correct way to to it is:
int main()
{
unsigned int a;
int junk1, junk2, junk3;
b:
asm ( "cpuid\n"
"rdtsc"
: "=a"(a), "=b"(junk1), "=c"(junk2), "=d"(junk3));
printf("%u\n", a);
goto b;
}
> Of couse, Fabrice will never patch TCC. Because of because.
> It is life.
No. It's because Fabrice has left the project years ago.
And it does not need patching. It behaves as intended.
Best regards,
Daniel
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Inline assembler
Hi, On Thu, Jul 13, 2017 at 07:19:30AM +0300, ANDY TAKKER wrote: > Evil tongues from > https://sites.google.com/site/excelmidi/universal_student_ide/universal_student_ide_en > claim that TCC inline Assembler > not see local variables. I don't believe. > TCC such old. What I do wrong? TCC uses the GCC way of passing parameters to inline assembler. See https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Annoying new warning
On Sat, Apr 29, 2017 at 07:55:18PM +0200, Michael Matz wrote: > ARMs long double > type simply is double itself, and hence these functions are unused > on ARM. Well, they would be if there wouldn't be strange code in > arm-gen.c that makes use of xfdi conversions when VFP is enabled. > That makes no sense, also with VFP there's only support for IEEE > double, not for extended double. Since LDOUBLE_SIZE == 8 on VFP, those code lines will only be used with FPA. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Ready for Release 0.9.27
On Thu, Feb 09, 2017 at 01:35:31PM +0100, Vincent Lefevre wrote: > If an int can represent all values of the original type (as > restricted by the width, for a bit-field), the value is converted > to an int; otherwise, it is converted to an unsigned int. These are > called the integer promotions.58) All other types are unchanged by > the integer promotions. I've had a look at the code. We can easily change gv() to cast unsigned bitfields < 32 bits to signed int, but there are lots of places where the code just looks at the VT_UNSIGNED flag or the VT_LLONG basic type and doesn't notice that VT_BITFIELD is set as well (and the size is < 32 bits). Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Weird bitfield size handling, discrepancy with gcc
On Tue, Oct 18, 2016 at 09:41:49AM +0200, Vincent Lefevre wrote: > AFAIK, both are correct. It depends on the ABI. The ARM EABI defines those details in http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042f/IHI0042F_aapcs.pdf section 7.1.7. But I don't know if we adhere to those rules when compiling for ARM. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Governance (Re: cleanups)
Hi, on Github we could use Travis to run tests after every commit. We could also use Qemu there to check if the other architectures still work. It might also serve as an example how to setup a cross development environment with TinyCC. Best regards. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Use TCC with GSL under Windows
Hi Xianwen, On Tue, Oct 11, 2016 at 11:43:40PM +0200, Chen, Xianwen wrote: > I have been very impressed by the size of exe's that TCC produces in > Windows. For the simple hello_world.c, TCC produces an exe of 2 KB, while > mingw-w64 produces an exe of 164 KB. Therefore, I would like to continue to > learn to use TCC. I'm pretty sure I've used MinGW to generate executables that small, although that was probably 16 years ago. Try to pass -s to GCC and don't use -g to get rid of symbol tables and debugging information. Most of the time TCC generates more code than GCC, especially when GCC is called with -Os. The linker of MinGW might enforce different section alignments than TCC. But that should add less than 10 kB of padding, regardless of the code size. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] ARM32 gfunc_epilog
On Mon, Oct 10, 2016 at 11:46:41AM +0200, Daniel Glöckner wrote:
> It emits the instruction "ldm fp, {fp, sp, pc}" which AFAIK will not
> do what we want when it is restarted after an exception, as the first
> thing it does is to change fp.
After reading all those ARM docs, I get the feeling that this will not
affect us. All existing Cortex-A processors do not support interruptible
LDM/STM as per ID_ISAR2 register and since ARM7EJ-S data aborts use the
base restored data abort model, meaning they restore the base register
to the value it had before the instruction. I have to check what my
Zaurus does. It still uses the base updated data abort model. The old
APCS standard apparently also used "ldmdb fp, {fp, sp, pc}", so it
would have suffered from the same problem.
The ARM11 (RPi!) does indicate support for interruptible LDM/STM in its
ID_ISAR2, but it will not interrupt these instructions unless low
interrupt latency mode is enabled. ARM11 was the first ARM with low
interrupt latency mode. I somehow doubt that Linux can run in this mode.
Generating APCS-compatible stack frames that can be unwound f.ex. by
the Linux OProfile code is easy. Creating the .ARM.extab and .ARM.exidx
sections specified by EABI would be significantly more work.
Best regards,
Daniel
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] ARM32 gfunc_epilog
Hi,
I think we need to change the epilog used on ARM.
It emits the instruction "ldm fp, {fp, sp, pc}" which AFAIK will not
do what we want when it is restarted after an exception, as the first
thing it does is to change fp. A workaround would be to move fp to lr
first and use that to load the other registers.
There once was a discussion about aligning our stack frame with the
one expected by debuggers. Maybe it is time to do that.
Any suggestions?
Best regards,
Daniel
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] PATCH: In gen_vla_sp_restore, use X30 rather than get_reg.
On Mon, Oct 10, 2016 at 10:19:24AM +0200, Daniel Glöckner wrote: > On Sun, Oct 09, 2016 at 11:51:11PM +0100, Edmund Grimley Evans wrote: > > -uint32_t r = intr(get_reg(RC_INT)); > > +// Use x30 because this function can be called when there > > +// is a live return value in x0 but there is nothing on > > +// the value stack to prevent get_reg from returning x0. > > +uint32_t r = 30; > > Wait, can this happen on ARM32 as well? Why is x0 still in use? Never mind, I was mentally inside gen_vla_alloc(). My gen_vla_sp_restore() just calls load(), which will use r14 if it needs a temporary register and usually doesn't need one (unless the current stack frame is > 4 kB). Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] PATCH: In gen_vla_sp_restore, use X30 rather than get_reg.
On Sun, Oct 09, 2016 at 11:51:11PM +0100, Edmund Grimley Evans wrote: > -uint32_t r = intr(get_reg(RC_INT)); > +// Use x30 because this function can be called when there > +// is a live return value in x0 but there is nothing on > +// the value stack to prevent get_reg from returning x0. > +uint32_t r = 30; Wait, can this happen on ARM32 as well? Why is x0 still in use? Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] BUG for ARM (32) maintainers
On Sat, Oct 08, 2016 at 07:33:03PM +0200, Christian Jullien wrote: > Now, the only two broken tests are related to unsupported vla: VLAs are now supported on ARM. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] BUG for ARM (32) maintainers
On Sat, Oct 08, 2016 at 02:13:54PM +0200, Christian Jullien wrote: > I don't know if you are aware, but for uncounted months, 73_arm64 is broken > on ARM (as with mi RPi which uses Hard floats). Try again. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] cleanups (Incorrect function call code on ARMv6)
On Mon, Oct 03, 2016 at 12:48:00PM +0200, grischka wrote: > Ok, have seen it: crash in "make test". So it's long long *p, v; p = p[0]++; that is miscompiled without the save_regs. To load the upper half of p[0] 4 is added to the register that holds p. But the register may not be modified because it is still used further down on vtop to store the incremented value. So actually we just have to save all entries on vtop that use the same register as the topmost one. We could also use a fresh register for the address of the upper half instead. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Incorrect function call code on ARMv6
On Thu, Aug 25, 2016 at 10:06:51AM +0100, Balazs Kezes wrote:
> On 2016-08-11 09:24 +0100, Balazs Kezes wrote:
> > I think it's just that that copy_params() never restores the spilled
> > registers. Maybe it needs some extra code at the end to see if any
> > parameters have been spilled to stack and then restore them?
>
> I've spent some time on this and I've found an alternative solution.
> Although I'm not entirely sure about it but I've attached a patch
> nevertheless.
> --- a/tccgen.c
> +++ b/tccgen.c
> @@ -854,11 +854,6 @@ ST_FUNC int gv(int rc)
> #endif
> if (r >= VT_CONST || /* XXX: test to VT_CONST incorrect ? */
> (vtop->r & VT_LVAL)) {
> -/* We do not want to modifier the long long
> - pointer here, so the safest (and less
> - efficient) is to save all the other registers
> - in the stack. XXX: totally inefficient. */
> -save_regs(1);
> /* load from memory */
> vtop->type.t = load_type;
> load(r, vtop);
This save_regs was added by Fabrice in October 2004 with the commit
message "fixed long long code gen bug". He didn't add a test case and
I couldn't find a mail related to this problem in the year before the
fix was committed.
I'd say we should apply your patch and wait for someone to hit the
original problem again.
Best regards,
Daniel
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Incorrect function call code on ARMv6
On Wed, Aug 10, 2016 at 06:59:46AM +0100, Balazs Kezes wrote: > 90: e5912000ldr r2, [r1] ; <-- This is the y argument. > 94: e50b2018str r2, [fp, #-24] > 98: e5901000ldr r1, [r0] > 9c: e284add r0, r0, #4 > a0: e5902000ldr r2, [r0] ; <-- The clobbering happens here. > a4: e50b101cstr r1, [fp, #-28] > a8: e1a01002mov r1, r2 > ac: e51b001cldr r0, [fp, #-28] > b0: ebfebl 0 I think the error is caused by the "vtop--;" lines in copy_params(). The former gfunc_call() implementation for ARM rotated the elements on the parameter stack to let get_reg() know that the registers are still in use. The current implementation drops each element directly after it has been moved to the final register. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] MAJOR bug: tcc doesn't detect duplicate cases in switch statements
On Sat, Mar 12, 2016 at 10:58:42AM -0700, arn...@skeeve.com wrote: > The bug caused me to push bad code to gawk's repo. It's only luck that it > wasn't noticed, but a bug is a bug. So you have personal feelings towards that bug. I'd never use TinyCC for serious development. There are simply not enough testers. > 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 be an integer constant expression and no two of the case constant expressions in the same switch statement shall have the same value after conversion. Section 4 paragraph 2: If a "shall" or "shall not" requirement that appears outside of a constraint or runtime-constraint is violated, the behavior is undefined. There you read it, C11 allows us to generate whatever we want. Regarding the cost of your solution, a tree structure might be faster and could also be implemented in a way that handles value ranges. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] License is too restrictive for real-world use.
On Wed, Mar 02, 2016 at 11:01:04AM +, John B wrote: > Also I was hoping maybe a previous version of it that didn't include > as many devs on-boarding from the 2013 version could be changed. Thus > nulling out the sign-off on devs that came afterwards. My first contribution was merged in 2003 if you are looking for older versions. > Because bsd license I believe would be 100x healthier for the project. It sounded like you wanted to keep it a secret in your product that is would be based on TinyCC. That is in violation of the second clause of the BSD license. The MIT license has a similar clause (actually it is more similar to the first BSD clause but not restricted to source code). > People would absolutely contribute back, but in a de-identified way. > I Absolutely believe this. So you would contribute back everything if it was BSD? What do you mean by "de-identified"? Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] License is too restrictive for real-world use.
On Wed, Mar 02, 2016 at 08:38:45AM +, John B wrote: > I love playing around with toys and trying to make them better. It beats > sudoku. But I am not going to surreptitiously steal the software but on > the cooperative flip side of that coin, I don't want to release my code, > either. After reading your side of the story, I have the feeling that keeping my parts of TinyCC as LGPL was the right choice. TinyCC is a small project with very few active developers. If your product uses TinyCC, you should feel the responsibility of committing improvements you made back the main project. (If on the other hand your product consists mainly of a modified version of TinyCC, you can try to convince us by offering a share of your earnings. ;) Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] You can use __declspec in TCC?
On Tue, Jan 12, 2016 at 02:38:50PM -0800, Ben Hutchinson wrote: > Also, I thought that to make it stdcall, you > needed to use __attributes__((stdcall)), not a standalone __stdcall. These > are the "weird" things that set TCC apart from all other C compilers I > thought, yet you say these C compiler standards also work in TCC? > > And by the way, I think __stdcall (with 2 underscores) for setting the use > of STDCALL calling convention is a Microsoft thing (as used in VC++). The > official C standard for setting the use of STDCALL calling convention is > actually supposed to be _stdcall (with 1 underscore). Isn't that correct? stdcall is a Microsoft thing. What are these C compiler standards you are talking about? AFAIK there are no standards for stdcall, only conventions. In a time before Cygwin and MinGW GCC did not know about stdcall. As GCC already had some other __attribute__((somethings)) they implemented stdcall as another function attribute instead of adding a new keyword. To get the Microsoft keyword #define __stdcall __attribute__((stdcall)) __stdcall has two underscores because the C standard (the real standard) says that all names that begin with two underscores are reserved, meaning you're on your own if there are name clashes when your code introduces a variable, function, or macro with the same name. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Source vandalism
On Wed, Jul 29, 2015 at 08:56:47AM -0400, gus knight wrote: The reformattings were to attempt to make everything conform to the CodingGuidelines document that was already in the tree (4 spaces not tabs, etc.) which a few files didn't conform to. The CodingStyle document is from April. Most code predates that file and I can't remember any discussion about the coding style on this list. The document merely lists what has been found while looking at several files. Yes, I will. Apologies, I should've looked more closely (or run the whole thing through clang-format, but that probably would've done damage in a different way...) If you use clang-format again, please don't change char *x to char* x. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Is this a duplicate ASM operation?
On Sun, Jan 18, 2015 at 02:10:52PM +0800, YX Hao wrote: I don't know much about ASM and how tcc translates c code into ASM. If the 2nd MOV is not necessary, can we optimize it in tcc? The redundant instruction is from the following printf call. TinyCC does not remember what is in each register when it starts to compile the next C statement. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] sinf/sin problems
Hi, just some nit-picking: On Wed, Dec 24, 2014 at 04:46:14PM +0800, Lee Duhem wrote: `sinf' is defined in libm.so, you need to link with it. on Linux As explained by Aharon, c compiler will offer an implicit declaration for any undeclared function that it saw, and the return type of this implicit declaration is `int'. Therefore those return values of `sin' in your code will be converted to `int' first, then convert to `double' for `printf' to print. The return value of a function returning an int is not passed in the register where a double would be returned, so you might get garbage that is in no way related to the input. On top of that the int is not cast to double in printf(\n%f, sin(1.0)); The bytes on the stack are simply reinterpreted as double, so printf(%f\n, 1); will not print 1.00. That's because of the ellipsis in the declaration of printf. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] How to use char \
Hi, On Wed, Oct 01, 2014 at 12:06:24AM +0800, Thomas Preud'homme wrote: I have a problem with the char \. For example in the line: strpbrk (file_name,\*?) ir order to know if i have a simple file name, tcc tells me unknown escape sequence. The manpage doesn't say that the strings accept escape sequence. Is it even defined in the standard? Sounds like a bug in TinyCC. Thomas, C does support the escape sequences \a, \b, \f, \n, \r, \t, \v, \', \, \?, \\, \3octal, \x2hex, \u4hex, and \U8hex. I guess BCC probably interpreted \* as \\*. When I want use as a char both text[i]='\' and text[i]='\\' do not work. Since I am there working on text strings I cannot equate '\' to ascii 28 first. '\' should be correct. What is the error you get? '\\' should be correct. What is the error you get? Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Building Unicode applications with TCC in Windows.
On Sat, Jul 05, 2014 at 10:09:34PM +0800, YX Hao wrote: Is is expected or is there something wrong? Would it be possible to make a modification to enable wmain() to be an entry point as well as main()? Maybe you can take a look at: win32\lib\crt1.c In crt1.c declare main and wmain as weak. In _start call __getmainargs/main if main and __wgetmainargs/wmain if !main. I wonder if this works when linking to static libraries like libfl (from GNU flex) that contain a main function. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Is static linking functional?
On Mon, Jun 23, 2014 at 12:07:45PM -0700, Wendell P wrote: I'll admit I'm confused by the operation of the -static switch in TCC. tcc app.c lib.a Links a single static library tcc -static app.c lib.a Instructs TinyCC to use only static libraries, even for implicitly linked libraries like msvcrt. I doubt you can create anything useful in Windows without dynamic libraries. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] run vs compiling
On Sat, Jun 21, 2014 at 03:44:27PM +0200, Markus Bergholz wrote: ~$ tcc *[^ca].c lgc.c lfunc.c -run lua.c Lua 5.2.3 Copyright (C) 1994-2013 Lua.org, PUC-Rio So far so good, but how can I compile/create binarys with tcc from lua? ~$ tcc *[^ca].c lgc.c lfunc.c tcc: error: undefined symbol 'main' tcc: error: undefined symbol 'fabs' ... How about ~$ tcc *[^ca].c lgc.c lfunc.c lua.c -lm -o lua ? ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] run vs compiling
On Sat, Jun 21, 2014 at 04:25:24PM +0200, Markus Bergholz wrote: Yes, this works. But why tcc don't need the -lm option when using -run? Because tcc itself is already linked to libm. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Tinycc from git still can't compile fossil-scm
On Sun, Mar 30, 2014 at 04:10:48PM +0100, Domingo Alvarez Duarte wrote: I followed the code on fossil-scm with printfs on va_start/va_end using the previous tcc stdargs implementation and it showed me that both the parent and child do va_end on the same pointer that's why the segfault. As long as fossil-scm uses fork and not vfork, calling va_end in the parent and child can't be the reason for the segfault. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Valgrind Inconsistency detected by ld.so: rtld.c:
On Fri, Mar 28, 2014 at 12:27:39PM +, Domingo Alvarez Duarte wrote: For arm experts, it gets a segfault on translate.c:98 Please try again with current mob. I fixed a bug that might be the cause for your segfault. Best regards, Daniel P.S.: I wonder if a better fix would be to use convert_parameter_type in gfunc_param_typed. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Tinycc from git still can't compile fossil-scm
Errr. I see you now fiddled with that on mob. Commit c025478d7c03, rewriting va* to not use malloc. That's completely wrong. You've effectively changed the ABI of stdarg, and hence interoperability with every non-TCC compiler. The public va_list on x86_64 _must_ be a pointer. Actually sizeof(va_list) is 24 on x86_64 GCC although va_list is passed as a pointer. So we should typedef void *va_list[3]; and cast that to struct __va_list_struct as needed. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Tinycc from git still can't compile fossil-scm
On Sat, Mar 29, 2014 at 11:46:26PM +0100, Daniel Glöckner wrote: Actually sizeof(va_list) is 24 on x86_64 GCC although va_list is passed as a pointer. So we should typedef void *va_list[3]; Or simply typedef struct __va_list_struct va_list[1]; ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Tinycc from git still can't compile fossil-scm
On Sat, Mar 29, 2014 at 11:52:42PM +0100, Daniel Glöckner wrote: Or simply typedef struct __va_list_struct va_list[1]; Fixed in mob. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Drop OABI and FPA from arm-gen.c
Hi Thomas, On Mon, Feb 10, 2014 at 10:22:03PM +0800, Thomas Preudhomme wrote: No new hardware come with a FPA unit as far as I know and kernel FPA implementation was removed from the Linux kernel a few versions ago. Russel King wanted to remove the NWFPE emulator in April 2013 because of licensing issues, but Linus overruled him. It is still available in 3.14-rc2. Also you might yourself have some hardware or installation with them I do still have the SL-5500 that I used back then to develop the TinyCC ARM backend, but the only thing I do with it these days is to recharge the battery. I suppose that doesn't change your mind, does it? How about a big fat warning to users of ARM OABI in 0.9.27 before it is removed once and for all an 0.9.28? Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Recent change breaks test3 on RPi
Hi Thomas, On Wed, Feb 05, 2014 at 02:15:07PM +0800, Thomas Preud'homme wrote: I would like to fix this but I need to see first why tcc and gcc differ. Daniel, if you read this, can you explain me why gcc seems to use a signed char while tcc uses an unsigned char? it seems char, signed char, and unsigned char are distinct types in C. With GCC neither unsigned char nor signed char is compatible with char. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] uint64_t/int64_t = double broken on ARM
Hello Thomas,
On Sat, Feb 01, 2014 at 07:04:24PM +0800, Thomas Preud'homme wrote:
Got a bit of time (and more importantly internet access) so it's now
fixed in mob. Thanks for reporting.
your patch makes
float f(unsigned long long x)
{
return x;
}
compile to
...
bl __aeabi_ul2f
vmovs0, r0
vmov.32 d0[0], r0
vmov.32 d0[1], r1
...
with softfp ABI and it generates the superfluous move from r1 with hard
float ABI. Maybe the cleanest solution is to temporarily change the ABI
when calling these functions.
Best regards,
Daniel
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] uint64_t/int64_t = double broken on ARM
On Tue, Jan 28, 2014 at 06:51:53AM +0100, Christian Jullien wrote: Playing with clock_gettime and uint64_t/int64_t on RPi (ARM), I discovered uint64_t = double conversion bug : NOTE: tcc is compiled using --with-libgcc The problem is that the EABI functions provided by libgcc still expect and return doubles in integer registers, even on hardfloat systems. This also affects casts in the other direction. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] linking tinycc
Hi Christian, On Sat, Jan 04, 2014 at 10:46:15AM +0100, Christian Jullien wrote: If I understand you well, you want to change RELICENSING file From Daniel Glöckner? arm-gen.c To Daniel GlöcknerNO arm-gen.c done. What can we do if we want an ARM backend having BSD Like license? - rewrite from scratch - dual license (either LGPL or BSD Like). I know many projects having dual license. - you allow tcc projet to make a fork, arm-gen.c - arm-bsd-gen.c (and maybe ./configure choose one or the other --bsd-only for example) Dual licensing defeats the purpose of not agreeing to the relicensing. It would be meaningful only if there were projects shipping modified versions of TinyCC that drop the BSD license in favor of the LGPL and that are more interesting to use as a base for new projects than TinyCC itself. Forking a BSD version is only useful if the BSD version initially contains less features, f.ex. by relicensing an old version of that file. I don't like playing those games. As for rewriting that file, I think Thomas is doing a good job at achieving that. Of the 2101 lines in that file git blame marks 525 lines as having been modified by him. Do you see other possible solution, what do you advice? Another possibility is that I might change my mind in the future. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] float value triggers error
On Sun, Nov 03, 2013 at 12:09:32PM -0800, Steven G. Messervey wrote:
mob-branch, configured with --with-libgcc only, debian squeeze 32-bit:
tcc: error: undefined symbol '__tcc_fpinit'
tcc: error: undefined symbol '__tcc_cvt_ftol'
--with-libgcc uses libgcc instead of libtcc1.
This will of course fail for tcc specific functions.
__tcc_cvt_ftol does the same as libgcc's __fix{s,d,x}fdi
and there are already tokens defined for those functions
for use on ARM. The only difference is that __tcc_cvt_ftol
passes the floating point value in a register and therefore
does not have to distinguish between float, double, and
long double.
__tcc_fpinit is probably redundant on Linux as GLIBC
already calls __setfpucw right before calling main.
Daniel
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Generating better i386 code
On Fri, Sep 27, 2013 at 11:21:19AM +1000, Jason Hood wrote:
On 26/09/2013 16:30, Daniel Glöckner wrote:
On Thu, Sep 26, 2013 at 03:39:45PM +1000, Jason Hood wrote:
* 4- 8-byte structs copy as int/long long (all targets);
did you check if the structure is aligned to a multiple of 4 bytes?
Otherwise it will crash on ARM.
No, as I thought structures of these sizes would already be
aligned (as if they were int or long long). Is that not
necessarily the case?
No,
struct {
char x[4];
}
has an alignment of 1 byte.
Daniel
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Generating better i386 code
Hi Jason, On Thu, Sep 26, 2013 at 03:39:45PM +1000, Jason Hood wrote: * 4- 8-byte structs copy as int/long long (all targets); did you check if the structure is aligned to a multiple of 4 bytes? Otherwise it will crash on ARM. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] TCC, king of small exe... hey wait...
On Fri, Sep 20, 2013 at 06:49:05PM +0200, Yann Collet wrote: - Is it even an objective for TCC to generate small-size exe ? No, Wikipedia refers to the size of the compiler, not to the size of the output. Have you tried GCC's -Os switch? On very small executables padding added by the linker might be significant. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Error: File crti.o/crt1.o Not Found and No Function Renaming
On Tue, Sep 17, 2013 at 07:07:38AM -0500, Cayce Pollard wrote: tcc: error: file '/project/arm-cc/sysroot/lib//libgcc_s.so.1' not found tcc: error: undefined symbol '__divsi3' tcc: error: undefined symbol '__modsi3' tcc: error: undefined symbol '__aeabi_uidiv' tcc: error: undefined symbol '__aeabi_uidivmod' tcc: error: undefined symbol '__aeabi_idiv' tcc: error: undefined symbol '__aeabi_idivmod' Android links statically against GCC's libgcc.a. See https://android.googlesource.com/platform/bionic.git/+/master/libc/arch-arm/bionic/libgcc_compat.c Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Problem Compiling tinycc For Android: strtold
On Wed, Sep 11, 2013 at 08:26:31PM -0500, Cayce Pollard wrote: Also, would that work for linking __clear_cache to the Android equivalent cacheflush? I would prefer directly using the __ARM_NR_cacheflush syscall to make it work on non-Bionic Linux as well. The syscall has been introduced into Linux in 2.3.7pre6. Glibc uses it in libdl after perfoming relocations since 2005 and according to https://github.com/android/platform_bionic/blob/master/libc/arch-arm/syscalls/cacheflush.S it is what Bionic's cacheflush uses under der hood. Unfortunately it is not exposed by Glibc. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Problem Compiling tinycc For Android: strtold
On Wed, Sep 11, 2013 at 03:40:15PM -0500, Cayce Pollard wrote: ./../tinycc/tccpp.c:1961: error: undefined reference to 'strtold' Just substitute strtod for strtold. It has probably been omitted from Android's libc because long double == double on ARM nowadays (i.e. with EABI or VFP). Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] TinyC configuration on WinXP
On Wed, Aug 07, 2013 at 08:37:22PM +0100, James Lyon wrote: It appears to add CPATH and C_INCLUDE_PATH to the header search path and LIBRARY_PATH to the linker search. I've not used this mechanism though. The code for this was added with 0ad857c80e1 after 0.9.26. 0.9.25 didn't use environment variables. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Fastest TCC version
On Fri, Jun 21, 2013 at 05:26:05AM +0530, Sherjil Ozair wrote: Could anyone direct me to the fastest TCC version that is there right now for compile-time? I downloaded 0.9.26 from http://bellard.org/tcc/. Is this the fastest one? I expect not, since this is quite an old version. That's a strange question. We don't try to improve the compile-time. I suspect the speed to be almost the same across releases with the later ones being slightly slower due to improved error checking and code optimization. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Do we want a BSD license for tinycc?
Hi Rune, On Thu, May 02, 2013 at 10:37:58AM +, u-tcc-u...@aetey.se wrote: From my perspective I'd like to skip the additional worry about which programs can be linked to which libraries and how. if you are a packager, why do you have to worry about that? I mean, if you still have the possibility to chose which library to link to, most of the time the program is already (L)GPL compatible. And if you always use the shared library, there is never a problem with LGPL. I dislike dynamic linking for technical reasons (too much complexity, artificial limitations and side effects, many times for no gain). Then, I dislike licenses which force me to use inferior/inappropriate technical means. Can you elaborate on that? Aside from some people not understanding how to use SONAMEs (Tegra 2 libjpeg.so binary blob...), I've never had problems with shared libraries. Off the top of my head I remember three cases where shared libs were superior: - Libgcc for ARM once had a bug in the division routine. If all applications had linked to the shared library, it would have been enough to replace just a single file. - Libpng has multiple times been updated because a vulnerability had been found in the code. And guess what, Firefox per default links statically to its own copy of libpng, so you have to replace Firefox as well. - I once had to squeeze ISC DHCP into a little NOR flash but each of the applications was linked statically to several ISC libraries and it appeared like no code was discarded during linking. It all magically fit once I persuaded the build process to create and use shared libraries. BSD license makes the software easier to package / deliver, which can make a big difference in certain cases. Btw., how do you at Aetey manage to provide the source code for the (L)GPL software you host? Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] ARM hardfloat prolog
On Thu, May 02, 2013 at 01:02:19PM +0200, Thomas Preud'homme wrote: Do you know where big-endian is used and by who? There once was a port of Debian for ARM big endian but it never got much traction so it seems to me there is not much interest for such a port anyway. No, I don't think I've seen a big endian ARM running Linux or BSD. But I know that there are TMS570 Cortex-R4 hard wired to big endian. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Do we want a BSD license for tinycc?
Hi, On Tue, Apr 30, 2013 at 09:14:58PM +0200, Marc Andre Tanner wrote: The fear of proprietary forks seems unfounded because there is already a mature BSD licensed C compiler (clang) available for people to base their work on. Let's see.. $ size /opt/llvm/bin/clang textdata bss dec hex filename 389997781193992 54640 40248410266245a /opt/llvm/bin/clang I think TinyCC might be preferred by some people who just need a small scripting engine. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Recent changes segfault on Linux ARM
On Fri, Apr 26, 2013 at 10:58:39PM +0200, Daniel Glöckner wrote: There are two things broken in the code generated by TCC: First of all TCC thinks it has to return the structure in memory pointed to by r0 and second it gets confused about where it stored r0 and instead reads the first float from the stack and interpretes that as a pointer. The latter should be fixed by the one-liner I just committed. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] ARM hardfloat prolog
Hi Thomas, I saw that you used the following line to store the floating point arguments that have been passed in fpu register: o(0xED2D0A00|nf); /* save s0-s15 on stack if needed */ In my 2nd edition ARM ARM this maps to the FSTMS instruction and there is a note allowing implementations to keep the values in an internal representation and just convert them to IEEE format for storing to memory. So I don't think we can use this instruction to store double arguments and need one FSTMS/FSTMD for each run of consecutive fpu registers of same precision to be stored. Or have read otherwise? Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Recent changes segfault on Linux ARM
Hi Christian, On Wed, May 01, 2013 at 04:44:09PM +0200, Christian Jullien wrote: ARM hardfloat: fix struct return with float/double args Fixes the case where the structure is not returned in registers. I thought it was related to ret_2float_test At least on Rpi I still have: ret_2float_test... Segmentation fault well, it should still crash if you compile abitest.c with GCC, as the first of the two issues is not resolved. With TinyCC it should work though, judging from visual inspection of the disassembly. Which hardfp environment do you use for the Rpi? Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Do we want a BSD license for tinycc?
On Tue, Apr 30, 2013 at 07:12:50PM +0200, Daniel Glöckner wrote: On Tue, Apr 30, 2013 at 07:07:34PM +0200, Thomas Preud'homme wrote: Mmmmh. Overall I'm more a (A|L)GPL guy but I choose different license for different project. For tcc I thought it could make sense since we have only libtcc has static lib and many people seem to build stuff around it. And if I volunteer to extend the Makefile for a shared libtcc? We already have rules for libtcc.so.1.0 and libtcc.dll in our Makefile. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] ARM hardfloat prolog
On Wed, May 01, 2013 at 05:02:54PM +0200, Thomas Preud'homme wrote: Le mercredi 1 mai 2013 16:59:25, Daniel Glöckner a écrit : In my 2nd edition ARM ARM this maps to the FSTMS instruction and there is a note allowing implementations to keep the values in an internal representation and just convert them to IEEE format for storing to memory. So I don't think we can use this instruction to store double arguments and need one FSTMS/FSTMD for each run of consecutive fpu registers of same precision to be stored. Or have read otherwise? Nope, I didn't see that line. Please go ahead if you want to fix it, otherwise I'll do it later (I'm working right now). I did some more research. ARM ARM 2nd edition (= Issue E) has several paragraphs below figure 2-1 in chapter C2 talking about that no assumptions can be made as to how single-precision registers overlap double-precision registers and that the value of double-precision registers after their corresponding single- precision registers have been loaded with a value becomes UNPREDICTABLE. Issue I, which can be downloaded after registering with ARM, replaces that half page of text with The mapping between a double-precision register and its pair of single-precision registers is as follows: - S2n lies in the least significant half of Dn - S2n+1 lies in the most significant half of Dn. So we are safe with the current implementation, at least on little-endian ARM. On big-endian ARM the halves will have the wrong order if we don't use FSTMD, but there is a lot more that needs to be done until we support big-endian ARM. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Do we want a BSD license for tinycc?
On Tue, Apr 30, 2013 at 03:40:43PM +0200, grischka wrote: So the questions is: Do you people want, is it possible, what would it take - to change our tinycc code's license from LGPL to a BSD-like one (such as below). Please discuss. I don't see anything good coming from a change from LGPL to BSD. It just encourages people to create private forks for binary-only releases. And I have yet to hear anyone complain on this list that they can't use TinyCC in their product because they can't link dynamically to the library. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Do we want a BSD license for tinycc?
On Tue, Apr 30, 2013 at 05:43:03PM +0200, Thomas Preud'homme wrote: As I already said privately, I'm fine with BSD-2-clause. Does that mean you prefer it over the LGPL? What about you, grischka? Which one do you prefer? Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Do we want a BSD license for tinycc?
On Tue, Apr 30, 2013 at 07:07:34PM +0200, Thomas Preud'homme wrote: Mmmmh. Overall I'm more a (A|L)GPL guy but I choose different license for different project. For tcc I thought it could make sense since we have only libtcc has static lib and many people seem to build stuff around it. And if I volunteer to extend the Makefile for a shared libtcc? Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Recent changes segfault on Linux ARM
On Fri, Apr 26, 2013 at 08:27:25PM +0100, James Lyon wrote: I think that ARM should use a hidden pointer to return the data in ret_2float_test, but reading the ARM EABI spec a structure with 2 floats in might count as a 64-bit containerized vector and thus would be returned in r0 and r1. In that case I think the thing to do is modify gfunc_sret to detect this. GCC with hard float ABI returns the structure in s0 and s1. There are two things broken in the code generated by TCC: First of all TCC thinks it has to return the structure in memory pointed to by r0 and second it gets confused about where it stored r0 and instead reads the first float from the stack and interpretes that as a pointer. And I am not happy that is_fconst() apparently does not work. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Recent changes segfault on Linux ARM
On Fri, Apr 26, 2013 at 10:58:39PM +0200, Daniel Glöckner wrote: And I am not happy that is_fconst() apparently does not work. Scratch that. is_fconst() is for FPA an the VMOV (imm) instruction I saw in the output of GCC is VFPv3. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] ARM code generator / ARM tiny C compiler
On Thu, Apr 25, 2013 at 01:11:42PM +0200, Armin Steinhoff wrote: libtcc1.c doesn't compile for ARMv7 :) libtcc1.c doesn't contain the functions needed for ARM. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] RE :Re: ARM code generator / ARM tiny C compiler
On Thu, Apr 25, 2013 at 04:05:24PM +0200, Christian JULLIEN wrote: Wouah! Do you mean you're implementing eabi_ functions for ARM (such as div and mod ?) Total respect!! I once had an incomplete libtcc1 on my homepage, where I used a division function from GMP. It could not be compiled with TinyCC because of the missing ARM assembler. At one point I stopped trying to reinvent the wheel and started to point everyone to libgcc. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] ARM code generator / ARM tiny C compiler
On Wed, Apr 24, 2013 at 06:00:17PM +0200, ggasnie...@free.fr wrote: Are there people working on the feature ? For this long-term feature, what are the main aspects of TCC to understand before going forward ? What do you miss in the current TCC ARM code generator? Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] ARM code generator / ARM tiny C compiler
On Wed, Apr 24, 2013 at 10:15:29PM +0200, ggasnie...@free.fr wrote: So where could I find the supported ARM architecture The generated code should be compatible with ARMv4. Floating point hardware or emulator (either FPA or VFP) is a must. and what is the roadmap for it ? There is no central roadmap. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Compiling preprocessed files with tinycc?
On Wed, Mar 20, 2013 at 01:01:10PM -0700, Austin English wrote:
manually correcting that, I'm able to preprocess the problematic file down to:
austin@debian-home:~/src/wine-tcc/dlls/d3d8/tests$ cat stateblock.i.tcc.c
typedef struct _D3DVECTOR
{
float x;
float y;
float z;
} D3DMATRIX;
You are aware that D3DMATRIX is supposed to consist of 16 floats?
Daniel
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] TCC and external variables - am I not seeing something?
On Sun, Mar 10, 2013 at 12:31:11AM +0100, Aleksandar Kuktin wrote:
The compiler I normally use is GCC, which has no problems about linking
these files.
Unless you compile with -fno-common
Header files have this:
/*extern*/ nbworks_do_align_t nbworks_do_align;
It is bad practice to have variable definitions in a header.
Add the extern to make it a declaration. Then add the definition
to a single source file in your project.
Source files have this:
struct thread_cache *
daemon_internal_initializer(struct thread_cache *tcache) {
extern nbworks_do_align_t nbworks_do_align;
Why declare the variable inside the function if you have a header
with a definition/declaration?
Daniel
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] how to get Unix style line endings for output (just \n not \r\n) --- works when writing to a file, not when redirecting stdout on command line
On Tue, Mar 05, 2013 at 11:05:59AM -0800, John Refling wrote: Just curious though, where would developers go to find information specific to tinycc like this? I'd like to learn more of the tinycc details. Is there a list of all the tinycc extensions somewhere? The truth is that your problem had nothing to do with tinycc. It is specific to the C library, which is part of Windows. And it seems that the setmode() on Unix has a different syntax and slightly different purpose, so I didn't pursue that one initially. Never heard of setmode on Unix and there is no manpage with that name. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Another ARM (RPi) compiler bug
Hi, On Mon, Feb 04, 2013 at 07:46:08AM +0100, Christian Jullien wrote: I'm still looking in ISO standard if there is a note on this conversion. Anyway, tcc behaves differently from gcc (and *all* other compiler I know where is conversion truncates) while tcc rounds it's specified in 6.3.1.4(1) in the N1124 draft. Try again with current mob. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] RE :Re: Another ARM (RPi) compiler bug
Hi, On Mon, Feb 04, 2013 at 09:51:04AM +0100, Christian JULLIEN wrote: Now my complete OpenLisp shows only ONE bug related to utf8 conversion (probably signed/unsigned char/int issue). keep in mind that on ARM plain char is unsigned. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] RE :Re: RE :Re: Another ARM (RPi) compiler bug
Hi, On Mon, Feb 04, 2013 at 01:47:46PM +0100, Christian JULLIEN wrote: your mail client produced a multipart/alternative with an empty text/plain part. The error is in gfunc_prolog when it does pn = (pn + (align-1)/4) -(align/4); while align is 4. Thomas, is the correct fix to clamp align to 4 if it is less than that? Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] ARM (RPi) compiler bug
Hi, should be fixed in mob now, please test. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Another ARM (RPi) compiler bug
On Sun, Feb 03, 2013 at 10:14:16PM +0100, Christian Jullien wrote: Wrong double - int conversion when double is 0 Should be fixed as well now. Same type of error. Must have had a bad day. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [PATCH] arm: Handle __builtin_frame_address(1) correctly
On Thu, Nov 29, 2012 at 09:43:33PM +0400, Kirill Smelkov wrote:
tcc first saves r0 r1, and only then fp:
$ ./arm-eabi-tcc -c y.c
$ arm-linux-gnueabi-objdump -d y.o
f:
0: e1a0c00dmov ip, sp
4: e92d0003push{r0, r1}
8: e92d5800push{fp, ip, lr}
c: e28db00cadd fp, sp, #12
10: e1a0nop ; (mov r0, r0)
14: e91ba800ldmdb fp, {fp, sp, pc}
I chose this stack frame format because it simplifies access to the
arguments from within tinycc. At that time I didn't think of trying to
be compatible to anything just to allow stack traces.
gcc does not, but it will save r5,r6,etc. before fp(=r13 iirc) ...
$ arm-linux-gnueabihf-gcc-4.7 -marm -c y.c
$ arm-linux-gnueabihf-objdump -d y.o
f:
0: e52db004push{fp}; (str fp, [sp, #-4]!)
4: e28db000add fp, sp, #0
8: e24dd00csub sp, sp, #12
c: e50b0008str r0, [fp, #-8]
10: e50b100cstr r1, [fp, #-12]
14: e28bd000add sp, fp, #0
18: e8bd0800pop {fp}
1c: e12fff1ebx lr
You should not look at a leaf function to derive the GCC stack frame.
It is probably different from the generic stack frame because GCC
knows this function will never be part of a stack trace done by
another function of the final program.
Take a look at arch/arm/kernel/stacktrace.c inside the Linux kernel.
They assume that every function pushes {fp, sp, lr, pc} and that
fp points to the address where pc is stored. I don't know why
GCC pushes pc. I can only imagine this being done to keep the
stack aligned to 8 bytes. Or maybe it is for exception handling
or association of stack frame debug info..
8: e92d0870push{r4, r5, r6, fp}; NOTE r4... go
before fp
14: e28db00cadd fp, sp, #12
5c: e59bldr r0, [fp]; BUG here!
Why is this a bug in GCC? It will load the old value of fp to r0.
... as probably required by arm calling convention (not looked at the spec
yet, but it seems reasanoble, given how push is really a block str and
that str stores register in ascending order).
I have once seen a page in MSDN describing the ARM stack frame of
Windows CE. I don't know if ARM specified how stack frames should look
like.
Best regards,
Daniel
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [ RFC] About packing two infos in a long v2
On Wed, Nov 07, 2012 at 04:18:00PM +0100, Thomas Preud'homme wrote: Le mercredi 7 novembre 2012 16:09:51, Milutin Jovanović a écrit : Other then that, looks OK to me. BTW, I did not check correctness, just reviewed the style and logic. Don't worry for the correctness. GOT needs to be aligned on 4 bytes on ARM so I know it's fine. I tested the code successfully on ARM and it yields the correct result on my tests. Can we assume GOT entries are aligned to 2 bytes on all architectures? Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] TCC and smart linking
Hi, On Thu, Oct 11, 2012 at 01:14:57PM +0300, Oleg N. Cher wrote: Do you know Total Commander by /Christian Ghisler? /It is very powerful and widely functional product which is able to many possibilities. Its author is not specifically to save the code size, but the size of distribution is about 2 megabytes. I believe, if it was from Microsoft, it would have occupied 300-500 Mb. just look at the size of the Sysinternals tools when Sysinternals was bought by Microsoft. Their tools grew by several hundred percent mainly because Microsoft thought it would be wise to display an EULA on first use and to add this EULA in uncompressed form to the binary. Milutin Jovanović wrote: I cannot imagine that marking symbols as referenced to be expensive... If it was as simple as not outputting into target executable symbols that are not marked as used, this would be a truly simple task. And fast, while we're on it. However, the problem arises when linking with libraries, which is already compiled code. When including a symbol from a library, a mechanism needs to be created to determine which symbols this routine references, and then recursively repeat the process. I think what Oleg wants is implemented in GCC as -ffunction-sections -fdata-section in combination with ld's --gc-sections. Every global function and variable is placed in its own section and the linker drops all sections which can't be reached starting from the entry point. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] question about bit-fields
On Mon, Oct 22, 2012 at 09:38:22PM +0200, Didier Barvaux wrote: Please send your patch, it may be better than mine. Or maybe we can create a third patch from ours and mine. By the way, ARM describes how to bit-fields should be laid out in http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042d/IHI0042D_aapcs.pdf sections 4.3.4 and 7.1.7. So for EABI compliance, this needs to be fixed. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Bug: malloc + function returning double + comparison between doubles
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 if alloca really isn't supported on arm, which I can't believe. If that really is the case callsave_test() needs to be conditional too. Some time ago I posted an alloca version for ARM: http://lists.nongnu.org/archive/html/tinycc-devel/2011-02/msg00046.html but we don't build a libtcc1 for ARM and libgcc/libc don't provide alloca as it is a GCC builtin. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Bug: malloc + function returning double + comparison between doubles
On Sun, Jun 10, 2012 at 08:03:24PM +0200, Thomas Preud'homme wrote: Le dimanche 10 juin 2012 20:01:11, Michael Matz a écrit : but we don't build a libtcc1 for ARM ... I think we should do so then. As it seems the various arithmetic routines of libtcc1.c aren't needed on arm it would only contain alloca. I'd vote for the assembler implementation (don't know if it would have to differ between the eabi and oldabi variants). It doesn't use VFP so it will work for both ABI. It also work for the new eabihf which I introduced as there is no float parameter. 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 hardware/emulator, where we could use the EABI soft float functions already contained in libgcc. I also added a configure option --with-libgcc to make TinyCC automatically link to libgcc_s.so.1 instead of libtcc1.a. If we now start to supply a libtcc1.a that does not include the functions from libgcc_s.so.1, we need to link to two libraries. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
