John Reiser wrote:
Right. However, specifying the flag -fno-builtin-memcpy at compilation
disables gcc inlining of memcpy
But not glibc's.
You need -D__NO_STRING_INLINES too. (That said, the most aggressive inlining
is disabled by default and only enabled if you use -D__USE_STRING_INLINES.)
On 11/29/2010 05:29 PM, Matt McCutchen wrote:
Still, you could split the patch into one that just adds
commented curly braces to existing code and a second with the
substantive changes, which would be easier for anyone interested to
review.
Good idea. I revised the web page. Here is the
John Reiser wrote:
This patch (with .rpms for x86_64 and i686) enables glibc optionally
to detect, diagnose, and work around overlap in memcpy/mempcpy:
http://bitwagon.com/glibc-memlap/glibc-memlap.html
The option to check is controlled by an environment variable
MEMCPY_CHECK_ which
On 11/28/2010 03:36 PM, Nicholas Miell wrote:
On 11/28/2010 03:13 PM, John Reiser wrote:
The option to check is controlled by an environment variable
MEMCPY_CHECK_ which influences choices made by __init_cpu_features
and the STT_GNU_IFUNC mechanism for choosing alternate implementations
at
On 11/29/2010 01:46 PM, Kevin Kofler wrote:
John Reiser wrote:
This patch (with .rpms for x86_64 and i686) enables glibc optionally
to detect, diagnose, and work around overlap in memcpy/mempcpy:
http://bitwagon.com/glibc-memlap/glibc-memlap.html
The option to check is controlled by an
On Sun, 2010-11-28 at 15:13 -0800, John Reiser wrote:
This patch (with .rpms for x86_64 and i686) enables glibc optionally
to detect, diagnose, and work around overlap in memcpy/mempcpy:
http://bitwagon.com/glibc-memlap/glibc-memlap.html
What is the mass addition of commented curly braces
On Mon, Nov 29, 2010 at 6:35 PM, John Reiser jrei...@bitwagon.com wrote:
While the details of inlining are subject
to change, copying in ascending address order is the order that is
assumed by all violators of the no-overlap requirement.
All violators? Citation needed.
I'm sure lurking
On 11/29/2010 03:44 PM, Matt McCutchen wrote:
On Sun, 2010-11-28 at 15:13 -0800, John Reiser wrote:
This patch (with .rpms for x86_64 and i686) enables glibc optionally
to detect, diagnose, and work around overlap in memcpy/mempcpy:
http://bitwagon.com/glibc-memlap/glibc-memlap.html
On Mon, 2010-11-29 at 16:08 -0800, John Reiser wrote:
On 11/29/2010 03:44 PM, Matt McCutchen wrote:
What is the mass addition of commented curly braces for? It is
distracting from the substance of the patch.
Those comments enable parenthesis matching in some text editors.
The scoping of
This patch (with .rpms for x86_64 and i686) enables glibc optionally
to detect, diagnose, and work around overlap in memcpy/mempcpy:
http://bitwagon.com/glibc-memlap/glibc-memlap.html
The option to check is controlled by an environment variable
MEMCPY_CHECK_ which influences choices made by
On 11/28/2010 03:13 PM, John Reiser wrote:
The option to check is controlled by an environment variable
MEMCPY_CHECK_ which influences choices made by __init_cpu_features
and the STT_GNU_IFUNC mechanism for choosing alternate implementations
at runtime.
If you're going to control it via an
11 matches
Mail list logo
