public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
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

  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).