From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 787BB384B821; Wed, 17 Mar 2021 15:34:17 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 787BB384B821 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug testsuite/99626] [10/11 regression] gcc.dg/strlenopt-73.c fails for 32 bits Date: Wed, 17 Mar 2021 15:34:17 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: testsuite X-Bugzilla-Version: 11.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 10.3 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 15:34:17 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D99626 --- Comment #1 from Jakub Jelinek --- Doesn't FAIL on i686-linux. I wonder if it is SLOW_UNALIGNED_ACCESS or something similar that for power= pc64 -m32 causes a lot of memcpy calls not to be folded. grep memcpy strlenopt-73.c.023t.ssa=20 memcpy (pa_41, iftmp.0_21, 17); memcpy (pa_49, iftmp.2_22, 17); memcpy (pa_56, iftmp.4_23, 16); memcpy (pa_63, iftmp.6_24, 15); memcpy (pa_78, iftmp.10_26, 32); memcpy (pa_85, iftmp.12_27, 31); memcpy (pa_92, iftmp.14_28, 30); is the same between i686 and powerpc64 -m64, while for powerpc64 -m32 shows grep memcpy strlenopt-73.c.023t.ssa=20 memcpy (pa_41, iftmp.0_21, 17); memcpy (pa_49, iftmp.2_22, 17); memcpy (pa_56, iftmp.4_23, 16); memcpy (pa_63, iftmp.6_24, 15); memcpy (pa_78, iftmp.10_26, 32); memcpy (pa_85, iftmp.12_27, 31); memcpy (pa_92, iftmp.14_28, 30); memcpy (pa_25, iftmp.20_13, 8); memcpy (pa_33, iftmp.22_14, 8); memcpy (pa_40, iftmp.24_15, 8); memcpy (pa_47, iftmp.26_16, 8); memcpy (pa_54, iftmp.28_17, 8); memcpy (pa_61, iftmp.30_18, 8); The test_copy_cond_unequal_length_i128 has the following misleading comment: #if __i386__ && __SIZEOF_INT128__ =3D=3D 16 /* The following tests assume GCC transforms the memcpy calls into int128_t assignments which it does only on targets that define the MOVE_MAX macro to 16. That's only s390 and i386 with int128_t support. */ I bet it is never tested, because __int128 isn't supported on 32-bit target= s. But __i386__ is defined only on 32-bit x86, so perhaps it meant to use __x86_64__ define instead? And test_copy_cond_unequal_length_i64 is essentially the same except with smaller size, so it again relies on targets transforming the memcpy calls to long long assignments. And there is a lot of targets that define MOVE_MAX to 4 or smaller: config/arc/arc.h:#define MOVE_MAX 4 config/arm/arm.h:#define MOVE_MAX 4 config/c6x/c6x.h:#define MOVE_MAX 4 config/cr16/cr16.h:#define MOVE_MAX 4 config/cris/cris.h:#define MOVE_MAX 4 config/csky/csky.h:#define MOVE_MAX 4 config/ft32/ft32.h:#define MOVE_MAX 4 config/h8300/h8300.h:#define MOVE_MAX 4 config/iq2000/iq2000.h:#define MOVE_MAX 4 config/lm32/lm32.h:#define MOVE_MAX UNITS_PER_WORD config/m32c/m32c.h:#define MOVE_MAX 4 config/m32r/m32r.h:#define MOVE_MAX 4 config/m68k/m68k.h:#define MOVE_MAX 4 config/mcore/mcore.h:#define MOVE_MAX 4 config/microblaze/microblaze.h:#define MOVE_MAX 4 config/mn10300/mn10300.h:#define MOVE_MAX 4 config/moxie/moxie.h:#define MOVE_MAX 4 config/nds32/nds32.h:#define MOVE_MAX 4 config/nios2/nios2.h:#define MOVE_MAX 4 config/or1k/or1k.h:#define MOVE_MAX 4 config/pdp11/pdp11.h:#define MOVE_MAX 2 config/rl78/rl78.h:#define MOVE_MAX 2 config/rs6000/rs6000.h:#define MOVE_MAX (! TARGET_POWERPC64 ? 4 : 8) config/rx/rx.h:#define MOVE_MAX 4 config/sh/sh.h:#define MOVE_MAX (4) config/stormy16/stormy16.h:#define MOVE_MAX 2 config/v850/v850.h:#define MOVE_MAX 4 config/visium/visium.h:#define MOVE_MAX 4 config/xtensa/xtensa.h:#define MOVE_MAX 4 So IMNSHO that function should be compiled only on a couple of targets know= n to fold memcpy (, , 8); to the assignments.=