From patchwork Wed Feb 7 17:29:11 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Patrick Palka X-Patchwork-Id: 85436 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 920153857C4A for ; Wed, 7 Feb 2024 17:30:02 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 2972F38582A3 for ; Wed, 7 Feb 2024 17:29:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2972F38582A3 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 2972F38582A3 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707326976; cv=none; b=dUx59RBAVyv0LaGHAZbVTmwXbmK7MZS8QcLaPeF2QQ2LbUg3bdyz5z+aNYVbQludwlYArDYgOLsTuah6fkjeEZJ2YY0sKmOs+155qQDLsMrNlm+QquwDM+sM1Za7PQvu37RW3GWWu/UMzUasMCCRAPjltrLGMzFJCKObRzc4UGs= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707326976; c=relaxed/simple; bh=Sr6BN2l+VZlUE+Bfw/KVuilDKeLuJr3dhtRmdLdFGWI=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=RuTTH6xj68MO3khHZTcgPVkdw1msW2KFNGlYs7oH2o8bG6TYnKclBR1iKlQuSSaaNiE0F/6hlTXZrW2MxyhzFpZLPml+m+Eaww1aOmVY9GjkJblKEYnCMUrdSpnw2q6iZUgFnI0soQbEd0/hlG9CtEDkgjnUXlMzjLn5Sfhg18M= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1707326974; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=VoFgKfufgI053m76QGnRSpOjDUdigHwvvQk+gu+8CSw=; b=ZMSjAQ4SYXoLSC25S9mWuPS1MoiEI+2+65RvJ48rdjVYezrC6oSjNLj6Jvh8HPpCJglvl9 YK7hkXILHn+HfipYVN4D5DuYe/YksC0ni0tcZgMazJxnepeP77egT/in3v3cckroytRYdF qf3oaMOPYAnswwa+nHnH7FGoghewoCo= Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-241-qubZQyVDPxKlFJQc7CRICQ-1; Wed, 07 Feb 2024 12:29:33 -0500 X-MC-Unique: qubZQyVDPxKlFJQc7CRICQ-1 Received: by mail-qv1-f72.google.com with SMTP id 6a1803df08f44-68ca5f30b20so9438896d6.2 for ; Wed, 07 Feb 2024 09:29:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707326971; x=1707931771; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=VoFgKfufgI053m76QGnRSpOjDUdigHwvvQk+gu+8CSw=; b=hWJvQzvBIClxDuACqrm/saCdT2SMTwWfA+GzDofseYFIyz9WKeGjZpHTf0d6jtVXey dG0Z6xgrt6VVr2PWaNBoBfxkKTdxfO8zhvjBhVatNWIACLoWZQXR0BVwSUYsLEeWGevn CVh5BEmqguBgQQZ76FpFE2fhZGA0M9ZqgRk7lVzd4N+O7EyAFiPjMrp1bCLUl0ieVLFC HQDBqtjZymhnPAN8yo792lroled2BmHuwuWzh0pzuAdGGMfKNZoQayD4t2sndLc/wxuE srzqtTDAwU9wZO56P9Ui3bVfaPs2Kpt5cgvS03QsG6bpBK2Fvub4hzOXmhSFjKcF2GBg Dibw== X-Gm-Message-State: AOJu0YwiH8kMvS9qaE8Itbx8XjZNL8NKB1hDykpL4RQ7XJjI9C8kPGuV jrhYTIynFquFdAbz7plFSBVGttvmRMmPqJrV86Mn5sldckYcOXovQoFDLK5G8pVimDuQAejIL+d dbgvfyWjqGs0caS6AZul1KBwWXxTdgdYkhW5J7MIaOpEAwTb/rg3IMRG4WR3DPX83cc9tu1ByOt tyTqmpOJf5TLmc66nySq/ePpJj1xEXd97sIEP/ X-Received: by 2002:a05:6214:2262:b0:68c:a7f6:12b2 with SMTP id gs2-20020a056214226200b0068ca7f612b2mr8478145qvb.8.1707326971470; Wed, 07 Feb 2024 09:29:31 -0800 (PST) X-Google-Smtp-Source: AGHT+IGGpG15WBWqKKvtYlRiteBoK9Dx6R4VuDHtBfInKOOIpd4nphqtxTvaTY/ST4oKiFUZujDfkQ== X-Received: by 2002:a05:6214:2262:b0:68c:a7f6:12b2 with SMTP id gs2-20020a056214226200b0068ca7f612b2mr8478121qvb.8.1707326971165; Wed, 07 Feb 2024 09:29:31 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCWZnE4HguQvbmJYaQImKMKqigCmSd922LpY3kK+8ePFyKvpERtW2QqM9ZLok8bOn7dwtvwRfbPM0AY876btsbXFb7weLCMc7oYmp5+QTydY75WroA== Received: from localhost.localdomain (ool-457670bb.dyn.optonline.net. [69.118.112.187]) by smtp.gmail.com with ESMTPSA id es17-20020a056214193100b0068c7eb9c640sm765641qvb.137.2024.02.07.09.29.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Feb 2024 09:29:30 -0800 (PST) From: Patrick Palka To: gcc-patches@gcc.gnu.org Cc: libstdc++@gcc.gnu.org, jason@redhat.com, Patrick Palka Subject: [PATCH] libstdc++: Work around modules issue causing hello-1 ICE [PR113710] Date: Wed, 7 Feb 2024 12:29:11 -0500 Message-ID: <20240207172911.4173062-1-ppalka@redhat.com> X-Mailer: git-send-email 2.43.0.561.g235986be82 MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-Spam-Status: No, score=-13.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Tested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- The forward declarations of std::get in added in r14-8710-g65b4cba9d6a9ff are causing an ICE in the test modules/hello-1 due to what seems to be a declaration merging issue in modules. What seems to be happening is that in hello-1_b.C we first include , which indirectly includes which forms the dependent specialization tuple_element<__i, tuple<_Elements...>> (appearing in some of the std::get overloads) and adds it to the specializations table. We then import hello which indirectly includes (in the GMF), within which we define a partial specialization of tuple_element with that same template-id. So importing hello in turn streams in this partial specialization, but we don't notice it matches the previously created dependent specialization, and we end up with two equivalent types for this template-id with different TYPE_CANONICAL. This patch works around this issue by adding a forward declaration of the tuple_element partial specialization from to so that it appears alongside the dependent specialization of the same template-id. So when including we immediately register the template-id as a partial specialization, and if we later stream in the partial specialization the MK_partial case of trees_in::key_mergeable will match them up. (So perhaps a proper modules fix for this might be to make key_mergeable try to match up a streamed in partial specialization with an existing specialization from the table via match_mergeable_specialization.) PR c++/113710 libstdc++-v3/ChangeLog: * include/bits/stl_pair.h (tuple_element): Add forward declaration of the partial specialization for tuple. --- libstdc++-v3/include/bits/stl_pair.h | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/libstdc++-v3/include/bits/stl_pair.h b/libstdc++-v3/include/bits/stl_pair.h index 00ec53ebc33..8c71b1350e5 100644 --- a/libstdc++-v3/include/bits/stl_pair.h +++ b/libstdc++-v3/include/bits/stl_pair.h @@ -1153,6 +1153,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION struct tuple_element<1, pair<_Tp1, _Tp2>> { typedef _Tp2 type; }; + // Forward declare the partial specialization for std::tuple + // to work around modules bug PR c++/113710. + template + struct tuple_element<__i, tuple<_Types...>>; + #if __cplusplus >= 201703L template inline constexpr size_t tuple_size_v> = 2;