"Hu, Jiangping" <hujiangp...@cn.fujitsu.com> writes: >> If there isn't anywhere that handles zero in the way that the documentation >> implies (i.e. with -falign-loops=0 being equivalent to -falign-loops) then >> maybe >> we should instead change the documentation to match the actual behaviour. >> > Yes, I confirmed in source level that there is no target that handles > zero in the way that the documentation implies.
OK. > But, I think just adjusting the documentation to reflect the > implementation behavior will cause -falign-functions=0 and > -falign-functions=1 to have the same meaning which is a bit confusing > from the user's perspective. Yeah, it isn't great. On the other hand, it seems more natural for -falign-functions=0 to be the same as -fno-align-functions than it is for -falign-functions=1 to be the same as -fno-align-functions. > In fact, I have issued a pr to Bugzilla, and got a comment from > Richard Biener. We are considering whether to reject 0, which means > both the source and the documentation should be modified a bit. Yeah, only saw that PR today, sorry. Got a lot of email to catch up on :-) > I found that function parse_and_check_align_values in gcc/opts.c maybe > the point we want to modify, values less than 0 are currently rejected > here. Maybe we can change the '<’ to '<=' in the if statement. But I > need test, to make sure there are no regression issues. > > What do you think? Either's fine with me. I guess treating =0 the same as =1 is less likely to break existing Makefiles. E.g. the usual practice has been to keep old options that no longer have an effect, rather than dropping them and turning them into errors. On the other hand, people trying to use -falign-functions=0 for the first time might prefer an error instead of unexpected behaviour. I guess yet another option would be to handle -falign-functions=0 like -falign-functions in common_handle_option (i.e. set the x_str_align_functions to null and x_align_functions to true.) Thanks, Richard
