RFC: Should the linker support '--fast' and if so, what should it do ?

[Jan Beulich]

On 01.04.2026 12:32, Nick Clifton wrote:
>>>     Attached is a proposed patch to implement "-O 0" as a command line option
>>>     that disables merging.
> 
>> I'm not entirely happy with forcing people to change the -O uses they may have.
>> But perhaps that's tolerable. A possible alternative might be to support -O- to
>> have the effect of setting optimize_level to 0, while -O <number> would set it
>> to <number>+1. Yet of course -O0 has widely known meaning ...
>>
>> I'm also uncertain as to the two "high cost" optimizations that you now move to
>> -O2. Are they really high cost?
>>
>> The doc change may want to be a little less ELF-centric. Inserting "e.g." may
>> already suffice to address that.
>>
>> --help output could do with also stating the default.
>>
>> Perhaps not for this patch, but the handling of -O could also do with some
>> improvement. "-O --help", for example, better wouldn't do what it does now.
> 
> Actually these are all good ideas.  So here is a version 2 patch.
> 
> It does not change the linker's use of -O <N> where N is a positive integer
> greater than zero.  But is does add "-O 0" to disable merging and "-O -" to
> restore the linker's default behaviour.  (I doubt that this will ever be used
> but it is always best to have a means of restoring the default).  In addition
> "-O <text>" will now trigger an error from the linker.
> 
> What do you think ?

Looks largely good. Maybe take Andreas' suggestion and support "default"
alongside "-"? Plus there's one other quirk as it looks: -O00 or -O0x0
will now be rejected as it looks, despite the option values clearly
being "numerical" (as the diagnostic demands). I think you better
wouldn't look at optarg[0] again in that check for 0. (Also e.g. -O1xyz
would still be accepted as valid. Properly rejecting all invalid forms
will make it easier to later assign meaning further forms of arguments.)

Jan