Will PR rtl-optimization/101188 be back-ported to v13 ?
We have this (rare?) wrong code bug https://gcc.gnu.org/PR101188 which Jeff fixed for v14: https://gcc.gnu.org/r14-1738 The fix doesn't fit 100% for v13 but the PR has a backport for v13 in comment #16. Would be great if this could be part of v13.3, but I don't have the resources to reg-test it on all the targets. Johann
Re: Will PR rtl-optimization/101188 be back-ported to v13 ?
On Fri, Feb 9, 2024 at 10:36 AM Georg-Johann Lay wrote: > > We have this (rare?) wrong code bug > > https://gcc.gnu.org/PR101188 > > which Jeff fixed for v14: > > https://gcc.gnu.org/r14-1738 > > The fix doesn't fit 100% for v13 but the PR has a backport for v13 > in comment #16. Would be great if this could be part of v13.3, > but I don't have the resources to reg-test it on all the targets. There's no automatic system to backport changes, the bug in question has been closed and it wasn't marked as regression (even though it indicates some older known-to-work version which would have made it qualify as such). I would suggest to re-open the bug and assign the author of the original fix asking for the backport. Richard. > Johann
Re: gcc 3.2.3 x64 negative indexes
On Wed, 7 Feb 2024 at 23:12, Jakub Jelinek 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
Re: gcc 3.2.3 x64 negative indexes
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 wrote:
> On Wed, 7 Feb 2024 at 23:12, Jakub Jelinek 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
>
>
gcc-12-20240209 is now available
Snapshot gcc-12-20240209 is now available on https://gcc.gnu.org/pub/gcc/snapshots/12-20240209/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 12 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-12 revision f7b3a82be2f4e9f43524185226c0df686c7b0154 You'll find: gcc-12-20240209.tar.xz Complete GCC SHA256=a8f391fa524081d18425d90df51f6367c383d99e2e3e875a8f53a3c76270d0fb SHA1=dff0cfaeba4eab45e037b335719dd97b13cf0841 Diffs from 12-20240202 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-12 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
