tools/include/nolibc/Makefile | 4 +- tools/include/nolibc/std.h | 15 +- tools/include/nolibc/stdint.h | 84 +++++++++++ tools/testing/selftests/nolibc/nolibc-test.c | 139 ++++++++++++------- 4 files changed, 177 insertions(+), 65 deletions(-) create mode 100644 tools/include/nolibc/stdint.h
Hi, This is version 4 of my patch to add stdint.h to nolibc. Previous versions of this patch are available here: * v3: https://lore.kernel.org/all/20230206013248.471664-1-v@vda.io/ * v2: https://lore.kernel.org/all/20230202201101.43160-1-v@vda.io/ * v1: https://lore.kernel.org/all/20230202160236.25342-1-v@vda.io/ I tested it successfully on x86_64, as well as i386 and arm on qemu. Thank you Willy for the review and the guidance! Vincent. Vincent Dagonneau (4): tools/nolibc: Adding stdint.h tools/nolibc: Adding integer types and integer limit macros tools/nolibc: Enlarging column width of tests tools/nolibc: Adds tests for the integer limits in stdint.h tools/include/nolibc/Makefile | 4 +- tools/include/nolibc/std.h | 15 +- tools/include/nolibc/stdint.h | 84 +++++++++++ tools/testing/selftests/nolibc/nolibc-test.c | 139 ++++++++++++------- 4 files changed, 177 insertions(+), 65 deletions(-) create mode 100644 tools/include/nolibc/stdint.h -- 2.39.1
On Wed, Feb 08, 2023 at 09:40:40PM -0500, Vincent Dagonneau wrote:
> Hi,
>
> This is version 4 of my patch to add stdint.h to nolibc. Previous
> versions of this patch are available here:
>
> * v3: https://lore.kernel.org/all/20230206013248.471664-1-v@vda.io/
> * v2: https://lore.kernel.org/all/20230202201101.43160-1-v@vda.io/
> * v1: https://lore.kernel.org/all/20230202160236.25342-1-v@vda.io/
>
> I tested it successfully on x86_64, as well as i386 and arm on qemu.
>
> Thank you Willy for the review and the guidance!
> Vincent.
Thanks Vincent. At first glance it looks good. I'll give it a try on
all supported archs to make sure we didn't overlook anything and we'll
merge it. One tiny comment though, look below:
> Vincent Dagonneau (4):
> tools/nolibc: Adding stdint.h
> tools/nolibc: Adding integer types and integer limit macros
> tools/nolibc: Enlarging column width of tests
> tools/nolibc: Adds tests for the integer limits in stdint.h
I mentioned in the first review that it's generally preferred to use
the imperative form rather than present participle on subject lines.
This would give:
tools/nolibc: Add stdint.h
tools/nolibc: Add integer types and integer limit macros
tools/nolibc: Enlarge column width of tests
tools/nolibc: Add tests for the integer limits in stdint.h
I can perform this trivial change locally before merging without asking
you to respin a series just for this if that's OK for you. Just let me
know.
Thanks!
Willy
On Wed, Feb 8, 2023, at 22:43, Willy Tarreau wrote: > On Wed, Feb 08, 2023 at 09:40:40PM -0500, Vincent Dagonneau wrote: >> Hi, >> >> This is version 4 of my patch to add stdint.h to nolibc. Previous >> versions of this patch are available here: >> >> * v3: https://lore.kernel.org/all/20230206013248.471664-1-v@vda.io/ >> * v2: https://lore.kernel.org/all/20230202201101.43160-1-v@vda.io/ >> * v1: https://lore.kernel.org/all/20230202160236.25342-1-v@vda.io/ >> >> I tested it successfully on x86_64, as well as i386 and arm on qemu. >> >> Thank you Willy for the review and the guidance! >> Vincent. > > Thanks Vincent. At first glance it looks good. I'll give it a try on > all supported archs to make sure we didn't overlook anything and we'll > merge it. One tiny comment though, look below: > >> Vincent Dagonneau (4): >> tools/nolibc: Adding stdint.h >> tools/nolibc: Adding integer types and integer limit macros >> tools/nolibc: Enlarging column width of tests >> tools/nolibc: Adds tests for the integer limits in stdint.h > > I mentioned in the first review that it's generally preferred to use > the imperative form rather than present participle on subject lines. > This would give: > > tools/nolibc: Add stdint.h > tools/nolibc: Add integer types and integer limit macros > tools/nolibc: Enlarge column width of tests > tools/nolibc: Add tests for the integer limits in stdint.h > > I can perform this trivial change locally before merging without asking > you to respin a series just for this if that's OK for you. Just let me > know. > > Thanks! > Willy Yep, go ahead! Thank you again for the guidance, Vincent.
Hi Vincent,
On Fri, Feb 10, 2023 at 08:03:02AM -0500, Vincent Dagonneau wrote:
> > Thanks Vincent. At first glance it looks good. I'll give it a try on
> > all supported archs to make sure we didn't overlook anything and we'll
> > merge it. One tiny comment though, look below:
> >
> >> Vincent Dagonneau (4):
> >> tools/nolibc: Adding stdint.h
> >> tools/nolibc: Adding integer types and integer limit macros
> >> tools/nolibc: Enlarging column width of tests
> >> tools/nolibc: Adds tests for the integer limits in stdint.h
> >
> > I mentioned in the first review that it's generally preferred to use
> > the imperative form rather than present participle on subject lines.
> > This would give:
> >
> > tools/nolibc: Add stdint.h
> > tools/nolibc: Add integer types and integer limit macros
> > tools/nolibc: Enlarge column width of tests
> > tools/nolibc: Add tests for the integer limits in stdint.h
> >
> > I can perform this trivial change locally before merging without asking
> > you to respin a series just for this if that's OK for you. Just let me
> > know.
> >
> > Thanks!
> > Willy
>
> Yep, go ahead!
Done, however I'm seeing the following failures on aarch64/riscv64/s390x:
$ grep -B 200 limit.*FAIL stdint.out | grep '\(limit.*FAIL\|gcc-11.3.0-nolibc.*-O0\)'
/f/tc/nolibc/gcc-11.3.0-nolibc/aarch64*/bin/aarch64*-gcc -g -O0 -g -o nolibc-test \
100 limit_intptr_min = -2147483648 [FAIL]
103 limit_ptrdiff_min = -2147483648 [FAIL]
105 limit_ptrdiff_min = -2147483648 [FAIL]
/f/tc/nolibc/gcc-11.3.0-nolibc/riscv64*/bin/riscv64*-gcc -g -O0 -g -o nolibc-test \
100 limit_intptr_min = -2147483648 [FAIL]
103 limit_ptrdiff_min = -2147483648 [FAIL]
105 limit_ptrdiff_min = -2147483648 [FAIL]
/f/tc/nolibc/gcc-11.3.0-nolibc/s390*/bin/s390*-gcc -g -march=z10 -m64 -O0 -g -o nolibc-test \
100 limit_intptr_min = -2147483648 [FAIL]
103 limit_ptrdiff_min = -2147483648 [FAIL]
105 limit_ptrdiff_min = -2147483648 [FAIL]
It makes me think that the __WORDSIZE==64 condition didn't match there,
I'm investigating. However while looking at this I noticed a mistake in
your patch: in the 32-bit part, limit_ptrdiff_{min,max} were repeated,
and no least64_{min,max} tests were placed, so I sense a copy-paste
mistake though I'm uncertain about the initial intent. If you just want
me to drop the duplicate lines I can easily do it, just let me know. I'll
be back with more info once I figure the reason for these archs not using
__WORDSIZE==64.
#if __WORDSIZE == 64
CASE_TEST(limit_int_least64_max); EXPECT_EQ(1, INT_LEAST64_MAX, (int_least64_t) 0x7fffffffffffffffLL); break;
CASE_TEST(limit_int_least64_min); EXPECT_EQ(1, INT_LEAST64_MIN, (int_least64_t) 0x8000000000000000LL); break;
CASE_TEST(limit_uint_least64_max); EXPECT_EQ(1, UINT_LEAST64_MAX, (uint_least64_t) 0xffffffffffffffffULL); break;
CASE_TEST(limit_intptr_min); EXPECT_EQ(1, INTPTR_MIN, (intptr_t) 0x8000000000000000LL); break;
CASE_TEST(limit_intptr_max); EXPECT_EQ(1, INTPTR_MAX, (intptr_t) 0x7fffffffffffffffLL); break;
CASE_TEST(limit_uintptr_max); EXPECT_EQ(1, UINTPTR_MAX, (uintptr_t) 0xffffffffffffffffULL); break;
CASE_TEST(limit_ptrdiff_min); EXPECT_EQ(1, PTRDIFF_MIN, (ptrdiff_t) 0x8000000000000000LL); break;
CASE_TEST(limit_ptrdiff_max); EXPECT_EQ(1, PTRDIFF_MAX, (ptrdiff_t) 0x7fffffffffffffffLL); break;
CASE_TEST(limit_size_max); EXPECT_EQ(1, SIZE_MAX, (size_t) 0xffffffffffffffffULL); break;
#else
CASE_TEST(limit_intptr_min); EXPECT_EQ(1, INTPTR_MIN, (intptr_t) 0x80000000); break;
CASE_TEST(limit_intptr_max); EXPECT_EQ(1, INTPTR_MAX, (intptr_t) 0x7fffffff); break;
CASE_TEST(limit_uintptr_max); EXPECT_EQ(1, UINTPTR_MAX, (uintptr_t) 0xffffffffU); break;
CASE_TEST(limit_ptrdiff_min); EXPECT_EQ(1, PTRDIFF_MIN, (ptrdiff_t) 0x80000000); break;
CASE_TEST(limit_ptrdiff_max); EXPECT_EQ(1, PTRDIFF_MAX, (ptrdiff_t) 0x7fffffff); break;
CASE_TEST(limit_ptrdiff_min); EXPECT_EQ(1, PTRDIFF_MIN, (ptrdiff_t) 0x80000000); break;
CASE_TEST(limit_ptrdiff_max); EXPECT_EQ(1, PTRDIFF_MAX, (ptrdiff_t) 0x7fffffff); break;
CASE_TEST(limit_size_max); EXPECT_EQ(1, SIZE_MAX, (size_t) 0xffffffffU); break;
#endif /* __WORDSIZE == 64 */
Regards,
Willy
Hi again Vincent,
On Sun, Feb 12, 2023 at 11:41:15AM +0100, Willy Tarreau wrote:
> Hi Vincent,
>
> On Fri, Feb 10, 2023 at 08:03:02AM -0500, Vincent Dagonneau wrote:
> > > Thanks Vincent. At first glance it looks good. I'll give it a try on
> > > all supported archs to make sure we didn't overlook anything and we'll
> > > merge it. One tiny comment though, look below:
> > >
> > >> Vincent Dagonneau (4):
> > >> tools/nolibc: Adding stdint.h
> > >> tools/nolibc: Adding integer types and integer limit macros
> > >> tools/nolibc: Enlarging column width of tests
> > >> tools/nolibc: Adds tests for the integer limits in stdint.h
> > >
> > > I mentioned in the first review that it's generally preferred to use
> > > the imperative form rather than present participle on subject lines.
> > > This would give:
> > >
> > > tools/nolibc: Add stdint.h
> > > tools/nolibc: Add integer types and integer limit macros
> > > tools/nolibc: Enlarge column width of tests
> > > tools/nolibc: Add tests for the integer limits in stdint.h
> > >
> > > I can perform this trivial change locally before merging without asking
> > > you to respin a series just for this if that's OK for you. Just let me
> > > know.
> > >
> > > Thanks!
> > > Willy
> >
> > Yep, go ahead!
>
> Done, however I'm seeing the following failures on aarch64/riscv64/s390x:
>
> $ grep -B 200 limit.*FAIL stdint.out | grep '\(limit.*FAIL\|gcc-11.3.0-nolibc.*-O0\)'
> /f/tc/nolibc/gcc-11.3.0-nolibc/aarch64*/bin/aarch64*-gcc -g -O0 -g -o nolibc-test \
> 100 limit_intptr_min = -2147483648 [FAIL]
> 103 limit_ptrdiff_min = -2147483648 [FAIL]
> 105 limit_ptrdiff_min = -2147483648 [FAIL]
> /f/tc/nolibc/gcc-11.3.0-nolibc/riscv64*/bin/riscv64*-gcc -g -O0 -g -o nolibc-test \
> 100 limit_intptr_min = -2147483648 [FAIL]
> 103 limit_ptrdiff_min = -2147483648 [FAIL]
> 105 limit_ptrdiff_min = -2147483648 [FAIL]
> /f/tc/nolibc/gcc-11.3.0-nolibc/s390*/bin/s390*-gcc -g -march=z10 -m64 -O0 -g -o nolibc-test \
> 100 limit_intptr_min = -2147483648 [FAIL]
> 103 limit_ptrdiff_min = -2147483648 [FAIL]
> 105 limit_ptrdiff_min = -2147483648 [FAIL]
>
> It makes me think that the __WORDSIZE==64 condition didn't match there,
> I'm investigating. However while looking at this I noticed a mistake in
> your patch: in the 32-bit part, limit_ptrdiff_{min,max} were repeated,
> and no least64_{min,max} tests were placed, so I sense a copy-paste
> mistake though I'm uncertain about the initial intent. If you just want
> me to drop the duplicate lines I can easily do it, just let me know. I'll
> be back with more info once I figure the reason for these archs not using
> __WORDSIZE==64.
>
> #if __WORDSIZE == 64
> CASE_TEST(limit_int_least64_max); EXPECT_EQ(1, INT_LEAST64_MAX, (int_least64_t) 0x7fffffffffffffffLL); break;
> CASE_TEST(limit_int_least64_min); EXPECT_EQ(1, INT_LEAST64_MIN, (int_least64_t) 0x8000000000000000LL); break;
> CASE_TEST(limit_uint_least64_max); EXPECT_EQ(1, UINT_LEAST64_MAX, (uint_least64_t) 0xffffffffffffffffULL); break;
> CASE_TEST(limit_intptr_min); EXPECT_EQ(1, INTPTR_MIN, (intptr_t) 0x8000000000000000LL); break;
> CASE_TEST(limit_intptr_max); EXPECT_EQ(1, INTPTR_MAX, (intptr_t) 0x7fffffffffffffffLL); break;
> CASE_TEST(limit_uintptr_max); EXPECT_EQ(1, UINTPTR_MAX, (uintptr_t) 0xffffffffffffffffULL); break;
> CASE_TEST(limit_ptrdiff_min); EXPECT_EQ(1, PTRDIFF_MIN, (ptrdiff_t) 0x8000000000000000LL); break;
> CASE_TEST(limit_ptrdiff_max); EXPECT_EQ(1, PTRDIFF_MAX, (ptrdiff_t) 0x7fffffffffffffffLL); break;
> CASE_TEST(limit_size_max); EXPECT_EQ(1, SIZE_MAX, (size_t) 0xffffffffffffffffULL); break;
> #else
> CASE_TEST(limit_intptr_min); EXPECT_EQ(1, INTPTR_MIN, (intptr_t) 0x80000000); break;
> CASE_TEST(limit_intptr_max); EXPECT_EQ(1, INTPTR_MAX, (intptr_t) 0x7fffffff); break;
> CASE_TEST(limit_uintptr_max); EXPECT_EQ(1, UINTPTR_MAX, (uintptr_t) 0xffffffffU); break;
> CASE_TEST(limit_ptrdiff_min); EXPECT_EQ(1, PTRDIFF_MIN, (ptrdiff_t) 0x80000000); break;
> CASE_TEST(limit_ptrdiff_max); EXPECT_EQ(1, PTRDIFF_MAX, (ptrdiff_t) 0x7fffffff); break;
> CASE_TEST(limit_ptrdiff_min); EXPECT_EQ(1, PTRDIFF_MIN, (ptrdiff_t) 0x80000000); break;
> CASE_TEST(limit_ptrdiff_max); EXPECT_EQ(1, PTRDIFF_MAX, (ptrdiff_t) 0x7fffffff); break;
> CASE_TEST(limit_size_max); EXPECT_EQ(1, SIZE_MAX, (size_t) 0xffffffffU); break;
> #endif /* __WORDSIZE == 64 */
So after investigation, __WORDSIZE is not defined, hence the failures!
It proves the importance of the tests you've added ;-)
However we have the size of these types defined by the compiler itself
at least since gcc-4.4 and clang-3.8 which are the oldest I could test:
$ mips-gcc44_glibc214-linux-gnu-gcc -xc -dM -E - </dev/null |grep SIZE
#define __SIZEOF_POINTER__ 4
#define __SIZEOF_LONG__ 4
#define __SIZEOF_LONG_DOUBLE__ 8
#define __SIZEOF_SIZE_T__ 4
#define __SIZEOF_WINT_T__ 4
#define __SIZE_TYPE__ unsigned int
#define __SIZEOF_PTRDIFF_T__ 4
#define __SIZEOF_INT__ 4
#define __SIZEOF_FLOAT__ 4
#define __SIZEOF_SHORT__ 2
#define __SIZEOF_WCHAR_T__ 4
#define __SIZEOF_DOUBLE__ 8
#define __SIZEOF_LONG_LONG__ 8
In addition both provide __SIZE_TYPE__ which is defined either as
unsigned int or long unsigned int, so that can simplify quite some
parts (and other types are defined for other types in more recent
versions). Both also define __LONG_MAX__ that you could possibly
use to conveniently create INTPTR_MAX, INTPTR_MIN, UINTPTR_MAX and
so on.
And finally we should set the __WORDSIZE ourselves as 8*__SIZEOF_LONG__
and that would do the job.
I tested the following patch which passes all the tests successfully
on all supported archs. Let me know if you agree with such a change
and how you want us to proceed. It would require a small change in the
commit message though, to explain that our pointers are the size of a
long on supported platforms.
Regards,
Willy
---
diff --git a/tools/include/nolibc/stdint.h b/tools/include/nolibc/stdint.h
index 6a7683de09ec..7da0d35c481c 100644
--- a/tools/include/nolibc/stdint.h
+++ b/tools/include/nolibc/stdint.h
@@ -65,20 +65,12 @@ typedef uint64_t uintmax_t;
#define UINT_LEAST32_MAX UINT32_MAX
#define UINT_LEAST64_MAX UINT64_MAX
-#if __WORDSIZE == 64
- #define SIZE_MAX UINT64_MAX
- #define INTPTR_MIN INT64_MIN
- #define INTPTR_MAX INT64_MAX
- #define UINTPTR_MAX UINT64_MAX
- #define PTRDIFF_MIN INT64_MIN
- #define PTRDIFF_MAX INT64_MAX
-#else
- #define SIZE_MAX UINT32_MAX
- #define INTPTR_MIN INT32_MIN
- #define INTPTR_MAX INT32_MAX
- #define UINTPTR_MAX UINT32_MAX
- #define PTRDIFF_MIN INT32_MIN
- #define PTRDIFF_MAX INT32_MAX
-#endif /* __WORDSIZE == 64 */
+#define SIZE_MAX ((__SIZE_TYPE__)(__LONG_MAX__) * 2 + 1)
+#define INTPTR_MIN (-__LONG_MAX__ - 1)
+#define INTPTR_MAX __LONG_MAX__
+#define UINTPTR_MAX (SIZE_MAX)
+#define PTRDIFF_MIN INTPTR_MIN
+#define PTRDIFF_MAX INTPTR_MAX
+#define __WORDSIZE (__SIZEOF_LONG__ * 8)
#endif /* _NOLIBC_STDINT_H */
On Sun, Feb 12, 2023, at 13:27, Willy Tarreau wrote:
> Hi again Vincent,
>
> On Sun, Feb 12, 2023 at 11:41:15AM +0100, Willy Tarreau wrote:
>> Hi Vincent,
>>
>> On Fri, Feb 10, 2023 at 08:03:02AM -0500, Vincent Dagonneau wrote:
>> > > Thanks Vincent. At first glance it looks good. I'll give it a try on
>> > > all supported archs to make sure we didn't overlook anything and we'll
>> > > merge it. One tiny comment though, look below:
>> > >
>> > >> Vincent Dagonneau (4):
>> > >> tools/nolibc: Adding stdint.h
>> > >> tools/nolibc: Adding integer types and integer limit macros
>> > >> tools/nolibc: Enlarging column width of tests
>> > >> tools/nolibc: Adds tests for the integer limits in stdint.h
>> > >
>> > > I mentioned in the first review that it's generally preferred to use
>> > > the imperative form rather than present participle on subject lines.
>> > > This would give:
>> > >
>> > > tools/nolibc: Add stdint.h
>> > > tools/nolibc: Add integer types and integer limit macros
>> > > tools/nolibc: Enlarge column width of tests
>> > > tools/nolibc: Add tests for the integer limits in stdint.h
>> > >
>> > > I can perform this trivial change locally before merging without asking
>> > > you to respin a series just for this if that's OK for you. Just let me
>> > > know.
>> > >
>> > > Thanks!
>> > > Willy
>> >
>> > Yep, go ahead!
>>
>> Done, however I'm seeing the following failures on aarch64/riscv64/s390x:
>>
>> $ grep -B 200 limit.*FAIL stdint.out | grep '\(limit.*FAIL\|gcc-11.3.0-nolibc.*-O0\)'
>> /f/tc/nolibc/gcc-11.3.0-nolibc/aarch64*/bin/aarch64*-gcc -g -O0 -g -o nolibc-test \
>> 100 limit_intptr_min = -2147483648 [FAIL]
>> 103 limit_ptrdiff_min = -2147483648 [FAIL]
>> 105 limit_ptrdiff_min = -2147483648 [FAIL]
>> /f/tc/nolibc/gcc-11.3.0-nolibc/riscv64*/bin/riscv64*-gcc -g -O0 -g -o nolibc-test \
>> 100 limit_intptr_min = -2147483648 [FAIL]
>> 103 limit_ptrdiff_min = -2147483648 [FAIL]
>> 105 limit_ptrdiff_min = -2147483648 [FAIL]
>> /f/tc/nolibc/gcc-11.3.0-nolibc/s390*/bin/s390*-gcc -g -march=z10 -m64 -O0 -g -o nolibc-test \
>> 100 limit_intptr_min = -2147483648 [FAIL]
>> 103 limit_ptrdiff_min = -2147483648 [FAIL]
>> 105 limit_ptrdiff_min = -2147483648 [FAIL]
>>
>> It makes me think that the __WORDSIZE==64 condition didn't match there,
>> I'm investigating. However while looking at this I noticed a mistake in
>> your patch: in the 32-bit part, limit_ptrdiff_{min,max} were repeated,
>> and no least64_{min,max} tests were placed, so I sense a copy-paste
>> mistake though I'm uncertain about the initial intent. If you just want
>> me to drop the duplicate lines I can easily do it, just let me know. I'll
>> be back with more info once I figure the reason for these archs not using
>> __WORDSIZE==64.
>>
>> #if __WORDSIZE == 64
>> CASE_TEST(limit_int_least64_max); EXPECT_EQ(1, INT_LEAST64_MAX, (int_least64_t) 0x7fffffffffffffffLL); break;
>> CASE_TEST(limit_int_least64_min); EXPECT_EQ(1, INT_LEAST64_MIN, (int_least64_t) 0x8000000000000000LL); break;
>> CASE_TEST(limit_uint_least64_max); EXPECT_EQ(1, UINT_LEAST64_MAX, (uint_least64_t) 0xffffffffffffffffULL); break;
>> CASE_TEST(limit_intptr_min); EXPECT_EQ(1, INTPTR_MIN, (intptr_t) 0x8000000000000000LL); break;
>> CASE_TEST(limit_intptr_max); EXPECT_EQ(1, INTPTR_MAX, (intptr_t) 0x7fffffffffffffffLL); break;
>> CASE_TEST(limit_uintptr_max); EXPECT_EQ(1, UINTPTR_MAX, (uintptr_t) 0xffffffffffffffffULL); break;
>> CASE_TEST(limit_ptrdiff_min); EXPECT_EQ(1, PTRDIFF_MIN, (ptrdiff_t) 0x8000000000000000LL); break;
>> CASE_TEST(limit_ptrdiff_max); EXPECT_EQ(1, PTRDIFF_MAX, (ptrdiff_t) 0x7fffffffffffffffLL); break;
>> CASE_TEST(limit_size_max); EXPECT_EQ(1, SIZE_MAX, (size_t) 0xffffffffffffffffULL); break;
>> #else
>> CASE_TEST(limit_intptr_min); EXPECT_EQ(1, INTPTR_MIN, (intptr_t) 0x80000000); break;
>> CASE_TEST(limit_intptr_max); EXPECT_EQ(1, INTPTR_MAX, (intptr_t) 0x7fffffff); break;
>> CASE_TEST(limit_uintptr_max); EXPECT_EQ(1, UINTPTR_MAX, (uintptr_t) 0xffffffffU); break;
>> CASE_TEST(limit_ptrdiff_min); EXPECT_EQ(1, PTRDIFF_MIN, (ptrdiff_t) 0x80000000); break;
>> CASE_TEST(limit_ptrdiff_max); EXPECT_EQ(1, PTRDIFF_MAX, (ptrdiff_t) 0x7fffffff); break;
>> CASE_TEST(limit_ptrdiff_min); EXPECT_EQ(1, PTRDIFF_MIN, (ptrdiff_t) 0x80000000); break;
>> CASE_TEST(limit_ptrdiff_max); EXPECT_EQ(1, PTRDIFF_MAX, (ptrdiff_t) 0x7fffffff); break;
>> CASE_TEST(limit_size_max); EXPECT_EQ(1, SIZE_MAX, (size_t) 0xffffffffU); break;
>> #endif /* __WORDSIZE == 64 */
>
> So after investigation, __WORDSIZE is not defined, hence the failures!
> It proves the importance of the tests you've added ;-)
>
> However we have the size of these types defined by the compiler itself
> at least since gcc-4.4 and clang-3.8 which are the oldest I could test:
>
> $ mips-gcc44_glibc214-linux-gnu-gcc -xc -dM -E - </dev/null |grep SIZE
> #define __SIZEOF_POINTER__ 4
> #define __SIZEOF_LONG__ 4
> #define __SIZEOF_LONG_DOUBLE__ 8
> #define __SIZEOF_SIZE_T__ 4
> #define __SIZEOF_WINT_T__ 4
> #define __SIZE_TYPE__ unsigned int
> #define __SIZEOF_PTRDIFF_T__ 4
> #define __SIZEOF_INT__ 4
> #define __SIZEOF_FLOAT__ 4
> #define __SIZEOF_SHORT__ 2
> #define __SIZEOF_WCHAR_T__ 4
> #define __SIZEOF_DOUBLE__ 8
> #define __SIZEOF_LONG_LONG__ 8
>
> In addition both provide __SIZE_TYPE__ which is defined either as
> unsigned int or long unsigned int, so that can simplify quite some
> parts (and other types are defined for other types in more recent
> versions). Both also define __LONG_MAX__ that you could possibly
> use to conveniently create INTPTR_MAX, INTPTR_MIN, UINTPTR_MAX and
> so on.
>
Mmmh, interesting, I hadn't thought about verifying what defined the __WORDSIZE. I assumed wrongly that it was set by standard but it seems not.
I replicated your example on my machine to see the intersection of what is defined by both GCC and clang. Do you know if we would need to check any other compilers?
> And finally we should set the __WORDSIZE ourselves as 8*__SIZEOF_LONG__
> and that would do the job.
>
> I tested the following patch which passes all the tests successfully
> on all supported archs. Let me know if you agree with such a change
> and how you want us to proceed. It would require a small change in the
> commit message though, to explain that our pointers are the size of a
> long on supported platforms.
>
I can integrate the changes and write an explanation as a commit message and submit a new version tomorrow, would that work for you?
> Regards,
> Willy
>
> ---
>
> diff --git a/tools/include/nolibc/stdint.h b/tools/include/nolibc/stdint.h
> index 6a7683de09ec..7da0d35c481c 100644
> --- a/tools/include/nolibc/stdint.h
> +++ b/tools/include/nolibc/stdint.h
> @@ -65,20 +65,12 @@ typedef uint64_t uintmax_t;
> #define UINT_LEAST32_MAX UINT32_MAX
> #define UINT_LEAST64_MAX UINT64_MAX
>
> -#if __WORDSIZE == 64
> - #define SIZE_MAX UINT64_MAX
> - #define INTPTR_MIN INT64_MIN
> - #define INTPTR_MAX INT64_MAX
> - #define UINTPTR_MAX UINT64_MAX
> - #define PTRDIFF_MIN INT64_MIN
> - #define PTRDIFF_MAX INT64_MAX
> -#else
> - #define SIZE_MAX UINT32_MAX
> - #define INTPTR_MIN INT32_MIN
> - #define INTPTR_MAX INT32_MAX
> - #define UINTPTR_MAX UINT32_MAX
> - #define PTRDIFF_MIN INT32_MIN
> - #define PTRDIFF_MAX INT32_MAX
> -#endif /* __WORDSIZE == 64 */
> +#define SIZE_MAX ((__SIZE_TYPE__)(__LONG_MAX__) * 2 + 1)
> +#define INTPTR_MIN (-__LONG_MAX__ - 1)
> +#define INTPTR_MAX __LONG_MAX__
> +#define UINTPTR_MAX (SIZE_MAX)
> +#define PTRDIFF_MIN INTPTR_MIN
> +#define PTRDIFF_MAX INTPTR_MAX
> +#define __WORDSIZE (__SIZEOF_LONG__ * 8)
>
> #endif /* _NOLIBC_STDINT_H */
Hi Vincent, On Wed, Feb 15, 2023 at 07:11:09PM -0500, Vincent Dagonneau wrote: > > So after investigation, __WORDSIZE is not defined, hence the failures! > > It proves the importance of the tests you've added ;-) > > > > However we have the size of these types defined by the compiler itself > > at least since gcc-4.4 and clang-3.8 which are the oldest I could test: > > > > $ mips-gcc44_glibc214-linux-gnu-gcc -xc -dM -E - </dev/null |grep SIZE > > #define __SIZEOF_POINTER__ 4 > > #define __SIZEOF_LONG__ 4 > > #define __SIZEOF_LONG_DOUBLE__ 8 > > #define __SIZEOF_SIZE_T__ 4 > > #define __SIZEOF_WINT_T__ 4 > > #define __SIZE_TYPE__ unsigned int > > #define __SIZEOF_PTRDIFF_T__ 4 > > #define __SIZEOF_INT__ 4 > > #define __SIZEOF_FLOAT__ 4 > > #define __SIZEOF_SHORT__ 2 > > #define __SIZEOF_WCHAR_T__ 4 > > #define __SIZEOF_DOUBLE__ 8 > > #define __SIZEOF_LONG_LONG__ 8 > > > > In addition both provide __SIZE_TYPE__ which is defined either as > > unsigned int or long unsigned int, so that can simplify quite some > > parts (and other types are defined for other types in more recent > > versions). Both also define __LONG_MAX__ that you could possibly > > use to conveniently create INTPTR_MAX, INTPTR_MIN, UINTPTR_MAX and > > so on. > > > > Mmmh, interesting, I hadn't thought about verifying what defined the > __WORDSIZE. I assumed wrongly that it was set by standard but it seems not. No problem, that's exactly why I wanted to retry every combination. > I replicated your example on my machine to see the intersection of what is > defined by both GCC and clang. Do you know if we would need to check any > other compilers? I don't think it's particularly needed to go further for now. For example I know that tcc doesn't support some of the asm constraints that we use in register alllocation. Supporting the most commonly encountered compilers is sufficient for our use case. > > And finally we should set the __WORDSIZE ourselves as 8*__SIZEOF_LONG__ > > and that would do the job. > > > > I tested the following patch which passes all the tests successfully > > on all supported archs. Let me know if you agree with such a change > > and how you want us to proceed. It would require a small change in the > > commit message though, to explain that our pointers are the size of a > > long on supported platforms. > > > > I can integrate the changes and write an explanation as a commit message and > submit a new version tomorrow, would that work for you? Sure that would be great! I'll look at it this week-end anyway. Thank you! Willy
© 2016 - 2025 Red Hat, Inc.