From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 710FA38515D9; Wed, 7 Sep 2022 12:10:25 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 710FA38515D9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1662552625; bh=YiDnWITtV365iK7k01UrcOEsiMyBJxWXgoYd7DPGjN8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=niFXDzz9+d4FwYYUrvjVfQnVsmwhiohgLfGXGIU0ZKvVp1/909qPHeD8PpDGbHyhA +ZwZ9ZQRx209ip1kfVcXvxJG+63taNzd6MiulJLfRmYsvfuYNce88aojmRu1LHmYG4 Lmfycg1g5rFfwtCDF9IMnK+B+YTI0M9Z9RNCgbAg= From: "uweigand at gcc dot gnu.org" To: gdb-prs@sourceware.org Subject: [Bug tdep/29543] [gdb/tdep, ppc] inferior call with long double vararg not handled correctly Date: Wed, 07 Sep 2022 12:10:24 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: tdep X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: uweigand at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- 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://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D29543 --- Comment #9 from Ulrich Weigand --- (In reply to Tom de Vries from comment #8) > (In reply to Ulrich Weigand from comment #7) > > Note it would appear the same problem also exists when handling homogen= eous > > (ELFv2) or single-element (ELFv1) aggregates: these also need 16-byte > > alignment if the base type is a vector or _Float128 type. >=20 > Can you or Carl propose a patch for this additional problem? It's just a few lines further down in the same function, in the final else branch: else { ppc64_sysv_abi_push_val (gdbarch, val, TYPE_LENGTH (type), 0, argpos); [...] followed by either ppc64_sysv_abi_push_vreg or ppc64_sysv_abi_push_freg. The problem is that alignment of 0 is only correct in those cases where ppc64_sysv_abi_push_freg is called - in those cases where ppc64_sysv_abi_push_vreg is called, we also need to use 16 byte alignment h= ere. > Alternatively, can you show code examples that fail due this problem? I haven't tried, but the original test case in the bugzilla should show this problem if you replace the "long double _Complex" with a single-element str= uct with just this type (or just "long double") as element. --=20 You are receiving this mail because: You are on the CC list for the bug.=