From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id E0FFA3836C07; Sun, 15 Nov 2020 03:26:02 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E0FFA3836C07 From: "foom at fuhm dot net" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/88115] Incorrect result from alignof in templates, if also using __alignof__. Date: Sun, 15 Nov 2020 03:26:02 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 8.2.1 X-Bugzilla-Keywords: ABI, wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: foom at fuhm dot net 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: --- 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: Sun, 15 Nov 2020 03:26:03 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D88115 --- Comment #6 from James Y Knight --- > c++: Change the mangling of __alignof__ [PR88115] The new mangling chosen for __alignof__(type) seems problematic, and I think this commit ought to be reverted until a new mangling scheme has been chose= n. At the very least, both __alignof__(expression) and __alignof__(type) can't both be encoded as "v111__alignof__", with no indication of whether the argument is a type or an expression, because that's ambiguous. Possibly it'd be okay to use v112__alignof__z and v112__alignof__t, similar= to how "az" and "at" are used for standard alignof expression/type. That solves the ambiguity. But -- this violates the generic grammar, which doesn't allow for a vendor operator to take type arguments at all. ::=3D v ::=3D Now...possibly it's okay to violate that and pass a type, regardless. But, = then the demangler needs to know what every vendor extension operator's semantics are in order to demangle -- which seems against the intent of the standardi= zed "vendor operator" syntax. So, that's not great. This seems like a problem which may be worth solving properly and generally= in the itanium ABI -- maybe now's the time to actually do this? (Fixing this w= ould allow __typeof__, __builtin_convertvector, and __builtin_offsetof to be mangleable too...) See also PR13740 and PR11078, for earlier (MUCH earlier!) discussion of possible mangling syntax extensions for this sort of thing. Unfortunately, it never went anywhere... ISTM that the most promising proposal in those earlier threads was to add a= "Y" to both type and expression expansions. To support vendor-specific builtins which returns a type, and can take type= s or expressions as arguments (e.g. typeof), add: ::=3D Y + E To support vendor-specific builtins which return a value, and can take type= s or expressions as arguments (e.g. __builtin_offsetof, or __alignof__): ::=3D Y + E=