All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: Cesar Eduardo Barros <cesarb@cesarb.eti.br>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Masahiro Yamada <masahiroy@kernel.org>
Subject: Re: [PATCH] Restore gcc check in mips asm/unroll.h
Date: Fri, 10 Jul 2020 15:31:00 -0700	[thread overview]
Message-ID: <CAHk-=whaqVGHSGstM4yHnJ+WkoHDBKWxMuZvgOYoxe9sYBOjEw@mail.gmail.com> (raw)
In-Reply-To: <CAKwvOdnbtbetfN5zF51QOXVhrutE8ak4uPe82iY6g9f6gwk=Vg@mail.gmail.com>

On Fri, Jul 10, 2020 at 11:43 AM Nick Desaulniers
<ndesaulniers@google.com> wrote:
>
> What I'd really like to see as a policy in the kernel going forward in
> that ANY new commit that adds some hack or workaround for a specific
> compiler version add a comment about which toolchain version was
> problematic, that way when we drop support for that version years
> later, we can drop whatever hacks and technical debt we've accumulated
> to support that older version.

The problem is that at the time we find and fix things, it's often
_very_ unclear which compiler versions are affected.

We also have the situation that a lot of distro compilers aren't
necessarily completely "clean" versions, particularly for the
"enterprise" ones that get stuck on some old version and then fix up
their breakage by backporting fixes.

When it's some particular version of a compiler that supports a
particular feature, that tends to be much more straightforward. But
we've had bugs where it was very unclear when exactly the bug was
fixed (fi it was fixed at all by the time we do the workaround).

              Linus

  reply	other threads:[~2020-07-10 22:31 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-09 22:11 [PATCH] Restore gcc check in mips asm/unroll.h Cesar Eduardo Barros
2020-07-10  0:53 ` Linus Torvalds
2020-07-10 18:43   ` Nick Desaulniers
2020-07-10 22:31     ` Linus Torvalds [this message]
2020-07-11  3:16       ` Nathan Chancellor
2020-07-10 22:34 ` [PATCH] mips: Remove compiler check in unroll macro Nathan Chancellor
2020-07-10 22:43   ` Linus Torvalds
2020-07-11  2:15     ` Nathan Chancellor

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='CAHk-=whaqVGHSGstM4yHnJ+WkoHDBKWxMuZvgOYoxe9sYBOjEw@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=cesarb@cesarb.eti.br \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=rostedt@goodmis.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.