Thread: 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 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
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 > 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 >
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, Pennsylvania19026
"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
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
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 originalAT&T lex implementation. Note that this does notmean full compatibility. Use of this option costs a considerable amount of performance... Cheers, Neil -- Neil Conway <neilconway@rogers.com> PGP Key ID: DB3C29FC
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
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
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
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, Pennsylvania19026