Upstreaming OpenRISC with GCC mainline
Joseph Myers
joseph@codesourcery.com
Wed Oct 27 22:13:14 GMT 2021
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
More information about the Libc-alpha
mailing list