On 12/30/25 8:41 PM, Jeffrey Law wrote:
On 12/30/2025 6:29 AM, Daniel Barboza wrote:
Add a pattern to handle cases where we have an OP that is
unconditionally being applied in the result of a gcond. In this case we
can apply OP to both legs of the conditional. E.g:
t = b ? 10 : 20;
t = t + 20;
becomes just:
t = b ? 30 : 40
A variant pattern was also added to handle the case where the gcond
result is used as the second operand. This was needed because most of
the ops we're handling aren't commutative.
PR 122608
gcc/ChangeLog:
* match.pd (`(c ? a : b) op d -> c ? (a op d) : (b op d)`): New
pattern.
(`d op (c ? a : b) -> c ? (d op a) : (d op b)`): Likewise
gcc/testsuite/ChangeLog:
* gcc.target/i386/pr110701.c: the pattern added is now folding
an XOR into the ifcond and the assembler isn't emitting an
'andl' anymore. The test was turned into a runtime test
instead.
* gcc.dg/torture/pr122608.c: New test.
OK. So one thing did pop from that test. On xstormy16-elf I'm seeing:
/home/jlaw/jenkins/workspace/xstormy16-elf/gcc/gcc/testsuite/gcc.dg/torture/pr122608.c:
In function 'mulhighpart_test':
/home/jlaw/jenkins/workspace/xstormy16-elf/gcc/gcc/testsuite/gcc.dg/torture/pr122608.c:151:1:
error: type mismatch in binary expression
int
int
long int
t = t h* 2147483647;
With a similar error in mulhighpart_test2. It's saying we have an integer
output (t), integer input (t) and long integer input (2147483647). Not sure
how we got long int type here. But it's clearly unhappy.
So I tried to amend the test by using stuff like UINT_MAX but, given
that it's a __GIMPLE test, seems like we can't use these macros inside
the functions.
One thing I came up with is:
git diff
diff --git a/gcc/testsuite/gcc.dg/torture/pr122608.c
b/gcc/testsuite/gcc.dg/torture/pr122608.c
index 8129a129769..0c29d1ccaaa 100644
--- a/gcc/testsuite/gcc.dg/torture/pr122608.c
+++ b/gcc/testsuite/gcc.dg/torture/pr122608.c
@@ -140,13 +140,24 @@ __GIMPLE ptrdiff_t pointer_diff_test2 (int a)
return t;
}
+#if __INT_WIDTH__ == 8
+#define HIGH1 0x7f
+#define HIGH2 0x5f
+#elif __INT_WIDTH__ == 16
+#define HIGH1 0x7fff
+#define HIGH2 0x5fff
+#else
+#define HIGH1 0x7fffffff
+#define HIGH2 0x5fffffff
+#endif
+
__GIMPLE int mulhighpart_test (int a)
{
_Bool b;
int t;
b = a > 0;
t = b ? 30 : 40;
- t = t __MULT_HIGHPART 0x7fffffff;
+ t = t __MULT_HIGHPART HIGH1;
return t;
}
@@ -155,7 +166,7 @@ __GIMPLE int mulhighpart_test2 (int a)
_Bool b;
int t;
b = a > 0;
- t = b ? 0x5fffffff : 0x7fffffff;
+ t = b ? HIGH2 : HIGH1;
t = 40 __MULT_HIGHPART t;
return t;
}
I believe this will make the xstormy16 problem go away. I'm all ears for
better solutions ... otherwise I'll send a v4 with this change. Thanks,
Daniel
Jeff
