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 bugzilla.redhat.com.
Bug 1800717 - [cpp]: unlike with clang, message from GLIB_DEPRECATED_MACRO of glib is ended prematurely/the token to be output swallowed unexpectedly
Summary: [cpp]: unlike with clang, message from GLIB_DEPRECATED_MACRO of glib is ended...
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: glib2
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Matthias Clasen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-02-07 19:43 UTC by Jan Pokorný [poki]
Modified: 2021-03-01 10:14 UTC (History)
19 users (show)

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

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
GNU Compiler Collection 99315 0 P3 UNCONFIRMED #pragma GCC warning does not concatenate string literals 2021-03-01 10:14:44 UTC

Internal Links: 1800072

Description Jan Pokorný [poki] 2020-02-07 19:43:12 UTC 
Case in point: [bug 1800072]
- build.log [attachment 1660881 [details]]

179 gcc -DHAVE_CONFIG_H -I. -I..  -I/usr/include/pacemaker -I/usr/include/heartbeat -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include  -Werror -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include  -I/usr/include/pacemaker -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/libxml2 -I/usr/include/uuid -I/usr/include/p11-kit-1   -I/usr/include/libxml2   -D_GNU_SOURCE -DCHECK_AIS -DSBINDIR=\"/usr/sbin\" -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=zEC12 -mtune=z13 -fasynchronous-unwind-tables -fstack-clash-protection -Wall -Werror -c -o sbd-cluster.o sbd-cluster.c
180 sbd-pacemaker.c: In function 'servant_pcmk':
181 sbd-pacemaker.c:491:13: error: Deprecated pre-processor symbol, replace with  [-Werror]
182   491 |  mainloop = g_main_new(FALSE);
183       |             ^~~~~~~~~~~~~~~~~~
184 sbd-pacemaker.c:497:13: error: Deprecated pre-processor symbol, replace with  [-Werror]
185   497 |  g_main_run(mainloop);
186       |             ^~~~~~~~~~
187 sbd-pacemaker.c:498:13: error: Deprecated pre-processor symbol, replace with  [-Werror]
188   498 |  g_main_destroy(mainloop);
189       |             ^~~~~~~~~~~~~~
190 sbd-cluster.c: In function 'servant_cluster':
191 sbd-cluster.c:545:13: error: Deprecated pre-processor symbol, replace with  [-Werror]
192   545 |     mainloop = g_main_new(FALSE);
193       |             ^~~~~~~~~~~~~~~~~~~~~
194 sbd-cluster.c:551:13: error: Deprecated pre-processor symbol, replace with  [-Werror]
195   551 |     g_main_run(mainloop);
196       |             ^~~~~~~~~~~~~
197 sbd-cluster.c:552:13: error: Deprecated pre-processor symbol, replace with  [-Werror]
198   552 |     g_main_destroy(mainloop);
199       |             ^~~~~~~~~~~~~~~~~
200 cc1: all warnings being treated as errors

Reproducible with something like:

cd /tmp
git clone --shallow-since 2019-08-20  https://github.com/ClusterLabs/sbd.git
cd sbd
git checkout -b test bce1f2b^
dnf builddep --spec sbd.spec
./autogen.sh && ./configure && make

> sbd-pacemaker.c: In function ‘servant_pcmk’:
> sbd-pacemaker.c:565:13: error: Deprecated pre-processor symbol, replace with  [-Werror]
>   565 |  mainloop = g_main_new(FALSE);
>       |             ^~~~~~~~~~~~~~~~~~                              
> sbd-pacemaker.c:571:13: error: Deprecated pre-processor symbol, replace with  [-Werror]
>   571 |  g_main_run(mainloop);
>       |             ^~~~~~~~~~                                      
> sbd-pacemaker.c:572:13: error: Deprecated pre-processor symbol, replace with  [-Werror]
>   572 |  g_main_destroy(mainloop);
>       |             ^~~~~~~~~~~~~~     

rpm -q gcc
> gcc-10.0.1-0.7.fc32.x86_64

With clang, though:

> sbd-pacemaker.c:565:13: warning: Deprecated pre-processor symbol, replace with g_main_loop_new [-W#pragma-messages]
>         mainloop = g_main_new(FALSE);
>                    ^
> /usr/include/glib-2.0/glib/deprecated/gmain.h:50:76: note: expanded from macro 'g_main_new'
> #define         g_main_new(is_running)  g_main_loop_new (NULL, is_running) GLIB_DEPRECATED_MACRO_IN_2_26_FOR(g_main_loop_new)
>                                                                            ^
> /usr/include/glib-2.0/glib/gversionmacros.h:333:49: note: expanded from macro 'GLIB_DEPRECATED_MACRO_IN_2_26_FOR'
> # define GLIB_DEPRECATED_MACRO_IN_2_26_FOR(f)   GLIB_DEPRECATED_MACRO_FOR(f)
>                                                 ^
> /usr/include/glib-2.0/glib/gmacros.h:990:38: note: expanded from macro 'GLIB_DEPRECATED_MACRO_FOR'
> #define GLIB_DEPRECATED_MACRO_FOR(f) _GLIB_GNUC_DO_PRAGMA(GCC warning "Deprecated pre-processor symbol, replace with " #f)
>                                      ^
> /usr/include/glib-2.0/glib/gmacros.h:988:33: note: expanded from macro '_GLIB_GNUC_DO_PRAGMA'
> #define _GLIB_GNUC_DO_PRAGMA(x) _Pragma(G_STRINGIFY (x))
>                                 ^
> <scratch space>:127:6: note: expanded from here
>  GCC warning "Deprecated pre-processor symbol, replace with " "g_main_loop_new"
>      ^

rpm -q clang
> clang-9.0.0-2.fc32.x86_64
Comment 1 Ben Cotton 2020-02-11 16:37:20 UTC 
This bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle.
Changing version to 32.
Comment 2 Jan Pokorný [poki] 2020-02-11 21:09:48 UTC 
Interestingly, the same problem is observed with

> gcc (GCC) 8.2.1 20180905 (Red Hat 8.2.1-3)
> gcc (GCC) 8.3.1 20191121 (Red Hat 8.3.1-5)

Note sure which compiler, gcc or clang, is correct here, and which
is not (both cannot be at the same time when they exhibit contradicting
behaviours, unless there's some explicit compiler-sensitive
conditionalizing, right?).

May as well be the case that clang + glib2 are wrong concurrently.
Comment 3 Jakub Jelinek 2020-02-12 19:51:28 UTC 
Just look at the definition of the macro, it is compiler and even compiler version specific, furthermore uses compiler specific pragmas.
Comment 4 Jakub Jelinek 2020-02-12 19:56:55 UTC 
Furthermore, I don't understand what you are complaining about, when you are compiling with -Werror, you request all the warnings to be promoted to errors and it is up to you to either fix those or disable.
From the #c0 output, it seems clang warns as well about those, so either you aren't compiling with -Werror when using clang, or clang can't handle -Werror in the preprocessor, or there are pragmas to downgrade these warnings to just warnings rather than errors.
Comment 5 Jan Pokorný [poki] 2020-02-13 11:41:12 UTC 
-Werror has (should not have) anything to do with this.
I see it casts some confusion, but that wasn't intended.
I don't think it would have any bearing on the effect I have
in mind.

The gist is, as per summary, that the trailing token (here
"g_main_loop_new" per what clang produces for the first occurrence)
is missing in the deprecation warning message when building with GCC.

As mentioned, might be the problem with GLib2 that it doesn't do
this messaging properly (plus that clang copes with that properly
anyway?) instead.  Not an expert, still could try to minimize the
scenario if it's asked.

The most descriptive line in GLib's code:
https://gitlab.gnome.org/GNOME/glib/blob/91cb1710574309b4c52b388bb5cc7a4e899050bc/glib/gmacros.h#L990

The question is: why does #f part resolve to empty string, when
it resolves to input argument with clang?
Comment 6 Jan Pokorný [poki] 2021-02-27 11:05:26 UTC 
Still reproducible with gcc-11.0.0-0.18.fc34.x86_64 and
glib2-devel-2.67.3-2.fc34.x86_64.

As I got confused myself, to demonstrate reality vs. expected clearly:

-sbd-pacemaker.c:565:20: error: Deprecated pre-processor symbol, replace with  [-Werror]
+sbd-pacemaker.c:565:20: error: Deprecated pre-processor symbol, replace with g_main_loop_new [-Werror]
   565 |         mainloop = g_main_new(FALSE);
       |                    ^~~~~~~~~~~~~~~~~~
Comment 7 Jakub Jelinek 2021-02-27 12:22:20 UTC 
That looks clearly like a glib2 bug.
As can be seen in:
#define G_STRINGIFY(macro_or_string)    G_STRINGIFY_ARG (macro_or_string)
#define G_STRINGIFY_ARG(contents)       #contents
#define _GLIB_GNUC_DO_PRAGMA(x) _Pragma(G_STRINGIFY (x))
#define GLIB_DEPRECATED_MACRO_FOR(f) _GLIB_GNUC_DO_PRAGMA(GCC warning "Deprecated pre-processor symbol, replace with" #f)

#define FOO GLIB_DEPRECATED_MACRO_FOR(foo)
FOO

#define GLIB_DEPRECATED_MACRO_FOR2(f) _GLIB_GNUC_DO_PRAGMA(GCC warning G_STRINGIFY(Deprecated pre-processor symbol; replace with f))
#define BAR GLIB_DEPRECATED_MACRO_FOR2(foo)
BAR

#pragma GCC warning "Deprecated pre-processor symbol, replace with" "foo"
#pragma GCC warning "Deprecated pre-processor symbol, replace with foo"

- #pragma GCC warning expects a single argument.  Pragma processing is during translation phase 4,
while adjacent string literal concatenation is later (translation phase 6), plus GCC warning is an extension,
so I don't see anything wrong with that.

So, IMHO glib2 should replace (at least for GCC its GLIB_DEPRECATED_MACRO_FOR macro with something like my
GLIB_DEPRECATED_MACRO_FOR2 above (note, what it has currently even if the concatenation worked, it lacks a space after with).
Getting a comma into it would be harder, but can be done too, just don't have time to do that now.
And similarly GLIB_UNAVAILABLE_MACRO needs fixing too.
Comment 8 Jakub Jelinek 2021-02-27 14:32:45 UTC 
If you want comma, you can do:
#define G_STRINGIFY_VA(...)    G_STRINGIFY_ARG_VA (__VA_ARGS__)
#define G_STRINGIFY_ARG_VA(...)       #__VA_ARGS__
#define GLIB_DEPRECATED_MACRO_FOR(f) _GLIB_GNUC_DO_PRAGMA(GCC warning G_STRINGIFY_VA(Deprecated pre-processor symbol, replace with f))
#define BAR GLIB_DEPRECATED_MACRO_FOR(foo)
BAR
Comment 9 Jan Pokorný [poki] 2021-02-27 14:38:33 UTC 
Thanks for looking into this.  I am confused about the culprit, indeed.
That Clang behaved as expected may have not helped in this confusion.
Note You need to log in before you can comment on or make changes to this bug.