Created attachment 1668185 [details] preprocessed source Compiling the attached source on s390x prints a warning when compiled without -fPIC [sharkcz@devel10 pengine]$ gcc -O2 -Wall -m64 -fgnu89-inline -march=zEC12 -mtune=z13 -c utils.i -o utils.o In function ‘pe_action_set_reason’, inlined from ‘custom_action’ at utils.c:605:13: utils.c:2502:28: warning: ‘%s’ directive argument is null [-Wformat-overflow=] 2502 | pe_rsc_trace(action->rsc, "Changing %s reason from '%s' to '%s'", action->uuid, action->reason, reason); The warning is not emitted when using -fPIC on s390x. On any other arch it's silent no matter whether -fPIC is used or not. Seems having -mtune=z13 is required for emitting the warning. Using only -march=z13 (or z14 or z15) also emits the warning, while -march=zEC12 without -mtune=z13 does not. Version-Release number of selected component (if applicable): gcc-10.0.1-0.8.fc33.s390x
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.
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 33 changed to end-of-life (EOL) status on 2021-11-30. Fedora 33 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.