From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) by sourceware.org (Postfix) with ESMTPS id AA619385E01D for ; Wed, 9 Jun 2021 10:53:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AA619385E01D Received: by mail-ed1-x531.google.com with SMTP id r7so13763233edv.12 for ; Wed, 09 Jun 2021 03:53:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Dp7bQBYYG+Kd5H/43gNTjQBQlZssmVwuHdbNvxblLiY=; b=jD8EFt5dEfNXXcMaMVezAKTpe9hVcd/heDMbYqjPMHdObpWckYymcHqXTqEg/t9WbQ dAASBLAveuvjb4nYyuaXGLhT8P0vPXFg/ryYMr+gQj+zOvrwGVbhyNH5FIDJ9SDKjvs7 cyJ4W1GLWEhSXcA9kv8Adp4t0YsLsMynv5Nd6pc/hotSD6Zo3WeXMBIdioJ7sK5wTDN4 r9K4NSShxExqxGe0IkZzUdKFjCQi34kFIgL4FGY0cJd9hcCwLspC07uzf52zFHMsXL3f d85a3atUHxpdOYty3NGMOIA8cewAQyExZSecZAv9WFd/44qDT16W9AyvPzFUJ9MAxPMJ hW/w== X-Gm-Message-State: AOAM531w+7usnf4kPZFewrxF3zXnmJ0xuyg4xA60GkvOxBqXPITV9f0Y mYgOrHaWiy2+lf0ABr7W9cm440TS0XThKI6EQhX9TWMmb2I= X-Google-Smtp-Source: ABdhPJyyTdT1aMQ3UQI+Ll4UhMz6f8pMc5VDOr6lBFmtE/Ihn3TDgohYVXStm4uZOxCtNzTLiVUltT9stQaZh7C0ECg= X-Received: by 2002:aa7:db49:: with SMTP id n9mr29750047edt.361.1623236012727; Wed, 09 Jun 2021 03:53:32 -0700 (PDT) MIME-Version: 1.0 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> <32470a10-e0b3-c2b5-9d36-58675f74ba56@linux.ibm.com> In-Reply-To: <32470a10-e0b3-c2b5-9d36-58675f74ba56@linux.ibm.com> From: Richard Biener Date: Wed, 9 Jun 2021 12:53:21 +0200 Message-ID: Subject: Re: [PATCH 02/57] Support scanning of build-time GC roots in gengtype To: Bill Schmidt Cc: Bill Schmidt via Gcc-patches Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, 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: Wed, 09 Jun 2021 10:53:35 -0000 On Tue, Jun 8, 2021 at 10:45 PM Bill Schmidt wrote: > > 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? Can't you use PATH_SEPARATOR somehow? See file-find.c / incpath.c or gcc.c for uses and system.h for where it is defined. Richard. > > Bill > > > > > Bill > > > > > >> > >> Richard. > >> > >>> Thanks for your help with this! > >>> > >>> Bill > >>>