On Mon, 29 Mar 2021, H.J. Lu wrote:
> On Mon, Mar 29, 2021 at 2:38 AM Richard Biener wrote:
> >
> > On Mon, 29 Mar 2021, Jiri Slaby wrote:
> >
> > > Any ideas on this?
> > >
> > > On 11. 01. 21, 7:31, Jiri Slaby wrote:
> > > > Hi,
ry - the one that will be used on
> > the second call (and on). This is used / emitted for ELF object
> > instrumented for Intel CET. The details escape me for the moment but I hope
> > the x86 ABI documents this (and the constraints) in detail.
I just checked and the x86_64 psABI doesn't say anything about .plt.sec
> > ==
> >
> > How should perf find out whether to consider .plt or .plt.sec? Or generally,
> > how to properly find an address of *@plt symbols like memcmp@plt above?
> > thanks,
>
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
result (ie
> inlinging things that were behind an "if (unlikely())" test, and
> causing the likely path to grow a stack fram and stack spills as a
> result).
>
> So just "O3 inlines more" is not a valid argument.
>
> Linus
>
--
Richard Biener
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
ne on earlier kernels though.
I've put a statically linked executable at
http://www.suse.de/~rguenther/memmove-1.exe (needs some time to sync
to the public webserver still).
Thanks,
Richard.
--
Richard Biener
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB
21284 (AG
On Wed, 10 Oct 2018, Nadav Amit wrote:
> at 7:53 AM, Segher Boessenkool wrote:
>
> > On Mon, Oct 08, 2018 at 11:07:46AM +0200, Richard Biener wrote:
> >> On Mon, 8 Oct 2018, Segher Boessenkool wrote:
> >>> On Sun, Oct 07, 2018 at 03:53:26PM +, Michael Matz
On Wed, 2 Nov 2016, Markus Trippelsdorf wrote:
> On 2016.10.19 at 12:25 +0200, Peter Zijlstra wrote:
> > On Wed, Oct 19, 2016 at 11:33:41AM +0200, Richard Biener wrote:
> > > On Wed, 19 Oct 2016, Peter Zijlstra wrote:
> >
> > > > This is also an entirely diffe
On Wed, 19 Oct 2016, Peter Zijlstra wrote:
> On Wed, Oct 19, 2016 at 11:33:41AM +0200, Richard Biener wrote:
> > On Wed, 19 Oct 2016, Peter Zijlstra wrote:
>
> > > This is also an entirely different class of optimizations than the whole
> > > pointer arithmetic
out the kernel usage. Looking
at GCC bug 77964 it is declaring
extern struct builtin_fw __start_builtin_fw[];
extern struct builtin_fw __end_builtin_fw[];
which are extern zero-sized arrays. I suppose they are nowhere
actually defined but these symbols are created by the linker script only.
I can thin
On Wed, 19 Oct 2016, Peter Zijlstra wrote:
> On Wed, Oct 19, 2016 at 10:18:43AM +0200, Richard Biener wrote:
>
> > The commit implements a long-standing failure to optimize trivial pointer
> > comparisons that arise for example from libstdc++. PR65686 contains
>
On Wed, May 20, 2015 at 9:34 AM, Jens Maurer wrote:
> On 05/20/2015 04:34 AM, Paul E. McKenney wrote:
>> On Tue, May 19, 2015 at 06:57:02PM -0700, Linus Torvalds wrote:
>
>>> - the "you can add/subtract integral values" still opens you up to
>>> language lawyers claiming "(char *)ptr - (intptr_t)
On June 10, 2014 8:04:13 PM CEST, Steven Noonan wrote:
>On Tue, Jun 10, 2014 at 10:46 AM, Linus Torvalds
> wrote:
>> On Tue, Jun 10, 2014 at 6:23 AM, Jiri Kosina wrote:
>>> We have been chasing a memory corruption bug, which turned out to be
>>> caused by very old gcc (4.3.4), which happily turne
On Mon, Feb 24, 2014 at 4:57 PM, Linus Torvalds
wrote:
> On Sun, Feb 23, 2014 at 11:31 AM, Linus Torvalds
> wrote:
>>
>> Let me think about it some more, but my gut feel is that just tweaking
>> the definition of what "ordered" means is sufficient.
>>
>> So to go back to the suggested ordering ru
On February 17, 2014 7:18:15 PM GMT+01:00, "Paul E. McKenney"
wrote:
>On Wed, Feb 12, 2014 at 07:12:05PM +0100, Peter Zijlstra wrote:
>> On Wed, Feb 12, 2014 at 09:42:09AM -0800, Paul E. McKenney wrote:
>> > You need volatile semantics to force the compiler to ignore any
>proofs
>> > it might oth
13 matches
Mail list logo
