From: Joseph Myers <joseph@codesourcery.com>
To: Stafford Horne <shorne@gmail.com>
Cc: GLIBC patches <libc-alpha@sourceware.org>
Subject: Re: Upstreaming OpenRISC with GCC mainline
Date: Wed, 27 Oct 2021 22:13:14 +0000 [thread overview]
Message-ID: <alpine.DEB.2.22.394.2110272203480.1681686@digraph.polyomino.org.uk> (raw)
In-Reply-To: <CAAfxs77MfWtYGYLgycvF0Utvq-rqbfaekCHAWL5R2bDLa3oKKQ@mail.gmail.com>
On Thu, 28 Oct 2021, Stafford Horne via Libc-alpha wrote:
> The question now being, how should I go about upstreaming? Should I
> just backport my gcc patches to gcc-11 and move forward? Or should I
> work to fixup all of the GCC mainline issues the correct way? I think
> the second option may take quite some time though.
What are you doing differently in your GCC or glibc ports that results in
getting these warnings for OpenRISC but not for other architectures?
That's a key thing to understand, separately for each issue (for example,
S/390 sometimes has problems with warnings not seen on other architectures
because it sets various tuning parameters differently). In some cases, it
might be that GCC *should* warn for other architectures, in which case an
upstream GCC bug needs reporting about the missing warning. For example,
I can see no good reason for the "'strcmp' argument 2 declared attribute
'nonstring'" warnings you quote to depend on the architecture; they should
appear on all architectures or none.
Then, if a warning is a false positive (and really is still present with
current GCC mainline), adding an initialization is not normally the
appropriate fix; rather, for uninitialized warnings we use DIAG_* to
suppress them, with a comment explaining the analysis of *why* the warning
is a false positive. For example, in sysdeps/ieee754/flt-32/s_log1pf.c we
already have a use of those macros for what looks like the specific
warning case you quote; if, despite that, you see the warning for a
different place in the same file for the same variable, it might be
reasonable to repeat the same macro calls and comment there, if the same
analysis applies.
--
Joseph S. Myers
joseph@codesourcery.com
next prev parent reply other threads:[~2021-10-27 22:13 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-27 20:49 Stafford Horne
2021-10-27 22:13 ` Joseph Myers [this message]
2021-10-27 23:19 ` Stafford Horne
2021-10-28 17:15 ` Joseph Myers
2021-10-28 21:17 ` Stafford Horne
2021-10-28 21:45 ` Joseph Myers
2021-10-28 22:18 ` Stafford Horne
2021-10-29 9:05 ` Stafford Horne
2021-10-29 14:43 ` Joseph Myers
2021-10-29 15:08 ` Stafford Horne
2021-10-30 8:56 ` Stafford Horne
2021-11-01 20:47 ` Joseph Myers
2021-11-02 4:18 ` Stafford Horne
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=alpine.DEB.2.22.394.2110272203480.1681686@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=libc-alpha@sourceware.org \
--cc=shorne@gmail.com \
/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).