Bug 169991 - gcc4 problem with glib g_return_val... functions
gcc4 problem with glib g_return_val... functions
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
4
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-10-06 03:32 EDT by Thomas M Steenholdt
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-07 06:24:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
testcase created from trimmed down gaim plugin (1.91 KB, application/octet-stream)
2005-10-06 17:18 EDT, Thomas M Steenholdt
no flags Details
tiny g_return_val_if_fail testcase (66 bytes, text/plain)
2005-10-07 06:18 EDT, Thomas M Steenholdt
no flags Details

  None (edit)
Description Thomas M Steenholdt 2005-10-06 03:32:39 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20051006 Fedora/1.5b1-0.fc4 Firefox/1.4

Description of problem:
The g_return_val_if_fail macro from glib-2.0 fails with gcc4.
The macro wraps the g_return_if_fail_warning function, but building with gcc4 and "-Wall -Werror -ansi" makes it spew the following error at every call to g_return_val_if_fail

warning: passing argument 2 of 'g_return_if_fail_warning' discards qualifiers from pointer target type

i'm not calling g_return_if_fail_warning directly from anywhere within my code.

if i do the exact same build with gcc32,  I have no problems...


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. get meanwhile (or other software that uses g_return_val_if_fail) from meanwhile.sf.net
2. untar and CFLAGS="-Wall -Werror -ansi" ./configure
3. make and watch the errors
  

Actual Results:  lots of "warning: passing argument 2 of 'g_return_if_fail_warning' discards qualifiers from pointer target type" 

Expected Results:  clean compile!

Additional info:

Trying instead :

CC=gcc32 CFLAGS="-Wall -Werror -ansi" ./configure
make

All is good!

It looks like it may have something to do with gcc's __PRETTY_FUNCTION__ thing?
Comment 1 Jakub Jelinek 2005-10-06 03:44:50 EDT
Please provide either preprocessed source of the file on which you get the
warning, or create a minimal self-contained testcase.
I haven't seen any problem on the short testcase I tried, so likely the program
you're trying to build is doing something wrong.
g_return_if_fail_warning has 3 const char * arguments, so if you pass say a char
* argument to it, the warning is in order.  But, __PRETTY_FUNCTION__ unless
redefined in the source is const char *.
Comment 2 Thomas M Steenholdt 2005-10-06 17:18:15 EDT
Created attachment 119688 [details]
testcase created from trimmed down gaim plugin

This is the easiest way (for me) to try to illustrate the problem for you.

untar, then run CFLAGS="-Wall -Werror -ansi" ./autogen.sh followed by make...
assuming you're on FC4 or likely any gcc4 based platform, you should get the
error i'm talking about.

then try make clean, CC=gcc32 CFLAGS="-Wall -Werror -ansi" ./autogen.sh
followed by make and the error is gone.

I have to admit that i'm new to gnu make and all the stuff that goes on in
here, so i hope that's not what screws things up!
Comment 3 Jakub Jelinek 2005-10-06 17:56:47 EDT
I can't reproduce this.  Though I can't understand how is it easiest for you
to create such trimmed down testcase as opposed simply noting all command line
options used to build that file, replacing -c on that command line with -E
and if -o is missing, adding -o test.i and attaching test.i here, plus
writing what options were used.
Comment 4 Thomas M Steenholdt 2005-10-07 06:17:24 EDT
That's because i'm a moron!

Here's a better way to reproduce that involves much less work and much fewer
variable/unknown factors.

gcc -Dconst= -I. -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -Wall
-Werror -ansi test.c

I'll attach the test.c file in 30 secs...

Also, in cleaning up this test to be a lot better suited for tracking down
problems, I discovered that the problem goes away when taking -Dconst= out of
the command.

I hope this works for you!

I have tried this with several FC4 installations all on latest errata level and
they all do the same thing!
Comment 5 Thomas M Steenholdt 2005-10-07 06:18:28 EDT
Created attachment 119701 [details]
tiny g_return_val_if_fail testcase
Comment 6 Thomas M Steenholdt 2005-10-07 06:21:22 EDT
Exact output is:

[tmus@home testcase]$ gcc -Dconst= -I. -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -Wall -Werror -ansi test.c
cc1: warnings being treated as errors
test.c: In function ‘test’:
test.c:4: warning: passing argument 2 of ‘g_return_if_fail_warning’ discards
qualifiers from pointer target type

Comment 7 Jakub Jelinek 2005-10-07 06:24:32 EDT
If you use -Dconst=, then you certainly get what you are asking for.
There is no bug on the GCC side.  __PRETTY_FUNCTION__ is const char *,
no matter if you redefine const keyword using a macro or not, so the
compiler has all rights to warn about it being assigned to a char * argument
(as g_return_if_fail_warning uses const in the prototype and you changed
the prototype with -Dconst=).
Comment 8 Thomas M Steenholdt 2005-10-07 11:47:32 EDT
Right, that's what I thought - I'm no compiler expert even by a longshot. But
try to do the same thing with gcc32 - No warning! Which indicates to me that
something is rotten! It may be with gcc32 though??
Comment 9 Thomas M Steenholdt 2005-10-09 17:41:55 EDT
Anyways - I should have trimmed it all the way down to this from the beginning.
I don't really need the -Dconst= and everyhing is working now!

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