Re: [Tinycc-devel] Error with today's patches

[Kyryl Melekhin]

Hey Christian Jullien, the patch is only a temporary workaround to get
correct code gen working. Right I have to confront the C standard
to understand if calling __fixunsxfdi on long double to uin64_t
is actually correct. And if we need to fix the code generator to emit
__fixxfdi in this case instead. It looks like tcc always emits __fixunsxfdi
even on non constants. Gcc and Clang always end up keeping the
floats sign, ie on x86_64 cvttss2si instruction is used, which is basically
what __fixxfdi does as well.

What do you think? Should we just make tcc always call __fixxfdi
on every unsigned conversion?

I don't really know how to write tests for this yet, besides I think
there is no need yet. Because the bug is not solved correctly yet.

чт, 10 сент. 2020 г. в 03:58, Christian Jullien <eligis@orange.fr>:
>
> I know how Herman works and I was sure its patch was Ok (and it is) . The 
> patch made by wanjochan was the culprit. I just reverted his patch until 
> better tested.
>
> On its side, Kyryl patch “looks” Ok. At least it does not break the test 
> suite.
>
> Kyryl can you add the test case in tcc suite so that we can verify your patch 
> works on all supported platforms.
>
>
>
> Christian
>
>
>
> From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange.fr@nongnu.org] 
> On Behalf Of ian
> Sent: Wednesday, September 09, 2020 23:57
> To: tinycc-devel@nongnu.org
> Subject: Re: [Tinycc-devel] Error with today's patches
>
>
>
> Hi back to all.
>
> I read carefully all of the mailing-list, but I hava add a quick comment, 
> right now.
>
> The main aim of a CVS is to able people to test patches, and concurrent 
> versions.
>
> The target should be to create a fork, and, tests achieved, to merge them to 
> the mob.
>
> Every one HAVE to test their modifications upon EVERY structures (OSes, 
> procs, byte lengthS, and so on) before submitting them, or to leave them in 
> the fork branch before merging....
>
> It's a shame that everybody could come and propose modifications, even push 
> them on mob, without a complete review....
>
> Really, I do believe that Christian, while working on his own language, is 
> right in many ways.... You should read him with attention.
>
>
>
> Take care all,  and sorry for this.
>
> ian
>
>
>
> Le 09/09/2020 à 11:44, Christian Jullien a écrit :
>
> macOS:
>
>
>
> …
>
> compiling tcc.c 10 times
>
> (827 ms)
>
> ------------ test3 ------------
>
> tcc: error: undefined symbol '___va_arg'
>
> tcc: error: undefined symbol '_alloca'
>
> make[2]: *** [test3] Error 255
>
> ------------ memtest ------------
>
>
>
> RPi:
>
> running fib in threads
>
>   1 8 144 5 10946 21 6765 89 55 34 3 377 610 233 987 2 13 4181 2584 1597
>
> (35 ms)
>
> running tcc.c in threads to run fib
>
> tcc: error: undefined symbol '__aeabi_idivmod'
>
> tcc: error: undefined symbol '__aeabi_idivmod'
>
> tcc: error: undefined symbol '__aeabi_idiv'
>
> tcc: error: undefined symbol '__aeabi_uldivmod'
>
> tcc: error: undefined symbol '__aeabi_llsl'
>
> tcc: error: undefined symbol '__aeabi_llsr'
>
> tcc: error: undefined symbol '__aeabi_ul2d'
>
> tcc: error: undefined symbol '__aeabi_d2lz'
>
> tcc: error: undefined symbol '__aeabi_uidivmod'
>
> tcc: error: undefined symbol '__clear_cache'
>
> tcc: error: undefined symbol '__aeabi_uidiv'
>
> tcc: error: undefined symbol '__aeabi_idivmod'
>
> tcc: error: undefined symbol '__aeabi_idiv'
>
> tcc: error: undefined symbol '__aeabi_uldivmod'
>
> tcc: error: undefined symbol '__aeabi_llsl'
>
> tcc: error: undefined symbol '__aeabi_llsr'
>
> tcc: error: undefined symbol '__aeabi_ul2d'
>
> …
>
>
>
>
>
> _______________________________________________
>
> Tinycc-devel mailing list
>
> Tinycc-devel@nongnu.org
>
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
> --
> -- sibian0218@gmail.com
> -- Développeur compulsif
>
> _______________________________________________
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel