Thread: Compilation warning on 9.5

Compilation warning on 9.5

From
Vicky Vergara
Date:
<div dir="ltr"><pre>Hello:<br /><br />I am a pgRouting developer.<br /><br />In my CmakeLists.txt I use this flags:<br
/>set(CMAKE_C_FLAGS  "${CMAKE_C_FLAGS}   -std=gnu99 -fPIC -O2 -g -Wall -Wconversion -pedantic -fmax-errors=10
-Wmissing-prototypes-frounding-math") 
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++0x -fPIC -O2 -g -Wconversion -Wall -pedantic -fmax-errors=10 -Wextra
-frounding-math-Wno-deprecated") 
<br /><br />for testing I use travis CI framework and test pgRouting using postgresql 9.1 to 9.5<br />I follow the
instructionsfor including:<br />#include "postgres.h"<br />#include "executor/spi.h"<br />#include "funcapi.h"<br
/>#include"catalog/pg_type.h"<br />#if PGSQL_VERSION > 92<br />#include "access/htup_details.h"<br />#endif<br
/>#include"fmgr.h"<br /><br /><br />I wonder if -std=gnu99 is the correct standard to include postgres.h etc. in 9.5
<br/>because that standard (and all the flags I am using to generate pgrouting code without warnings)<br />catches the
followingcatches warnings of type conversions on some postgresql included files.<br />This doesn't happen on postgresql
9.1to 9.4<br /><br />for example:<br /><br /></pre><span id="1-2270">In file included from
/usr/include/postgresql/9.5/server/postgres.h:47:0,</span><br/><span id="1-2271"> from
/home/travis/build/pgRouting/pgrouting/src/dijkstra/src/many_to_many_dijkstra.c:31:</span><br/><span
id="1-2272">/usr/include/postgresql/9.5/server/c.h:298:9:warning: ISO C does not support ‘__int128’ type
[-pedantic]</span><br/><span id="1-2273">/usr/include/postgresql/9.5/server/c.h:299:18: warning: ISO C does not support
‘__int128’type [-pedantic]</span><br /><br /><span id="1-2273"></span><br /><span id="1-2273"><br /></span><br /><span
id="1-2274">Infile included from /usr/include/postgresql/9.5/server/port/atomics.h:119:0,</span><br /><span
id="1-2275">from /usr/include/postgresql/9.5/server/storage/lwlock.h:19,</span><br /><span id="1-2276"> from
/usr/include/postgresql/9.5/server/storage/lock.h:18,</span><br/><span id="1-2277"> from
/usr/include/postgresql/9.5/server/access/genam.h:20,</span><br/><span id="1-2278"> from
/usr/include/postgresql/9.5/server/nodes/execnodes.h:17,</span><br/><span id="1-2279"> from
/usr/include/postgresql/9.5/server/executor/execdesc.h:18,</span><br/><span id="1-2280"> from
/usr/include/postgresql/9.5/server/utils/portal.h:50,</span><br/><span id="1-2281"> from
/usr/include/postgresql/9.5/server/executor/spi.h:18,</span><br/><span id="1-2282"> from
/home/travis/build/pgRouting/pgrouting/src/dijkstra/src/many_to_many_dijkstra.c:32:</span><br/><span
id="1-2283">/usr/include/postgresql/9.5/server/port/atomics/generic.h:In function
‘pg_atomic_add_fetch_u32_impl’:</span><br/><span
id="1-2284">/usr/include/postgresql/9.5/server/port/atomics/generic.h:238:2:warning: conversion to ‘uint32’ from
‘int32’may change the sign of the result [-Wsign-conversion]</span><br /><span
id="1-2285">/usr/include/postgresql/9.5/server/port/atomics/generic.h:In function
‘pg_atomic_sub_fetch_u32_impl’:</span><br/><span
id="1-2286">/usr/include/postgresql/9.5/server/port/atomics/generic.h:247:2:warning: conversion to ‘uint32’ from
‘int32’may change the sign of the result [-Wsign-conversion]</span><br /><span
id="1-2287">/usr/include/postgresql/9.5/server/port/atomics/generic.h:In function
‘pg_atomic_add_fetch_u64_impl’:</span><br/><span
id="1-2288">/usr/include/postgresql/9.5/server/port/atomics/generic.h:372:2:warning: conversion to ‘long unsigned int’
from‘int64’ may change the sign of the result [-Wsign-conversion]</span><br /><span
id="1-2289">/usr/include/postgresql/9.5/server/port/atomics/generic.h:In function
‘pg_atomic_sub_fetch_u64_impl’:</span><br/><span
id="1-2290">/usr/include/postgresql/9.5/server/port/atomics/generic.h:381:2:warning: conversion to ‘long unsigned int’
from‘int64’ may change the sign of the result [-Wsign-conversion]</span><br /><pre>of course, I can't go and modify
<spanid="1-2290">generic.h, </span><span id="1-2273">c.h which are included when I include postgres.h or spi.h, or any
ofthe files<br />that I include that are of the postgresql project.<br /><br />I already posted in this mailing list <a
href="http://www.postgresql.org/message-id/BAY177-W104EC0B93C9FC5453B04CD8AA90@phx.gbl"
target="_blank">http://www.postgresql.org/message-id/BAY177-W104EC0B93C9FC5453B04CD8AA90@phx.gbl</a><br/>But talking
withmy co-developer Steve Woodbri, he suggested this mailing list.<br /></span></pre> <pre> 
you can see a full travis test here:
<a href="https://travis-ci.org/pgRouting/pgrouting/builds/108791787"
rel="nofollow">https://travis-ci.org/pgRouting/pgrouting/builds/108791787</a>
(I have my own warnings which I am fixing and are very visible from 9.1 to 9.4)

Note1: when pgRouting gets released, all those flags:<br />-Wall -Wconversion -pedantic -fmax-errors=10
-Wmissing-prototypes<br/>will be removed, and of course those warnings won't show up.<br /><br /><br /><br /> 
Thanks
Vicky Vergara</pre></div>

Re: Compilation warning on 9.5

From
Tom Lane
Date:
Vicky Vergara <vicky_vergara@hotmail.com> writes:
> I wonder if -std=gnu99 is the correct standard to include postgres.h etc. in 9.5 
> because that standard (and all the flags I am using to generate pgrouting code without warnings)
> catches the following catches warnings of type conversions on some postgresql included files.

It's not -std=gnu99 that's causing those messages, it's -pedantic and
-Wconversion respectively.

> /usr/include/postgresql/9.5/server/c.h:298:9: warning: ISO C does not support �__int128� type [-pedantic]
> /usr/include/postgresql/9.5/server/c.h:299:18: warning: ISO C does not support �__int128� type [-pedantic]

We're not going to do anything about this one; certainly we won't stop
using int128 where it's available, and there isn't any other apparent way
to suppress the warning.  I doubt that -pedantic is a useful switch in
practice, and this seems to be a particularly unhelpful bit of pedantry.
Consider dropping that flag.

> /usr/include/postgresql/9.5/server/port/atomics/generic.h: In function �pg_atomic_add_fetch_u32_impl�:
> /usr/include/postgresql/9.5/server/port/atomics/generic.h:238:2: warning: conversion to �uint32� from �int32� may
changethe sign of the result [-Wsign-conversion]
 

According to the gcc manual, inserting explicit casts would silence these;
is that worth doing?  I doubt anyone cares about making all our code
-Wconversion clean, but maybe making the headers clean would be worth
the trouble.
        regards, tom lane



RV: Compilation warning on 9.5

From
Vicky Vergara
Date:


 

Hello,

Posting an update to this issue (which by the way also shows up on 9.6)

Maybe this information is useful for extension developers (that have all the warnings flags on while developing using GNUC)


By wrapping the files as follows, any warnings generated by the postgres's header files are ignored.


#ifdef __GNUC__
#pragma GCC diagnostic ignored "-pedantic"
#endif

#include "postgres.h"

#ifdef __GNUC__
#pragma GCC diagnostic pop
#endif


#ifdef __GNUC__
#pragma GCC diagnostic ignored "-Wsign-conversion"
#pragma GCC diagnostic ignored "-Wunused-parameter"
#endif

#include "executor/spi.h"

#ifdef __GNUC__
#pragma GCC diagnostic pop
#pragma GCC diagnostic pop
#endif

#ifdef __GNUC__
#pragma GCC diagnostic ignored "-Wunused-parameter"
#endif

#include "funcapi.h"

#ifdef __GNUC__
#pragma GCC diagnostic pop
#endif

Vicky




De: Tom Lane <tgl@sss.pgh.pa.us>
Enviado: viernes, 12 de febrero de 2016 01:45 p. m.
Para: Vicky Vergara
Cc: pgsql-hackers@postgresql.org
Asunto: Re: [HACKERS] Compilation warning on 9.5
 
Vicky Vergara <vicky_vergara@hotmail.com> writes:
> I wonder if -std=gnu99 is the correct standard to include postgres.h etc. in 9.5
> because that standard (and all the flags I am using to generate pgrouting code without warnings)
> catches the following catches warnings of type conversions on some postgresql included files.

It's not -std=gnu99 that's causing those messages, it's -pedantic and
-Wconversion respectively.

> /usr/include/postgresql/9.5/server/c.h:298:9: warning: ISO C does not support ‘__int128’ type [-pedantic]
> /usr/include/postgresql/9.5/server/c.h:299:18: warning: ISO C does not support ‘__int128’ type [-pedantic]

We're not going to do anything about this one; certainly we won't stop
using int128 where it's available, and there isn't any other apparent way
to suppress the warning.  I doubt that -pedantic is a useful switch in
practice, and this seems to be a particularly unhelpful bit of pedantry.
Consider dropping that flag.

> /usr/include/postgresql/9.5/server/port/atomics/generic.h: In function ‘pg_atomic_add_fetch_u32_impl’:
> /usr/include/postgresql/9.5/server/port/atomics/generic.h:238:2: warning: conversion to ‘uint32’ from ‘int32’ may change the sign of the result [-Wsign-conversion]

According to the gcc manual, inserting explicit casts would silence these;
is that worth doing?  I doubt anyone cares about making all our code
-Wconversion clean, but maybe making the headers clean would be worth
the trouble.

                        regards, tom lane

Re: RV: Compilation warning on 9.5

From
Robert Haas
Date:
On Mon, Nov 7, 2016 at 2:34 PM, Vicky Vergara <vicky_vergara@hotmail.com> wrote:
Hello,

Posting an update to this issue (which by the way also shows up on 9.6)

Maybe this information is useful for extension developers (that have all the warnings flags on while developing using GNUC)


By wrapping the files as follows, any warnings generated by the postgres's header files are ignored.


#ifdef __GNUC__
#pragma GCC diagnostic ignored "-pedantic"
#endif

#include "postgres.h"

#ifdef __GNUC__
#pragma GCC diagnostic pop
#endif


#ifdef __GNUC__
#pragma GCC diagnostic ignored "-Wsign-conversion"
#pragma GCC diagnostic ignored "-Wunused-parameter"
#endif

#include "executor/spi.h"

#ifdef __GNUC__
#pragma GCC diagnostic pop
#pragma GCC diagnostic pop
#endif

#ifdef __GNUC__
#pragma GCC diagnostic ignored "-Wunused-parameter"
#endif

#include "funcapi.h"

#ifdef __GNUC__
#pragma GCC diagnostic pop
#endif

Wow, that's pretty ugly.  But it's useful to know that it is available in a pinch.  Thanks!
 
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company