From: Jim Wilson <jimw@sifive.com>
To: Newlib <newlib@sourceware.org>
Subject: __restrict defined away for C++
Date: Mon, 13 Jul 2020 13:02:07 -0700 [thread overview]
Message-ID: <CAFyWVab4RES_jp5rxcKMO4BRXmFWtxaSjuRSS916=ApxSLifEQ@mail.gmail.com> (raw)
This problem was originally reported on the RISC-V sw-dev mailing list.
https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/b55LI9OSFwo/m/d8-_NGmlAQAJ
I see that newlib/libc/include/sys/cdefs.h has
/*
* GCC 2.95 provides `__restrict' as an extension to C90 to support the
* C99-specific `restrict' type qualifier. We happen to use `__restrict' as
* a way to define the `restrict' type qualifier without disturbing older
* software that is unaware of C99 keywords.
*/
#if !(__GNUC__ == 2 && __GNUC_MINOR__ == 95)
#if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 199901
#define __restrict
#else
#define __restrict restrict
#endif
#endif
The flaw here is that C++ compilers don't define __STDC_VERSION so
this always causes __restrict to be defined away, even if the C++
compiler supports it. This prevents use of the GNU extension
__restrict in C++ code. The workaround is to use __restrict__ in user
code which GNU C++ also supports, and which newlib doesn't define
away.
I don't have a patch. I'm hoping someone else writes one. One
possible solution is to use a different keyword inside newlib, e.g.
__newlib_retrict. This way we don't conflict with the compiler
__restrict feature. Though this means newlib functions will be
declared without __restrict. Another solution would be to check for
C++ compilers with __restrict support and support them. Or maybe both
of these are appropriate.
We may not need the gcc-2.95 support anymore.
Jim
reply other threads:[~2020-07-13 20:02 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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='CAFyWVab4RES_jp5rxcKMO4BRXmFWtxaSjuRSS916=ApxSLifEQ@mail.gmail.com' \
--to=jimw@sifive.com \
--cc=newlib@sourceware.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 read-only IMAP folder(s) and NNTP newsgroup(s).