On Wed, 1 Aug 2018, Martin Sebor wrote: > Richard, do you have any further comments or suggestions or is > the patch acceptable? > > I realize it's not ideal but I don't see how to achieve the ideal > (understanding PTRDIFF_MAX) without deferring the processing of > these options until the back end has been initialized. It would > still mean setting aside some special value, traversing options > again, looking for the Host_Wide_Int ones with the special value, > and replacing it with the value of PTRDIFF_MAX. That doesn't seem > any cleaner than the current solution, just a lot more work (not > just to implement but for the compiler to go through at startup). > > Joseph, can you think of anything better? > > https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01455.html
I think the cleanest option for accepting symbolic values would require options accepting such a value in addition to numeric arguments to have additional data allocated (effectively storing both a numeric argument and an Enum argument), and then the late initialization as noted to set the numeric value based on the Enum argument if one was given. As noted, that's significant extra complexity. -- Joseph S. Myers jos...@codesourcery.com
