On 11/28/2016 07:57 PM, Martin Sebor wrote:
PR 78512 - r242674 miscompiles Linux kernel observes that the Linux
kernel fails to boot as a result of enabling the -fprintf-return-value
optimization in GCC.  This is likely because the kernel has its own
sprintf with a large set of extensions to the %p directive that
conflict with the optimization.  Ordinarily, programs that define
their own versions of C library functions that differ from what C
specifies are expected to disable GCC's built-ins (e.g., by
-fno-builtin, or for freestanding environments like the Linux kernel,
by -ffreestanding).  But the Linux kernel doesn't do that and hence
the conflict.

After discussing a few possible options (handling the kernel extensions
in GCC, providing a new GCC option to disable the %p handling, and
disabling both the optimization and the warning for calls involving
the %p directive, the last was viewed as the best alternative).  The
attached patch removes the %p handling from GCC.
And just to give a little more information here.

The fundamental issue is that %p handling is implementation defined and the implementations can (of course) change over time. Handling of %p essentially turns into coding GCC to an implementation rather than a real specification.

The details of those implementations would have to be baked into GCC itself. That wasn't terrible when we were just trying to support the rather limited cases found in glibc, uClibc, aix & solaris. But when we add the linux kernel and its extensions into the mix, it didn't seem wise to continue bake that knowledge into GCC. The need to support multiple %p implementations from a single compiler just makes things even worse.

After deliberating those issues, Jakub, Martin and myself ultimately decided that supporting %p for warnings and optimization was unwise.

It's unfortunate because the kernel makes extensive use of %p. I guess one could create a plug-in to check %p for the kernel if they wanted to take advantage of the checking capabilities.

Approved for the trunk.

Thanks,

jeff

Reply via email to