linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sasha Levin <sasha.levin@oracle.com>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	"Kirill A. Shutemov" <kirill@shutemov.name>
Cc: Aaro Koskinen <aaro.koskinen@iki.fi>,
	Andrew Pinski <pinskia@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] kernel: use the gnu89 standard explicitly
Date: Sun, 19 Oct 2014 19:59:53 -0400	[thread overview]
Message-ID: <54445079.4000803@oracle.com> (raw)
In-Reply-To: <CA+55aFxf6_cA5hTtDGqPU4=DkKz_6OUizhiqge+Xf5u34RxeXw@mail.gmail.com>

On 10/19/2014 07:49 PM, Linus Torvalds wrote:
> On Sun, Oct 19, 2014 at 4:10 PM, Kirill A. Shutemov
> <kirill@shutemov.name> wrote:
>> >
>> > IIUC, it's nothing to do with volatile. C11 and above reads
>> >
>> >         (rwlock_t) { .raw_lock = { 0 }, }
>> >
>> > as compound literal (which is not constant) rather than constant
>> > initalizer plus a cast.
> Ahh. I thought it was the volatile, just because of the "constant"
> part and the fact that it looked like the test-case was minimal. But
> apparently that was just a red herring.
> 
> So it's just the fact that C11 hasn't got the useful GNU extension of
> a cast-with-initializer, and then that extension got removed (probably
> just an oversight) because people thought that the "standard" C11
> initializers were good enough.
> 
> And it sounds like this will get fixed (perhaps already is) in gcc anyway.

It was already fixed in gcc (I've reported it here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63567)

> So maybe we need to do that "--std=gnu89" as a temporary workaround,
> but not as long long-term "newer versions are broken".

Agreed, I could send patches to fix the build issues resulting from c11,
but I'm afraid that it'll need real good testing to uncover things that don't
show up during the build.

> That doesn't sound too bad. My main objection to the patch was a
> "let's try to fix this properly instead", but if the breakage is just
> a temporary problem, there's no issue with "properly". Although it
> does look like the *placement* of the --std=gnu89 was incorrect in
> that original patch, so it needs updating regardless.

Apologies. It seemed like the right place to me and it worked fine when
I tested it.

> AndrewP, mind explaing the other difference you mentioned (ie wrt
> "extern inline")? I thought we had already long since ended up
> following the gcc semantics (ie use "static inline" if we don't have
> an external version somehwre), what exactly changed?

(Stolen from gcc changelog:)

gnu89: extern inline: Will not generate an out-of-line version, but
	might call one.
gnu99: extern inline: like GNU "inline", externally visible code is
	emitted.

(So what happens is that with gnu99 you end up with multiple definitions
of the symbol since it was externed from multiple compilation units).


Thanks,
Sasha

  reply	other threads:[~2014-10-20  0:00 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-19 16:07 [PATCH] kernel: use the gnu89 standard explicitly Sasha Levin
2014-10-19 20:05 ` Linus Torvalds
2014-10-19 20:23   ` Joe Perches
     [not found]     ` <CA+55aFwbq4TtQXC9PTjOF3UPP7u8XH1mSYjvT7pevKcQBfy25A@mail.gmail.com>
2014-10-19 21:31       ` Joe Perches
2014-10-19 21:03   ` Aaro Koskinen
2014-10-19 23:05     ` Linus Torvalds
2014-10-19 23:10       ` Kirill A. Shutemov
2014-10-19 23:19         ` Al Viro
2014-10-19 23:21         ` Kirill A. Shutemov
2014-10-19 23:26           ` Al Viro
2014-10-19 23:49         ` Linus Torvalds
2014-10-19 23:59           ` Sasha Levin [this message]
2014-10-20  0:23             ` Linus Torvalds
2014-10-20  4:16               ` Al Viro
2014-10-19 23:25       ` pinskia
2014-10-19 23:52   ` Sasha Levin
2014-10-19 22:29 ` Kirill A. Shutemov

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=54445079.4000803@oracle.com \
    --to=sasha.levin@oracle.com \
    --cc=aaro.koskinen@iki.fi \
    --cc=akpm@linux-foundation.org \
    --cc=kirill@shutemov.name \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pinskia@gmail.com \
    --cc=torvalds@linux-foundation.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).