On 11/11/19 2:33 PM, Joseph Myers wrote: > 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. Ok Understand. What arch(es) / build options would you want this tested for in aforementioned way to get a reasonable confidence ? > (In any case, please specify when submitting a patch how it was tested.) I've currently tested this with build-many-glibcs.py for ARC port only with and w/o hard float support being worked on. _______________________________________________ linux-snps-arc mailing list linux-snps-arc@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/linux-snps-arc
