[Patch] Add 'default' to -foffload=; document that flag [PR67300]

Sandra Loosemore sandra@codesourcery.com
Thu Jun 17 21:57:58 GMT 2021

On 6/17/21 1:40 PM, Jakub Jelinek wrote:
> On Thu, Jun 17, 2021 at 09:28:00PM +0200, Tobias Burnus wrote:
>> I am not sure whether I fully agree with this or not. However:
>> Let's propose something radical, which probably won't break any real-world
>> code, avoids the need to add a new -foffload=<something> keyword and is
>> also intuitive to the user:
>> * -foffload=<target triplet list>=-option
>> Suggestion: This no longer affects the list of enabled targets. As by default
>> all targets are enabled, this one will (kept) be(en) enabled (but might
>> silently fail if the target lto1 is not installed).
>> * -foffload=disable  and -foffload=<triplet-list>
>> This is the only way to modify the list of supported offload devices to those
>> specified. By adding a triplet explicitly, it will give an error via lto1.
>> That will solve all issues, possibly except for
>>    -foffload=-lm -foffload=nxpt-none=-latomic -foffload=amdgcn-amdhsa
>> some might find it surprising that nvptx offloading will be disabled,
>> but others might find it natural.
> Could we introduce a different option which wouldn't imply enabling that
> target:
> -foffload-options=<target triplet list>=option
> and make
> -foffload=<target triplet list>=option
> imply (expand in the driver)
> -foffload-options=<target triplet list>=option -foffload=<target triplet list>
> ?
> That would be mostly backwards compatible, but would allow users to specify options
> separately from the enabled target list.
> The <target triplet list> in the above cases couldn't include disable or
> default, but the -foffload=<target triplet list> case could, and disable
> (either in the list or separately) would simply disable all targets (even
> those enabled earlier), while default would reset the list to the default
> (basically cancel all previous non-options -foffload= options).
> And the -foffload-options= would accumulate in the order given on the
> command line.

I don't feel qualified to comment on the details of the behavior, but 
separating the options and making them more orthogonal to one another 
would certainly make things easier to document.  :-)

One other thing I'd like to see in the docs is how to ask GCC what 
offload targets it is configured to support by default.  This could be 
put in a paragraph that also includes the language about how you need to 
have the compilers for those offload targets installed too.


More information about the Gcc-patches mailing list