Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 1811158 - inconsistent "directive argument is null" warning
Summary: inconsistent "directive argument is null" warning
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc
Version: 33
Hardware: s390x
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: 1799842
TreeView+ depends on / blocked
Reported: 2020-03-06 18:10 UTC by Dan Horák
Modified: 2021-06-18 07:18 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed:
Type: Bug

Attachments (Terms of Use)
preprocessed source (1.02 MB, text/plain)
2020-03-06 18:10 UTC, Dan Horák
no flags Details

System ID Private Priority Status Summary Last Updated
IBM Linux Technology Center 184303 0 None None None 2020-03-09 15:14:15 UTC

Description Dan Horák 2020-03-06 18:10:23 UTC
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):

Comment 1 Martin Sebor 2020-03-09 18:01:11 UTC
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:

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

Comment 2 Jakub Jelinek 2020-03-09 18:15:07 UTC
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.

Comment 3 Dan Horák 2020-03-10 08:28:07 UTC
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.

Comment 4 Jakub Jelinek 2020-03-10 09:00:27 UTC
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.

Comment 5 Dan Horák 2020-03-10 10:08:17 UTC
(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.

Comment 6 Jan Pokorný [poki] 2020-03-10 10:15:00 UTC
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.

Comment 7 Jan Pokorný [poki] 2020-03-10 10:18:34 UTC
... 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 8 IBM Bug Proxy 2020-03-12 07:31:15 UTC
------- Comment From 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.

Comment 9 Ben Cotton 2020-08-11 15:26:55 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle.
Changing version to 33.

Note You need to log in before you can comment on or make changes to this bug.