Flow-sensitive warnings like -Wnonnull depend on the compiler's ability to track the flow of data through a function.  When functions are inlined, this ability extends to the bodies of such functions.  As different targets use different heuristics to enable inlining, some targets may expose more code to the warning than others, leading to more instances of it (which could be either true or false positives).  As s390x appears to inlinine more aggressively than other targets this would fit the pattern we have seen in similar cases that have been reported.  Declaring the pe_action_set_reason inline (and with attribute always_inline) reproduces the warning without any -march options.

The inlined function referenced in the warning, pe_action_set_reason, is declared like this:

void pe_action_set_reason(pe_action_t *action, const char *reason, _Bool overwrite);

It calls qb_log_from_external_source for example like this:

    if(action->reason && overwrite) {
       ...
       qb_log_from_external_source(__func__, "utils.c", "Changing %s reason from '%s' to '%s'", 
       (7 + 1)
       , 2502, converted_tag , action->uuid, action->reason, reason);

qb_log_from_external_source is in turn declared with the format attribute:

void qb_log_from_external_source(const char *function,
     const char *filename,
     const char *format,
     uint8_t priority,
     uint32_t lineno,
     uint32_t tags,
     ...)
 __attribute__ ((format (printf, 3, 7)));

That means calls to it will have its arguments checked against the format string.

Finally, pe_action_set_reason is called like this in custom_action:

            pe_action_set_reason(action, 
                                        ((void *)0)
                                            , (!(0)));

i.e., with the reason char* pointer set to null and with overwrite set to true (overwrite controls the call to qb_log_from_external_source above).  The pointer is the argument to the %s directive above, which is what triggers the warning.

I couldn't see what value action->reason is set to but assuming it's not set to null in a way GCC should be able to see it seems like the warning is justified.

With that, it's not clear to me what the subject of the report is: do you think the warning is a false positive, or is it that you'd like the warning issued consistently, regardless of the target?  (Did I miss something in the analysis above? The latter can't happen for the reasons I explained.)

Indeed, s390x with -mtune=z13 and higher uses much aggressive inlining than other arches:
  /* Use aggressive inlining parameters.  */
  if (opts->x_s390_tune >= PROCESSOR_2964_Z13)
    {
      SET_OPTION_IF_UNSET (opts, opts_set, param_inline_min_speedup, 2);
      SET_OPTION_IF_UNSET (opts, opts_set, param_max_inline_insns_auto, 80);
    }
but you can use --param=inline-min-speedup=2 --param=max-inline-insns-auto=80 on other arches to get similar behavior.
The defaults for these params are 30 and 15 on other arches or for older s390x tunings.
And the reason why -fPIC plays a significant role is likely that with -fPIC some functions could be overridden, the compiler can't assume references to them will bind to the definitions in the same TU, as e.g. the main program or some earlier shared library could interpose those symbols, and so can't inline those without being told it can.
I guess you could use -fno-semantic-interposition to get the same behavior even with -fPIC, but then of course, symbol interposition will not work.

Martin, my main concern is the inconsistency across arches, when the warning is emitted only on s390x, causing s390x to be considered weird/broken/... especially when projects default to using -Werror like it was here.

See above, that is the consequence of the aggressive inlining parameters on s390x.  Yes, it changes a lot of things, and the answer can be if you use this and that option (again, listed above), you'll get the same thing on x86_64 and other arches too.

(In reply to Jakub Jelinek from comment #4)
> See above, that is the consequence of the aggressive inlining parameters on
> s390x.  Yes, it changes a lot of things, and the answer can be if you use
> this and that option (again, listed above), you'll get the same thing on
> x86_64 and other arches too.

yup, I see, I guess we can close this as NOTABUG.

At the original [bug 1799842 comment 18], I've expressed an idea
that perhaps GCC is not the right battlefield and instead, libtool
is what shall be modified to address inherently unequal sets of
warnigns emitted with -fPIC or without (i.e. not to suppress any
output or to do some equality matching under the hood first,
alternatively to reorder the compilation passes if one is always
expected to yield same amount or more discoveries than the other),
especially when -Werror is spotted amongst the compiler flags,
as this is a significant game changer when it comes to successfulness
of the compilation, indeed.

... why that?  Exactly to get rid of completely silent failures of
the build, especially with unattended compilation scenarios
(and especially for archs that are not easy to get one's hand on
so as to reproduce the problem by hand).

------- Comment From tstaudt.com 2020-03-12 03:25 EDT-------
Comment from Andreas Krebbel 2020-03-11 07:24:11 CDT
"
The warning appears to be correct and the code which triggers it should be fixed. Nothing to do for GCC as I understand it.
"

This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle.
Changing version to 33.