public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: Vincent Dagonneau <v@vda.io>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 0/4] tools/nolibc: Adding stdint.h, more integer types and tests
Date: Thu, 16 Feb 2023 04:29:47 +0100	[thread overview]
Message-ID: <Y+2jK3yyLx+0cPr9@1wt.eu> (raw)
In-Reply-To: <d89977ec-d8a8-4ffe-8e3e-a77885ff5f96@app.fastmail.com>

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

  reply	other threads:[~2023-02-16  3:29 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-09  2:40 [PATCH v4 0/4] tools/nolibc: Adding stdint.h, more integer types and tests Vincent Dagonneau
2023-02-09  2:40 ` [PATCH v4 1/4] tools/nolibc: Adding stdint.h Vincent Dagonneau
2023-02-09  2:40 ` [PATCH v4 2/4] tools/nolibc: Adding integer types and integer limit macros Vincent Dagonneau
2023-02-09  2:40 ` [PATCH v4 3/4] tools/nolibc: Enlarging column width of tests Vincent Dagonneau
2023-02-09  2:40 ` [PATCH v4 4/4] tools/nolibc: Adds tests for the integer limits in stdint.h Vincent Dagonneau
2023-02-09  3:43 ` [PATCH v4 0/4] tools/nolibc: Adding stdint.h, more integer types and tests Willy Tarreau
2023-02-10 13:03   ` Vincent Dagonneau
2023-02-12 10:41     ` Willy Tarreau
2023-02-12 18:27       ` Willy Tarreau
2023-02-16  0:11         ` Vincent Dagonneau
2023-02-16  3:29           ` Willy Tarreau [this message]
  -- strict thread matches above, loose matches on Subject: below --
2023-02-20 20:20 Vincent Dagonneau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y+2jK3yyLx+0cPr9@1wt.eu \
    --to=w@1wt.eu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=v@vda.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox