Re: [Tinycc-devel] function pointer problem on x86_64/macos/riscv
Thanks for analyzing this so quickly.
This only happened for one testcase in the gmp testsuite.
It is also easy to fix.
So not so important.
Herman
On 2020-07-16 17:54, Michael Matz wrote:
Hello,
On Thu, 16 Jul 2020, Herman ten Brugge via Tinycc-devel wrote:
While testing gmp on the x86_64 target I discovered a fuction pointer
bug.
(reuse in directory tests/mpf)
The code:
#include
typedef int (*func) (int);
func allfunc[] = { putchar };
int main(void) {
printf ("%d\n", allfunc[0] == putchar);
return 0;
}
prints 0 on x86_64, macos and riscv (all other targets (i386, arm,
arm64, win32, win64) print 1).
There seems to be something wrong with relocation.
The allfunc[0] points to the got table. The putchar to the externel
symbol.
Yeah, known problem. Function pointer value comparisons involving
functions in other shared objects are surprisingly complicated when
shared objects and lazy linking (and hence PLT slots) are involved.
It took many years to fix most (or all?) corners cases even in
binutils and gcc, and some even can't be fixed when weak or protected
symbols are involved.
In this particular case the reason is that TCCs linker doesn't
currently emit outstanding relocations for executables except for the
GOT, so the reference to putchar in the data section (in allfunc) has
to be statically resolved to something local, and that's the PLT slot.
Note that this only affects the value of the function pointer itself,
not the semantics (i.e. you can call through allfunc[0] just fine), so
it's relatively seldomly a real problem. Does this affect anything
else than a synthetic test case in gmp?
Ciao,
Michael.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] compare problem on riscv target
Hello,
On Thu, 16 Jul 2020, Herman ten Brugge via Tinycc-devel wrote:
While testing gmp on the riscv target I discovered a compare bug.
(t-get_d test fails in directory tests/mpq)
The code:
#include
int tst(void) {
long value = 3;
return -value;
}
int main(void) {
printf ("%d\n", tst());
if (tst() > 0) printf ("error\n");
return 0;
}
prints "error" on the riscv target. The problem is that the value returned is
converted from long to int in gen_cast and is returned as 0xfffd from
tst().
On riscv registers should always contain the sign-extended value of
shorter values, so this here is the bug, and ...
The compare in the main code fails because it does a long compare
instead
... this is the okay because of the above invariant.
TCCs other architectures expect either zero extension or don't care or
natural extension about narrow values in large registers, so riscv was
somewhat novel in that respect; obviously I didn't catch all corner cases
yet, so thanks for the report.
Ciao,
Michael.___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] function pointer problem on x86_64/macos/riscv
Hello,
On Thu, 16 Jul 2020, Herman ten Brugge via Tinycc-devel wrote:
While testing gmp on the x86_64 target I discovered a fuction pointer bug.
(reuse in directory tests/mpf)
The code:
#include
typedef int (*func) (int);
func allfunc[] = { putchar };
int main(void) {
printf ("%d\n", allfunc[0] == putchar);
return 0;
}
prints 0 on x86_64, macos and riscv (all other targets (i386, arm, arm64,
win32, win64) print 1).
There seems to be something wrong with relocation.
The allfunc[0] points to the got table. The putchar to the externel symbol.
Yeah, known problem. Function pointer value comparisons involving
functions in other shared objects are surprisingly complicated when shared
objects and lazy linking (and hence PLT slots) are involved. It took many
years to fix most (or all?) corners cases even in binutils and gcc, and
some even can't be fixed when weak or protected symbols are involved.
In this particular case the reason is that TCCs linker doesn't currently
emit outstanding relocations for executables except for the GOT, so the
reference to putchar in the data section (in allfunc) has to be statically
resolved to something local, and that's the PLT slot.
Note that this only affects the value of the function pointer itself, not
the semantics (i.e. you can call through allfunc[0] just fine), so it's
relatively seldomly a real problem. Does this affect anything else than a
synthetic test case in gmp?
Ciao,
Michael.___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] function pointer problem on x86_64/macos/riscv
While testing gmp on the x86_64 target I discovered a fuction pointer bug.
(reuse in directory tests/mpf)
The code:
#include
typedef int (*func) (int);
func allfunc[] = { putchar };
int main(void) {
printf ("%d\n", allfunc[0] == putchar);
return 0;
}
prints 0 on x86_64, macos and riscv (all other targets (i386, arm,
arm64, win32, win64) print 1).
There seems to be something wrong with relocation.
The allfunc[0] points to the got table. The putchar to the externel symbol.
Herman
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] compare problem on riscv target
While testing gmp on the riscv target I discovered a compare bug.
(t-get_d test fails in directory tests/mpq)
The code:
#include
int tst(void) {
long value = 3;
return -value;
}
int main(void) {
printf ("%d\n", tst());
if (tst() > 0) printf ("error\n");
return 0;
}
prints "error" on the riscv target. The problem is that the value
returned is
converted from long to int in gen_cast and is returned as 0xfffd
from tst().
The compare in the main code fails because it does a long compare
instead of an int compare.
Herman
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] aarch64: subnormal double to long double conversion bug
I tested latest patches on Rpi Fedora 32 (aarch64) and I confirm it now pass all mpfr tests on this platform.Many thanks. C. Le :16 juillet 2020 à 02:13 (GMT +02:00) De :"Vincent Lefevre" vinc...@vinc17.net À :"tinycc-devel@nongnu.org" tinycc-devel@nongnu.org Objet :Re: [Tinycc-devel] aarch64: subnormal double to long double conversion bug On 2020-07-15 23:15:59 +0200, Michael Matz wrote: Hello, On Wed, 15 Jul 2020, Vincent Lefevre wrote: With TCC mob on aarch64, the double to long double conversion is buggy on subnormal values. This makes a MPFR test fail (reported by Christian Jullien). Thanks for the report, it was indeed unhandled in the support routines. I fixed this in mob for riscv64, but the routines are shared with aarch64 so it's likely also fixed there, please check. Thanks. Everything is fine now. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/; 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/; Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
