From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id D7C7E3857C75 for ; Tue, 8 Jun 2021 20:45:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D7C7E3857C75 Received: from pps.filterd (m0098396.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 158KYj9o156292 for ; Tue, 8 Jun 2021 16:45:32 -0400 Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 392fk8remx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 08 Jun 2021 16:45:32 -0400 Received: from m0098396.ppops.net (m0098396.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 158KYpeI156778 for ; Tue, 8 Jun 2021 16:45:32 -0400 Received: from ppma01dal.us.ibm.com (83.d6.3fa9.ip4.static.sl-reverse.com [169.63.214.131]) by mx0a-001b2d01.pphosted.com with ESMTP id 392fk8rem8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 08 Jun 2021 16:45:32 -0400 Received: from pps.filterd (ppma01dal.us.ibm.com [127.0.0.1]) by ppma01dal.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 158KbIkE011330; Tue, 8 Jun 2021 20:45:31 GMT Received: from b03cxnp08025.gho.boulder.ibm.com (b03cxnp08025.gho.boulder.ibm.com [9.17.130.17]) by ppma01dal.us.ibm.com with ESMTP id 3900w9gs5c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 08 Jun 2021 20:45:31 +0000 Received: from b03ledav001.gho.boulder.ibm.com (b03ledav001.gho.boulder.ibm.com [9.17.130.232]) by b03cxnp08025.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 158KjTlq16843114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 8 Jun 2021 20:45:29 GMT Received: from b03ledav001.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B2EF86E053; Tue, 8 Jun 2021 20:45:29 +0000 (GMT) Received: from b03ledav001.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 866066E054; Tue, 8 Jun 2021 20:45:29 +0000 (GMT) Received: from Bills-MacBook-Pro.local (unknown [9.211.74.187]) by b03ledav001.gho.boulder.ibm.com (Postfix) with ESMTP; Tue, 8 Jun 2021 20:45:29 +0000 (GMT) Reply-To: wschmidt@linux.ibm.com Subject: Re: [PATCH 02/57] Support scanning of build-time GC roots in gengtype From: Bill Schmidt To: Richard Biener Cc: Bill Schmidt via Gcc-patches References: <26d623c5117d22fbaea2ce1a445ba2d32df437ad.1619537141.git.wschmidt@linux.ibm.com> <20210520222454.GW10366@gate.crashing.org> <9a9dcf68-cdef-507a-a124-a9229e5c7c0b@linux.ibm.com> <2d0a308c-5e5b-d3a4-3d66-b16245d9c9a4@linux.ibm.com> <22d5bd15-0e1c-0c2c-ccfc-157f3d97277f@linux.ibm.com> Message-ID: <32470a10-e0b3-c2b5-9d36-58675f74ba56@linux.ibm.com> Date: Tue, 8 Jun 2021 15:45:28 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <22d5bd15-0e1c-0c2c-ccfc-157f3d97277f@linux.ibm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-TM-AS-GCONF: 00 X-Proofpoint-GUID: l8GQPcL5jlEkRyBceV_zvS7a1aLVtc3V X-Proofpoint-ORIG-GUID: Ra3MkP9JO6OeqOoMntxcDY9yRRV10xaN X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-06-08_16:2021-06-04, 2021-06-08 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 bulkscore=0 adultscore=0 phishscore=0 impostorscore=0 spamscore=0 malwarescore=0 mlxlogscore=999 lowpriorityscore=0 mlxscore=0 clxscore=1015 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2106080131 X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2021 20:45:36 -0000 On 6/7/21 12:48 PM, Bill Schmidt wrote: > On 6/7/21 12:45 PM, Richard Biener wrote: >> On Mon, Jun 7, 2021 at 5:38 PM Bill Schmidt >> wrote: >>> On 6/7/21 8:36 AM, Richard Biener wrote: >>>> Some maybe obvious issue - what about DOS-style path hosts? >>>> You seem to build ../ strings to point to parent dirs... I'm not sure >>>> what we do elsewhere - I suppose we arrange for appropriate >>>> -I command line arguments? >>>> >>> Well, actually it's just using "./" to identify the build directory, >>> though I see what you mean about potential Linux bias. There is >>> precedent for this syntax identifying the build directory in config.gcc >>> for target macro files: >>> >>> #  tm_file              A list of target macro files, if different from >>> #                       "$cpu_type/$cpu_type.h". Usually it's >>> constructed >>> #                       per target in a way like this: >>> #                       tm_file="${tm_file} dbxelf.h elfos.h >>> ${cpu_type.h}/elf.h" >>> #                       Note that the preferred order is: >>> #                       - specific target header >>> "${cpu_type}/${cpu_type.h}" >>> #                       - generic headers like dbxelf.h elfos.h, etc. >>> #                       - specializing target headers like >>> ${cpu_type.h}/elf.h >>> #                       This helps to keep OS specific stuff out of >>> the CPU >>> #                       defining header ${cpu_type}/${cpu_type.h}. >>> # >>> #                       It is possible to include >>> automatically-generated >>> #                       build-directory files by prefixing them with >>> "./". >>> #                       All other files should relative to >>> $srcdir/config. >>> >>> ...so I thought I would try to be consistent with this change. In patch >>> 0025 I use this as follows: >>> >>> --- a/gcc/config.gcc >>> +++ b/gcc/config.gcc >>> @@ -491,6 +491,7 @@ powerpc*-*-*) >>>           extra_options="${extra_options} g.opt fused-madd.opt >>> rs6000/rs6000-tables.opt" >>>           target_gtfiles="$target_gtfiles >>> \$(srcdir)/config/rs6000/rs6000-logue.c >>> \$(srcdir)/config/rs6000/rs6000-call.c" >>>           target_gtfiles="$target_gtfiles >>> \$(srcdir)/config/rs6000/rs6000-pcrel-opt.c" >>> +       target_gtfiles="$target_gtfiles ./rs6000-builtins.h" >>> ;; >>>    pru-*-*) >>> cpu_type=pru >>> >>> I'm open to trying to do something different if you think that's >>> appropriate. >> Well, I'm not sure whether/how to resolve this.  You could try >> building a cross to powerpc-linux from a x86_64-mingw host ... >> maybe there's one on the CF?  Or some of your fellow RedHat >> people have access to mingw or the like envs to try whether it >> just works with your change ... >> >> Otherwise it looks OK. > > I'll see what I can find.  Thanks again for reviewing the patch! Hm.  Ultimately, I think the cross compiler case is doomed unless mingw already handles converting forward slashes to back slashes. There's no single syntax that works on both Windows and Linux. (There's no mingw server in the compile farm to play with.) I'm inclined to accept both "./" and ".\" for native builds, and kick the can down the road beyond that.  What do you think? Bill > > Bill > > >> >> Richard. >> >>> Thanks for your help with this! >>> >>> Bill >>>