ot of with
this issue :-(, google gives a lot of hits on the issue but it is a bit
hard to get the current impl. status for 3.4. Which in turn makes it
hard to decide on how to bandage our foot.
Kind regards,
Peter Zijlstra
On Mon, 2005-08-15 at 06:12 -0700, Dan Kegel wrote:
> Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> > On this controversial subject, could somebody please - pretty please
> > with a cherry on top - tell me what the current status is:
> > - in general,
> > - as
On Mon, 2005-08-15 at 09:33 -0400, Andrew Pinski wrote:
> >
> > Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> > > On this controversial subject, could somebody please - pretty please
> > > with a cherry on top - tell me what the current status is:
> > >
ack of exception information set in:
glibc-2.3.5/nptl/unwind.c:__pthread_unwind()
Hence once is left in the situation where both forward and backward are
not an option.
Nor do I think they (being the company I work for) will allow me to ship
patched versions of libpthread.so and libstdc++.so.5.
Too bad, guess I have to redesign the issue.
Peter Zijlstra
for exception model to use... configure: error: unable to
detect exception model
make[1]: *** [configure-target-libstdc++-v3] Error 1
make[1]: Leaving directory `/usr/local/src/gcc-4.0-20051117/build'
make: *** [bootstrap] Error 2
I'm sure I'm doing something horribly wrong her
On Tue, Apr 28, 2020 at 02:41:33PM +0100, Andrew Cooper wrote:
> Its fine to focus on userspace first, but the kernel is far more simple.
>
> Looking at that presentation, the only thing missing for kernel is the
> notrack thunks, in the unlikely case that such code would be tolerated
> (Frankly,
+ lots of people and linux-toolchains
On Wed, Nov 04, 2020 at 07:31:42PM +0100, Uros Bizjak wrote:
> Hello!
>
> I was looking at the recent linux patch series [1] where segment
> qualifiers (named address spaces) were introduced to handle percpu
> variables. In the patch [2], the author mention
On Mon, Nov 09, 2020 at 01:38:51PM -0600, Segher Boessenkool wrote:
> On Mon, Nov 09, 2020 at 01:47:13PM +0100, Peter Zijlstra wrote:
> >
> > + lots of people and linux-toolchains
> >
> > On Wed, Nov 04, 2020 at 07:31:42PM +0100, Uros Bizjak wrote:
> > > Hell
On Mon, Nov 09, 2020 at 11:50:15AM -0800, Nick Desaulniers wrote:
> On Mon, Nov 9, 2020 at 11:46 AM Segher Boessenkool
> wrote:
> >
> > On Mon, Nov 09, 2020 at 01:47:13PM +0100, Peter Zijlstra wrote:
> > >
> > > + lots of people and linux-toolchains
> >
On Tue, Nov 10, 2020 at 10:42:58AM -0800, Nick Desaulniers wrote:
> When I think of qualifiers, I think of const and volatile. I'm not
> sure why the first post I'm cc'ed on talks about "segment" qualifiers.
> Maybe it's in reference to a variable attribute that the kernel
> defines? Looking at
fiers. The syntax as proposed above seems
very error prone to me.
---
Subject: compiler: Improve __unqual_typeof()
Improve our __unqual_scalar_typeof() implementation by relying on C
dropping qualifiers for lvalue convesions. There is one small catch in
that GCC is currently known broken in this re
On Mon, Nov 16, 2020 at 12:10:56PM +0100, Peter Zijlstra wrote:
> > > Another way to drop qualifiers is using a cast. So you
> > > can use typeof twice:
> > >
> > > typeof((typeof(_var))_var) tmp__;
> > >
> > > This also works for non-scal
On Mon, Nov 16, 2020 at 12:23:17PM +, Uecker, Martin wrote:
> > > > Another way to drop qualifiers is using a cast. So you
> > > > can use typeof twice:
> > > >
> > > > typeof((typeof(_var))_var) tmp__;
> > > >
> > > > This also works for non-scalars but this is a GCC extension.
>
> (That c
On Tue, Jun 10, 2014 at 03:23:36PM +0200, Jiri Kosina wrote:
> +# Tell gcc to never replace conditional load with a non-conditional one
> +KBUILD_CFLAGS+= $(call cc-option,--param allow-store-data-races=0)
> +
Why do we not want: -fmemory-model=safe? And should we not at the very
least als
On Tue, Jun 10, 2014 at 05:04:55PM +0200, Marek Polacek wrote:
> On Tue, Jun 10, 2014 at 04:53:27PM +0200, Peter Zijlstra wrote:
> > On Tue, Jun 10, 2014 at 03:23:36PM +0200, Jiri Kosina wrote:
> > > +# Tell gcc to never replace conditional load with a non-conditional one
&g
On Wed, 2009-11-25 at 20:38 +0100, Richard Guenther wrote:
> If you can offer advice on how to teach quilt
> (which I belive uses patch) to ignore whitespace changes when
> applying patches then more power to you
QUILT_PATCH_OPTS="-l"
On Tue, Apr 05, 2022 at 01:51:30PM +0100, Mark Rutland wrote:
> Hi all,
>
> [adding kernel folk who work on asm stuff]
>
> As a heads-up, GCC 12 (not yet released) appears to erroneously optimize away
> calls to functions with volatile asm. Szabolcs has raised an issue on the GCC
> bugzilla:
>
On Mon, Jul 03, 2023 at 03:20:31PM -0400, Olivier Dion wrote:
> int x = 0;
> int y = 0;
> int r0, r1;
>
> int dummy;
>
> void t0(void)
> {
> __atomic_store_n(&x, 1, __ATOMIC_RELAXED);
>
> __atomic_exchange_n(&dummy, 1, __ATOMIC_SEQ_CST);
> __atomic_thre
On Fri, Jul 07, 2023 at 10:04:06AM -0400, Olivier Dion wrote:
> On Tue, 04 Jul 2023, Peter Zijlstra wrote:
> > On Mon, Jul 03, 2023 at 03:20:31PM -0400, Olivier Dion wrote:
> [...]
> >> On x86-64 (gcc 13.1 -O2) we get:
> >>
> >> t0():
> >>
On Mon, Aug 05, 2013 at 12:55:15PM -0400, Steven Rostedt wrote:
> [ sent to both Linux kernel mailing list and to gcc list ]
>
Let me hijack this thread for something related...
I've been wanting to 'abuse' static_key/asm-goto to sort-of JIT
if-forest functions like perf_prepare_sample() and per
On Mon, Aug 12, 2013 at 07:56:10AM -0700, H. Peter Anvin wrote:
> On 08/12/2013 02:17 AM, Peter Zijlstra wrote:
> >
> > I've been wanting to 'abuse' static_key/asm-goto to sort-of JIT
> > if-forest functions like perf_prepare_sample() and perf_output_sam
On Mon, Aug 12, 2013 at 09:02:02AM -0700, Andi Kleen wrote:
> "H. Peter Anvin" writes:
>
> > However, I would really like to
> > understand what the value is.
>
> Probably very little. When I last looked at it, the main overhead in
> perf currently seems to be backtraces and the ring buffer, not
On Mon, Aug 12, 2013 at 10:47:37AM -0700, H. Peter Anvin wrote:
> On 08/12/2013 09:09 AM, Peter Zijlstra wrote:
> >>
> >> On the majority of architectures, including x86, you cannot simply copy
> >> a piece of code elsewhere and have it still work.
> >
>
On Thu, Feb 06, 2014 at 08:20:51PM -0800, Paul E. McKenney wrote:
> Hopefully some discussion of out-of-thin-air values as well.
Yes, absolutely shoot store speculation in the head already. Then drive
a wooden stake through its hart.
C11/C++11 should not be allowed to claim itself a memory model
On Fri, Feb 07, 2014 at 05:13:36PM +, Will Deacon wrote:
> Understood, but that doesn't explain why Paul wants to add ISB/isync
> instructions which affect the *CPU* rather than the compiler!
I doubt Paul wants it, but yeah, I'm curious about that proposal as
well, sounds like someone took a b
On Fri, Feb 07, 2014 at 04:55:48PM +, Will Deacon wrote:
> Hi Paul,
>
> On Fri, Feb 07, 2014 at 04:50:28PM +, Paul E. McKenney wrote:
> > On Fri, Feb 07, 2014 at 08:44:05AM +0100, Peter Zijlstra wrote:
> > > On Thu, Feb 06, 2014 at 08:20:51PM -0800
On Mon, Feb 10, 2014 at 01:27:51AM +0100, Torvald Riegel wrote:
> > Initial state: x == y == 0
> >
> > T1: r1 = atomic_load_explicit(x, memory_order_relaxed);
> > atomic_store_explicit(42, y, memory_order_relaxed);
> > if (r1 != 42)
> > atomic_store_explicit(r1, y, memory_order
On Fri, Feb 07, 2014 at 10:02:16AM -0800, Paul E. McKenney wrote:
> As near as I can tell, compiler writers hate the idea of prohibiting
> speculative-store optimizations because it requires them to introduce
> both control and data dependency tracking into their compilers. Many of
> them seem to
On Mon, Feb 10, 2014 at 11:49:29AM +, Will Deacon wrote:
> On Mon, Feb 10, 2014 at 11:48:13AM +0000, Peter Zijlstra wrote:
> > On Fri, Feb 07, 2014 at 10:02:16AM -0800, Paul E. McKenney wrote:
> > > As near as I can tell, compiler writers hate the idea of prohibiting
>
> I don't know the specifics of your example, but from how I understand
> it, I don't see a problem if the compiler can prove that the store will
> always happen.
>
> To be more specific, if the compiler can prove that the store will
> happen anyway, and the region of code can be assumed to always
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 otherwise attempt to construct. Hence all the ACCESS_ONCE()
> calls in my email to Torvald. (Hopefully I translated your example
> reasonably.)
My
On Thu, Feb 13, 2014 at 09:07:55PM -0800, Torvald Riegel wrote:
> That depends on what your goal is.
A compiler that we don't need to fight in order to generate sane code
would be nice. But as Linus said; we can continue to ignore you lot and
go on as we've done.
On Tue, Feb 18, 2014 at 12:12:06PM +, Peter Sewell wrote:
> Several of you have said that the standard and compiler should not
> permit speculative writes of atomics, or (effectively) that the
> compiler should preserve dependencies.
The example below only deals with control dependencies; so I
On Tue, Feb 18, 2014 at 10:21:56PM +0100, Torvald Riegel wrote:
> Well, that's how atomics that aren't volatile are defined in the
> standard. I can see that you want something else too, but that doesn't
> mean that the other thing is broken.
Well that other thing depends on being able to see the
On Tue, Feb 18, 2014 at 10:21:56PM +0100, Torvald Riegel wrote:
> Yes, I do. But that seems to be "volatile" territory. It crosses the
> boundaries of the abstract machine, and thus is input/output. Which
> fraction of your atomic accesses can read values produced by hardware?
> I would still su
> > 4. Some drivers allow user-mode code to mmap() some of their
> > state. Any changes undertaken by the user-mode code would
> > be invisible to the compiler.
>
> A good point, but a compiler that doesn't try to (incorrectly) assume
> something about the semantics of mmap will simply s
On Wed, Feb 19, 2014 at 12:07:02PM +0100, Torvald Riegel wrote:
> > Its not only hardware; also the kernel/user boundary has this same
> > problem. We cannot a-priory say what userspace will do; in fact, because
> > we're a general purpose OS, we must assume it will willfully try its
> > bestest to
37 matches
Mail list logo
