9front - general discussion about 9front
 help / color / mirror / Atom feed
From: Michael Forney <mforney@mforney.org>
To: 9front@9front.org
Subject: Re: [9front] cc: fix conversion of constants to match c99.
Date: Thu, 5 May 2022 11:20:33 -0700	[thread overview]
Message-ID: <CAGw6cBttLb5j899n_qhn-3-OegyOkwBVzNdF-c2KVvoWcCedTQ@mail.gmail.com> (raw)
In-Reply-To: <13CBD0AF060D51D940C5C190309C99E9@eigenstate.org>

On 2022-05-05, ori@eigenstate.org <ori@eigenstate.org> wrote:
> Earlier, I'd done a half-assed job of this, this patch corrects
> it and makes the code less ugly. (thanks to adr on 9fans)

Are there any constants in the 9front codebase that change their type
after this change? If so, which ones?

Maybe we could do a test build that has the old and new logic and
prints a diagnostic if anything changes type, then investigate any
results to see if it would introduce any bugs.

> ok to commit?
>
> diff 641bd4512ff02b1b86157263ab604bc790f0c89d uncommitted
> --- a/sys/src/cmd/cc/lex.c
> +++ b/sys/src/cmd/cc/lex.c
> @@ -444,7 +444,7 @@
>  yylex(void)
>  {
>  	vlong vv;
> -	long c, c1, t, w;
> +	long c, c1, t;
>  	char *cp;
>  	Rune rune;
>  	Sym *s;
> @@ -848,17 +848,11 @@
>  		yyerror("overflow in constant");
>
>  	vv = yylval.vval;
> -	/*
> -	 * c99 is silly: decimal constants stay signed,
> -	 * hex and octal go unsigned before widening.
> -	 */
> -	w = 32;
> -	if((c1 & (Numdec|Numuns)) == Numdec)
> -		w = 31;
> -	if(c1 & Numvlong || (c1 & Numlong) == 0 && (uvlong)vv >= 1ULL<<w){
> -		if((c1&(Numdec|Numvlong)) == Numdec && vv < 1ULL<<32)
> -			warn(Z, "int constant widened to vlong: %s", symb);
> -		if((c1 & Numuns) || convvtox(vv, TVLONG) < 0) {
> +	if(c1 & Numvlong ||
> +	  convvtox(vv, TUVLONG) > convvtox(vv, TULONG) ||

Since the return type of convvtox is vlong, I don't think this behaves
as you expect.

If we have "0xffffffffffffffff", then vv == -1LL. So convvtox(-1LL,
TUVLONG) == -1LL and convvtox(-1LL, TULONG) == 0xffffffffLL, which
means this condition fails (-1LL < 0xffffffffLL), and we end up not
choosing a 64-bit type.

> +	  (c1 & (Numdec|Numuns)) == Numdec && convvtox(vv, TLONG) < 0) {
> +   		if((c1 & (Numdec|Numuns)) == 0 &&

Indentation is a bit weird here. I think there are some leading spaces.

> +		  ((c1 & Numuns) || convvtox(vv, TVLONG) < 0)) {

Something is funny with the logic here. In the LHS of the &&, you
checked that c1 has neither Numdec or Numuns, so it is impossible that
c1 has Numuns here.

I haven't tested, but I think we'd end up with 0ULL having type vlong,
not uvlong (hit the first case in the outer if-statement, and fail the
first case in the inner if-statement).

Maybe the following is correct?

if((c1 & Numuns) || !(c1 & Numdec) && convvtox(vv, TLONG) < 0)

>  			c = LUVLCONST;
>  			t = TUVLONG;
>  			goto nret;
> @@ -867,8 +861,11 @@
>  		t = TVLONG;
>  		goto nret;
>  	}
> -	if(c1 & Numlong) {
> -		if((c1 & Numuns) || convvtox(vv, TLONG) < 0) {
> +	if(c1 & Numlong ||
> +	  convvtox(vv, TULONG) > convvtox(vv, TUINT) ||
> +	  (c1 & (Numdec|Numuns)) == Numdec && convvtox(vv, TINT) < 0) {
> +		if((c1 & (Numdec|Numuns)) == 0 &&

Same problem here. Maybe

if((c1 & Numuns) || !(c1 & Numdec) && convvtox(vv, TLONG) < 0)

instead?

Trailing space on this line.

> +		  ((c1 & Numuns) || convvtox(vv, TLONG) < 0)) {
>  			c = LULCONST;
>  			t = TULONG;
>  			goto nret;

Also, just want to throw out an alternative table-based approach (what
I'm doing in cproc) that has a lot less logic. Not even compile
tested, but something like

static struct {
	long t, c, c1;
} inttypes[] = {
	{TINT, LCONST, 0},
	{TUINT, LUCONST, Numuns},
	{TLONG, LLCONST, Numlong},
	{TULONG, LULCONST, Numuns|Numlong},
	{TVLONG, LVLCONST, Numvlong|Numlong},
	{TUVLONG, LUVLCONST, Numuns|Numvlong|Numlong},
};
for(i = 0; i < nelem(inttypes); i++){
	if((c1 & (Numuns|Numlong|Numvlong)) == inttypes[i].c1)
		break;
}
for(; i < nelem(inttypes); i += c1 & (Numuns|Numdec) ? 2 : 1)
	t = inttypes[i].t;
	c = inttypes[i].c;
	if(vv <= 0xffffffffffffffffu >> 64 - 8 * ewidth[t] + !typeu[t])
		break;
}

      reply	other threads:[~2022-05-05 18:23 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-05 13:18 ori
2022-05-05 18:20 ` Michael Forney [this message]

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=CAGw6cBttLb5j899n_qhn-3-OegyOkwBVzNdF-c2KVvoWcCedTQ@mail.gmail.com \
    --to=mforney@mforney.org \
    --cc=9front@9front.org \
    --subject='Re: [9front] cc: fix conversion of constants to match c99.' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).