compile warnings in CVS HEAD?

Neil Conway writes:

lex.Int_yy.c:1832: warning: no previous prototype for `Int_yyget_lineno'

These are caused by the new flex. Ignore them.

tablecmds.c: In function `validateForeignKeyConstraint':
tablecmds.c:3546: warning: dereferencing type-punned pointer will break
strict-a liasing rules

Probably the new compiler. These might deserve some investigation.

--
Peter Eisentraut peter_e@gmx.net

Neil Conway wrote:

I'm seeing the following with the current CVS code on my Linux dev box:

Gee, that's strange. I have never seen those errors before.

$ make maintainer-clean
$ ./configure --enable-depend --enable-cassert --enable-debug
--prefix=/pgsql --with-openssl
[ ... ]
$ make -s
In file included from bootparse.y:340:
lex.Int_yy.c:1832: warning: no previous prototype for `Int_yyget_lineno'
lex.Int_yy.c:1841: warning: no previous prototype for `Int_yyget_in'
lex.Int_yy.c:1849: warning: no previous prototype for `Int_yyget_out'
lex.Int_yy.c:1857: warning: no previous prototype for `Int_yyget_leng'
lex.Int_yy.c:1866: warning: no previous prototype for `Int_yyget_text'
lex.Int_yy.c:1875: warning: no previous prototype for `Int_yyset_lineno'
lex.Int_yy.c:1887: warning: no previous prototype for `Int_yyset_in'
lex.Int_yy.c:1892: warning: no previous prototype for `Int_yyset_out'
lex.Int_yy.c:1897: warning: no previous prototype for `Int_yyget_debug'
lex.Int_yy.c:1902: warning: no previous prototype for `Int_yyset_debug'
lex.Int_yy.c:1908: warning: no previous prototype for
`Int_yylex_destroy'
In file included from gram.y:8094:
scan.c:6021: warning: no previous prototype for `base_yyget_lineno'
scan.c:6030: warning: no previous prototype for `base_yyget_in'
scan.c:6038: warning: no previous prototype for `base_yyget_out'
scan.c:6046: warning: no previous prototype for `base_yyget_leng'
scan.c:6055: warning: no previous prototype for `base_yyget_text'
scan.c:6064: warning: no previous prototype for `base_yyset_lineno'
scan.c:6076: warning: no previous prototype for `base_yyset_in'
scan.c:6081: warning: no previous prototype for `base_yyset_out'
scan.c:6086: warning: no previous prototype for `base_yyget_debug'
scan.c:6091: warning: no previous prototype for `base_yyset_debug'
scan.c:6097: warning: no previous prototype for `base_yylex_destroy'
tablecmds.c: In function `validateForeignKeyConstraint':
tablecmds.c:3546: warning: dereferencing type-punned pointer will break
strict-a liasing rules
execQual.c: In function `ExecMakeFunctionResult':
execQual.c:737: warning: dereferencing type-punned pointer will break
strict-ali asing rules
execQual.c: In function `ExecMakeTableFunctionResult':
execQual.c:983: warning: dereferencing type-punned pointer will break
strict-ali asing rules
proc.c: In function `enable_sig_alarm':
proc.c:1016: warning: dereferencing type-punned pointer will break
strict-aliasi ng rules
proc.c: In function `disable_sig_alarm':
proc.c:1057: warning: dereferencing type-punned pointer will break
strict-aliasi ng rules
proc.c: In function `CheckStatementTimeout':
proc.c:1123: warning: dereferencing type-punned pointer will break
strict-aliasi ng rules
In file included from guc.c:4390:
lex.GUC_yy.c:1586: warning: no previous prototype for `GUC_yyget_lineno'
lex.GUC_yy.c:1595: warning: no previous prototype for `GUC_yyget_in'
lex.GUC_yy.c:1603: warning: no previous prototype for `GUC_yyget_out'
lex.GUC_yy.c:1611: warning: no previous prototype for `GUC_yyget_leng'
lex.GUC_yy.c:1620: warning: no previous prototype for `GUC_yyget_text'
lex.GUC_yy.c:1629: warning: no previous prototype for `GUC_yyset_lineno'
lex.GUC_yy.c:1641: warning: no previous prototype for `GUC_yyset_in'
lex.GUC_yy.c:1646: warning: no previous prototype for `GUC_yyset_out'
lex.GUC_yy.c:1651: warning: no previous prototype for `GUC_yyget_debug'
lex.GUC_yy.c:1656: warning: no previous prototype for `GUC_yyset_debug'
lex.GUC_yy.c:1662: warning: no previous prototype for
`GUC_yylex_destroy'
[ tsort output omitted ]
All of PostgreSQL successfully made. Ready to install.
$ gcc --version
gcc (GCC) 3.3.2 20030831 (Debian prerelease)
$ bison --version
bison (GNU Bison) 1.875a
$ flex --version
flex 2.5.31

Does this reproduce for anyone else?

-Neil

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Neil Conway <neilc@samurai.com> writes:

I'm seeing the following with the current CVS code on my Linux dev box:

In file included from bootparse.y:340:
lex.Int_yy.c:1832: warning: no previous prototype for `Int_yyget_lineno'
lex.Int_yy.c:1841: warning: no previous prototype for `Int_yyget_in'
...etc...

These are flex's fault. AFAICT flex 2.5.31 is a long way short of being
production quality. I recommend reverting to 2.5.4.

tablecmds.c: In function `validateForeignKeyConstraint':
tablecmds.c:3546: warning: dereferencing type-punned pointer will break
strict-aliasing rules

Hm. Got any idea what these are really complaining about? I see no
such gripes with the gcc versions I use, but I wouldn't be surprised
if gcc 3.3 is trying to tighten up.

regards, tom lane

On Wed, Sep 03, 2003 at 10:30:05PM -0400, Tom Lane wrote:

tablecmds.c: In function `validateForeignKeyConstraint':
tablecmds.c:3546: warning: dereferencing type-punned pointer will break
strict-aliasing rules

Hm. Got any idea what these are really complaining about? I see no
such gripes with the gcc versions I use, but I wouldn't be surprised
if gcc 3.3 is trying to tighten up.

It's about optimisation.

The compiler is free to assume that 2 pointers of a different
type never point to the same variable.

It basicly happens when you cast a pointer of 1 type to an other.

See the gcc info page for a little more information.

The recommended way to deal with is to put them into a union.

Kurt

On Thu, 2003-09-04 at 13:14, Kurt Roeckx wrote:

tablecmds.c: In function `validateForeignKeyConstraint':
tablecmds.c:3546: warning: dereferencing type-punned pointer will break
strict-aliasing rules

So, what should we do with this?

The recommended way to deal with is to put them into a union.

Yuck...

Other ways to deal with the problem include using -fno-strict-aliasing
or -Wno-strict-aliasing (to disable the optimization itself and to
disable the warnings about it, respectively).

-Neil

Neil Conway writes:

On Thu, 2003-09-04 at 13:14, Kurt Roeckx wrote:

tablecmds.c: In function `validateForeignKeyConstraint':
tablecmds.c:3546: warning: dereferencing type-punned pointer will break
strict-aliasing rules

So, what should we do with this?

Rumor has it that many of these warnings are bogus. But I wouldn't want
to turn them off altogether because that might hide real problems. At
this point, I think we should wait a while until the compiler becomes more
mature.

--
Peter Eisentraut peter_e@gmx.net

On Mon, Sep 15, 2003 at 08:09:22PM +0200, Peter Eisentraut wrote:

Neil Conway writes:

On Thu, 2003-09-04 at 13:14, Kurt Roeckx wrote:

tablecmds.c: In function `validateForeignKeyConstraint':
tablecmds.c:3546: warning: dereferencing type-punned pointer will break
strict-aliasing rules

So, what should we do with this?

Rumor has it that many of these warnings are bogus. But I wouldn't want
to turn them off altogether because that might hide real problems. At
this point, I think we should wait a while until the compiler becomes more
mature.

I agree to that.

Kurt

On Mon, Sep 15, 2003 at 08:09:22PM +0200, Peter Eisentraut wrote:

Neil Conway writes:

On Thu, 2003-09-04 at 13:14, Kurt Roeckx wrote:

tablecmds.c: In function `validateForeignKeyConstraint':
tablecmds.c:3546: warning: dereferencing type-punned pointer will break
strict-aliasing rules

So, what should we do with this?

Rumor has it that many of these warnings are bogus. But I wouldn't want
to turn them off altogether because that might hide real problems. At
this point, I think we should wait a while until the compiler becomes more
mature.

Bother - I'm just upgrading from 2.95.3 to 3.3.1 as this will be default
on NetBSD :/

Patrick