public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Paul Edwards <mutazilah@gmail.com>
To: Jakub Jelinek <jakub@redhat.com>
Cc: GCC Development <gcc@gcc.gnu.org>
Subject: Re: gcc 3.2.3 x64 negative indexes
Date: Sat, 10 Feb 2024 05:38:05 +0800	[thread overview]
Message-ID: <CAMi4NxZsEWNWWEJZ+Bf+HYiP+45fU82CZb-k2kJnHLLS=ESkSg@mail.gmail.com> (raw)
In-Reply-To: <CAMi4NxZbzs8v-nAui8P5rkNbgi8woW-3aEnmZmc4a8XtrX7RUg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4372 bytes --]

Oh - I switched to -2 to make debugging easier:

D:\devel\gcc\gcc>type foo.c
int foo(char *in)
{
return in[-2];
}

D:\devel\gcc\gcc>


Note that my flavor of gcc 3.2.3 can be found in gcc-stage*.zip
in custom.zip at http://pdos.org




On Sat, 10 Feb 2024 at 05:34, Paul Edwards <mutazilah@gmail.com> wrote:

> On Wed, 7 Feb 2024 at 23:12, Jakub Jelinek <jakub@redhat.com> wrote:
> On Wed, Feb 07, 2024 at 11:02:51PM +0800, Paul Edwards via Gcc wrote:
>
> >> I am using a slightly modified gcc 3.2.3 for x86_64 and for this code:
>
> > Don't, gcc 3.2.3 is not supported for more than 20 years already.
>
> And the i370 target hasn't been supported for that long
> either - but that's a target I want too.
>
> And nor has any version ever run on MVS 3.8J - but
> that's an execution platform I want too.
>
> And the same goes for PDOS/386 as an execution platform.
>
> >> int fff(char *x)
> >> {
> >> return (x[-1]);
> >> }
> >
> >> It is generating:
> >
> >> .globl fff
> >> fff:
> >> .LFB2:
> >>         movl    $4294967295, %eax
> >>         movsbl  (%rax,%rcx),%eax
>
> > That said, I can't reproduce it and get
> >        movsbl  -1(%rdi),%eax
> >        ret
> > from 3.2.3.
>
> Thanks for that! So one of the "slight modifications"
> was to switch to Win64 ABI, which is why rcx is being
> selected instead of rdi. So that bit is expected.
>
> So I need to know why I'm not getting -1.
>
> Since your email I have been trying to explain that.
> It is likely a problem with the C library I am using
> (PDPCLIB) - strtol or something like that.
>
> I am using 64-bit longs and I can see that that large
> value (-1 as unsigned 32-bit) is being stored in the
> 64-bit field and being preserved.
>
> So far I have tracked it down to happening in the
> early stages. fold() is called and I can see that it
> is initially good for something, and bad later.
>
> I'm still working on it.
>
> BFN. Paul.
>
>
> fold-const.c
>
> tree
> fold (expr)
>      tree expr;
> {
>   tree t = expr;
>   tree t1 = NULL_TREE;
>   tree tem;
>   tree type = TREE_TYPE (expr);
>   tree arg0 = NULL_TREE, arg1 = NULL_TREE;
>   enum tree_code code = TREE_CODE (t);
>   int kind = TREE_CODE_CLASS (code);
>   int invert;
>   /* WINS will be nonzero when the switch is done
>      if all operands are constant.  */
>   int wins = 1;
>
> printf("bbb in fold\n");
>   /* Don't try to process an RTL_EXPR since its operands aren't trees.
>      Likewise for a SAVE_EXPR that's already been evaluated.  */
>   if (code == RTL_EXPR || (code == SAVE_EXPR && SAVE_EXPR_RTL (t) != 0))
>     return t;
>
>   /* Return right away if a constant.  */
>   if (kind == 'c')
>     return t;
>
> printf("bbb fold2\n");
> printf("bbb fold2b %d\n", (int)TREE_CODE(t));
> if (TREE_CODE (t) == INTEGER_CST)
> {
> printf("bbb fold2c is %ld\n",
>        (long)TREE_INT_CST_LOW (t));
> }
>
>
> ...
>
>
>   /* If this is a commutative operation, and ARG0 is a constant, move it
>      to ARG1 to reduce the number of tests below.  */
>   if ((code == PLUS_EXPR || code == MULT_EXPR || code == MIN_EXPR
>        || code == MAX_EXPR || code == BIT_IOR_EXPR || code == BIT_XOR_EXPR
>        || code == BIT_AND_EXPR)
>       && (TREE_CODE (arg0) == INTEGER_CST || TREE_CODE (arg0) == REAL_CST))
>     {
> printf("bbb fold3\n");
> printf("bbb fold3b is %ld\n",
>        (long)TREE_INT_CST_LOW (arg0));
>
>       tem = arg0; arg0 = arg1; arg1 = tem;
>
>       tem = TREE_OPERAND (t, 0); TREE_OPERAND (t, 0) = TREE_OPERAND (t, 1);
>       TREE_OPERAND (t, 1) = tem;
>     }
>
> printf("bbb fold4\n");
>
>
>
> temp.txt: bbb fold2
> temp.txt: bbb fold2b 77
> temp.txt: bbb fold4
> temp.txt: bbb fold5
> temp.txt: bbb -2 -1
> temp.txt: bbbj 0
> temp.txt: bbbs1
> temp.txt: bbbs2
> temp.txt: bbbs9
> temp.txt: bbbq
> temp.txt: bbb in fold
> temp.txt: bbb fold2
> temp.txt: bbb fold2b 115
> temp.txt: bbb fold4
> temp.txt: bbb fold5
> temp.txt: bbb -2 -1
> temp.txt: bbbj 0
> temp.txt: bbb in fold
> temp.txt: bbb fold2
> temp.txt: bbb fold2b 115
> temp.txt: bbb fold4
> temp.txt: bbb fold5
> temp.txt: bbb 1 0
> temp.txt: bbbj 0
> temp.txt: bbbq
> temp.txt: bbb about to do build
> temp.txt: bbbo
> temp.txt: bbb done build
> temp.txt: bbb in fold
> temp.txt: bbb fold2
> temp.txt: bbb fold2b 61
> temp.txt: bbb fold3
> temp.txt: bbb fold3b is 4294967294
> temp.txt: bbb fold4
> temp.txt: bbb fold5
> temp.txt: bbb 4294967294 0
>
>

  reply	other threads:[~2024-02-09 21:38 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-07 15:02 Paul Edwards
2024-02-07 15:12 ` Jakub Jelinek
2024-02-09 21:34   ` Paul Edwards
2024-02-09 21:38     ` Paul Edwards [this message]
2024-02-10 13:41       ` Paul Edwards
2024-02-10 17:42         ` Joe Monk
2024-02-10 19:48         ` Paul Edwards
2024-02-11  0:03         ` Paul Edwards

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='CAMi4NxZsEWNWWEJZ+Bf+HYiP+45fU82CZb-k2kJnHLLS=ESkSg@mail.gmail.com' \
    --to=mutazilah@gmail.com \
    --cc=gcc@gcc.gnu.org \
    --cc=jakub@redhat.com \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).