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