compile bug in HEAD?

Started by Christopher Kings-Lynnealmost 24 years ago10 messages

Christopher Kings-Lynne

chriskl@familyhealth.com.au

almost 24 years ago

I don't think this is me...

gcc -pipe -O -Wall -Wmissing-prototypes -Wmissing-declarations -Wno-error -I
./../include -I. -I../../../../src/include -DMAJOR_VERSION=2 -DMINOR_VERSIO
N=10 -DPATCHLEVEL=0 -DINCLUDE_PATH=\"/home/chriskl/local/include\" -c -o
pgc.o pgc.c
pgc.c: In function `yylex':
pgc.c:1250: warning: label `find_rule' defined but not used
pgc.l: At top level:
pgc.c:3079: warning: `yy_flex_realloc' defined but not used

Chris

nbazin@ingenico.com.au

almost 24 years ago

In reply to: Christopher Kings-Lynne (#1)

Re: compile bug in HEAD?

It's more warnings than bugs. I also have seen that but not familiar enough
with bison or yacc to think more of it. Have you got an idea on how to fix
these warnings?
----- Original Message -----
From: "Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
To: "Hackers" <pgsql-hackers@postgresql.org>
Sent: Wednesday, March 27, 2002 4:24 PM
Subject: [HACKERS] compile bug in HEAD?

I don't think this is me...

gcc -pipe -O -Wall -Wmissing-prototypes -Wmissing-declarations -Wno-error -I

./../include -I. -I../../../../src/include -DMAJOR_VERSION=2 -DMINOR_VERSIO

Show quoted text

N=10 -DPATCHLEVEL=0 -DINCLUDE_PATH=\"/home/chriskl/local/include\" -c -o
pgc.o pgc.c
pgc.c: In function `yylex':
pgc.c:1250: warning: label `find_rule' defined but not used
pgc.l: At top level:
pgc.c:3079: warning: `yy_flex_realloc' defined but not used

Chris

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

pgman@candle.pha.pa.us

almost 24 years ago

In reply to: Christopher Kings-Lynne (#1)

Re: compile bug in HEAD?

Christopher Kings-Lynne wrote:

I don't think this is me...

gcc -pipe -O -Wall -Wmissing-prototypes -Wmissing-declarations -Wno-error -I
./../include -I. -I../../../../src/include -DMAJOR_VERSION=2 -DMINOR_VERSIO
N=10 -DPATCHLEVEL=0 -DINCLUDE_PATH=\"/home/chriskl/local/include\" -c -o
pgc.o pgc.c
pgc.c: In function `yylex':
pgc.c:1250: warning: label `find_rule' defined but not used
pgc.l: At top level:
pgc.c:3079: warning: `yy_flex_realloc' defined but not used

Yes, I have gotten the same warning for several releases but haven't
researched the cause. Patch?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

tgl@sss.pgh.pa.us

almost 24 years ago

In reply to: Nicolas Bazin (#2)

Re: compile bug in HEAD?

"Nicolas Bazin" <nbazin@ingenico.com.au> writes:

It's more warnings than bugs. I also have seen that but not familiar enough
with bison or yacc to think more of it. Have you got an idea on how to fix
these warnings?

ecpg's lexer has always generated those warnings, and so has plpgsql's
lexer. AFAICT the sloppy C code is triggered by use of yylineno.
Suggest griping to the flex authors.

regards, tom lane

Peter Eisentraut

peter_e@gmx.net

almost 24 years ago

In reply to: Bruce Momjian (#3)

Re: compile bug in HEAD?

Bruce Momjian writes:

Christopher Kings-Lynne wrote:

I don't think this is me...

gcc -pipe -O -Wall -Wmissing-prototypes -Wmissing-declarations -Wno-error -I
./../include -I. -I../../../../src/include -DMAJOR_VERSION=2 -DMINOR_VERSIO
N=10 -DPATCHLEVEL=0 -DINCLUDE_PATH=\"/home/chriskl/local/include\" -c -o
pgc.o pgc.c
pgc.c: In function `yylex':
pgc.c:1250: warning: label `find_rule' defined but not used
pgc.l: At top level:
pgc.c:3079: warning: `yy_flex_realloc' defined but not used

Yes, I have gotten the same warning for several releases but haven't
researched the cause. Patch?

If someone is really bored out of their mind, at least one of these
warnings can be gotten rid of by not using the -l option to flex. That
might be desirable for other reasons, too, one of which is improved speed.

No, just removing -l from the makefile is not the right fix.

--
Peter Eisentraut peter_e@gmx.net

nconway@klamath.dyndns.org

almost 24 years ago

In reply to: Peter Eisentraut (#5)

Re: compile bug in HEAD?

On Wed, 2002-03-27 at 11:06, Peter Eisentraut wrote:

If someone is really bored out of their mind, at least one of these
warnings can be gotten rid of by not using the -l option to flex. That
might be desirable for other reasons, too, one of which is improved speed.

No, just removing -l from the makefile is not the right fix.

I'm curious; why is this "not the right fix"? According to the manpage:

-l turns on maximum compatibility with the original
AT&T lex implementation. Note that this does not
mean full compatibility. Use of this option
costs a considerable amount of performance...

Cheers,

Neil

--
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC

Peter Eisentraut

peter_e@gmx.net

almost 24 years ago

In reply to: Neil Conway (#6)

Re: compile bug in HEAD?

Neil Conway writes:

I'm curious; why is this "not the right fix"? According to the manpage:

-l turns on maximum compatibility with the original
AT&T lex implementation. Note that this does not
mean full compatibility. Use of this option
costs a considerable amount of performance...

The manpage also lists the specific incompatibilities. I think we should
not be affected by them, but someone better check before removing the -l.

--
Peter Eisentraut peter_e@gmx.net

nconway@klamath.dyndns.org

almost 24 years ago

In reply to: Peter Eisentraut (#7)

Re: compile bug in HEAD?

On Wed, Mar 27, 2002 at 07:56:15PM -0500, Peter Eisentraut wrote:

Neil Conway writes:

I'm curious; why is this "not the right fix"? According to the manpage:

-l turns on maximum compatibility with the original
AT&T lex implementation. Note that this does not
mean full compatibility. Use of this option
costs a considerable amount of performance...

The manpage also lists the specific incompatibilities. I think we should
not be affected by them, but someone better check before removing the -l.

AFAICT current sources don't actually use "-l" anywhere.

However, it does appear that we can tweak flex for more performance
(usually at the expense of a larger generated parser). In particular, it
looks like we could use "-Cf" or "-CF". Is this a good idea?

While we're on the subject of minor optimizations, is there a reason why
we execute gcc with "-O2" rather than "-O3" during compilation?

Cheers,

Neil

--
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC

Peter Eisentraut

peter_e@gmx.net

almost 24 years ago

In reply to: Noname (#8)

Re: compile bug in HEAD?

Neil Conway writes:

However, it does appear that we can tweak flex for more performance
(usually at the expense of a larger generated parser). In particular, it
looks like we could use "-Cf" or "-CF". Is this a good idea?

Probably. Run some performance tests if you like. It looks like -CFea
might be a reasonable candidate.

While we're on the subject of minor optimizations, is there a reason why
we execute gcc with "-O2" rather than "-O3" during compilation?

Mainly because everyone does it this way. Probably because it's a
reasonable compromise between execution speed, compilation speed,
debuggability, and compiler bugs.

--
Peter Eisentraut peter_e@gmx.net

pgman@candle.pha.pa.us

over 23 years ago

In reply to: Noname (#8)

Re: compile bug in HEAD?

Neil Conway wrote:

On Wed, Mar 27, 2002 at 07:56:15PM -0500, Peter Eisentraut wrote:

Neil Conway writes:

I'm curious; why is this "not the right fix"? According to the manpage:

-l turns on maximum compatibility with the original
AT&T lex implementation. Note that this does not
mean full compatibility. Use of this option
costs a considerable amount of performance...

The manpage also lists the specific incompatibilities. I think we should
not be affected by them, but someone better check before removing the -l.

AFAICT current sources don't actually use "-l" anywhere.

However, it does appear that we can tweak flex for more performance
(usually at the expense of a larger generated parser). In particular, it
looks like we could use "-Cf" or "-CF". Is this a good idea?

While we're on the subject of minor optimizations, is there a reason why
we execute gcc with "-O2" rather than "-O3" during compilation?

Added to TODO:

* Try flex flags -Cf and -CF to see if performance improves

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026