From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) by sourceware.org (Postfix) with ESMTPS id 3ECC13857013 for ; Wed, 10 Jan 2024 11:53:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3ECC13857013 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=adacore.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 3ECC13857013 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::335 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704887596; cv=none; b=VqZdXhmBrK8Wh4EKWTPGFkc9lppF93q/9/uRyHoH8614xU90AHWTjd6+rLYyjTV/Ssyr+zhuvTdBb1UoNWBa8D4UgAYU5zbXuAYBk8KtO5F83f1/PIqNRfZaPZQjftR5MpTvyBvUxVDGPEOGhFy1RnnYSyhmTG5hF6WNS7bBuVo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704887596; c=relaxed/simple; bh=BiS7G6l8UHCROnY+uqIksWXWcL0nfxn/LQjS8jEuk/A=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=fiXJBx7KeE8SGrb3daTtGrqzd3oNVyK6GV6ykPzir9Zl1dzhzBYvXms+9k0mMjcgpqdq2ymVhim5LE2l3evKjbH8kOrAse9I07c/Yd9J/+oe+kxuuVeFKNdqzzBJL9NsgRblg9Gfqh54di+NCqXbwK4XT8qtl6XfWAm8UJB63lE= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-40d604b4b30so30023375e9.1 for ; Wed, 10 Jan 2024 03:53:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adacore.com; s=google; t=1704887591; x=1705492391; darn=gcc.gnu.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=RWPe+ggLEYOUrZjU5v1NLpj29rWhpL6rAw18mHttTeM=; b=Beqi68QSIfkxguTvMBa4UnugCc35sH6VcSDNQeWjPYD1S8dPOiFp4v7gnhVS7IcQgH fu4Sn76DCK1wVyYtTJEpwMXHLTs7YL858eBGuJ17OWCXwi6RJU3llae3KiihgX9V5vJ4 CHjETYtOJM2K9JjU0SLbAy7TpBbgnoDHDCjyjAryZEjpyKeKcGgKCDwJl0GDoiriKk1F g/Fc9qFeTnTnEDEfgR4nyE7rfWKOI/s8SpihyBlLNOQUPrDNQTn485BehCJjBfe86gSd fQIwWlEcOIwyKdRkhWyI7OIzEZwVZFAQy2Q2C+WB3lVvkg4J4bpmLehQ96zciAfEtdG5 eLgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704887591; x=1705492391; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=RWPe+ggLEYOUrZjU5v1NLpj29rWhpL6rAw18mHttTeM=; b=vyDSEOqdv7IEDXS5TxlMJ1mhSoo0XrYxFPPaZyKA0Px1t4NSA0kF8mzXPaw6fHtJ2c 7tZtGMxx9wqahebXy4ZeJe1aqrp+d1Ze2qyB/vKXQHWpjbW7uFBi/oKTKkiQDD7bzbOE jN8vZuRfp/Npw/EFb61suOkQ+IlCbSOGVuZppkpxLNIX1g3VIUfflogizsIfR1JedqM0 XkusPv/3FAAFwRzn5p6L1eH+2XtalPf64iO4JyfxFraOlOuJzk9DRtcNKIh5yCX05JH9 3G5Hxw2OMz2mJ/pTUelZCrtOVN7tYMYRPNCVprRQ9Zy8t/bcIIa348e3LPvUVPLr3xOF +lVA== X-Gm-Message-State: AOJu0YydifyVjUMx20Yp62QZxtXM7oILTsNzkBAhQ4grSNahD+woT9+v FfcFuMuU6q+T7YNPSWy7YtK5C1zkeRR2 X-Google-Smtp-Source: AGHT+IFoJeuUk57qIMpqPaBSkttsg/oCu5pYbW6EtsDLuNzvGwCA3eo7laGg1OsP46fY/9HefbKFWQ== X-Received: by 2002:a05:600c:6b17:b0:40d:88bf:da7c with SMTP id jn23-20020a05600c6b1700b0040d88bfda7cmr601738wmb.159.1704887590946; Wed, 10 Jan 2024 03:53:10 -0800 (PST) Received: from fomalhaut.localnet ([2a01:e0a:8d5:d990:e654:e8ff:fe8f:2ce6]) by smtp.gmail.com with ESMTPSA id s12-20020adfeccc000000b003368849129dsm4717221wro.15.2024.01.10.03.53.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Jan 2024 03:53:10 -0800 (PST) From: Eric Botcazou X-Google-Original-From: Eric Botcazou To: Tom Tromey , Richard Biener Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Fix debug info for enumeration types with reverse Scalar_Storage_Order Date: Wed, 10 Jan 2024 12:53:10 +0100 Message-ID: <1875304.tdWV9SEqCh@fomalhaut> In-Reply-To: References: <3238326.AJdgDx1Vlc@fomalhaut> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > Can you elaborate on the DIE order constraint and why it was chosen? That > is, > > + /* The DIE with DW_AT_endianity is placed right after the naked DIE. > */ + if (reverse) > + { > + gcc_assert (type_die); > ... > > and > > + /* The DIE with DW_AT_endianity is placed right after the naked DIE. > */ + if (reverse_type) > + { > + dw_die_ref after_die > + = modified_type_die (type, cv_quals, false, context_die); > + gen_type_die (type, context_die, true); > + gcc_assert (after_die->die_sib > + && get_AT_unsigned (after_die->die_sib, > DW_AT_endianity)); + return after_die->die_sib; > > ? That's preexisting though, see line 13730 where there is a small blurb. The crux of the matter is that there is no scalar *_TYPE node with a reverse SSO, so there is nothing to equate with for the DIE carrying DW_AT_endianity, unlike for type variants (the reverse SSO is on the enclosing aggregate type instead but this does not match the way DWARF describes it). Therefore, in order to avoid building a new DIE with DW_AT_endianity each time, the DIE with DW_AT_endianity is placed right after the naked DIE, so that the lookup done at line 13730 for reverse SSO is immediate. > Likewise the extra argument to the functions is odd - is that not available > on the tree type? No, for the reason described above, so the extra parameter is preexisting for base_type_die, modified_type_die and add_type_attribute. -- Eric Botcazou