https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121785
Bug ID: 121785
Summary: [aarch64] inconsistent result after matching bcaxqdi4
instruction
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: dizhao at os dot amperecomputing.com
Target Milestone: ---
Created attachment 62300
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=62300&action=edit
preprocessed C++ source code file
Attached is a preprocessed source code file, for with GCC-trunk produced
different execution result after commit 1b7bcac0 ("aarch64: Handle DImode
BCAX operations").
About the preprocessed source code: function mul_internal_part is extracted
from wi::mul_internal in gcc.wide-int.cc. And function sext_hwi modified
(removed the original branch for __GNUC__) to be:
/* Sign extend SRC starting from PREC. */
inline HOST_WIDE_INT
sext_hwi (HOST_WIDE_INT src, unsigned int prec)
{
if (prec == HOST_BITS_PER_WIDE_INT)
return src;
else
{
/* Fall back to the slower, well defined path otherwise. */
gcc_checking_assert (prec < HOST_BITS_PER_WIDE_INT);
HOST_WIDE_INT sign_mask = HOST_WIDE_INT_1 << (prec - 1);
HOST_WIDE_INT value_mask = (HOST_WIDE_INT_1U << prec) - HOST_WIDE_INT_1U;
return (((src & value_mask) ^ sign_mask) - sign_mask);
}
}
Given that the original comment mentioned that the path is well defined, I
suppose this is a bug in GCC?
Current results:
1. Compiled with GCC before 1b7bcac0, with option "-O3 -std=c++17 -mabi=lp64
-march=armv8.4-a+sha3":
sext_hwi(64,32)=64
sext_hwi(8192,32)=8192
2. Compiled with GCC after 1b7bcac0, with option "-O3 -std=c++17 -mabi=lp64
-march=armv8.4-a+sha3":
sext_hwi(64,32)=0
sext_hwi(8192,32)=0
3. Compiled with GCC with option "-O3 -std=c++17 -mabi=lp64 -march=armv8.4-a":
sext_hwi(64,32)=64
sext_hwi(8192,32)=8192
