[PATCH 02/57] Support scanning of build-time GC roots in gengtype

Bill Schmidt wschmidt@linux.ibm.com
Tue Jun 8 20:45:28 GMT 2021


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 <wschmidt@linux.ibm.com> 
>> 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
>>>


More information about the Gcc-patches mailing list