On Mon, 11 Nov 2019, Vineet Gupta wrote: > Functionally it should not result in code gen changes and if at all > those would be better since the scope of those temporaries is greatly > reduced now This feels like the sort of thing where "should not result in code gen changes" should be tested by running build-many-glibcs.py --strip with unmodified glibc sources to build a full set of stripped glibc binaries, saving those binaries and then running build-many-glibcs.py --strip again and comparing the two sets of shared libraries (something I did a lot of when reworking how libm function aliases were defined; static libraries are expected to change because of timestamps, but shared library binaries can be usefully compared like this). If the two sets of stripped binaries are indeed identical, that is strong evidence that the patch is safe; otherwise, review of the patch will require more detailed inspection of the types of the arguments to these macros, and the uses of the temporary variables, at every call site, to make sure that semantics aren't being changed. (In any case, please specify when submitting a patch how it was tested.) -- Joseph S. Myers joseph@xxxxxxxxxxxxxxxx _______________________________________________ linux-snps-arc mailing list linux-snps-arc@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/linux-snps-arc
