From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 403963858C42; Wed, 17 Apr 2024 14:06:37 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 403963858C42 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1713362797; bh=OMVwJuBzjcHJ3WZTduqLp9ublcfNz98JMNrLwNTIr7c=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ugglMmdMSAXpsOhROFtJjk9BJ6ByguoIg+swVcALH1xK5VLS9txNS8C1T+G6amSik a5WbHZNIeBDn7ExObRP3LEjOtThIXBjzupjpFwQ1k4tu8RfO6yNTJXXi62Nd1uQ0ni V7RqZ1d3PjP8iqHheuZRqeQMOiyvbTpCaCIXn7Ns= From: "jakub.kulik at oracle dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/114416] calling convention incompatibility with vendor compiler for V9 Date: Wed, 17 Apr 2024 14:06:35 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 14.0 X-Bugzilla-Keywords: ABI, wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub.kulik at oracle dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 14.0 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D114416 --- Comment #10 from Jakub Kulik --- Sorry for longer response. I asked internally again and was told by a colleague who was in the room wh= en the spec was created, that: "the intent was (and is) that the individual elements/atoms/fundamental types that make up a small structure, no matter = how those elements/atoms/fundamental types are aggregated within the structure,= are passed in registers appropriate for the fundamental type in question. (That= is, pointers and integral types are passed in the %o registers, and floating po= int types are passed in the floating-point registers.) So a structure that cont= ains an array of two floats is treated the same as a structure that contains two floats." That said, he agreed that the spec could perhaps be better written. He also added: Page 3P-11 says this, under "Function Argument Passing": "It is convenient to describe parameter linkage in terms of an array. Conceptually, parameters are assigned into an array of extended words, left-to-right, with an occasional =E2=80=9Chole=E2=80=9D to satisfy alignme= nt restrictions. Typically, most parameter values will be =E2=80=9Cpromoted=E2=80=9D from th= eir memory locations into registers, and most calls are expected to execute this way with less overhead." There is then a diagram that shows the correspondence between parameter registers and the parameter array. On page 3P-12, under "Structure and Union arguments", it says this: "Structure or union types up to eight bytes in size are assigned to one parameter array word, and align to eight-byte boundaries. "Structure or union types larger than eight bytes, and up to sixteen bytes = in size are assigned to two consecutive parameter array words, and align accor= ding to the alignment requirements of the structure or at least to an eight-byte boundary." So perhaps instead of saying "The individual fields of a structure ... are subject to promotion into registers based on their type using the same rule= s as apply to scalar values" the spec should have said "The individual parameter array words assigned to a structure ... are subject to promotion into regis= ters based on their type using the same rules as apply to scalar values."=