From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 3C1C53858C83 for ; Wed, 22 Feb 2023 09:25:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3C1C53858C83 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1677057910; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type; bh=zybwiAzf+pS8VAG1E4KJKAg3QPpXGx5qwQeRLuQ3nww=; b=EehnH2akLMhmEl3Qj3zLboZ1T1yxDi6qEZjL/RdpImo2stj7C7eYACk1/oa3sFvGR5TDP5 GTJ6bxUgz7xuZ0tbytdghSlRYBVOlGBpIv5vlbZUw+n6+T425HBdgFfEtOSN8OOms/C3Xe okht4rpov47J43NpRbigBsoABOyJfMA= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-436-lcPNwHcKPZqF1WniFDvkyg-1; Wed, 22 Feb 2023 04:25:08 -0500 X-MC-Unique: lcPNwHcKPZqF1WniFDvkyg-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 62E971C05AC5; Wed, 22 Feb 2023 09:25:08 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.62]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 21FBF40B4138; Wed, 22 Feb 2023 09:25:08 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 31M9P5tl4178363 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 22 Feb 2023 10:25:06 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 31M9P5Ja4178362; Wed, 22 Feb 2023 10:25:05 +0100 Date: Wed, 22 Feb 2023 10:25:04 +0100 From: Jakub Jelinek To: Jonathan Yong <10walls@gmail.com> Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] cygwin: Don't try to support multilibs [PR107998] Message-ID: Reply-To: Jakub Jelinek MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP 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: Hi! As discussed in the PR, t-cygwin-w64 file has been introduced in 2013 and has one important problem, two different multilib options -m64 and -m32, but MULTILIB_DIRNAMES with just one word in it. Before the genmultilib sanity checking was added, my understanding is that this essentially resulted in effective --disable-multilib, $ gcc -print-multi-lib .; ;@m32 $ gcc -print-multi-directory . $ gcc -print-multi-directory -m64 . $ gcc -print-multi-directory -m32 $ gcc -print-multi-os-directory ../lib $ gcc -print-multi-os-directory -m64 ../lib $ gcc -print-multi-os-directory -m32 ../lib32 and because of the way e.g. config-ml.in operates multidirs= for i in `${CC-gcc} --print-multi-lib 2>/dev/null`; do dir=`echo $i | sed -e 's/;.*$//'` if [ "${dir}" = "." ]; then true else if [ -z "${multidirs}" ]; then multidirs="${dir}" else multidirs="${multidirs} ${dir}" fi fi done dir was . first time (and so nothing was done) and empty second time, multidirs empty too, so multidirs was set to empty like it would be with --disable-multilib. With the added sanity checking the build fails unless --disable-multilib is used in configure (dunno whether people usually configure that way on cygwin). >From what has been said in the PR, multilibs were not meant to be supported and e.g. cygwin headers probably aren't ready for it. So the following patch just removes the file with the (incorrect) multilib stuff instead of fixing it (say by setting MULTILIB_DIRNAMES to 64 32). I have no way to test this though, no Windows around, can anyone please test this? I just would like to get some progress on the P1s we have... 2023-02-22 Jakub Jelinek PR target/107998 * config.gcc (x86_64-*-cygwin*): Don't add i386/t-cygwin-w64 into $tmake_file. * config/i386/t-cygwin-w64: Remove. --- gcc/config.gcc.jj 2023-02-18 12:38:30.803025062 +0100 +++ gcc/config.gcc 2023-02-21 17:07:12.143164563 +0100 @@ -2105,7 +2105,7 @@ x86_64-*-cygwin*) need_64bit_isa=yes tm_file="${tm_file} i386/unix.h i386/bsd.h i386/gas.h i386/cygming.h i386/cygwin.h i386/cygwin-w64.h i386/cygwin-stdint.h" xm_file=i386/xm-cygwin.h - tmake_file="${tmake_file} i386/t-cygming t-slibgcc i386/t-cygwin-w64" + tmake_file="${tmake_file} i386/t-cygming t-slibgcc" target_gtfiles="$target_gtfiles \$(srcdir)/config/i386/winnt.cc" extra_options="${extra_options} i386/cygming.opt i386/cygwin.opt" extra_objs="${extra_objs} winnt.o winnt-stubs.o" --- gcc/config/i386/t-cygwin-w64.jj 2020-01-12 11:54:36.333414616 +0100 +++ gcc/config/i386/t-cygwin-w64 2023-02-21 17:06:44.121572616 +0100 @@ -1,3 +0,0 @@ -MULTILIB_OPTIONS = m64/m32 -MULTILIB_DIRNAMES = 64 -MULTILIB_OSDIRNAMES = ../lib ../lib32 Jakub