linux-toolchains.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andi Kleen <ak@linux.intel.com>
To: Florian Weimer <fweimer@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	linux-kernel@vger.kernel.org, Andi Kleen <andi@firstfloor.org>,
	linux-toolchains@vger.kernel.org
Subject: Re: [PATCH] sched: Work around undefined behavior in sched class checking
Date: Wed, 5 May 2021 07:39:16 -0700	[thread overview]
Message-ID: <20210505143916.GS4032392@tassilo.jf.intel.com> (raw)
In-Reply-To: <875yzxh8j8.fsf@oldenburg.str.redhat.com>

> Context:
> 
>   <https://lore.kernel.org/lkml/20210505033945.1282851-1-ak@linux.intel.com/>
> 
> Obviously, GCC doesn't do this in general. 

We've seen it in other cases before, that's why RELOC_HIDE exists.
A classic case was __pa_symbol()

That dates back nearly two decades at this point.

>  Would you please provide a
> minimal test case?

You can only reproduce it with a LTO build because it needs knowledge
between different translation units for this specific case.

But gcc will totally do the optimization even without LTO if it can
prove the same inside a single TU.

If you want to reproduce it you can use my tree here
git://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-misc lto-5.12-3
and revert the fix. The kernel will not boot.

-Andi

  parent reply	other threads:[~2021-05-05 14:39 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20210505033945.1282851-1-ak@linux.intel.com>
2021-05-05  6:46 ` [PATCH] sched: Work around undefined behavior in sched class checking Peter Zijlstra
2021-05-05  8:47   ` Florian Weimer
2021-05-05  9:04     ` Peter Zijlstra
2021-05-05 14:39     ` Andi Kleen [this message]
2021-05-05 16:41       ` Nick Desaulniers
2021-05-05 16:48         ` Andi Kleen
2021-05-05 17:08           ` Nick Desaulniers
2021-05-05 17:20             ` Andi Kleen
2021-05-05 14:34   ` Andi Kleen
2021-05-05 15:34     ` Peter Zijlstra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210505143916.GS4032392@tassilo.jf.intel.com \
    --to=ak@linux.intel.com \
    --cc=andi@firstfloor.org \
    --cc=fweimer@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-toolchains@vger.kernel.org \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).