On Sat, Mar 02, 2019 at 03:40:48PM +1100, Finn Thain wrote:
On Fri, 1 Mar 2019, Guenter Roeck wrote:
Another possible fix might be to write a 'static inline int strncmp()'
function for non-coldfire code.
This build failure and some possible fixes have been discussed before...
https://lore.kernel.org/lkml/28ebe45d-3dbd-2a82-f537-b0725f7a2bcf@xxxxxxxxxxxxx/
https://marc.info/?l=linux-m68k&m=153791317509016&w=2
https://marc.info/?l=linux-m68k&m=154591539929923&w=2
https://marc.info/?l=linux-m68k&m=154762988212234&w=2
https://lore.kernel.org/lkml/?q=3ba14e34f666486b5e77253a82dfde882a505e23.1547616204.git.fthain
The reason I sent that patch is that I want the compiler to just do code
generation and not pretend that it is doing program transformation.
If we use static analysis and semantic patching for actual program
transformation then users of any compiler and architecture can benefit.
That would not work in the observed case, or I would have submitted
a patch to do just that. The strncmp() is against a configuration symbol
and can not always be replaced with strcmp(). Providing strncmp()
explicitly as static inline would serve the same purpose, ie it would
also prevent the compiler from trying to do anything fancy.
Never mind, who am I to argue. Thanks for the information.
Guenter
