Re: [HACKERS] Compiler warnings

2017-01-02 Thread Joe Conway
On 01/02/2017 10:55 AM, Joe Conway wrote: > On the 9.2 and 9.3 branches I see two warnings: > This one once: > --- > plancache.c:1197:9: warning: ‘plan’ may be used uninitialized in this > function [-Wmaybe-uninitialized] > > And this one once per bison file: > --- >

Re: [HACKERS] Compiler warnings

2017-01-02 Thread Tom Lane
Joe Conway writes: > On 01/02/2017 11:09 AM, Tom Lane wrote: >> The bison issue is discussed in >> https://www.postgresql.org/message-id/flat/E1WpjkB-0003zA-N4%40gemulon.postgresql.org > Ah, thanks. I vaguely remember that thread now. > Looks like there was some consensus

Re: [HACKERS] Compiler warnings

2017-01-02 Thread Joe Conway
On 01/02/2017 11:09 AM, Tom Lane wrote: > Joe Conway writes: >> If there is agreement on fixing these warnings, other than the bison >> generated warning, I would be happy to do it. I'd also be happy to look >> for a fix the bison warning as well if desired, but that should be

Re: [HACKERS] Compiler warnings

2017-01-02 Thread Tom Lane
Joe Conway writes: > If there is agreement on fixing these warnings, other than the bison > generated warning, I would be happy to do it. I'd also be happy to look > for a fix the bison warning as well if desired, but that should be > handled separately I would think. The

Re: [HACKERS] Compiler warnings

2017-01-02 Thread Joe Conway
On 01/02/2017 10:18 AM, Robert Haas wrote: > On Thu, Dec 29, 2016 at 10:47 AM, Joe Conway wrote: >> Shouldn't this be back-patched? The plancache warning goes back through >> 9.2 (at least) and the lwlocks warning through 9.5 (or maybe it was 9.4). > > Warnings are going to

Re: [HACKERS] Compiler warnings

2017-01-02 Thread Robert Haas
On Thu, Dec 29, 2016 at 10:47 AM, Joe Conway wrote: > Shouldn't this be back-patched? The plancache warning goes back through > 9.2 (at least) and the lwlocks warning through 9.5 (or maybe it was 9.4). Warnings are going to be different for each individual developer, but I am

Re: [HACKERS] Compiler warnings

2016-12-29 Thread Joe Conway
On 12/06/2016 01:59 PM, Robert Haas wrote: > On Tue, Dec 6, 2016 at 3:46 PM, Stephen Frost wrote: >> Good thought, thanks! >> >> Updated patch attached with that change and I also added an Assert() to >> GetCachedPlan(), in case that code gets whacked around later and somehow

Re: [HACKERS] Compiler warnings

2016-12-06 Thread Robert Haas
On Tue, Dec 6, 2016 at 3:46 PM, Stephen Frost wrote: > Good thought, thanks! > > Updated patch attached with that change and I also added an Assert() to > GetCachedPlan(), in case that code gets whacked around later and somehow > we end up falling through without actually

Re: [HACKERS] Compiler warnings

2016-12-06 Thread Stephen Frost
Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Tue, Dec 6, 2016 at 3:23 PM, Stephen Frost wrote: > > Given the lack of screaming, I'll push the attached in a bit, which just > > initializes the two variables being complained about. As mentioned, > > there doesn't

Re: [HACKERS] Compiler warnings

2016-12-06 Thread Robert Haas
On Tue, Dec 6, 2016 at 3:23 PM, Stephen Frost wrote: > * Stephen Frost (sfr...@snowman.net) wrote: >> Not sure if anyone else has been seeing these, but I'm getting a bit >> tired of them. Neither is a live bug, but they also seem pretty simple >> to fix. The attached patch

Re: [HACKERS] Compiler warnings

2016-12-06 Thread Stephen Frost
All, * Stephen Frost (sfr...@snowman.net) wrote: > Not sure if anyone else has been seeing these, but I'm getting a bit > tired of them. Neither is a live bug, but they also seem pretty simple > to fix. The attached patch makes both of these warnings go away. At > least for my common build,

Re: [HACKERS] Compiler warnings

2016-11-29 Thread Stephen Frost
* Stephen Frost (sfr...@snowman.net) wrote: > diff --git a/src/backend/utils/cache/plancache.c > b/src/backend/utils/cache/plancache.c > new file mode 100644 > index 884cdab..b5d97c8 > *** a/src/backend/utils/cache/plancache.c > --- b/src/backend/utils/cache/plancache.c > ***

Re: [HACKERS] compiler warnings in lwlock

2015-03-26 Thread Tom Lane
Jeff Janes jeff.ja...@gmail.com writes: When building with LOCK_DEBUG but without casserts, I was getting unused variable warnings. I believe this is the correct way to silence them. Committed, thanks. regards, tom lane -- Sent via pgsql-hackers mailing list

Re: [HACKERS] compiler warnings in copy.c

2015-01-28 Thread Stephen Frost
* Andres Freund (and...@2ndquadrant.com) wrote: On 2015-01-28 15:05:11 -0500, Stephen Frost wrote: Also, you seem to have pushed these commits with a date more than two weeks in the past. Please don't do that! Oh, wow, sorry about that. I had expected a rebase to update the date.

Re: [HACKERS] compiler warnings in copy.c

2015-01-28 Thread Stephen Frost
* Robert Haas (robertmh...@gmail.com) wrote: My compiler is unhappy with the latest changes to copy.c: gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv

Re: [HACKERS] compiler warnings in copy.c

2015-01-28 Thread Andres Freund
On 2015-01-28 15:05:11 -0500, Stephen Frost wrote: Also, you seem to have pushed these commits with a date more than two weeks in the past. Please don't do that! Oh, wow, sorry about that. I had expected a rebase to update the date. It updates the committer, but not the author date. Use

Re: [HACKERS] compiler warnings on the buildfarm

2012-07-12 Thread Peter Eisentraut
On sön, 2012-07-01 at 19:04 +0200, Stefan Kaltenbrunner wrote: seeing some of the latest commits about fixing compiler warnings I took a look at the buildfarm to see if there are any interesting ones there (in total we have a thousends of warnings on the buildfarm but most of those are from

Re: [HACKERS] compiler warnings on mingw

2012-06-25 Thread Magnus Hagander
On Mon, Jun 25, 2012 at 11:42 AM, Peter Eisentraut pete...@gmx.net wrote: I've tried to cross-compile PostgreSQL from Linux to Windows, following the ideas of Andrew Dunstan [0].  This works quite well.  I see two compiler warnings altogether, which might be worth getting rid of: #1

Re: [HACKERS] Compiler warnings with stringRelOpts (was WIP: Fast GiST index build)

2011-08-09 Thread Heikki Linnakangas
On 08.08.2011 22:11, Alvaro Herrera wrote: Perhaps the easiest way to fix it is as you suggest, by declaring the struct to take a pointer rather than the value directly. Not sure how to make both cases work sanely; the add_string_reloption path will need updates. Agreed, I propose the

Re: [HACKERS] Compiler warnings with stringRelOpts (was WIP: Fast GiST index build)

2011-08-09 Thread Heikki Linnakangas
On 09.08.2011 13:25, Heikki Linnakangas wrote: On 08.08.2011 22:11, Alvaro Herrera wrote: Perhaps the easiest way to fix it is as you suggest, by declaring the struct to take a pointer rather than the value directly. Not sure how to make both cases work sanely; the add_string_reloption path

Re: [HACKERS] Compiler warnings with stringRelOpts (was WIP: Fast GiST index build)

2011-08-09 Thread Alvaro Herrera
Excerpts from Heikki Linnakangas's message of mar ago 09 08:32:43 -0400 2011: On 09.08.2011 13:25, Heikki Linnakangas wrote: On 08.08.2011 22:11, Alvaro Herrera wrote: Perhaps the easiest way to fix it is as you suggest, by declaring the struct to take a pointer rather than the value

Re: [HACKERS] Compiler warnings with stringRelOpts (was WIP: Fast GiST index build)

2011-08-09 Thread Heikki Linnakangas
On 09.08.2011 18:04, Alvaro Herrera wrote: Excerpts from Heikki Linnakangas's message of mar ago 09 08:32:43 -0400 2011: On 09.08.2011 13:25, Heikki Linnakangas wrote: On 08.08.2011 22:11, Alvaro Herrera wrote: Perhaps the easiest way to fix it is as you suggest, by declaring the struct to

Re: [HACKERS] Compiler warnings with stringRelOpts (was WIP: Fast GiST index build)

2011-08-09 Thread Tom Lane
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: On 09.08.2011 18:04, Alvaro Herrera wrote: I think I vaguely remember that the reason for doing it this way is that the copy into the relcache worked, i.e. if the originals went away, there was no dangling pointer. Did you test

Re: [HACKERS] Compiler warnings with stringRelOpts (was WIP: Fast GiST index build)

2011-08-08 Thread Alvaro Herrera
Excerpts from Alexander Korotkov's message of lun ago 08 06:27:33 -0400 2011: String-formatted relopts was never used before, but I've used it in buffering GiST index build patch and encountered with following compiler warnings: reloptions.c:259: warning: initializer-string for array of

Re: [HACKERS] Compiler warnings with stringRelOpts (was WIP: Fast GiST index build)

2011-08-08 Thread Alexander Korotkov
On Mon, Aug 8, 2011 at 7:43 PM, Alvaro Herrera alvhe...@commandprompt.comwrote: Maybe this needs to use the new FLEXIBLE_ARRAY_MEMBER stuff. Can you try that please? typedef struct relopt_string { relopt_gen gen; int default_len; bool default_isnull; validate_string_relopt validate_cb;

Re: [HACKERS] Compiler warnings with stringRelOpts (was WIP: Fast GiST index build)

2011-08-08 Thread Alvaro Herrera
Excerpts from Alexander Korotkov's message of lun ago 08 11:50:53 -0400 2011: On Mon, Aug 8, 2011 at 7:43 PM, Alvaro Herrera alvhe...@commandprompt.comwrote: Maybe this needs to use the new FLEXIBLE_ARRAY_MEMBER stuff. Can you try that please? typedef struct relopt_string {

Re: [HACKERS] Compiler warnings with stringRelOpts (was WIP: Fast GiST index build)

2011-08-08 Thread Alexander Korotkov
On Mon, Aug 8, 2011 at 8:27 PM, Alvaro Herrera alvhe...@commandprompt.comwrote: An array of relopt_string? Isn't that a bit strange? If I recall correctly, the point of this was to be able to allocate the relopt_string struct and the char array itself as a single palloc unit, in a single

Re: [HACKERS] Compiler warnings with stringRelOpts (was WIP: Fast GiST index build)

2011-08-08 Thread Alvaro Herrera
Excerpts from Alexander Korotkov's message of lun ago 08 13:21:17 -0400 2011: On Mon, Aug 8, 2011 at 8:27 PM, Alvaro Herrera alvhe...@commandprompt.comwrote: An array of relopt_string? Isn't that a bit strange? If I recall correctly, the point of this was to be able to allocate the

Re: [HACKERS] compiler warnings with GCC 4.5

2010-01-17 Thread Tom Lane
Peter Eisentraut pete...@gmx.net writes: read.c: In function ‘nodeRead’: read.c:370:3: warning: case value ‘101’ not in enumerated type ‘NodeTag’ This can be fixed by changing switch (type) to switch ((int) type) No objection from here. We don't attempt to cover

Re: [HACKERS] Compiler warnings fix

2009-01-27 Thread Magnus Hagander
ITAGAKI Takahiro wrote: Here is a patch to surpress compiler warnings in pg_locale.c and pg_regress.c. There are following warnings if nls is enabled: pg_locale.c: In function `pg_perm_setlocale': pg_locale.c:161: warning: assignment discards qualifiers from pointer target type

Re: [HACKERS] Compiler warnings fix

2009-01-26 Thread Peter Eisentraut
ITAGAKI Takahiro wrote: Here is a patch to surpress compiler warnings in pg_locale.c and pg_regress.c. There are following warnings if nls is enabled: pg_locale.c: In function `pg_perm_setlocale': pg_locale.c:161: warning: assignment discards qualifiers from pointer target type and if

Re: [HACKERS] Compiler warnings fix

2009-01-26 Thread ITAGAKI Takahiro
Peter Eisentraut pete...@gmx.net wrote: ITAGAKI Takahiro wrote: Here is a patch to surpress compiler warnings in pg_locale.c and pg_regress.c. There are following warnings if nls is enabled: pg_locale.c: In function `pg_perm_setlocale': pg_locale.c:161: warning: assignment

Re: [HACKERS] Compiler warnings fix

2009-01-26 Thread Andrew Dunstan
ITAGAKI Takahiro wrote: Peter Eisentraut pete...@gmx.net wrote: ITAGAKI Takahiro wrote: Here is a patch to surpress compiler warnings in pg_locale.c and pg_regress.c. There are following warnings if nls is enabled: pg_locale.c: In function `pg_perm_setlocale':

Re: [HACKERS] Compiler warnings fix

2009-01-26 Thread Tom Lane
Andrew Dunstan and...@dunslane.net writes: There are same warning on vaquita in buildfarm. http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=vaquitadt=2009-01-26%20210011stg=make Wouldn't we be better off using defined(ENABLE_NLS) instead of defined(LC_MESSAGES) ? No, because the

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-17 Thread Zdenek Kotala
Stefan Kaltenbrunner napsal(a): Zdenek Kotala wrote: Stefan Kaltenbrunner wrote: Zdenek Kotala wrote: Stefan Kaltenbrunner wrote: Zdenek Kotala wrote: For sun studio -erroff=E_STATEMENT_NOT_REACHED is useful there. If you want to determine warning tags for each warning add -errtags. Is

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-17 Thread Tom Lane
Zdenek Kotala [EMAIL PROTECTED] writes: E_FUNC_HAS_NO_RETURN_STMT is there because main is leaved by exit() instead return. And In another case It should be regular warning. That should be gone now; I changed the two places that triggered it. I'd suggest not disabling that warning.

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-17 Thread Zdenek Kotala
Tom Lane napsal(a): Zdenek Kotala [EMAIL PROTECTED] writes: E_FUNC_HAS_NO_RETURN_STMT is there because main is leaved by exit() instead return. And In another case It should be regular warning. That should be gone now; I changed the two places that triggered it. I'd suggest not disabling that

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-17 Thread Tom Lane
Zdenek Kotala [EMAIL PROTECTED] writes: Tom Lane napsal(a): That should be gone now; I changed the two places that triggered it. I'd suggest not disabling that warning. Yes I agree. Did you also clean up on old branches? No, I'm not interested in doing that kind of fiddling on old branches.

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-16 Thread Gregory Stark
Do any of the build farm machines not support 64-bit integers? I just added a --enable-bigint flag to configure.in and tested building without it and got an error at xlog.c: xlog.c: In function 'ValidXLOGHeader': xlog.c:3240: error: 'UINT64_FORMAT' undeclared (first use in this function)

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-16 Thread Tom Lane
Gregory Stark [EMAIL PROTECTED] writes: It's possible I've done the autoconf hackery wrong though. Should UINT64_FORMAT still be defined if there's no int64? Yes. regards, tom lane ---(end of broadcast)--- TIP 9: In

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-16 Thread Zdenek Kotala
Stefan Kaltenbrunner wrote: Zdenek Kotala wrote: Stefan Kaltenbrunner wrote: Zdenek Kotala wrote: For sun studio -erroff=E_STATEMENT_NOT_REACHED is useful there. If you want to determine warning tags for each warning add -errtags. Is that supported on all versions of sun studio(Sun WorkShop

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-16 Thread Stefan Kaltenbrunner
Zdenek Kotala wrote: Stefan Kaltenbrunner wrote: Zdenek Kotala wrote: Stefan Kaltenbrunner wrote: Zdenek Kotala wrote: For sun studio -erroff=E_STATEMENT_NOT_REACHED is useful there. If you want to determine warning tags for each warning add -errtags. Is that supported on all versions of

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-16 Thread Gregory Stark
Stefan Kaltenbrunner [EMAIL PROTECTED] writes: pgstat.c, line 652: warning: const object should have initializer: all_zeroes (E_CONST_OBJ_SHOULD_HAVE_INITIZR) pgstat.c, line 2118: warning: const object should have initializer: all_zeroes (E_CONST_OBJ_SHOULD_HAVE_INITIZR) Man, even these are

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-15 Thread Stefan Kaltenbrunner
Zdenek Kotala wrote: Stefan Kaltenbrunner wrote: Zdenek Kotala wrote: For sun studio -erroff=E_STATEMENT_NOT_REACHED is useful there. If you want to determine warning tags for each warning add -errtags. Is that supported on all versions of sun studio(Sun WorkShop 6, Sun Studio 8,11) we

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-15 Thread Tom Lane
Stefan Kaltenbrunner [EMAIL PROTECTED] writes: Tom Lane wrote: What I suspect is happening is that lionfish is running the buildfarm script in a non-C locale, in which flex finds that some high-bit-set characters are case-folded by tolower() and accordingly issues this complaint. Now the

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-15 Thread Tom Lane
Stefan Kaltenbrunner [EMAIL PROTECTED] writes: and this is the initial list for contrib(excluding a lot of duplicate warnings and stuff that is a result of invalid compiler flags which I will mention seperatly): I fixed most of these, I believe. A couple remain untouched: animal: cuckoo

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-15 Thread Tom Lane
Gregory Stark [EMAIL PROTECTED] writes: Tom Lane [EMAIL PROTECTED] writes: Anyway, I tweaked plpgsql's Makefile to force LC_CTYPE=3DC, which theoretically should silence this warning. This doesn't mean that people were previousy able to use any of these exot= ic characters like a=DFertion

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-15 Thread Tom Lane
Chris Browne [EMAIL PROTECTED] writes: Tom Lane wrote: animal: grebe warnings: 45 xlog.c:651: warning: implicit declaration of function '_check_lock' xlog.c:654: warning: implicit declaration of function '_clear_lock' hba.c:1449: warning: implicit declaration of function

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-13 Thread Stefan Kaltenbrunner
Tom Lane wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: animal: lionfishwarnings: 16 scan.l:180: warning, the character range [80-FF] is ambiguous in a case-insensitive scanner scan.l:180: warning, the character range [80-FF] is ambiguous in a case-insensitive scanner

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-13 Thread Stefan Kaltenbrunner
Tom Lane wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: some more(I have removed duplicates and ones that should be fixed by your latest commits though): I did what I could with this batch. Some comments: animal: salamander warnings: 27 cash.c: In function `cash_in':

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-13 Thread Stefan Kaltenbrunner
Tom Lane wrote: [...] animal: clownfish warnings: 12 dynloader.c, line 4: warning: empty translation unit postgres.c, line 3758: warning: loop not entered at top The first of these is not a bug, the second seems to be some weird aberration in their statement-not-reached detection.

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-13 Thread Stefan Kaltenbrunner
Tom Lane wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: ok I did that for a few members (removing all the statement not reached ones as well as some purely informal notices and all the flex related warnings) and came up with something similiar to: [snip] Yeah, this looks like a good

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-13 Thread Tom Lane
Heikki Linnakangas [EMAIL PROTECTED] writes: Zdenek Kotala wrote: I don't see any const keyword there. Right after that: where int conv(int num_msg, const struct pam_message **msg, struct pam_response **resp, void *appdata_ptr); How confusing... And the pam_start page he cited earlier

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-13 Thread Zdenek Kotala
Heikki Linnakangas wrote: Zdenek Kotala wrote: If I look there http://www.opengroup.org/onlinepubs/008329799/chap5.htm#tagcjh_06 in Call Back Information section. The structure is defined as struct pam_conv{ int (*conv) (int, struct pam_message **, struct pam_response **, void *); void

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-13 Thread Kris Jurka
On Fri, 13 Jul 2007, Zdenek Kotala wrote: Tom Lane wrote: Kris Jurka [EMAIL PROTECTED] writes: So pam_message ** isn't const. Ah, thanks. I see luna_moth is giving the same warning, so it's still not const in Solaris 11 either. Is it worth working around this? It's strictly cosmetic

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-13 Thread Zdenek Kotala
Stefan Kaltenbrunner wrote: Zdenek Kotala wrote: For sun studio -erroff=E_STATEMENT_NOT_REACHED is useful there. If you want to determine warning tags for each warning add -errtags. Is that supported on all versions of sun studio(Sun WorkShop 6, Sun Studio 8,11) we have on the farm ? Yes.

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-13 Thread Heikki Linnakangas
Zdenek Kotala wrote: If I look there http://www.opengroup.org/onlinepubs/008329799/chap5.htm#tagcjh_06 in Call Back Information section. The structure is defined as struct pam_conv{ int (*conv) (int, struct pam_message **, struct pam_response **, void *); void *appdata_ptr; }; I don't

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-13 Thread Zdenek Kotala
Kris Jurka wrote: On Fri, 13 Jul 2007, Zdenek Kotala wrote: Tom Lane wrote: Kris Jurka [EMAIL PROTECTED] writes: So pam_message ** isn't const. Ah, thanks. I see luna_moth is giving the same warning, so it's still not const in Solaris 11 either. Is it worth working around this? It's

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-13 Thread Zdenek Kotala
Tom Lane wrote: Kris Jurka [EMAIL PROTECTED] writes: So pam_message ** isn't const. Ah, thanks. I see luna_moth is giving the same warning, so it's still not const in Solaris 11 either. Is it worth working around this? It's strictly cosmetic AFAICS. The main issue in my mind would be how

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-13 Thread Zdenek Kotala
Stefan Kaltenbrunner wrote: Peter Eisentraut wrote: Am Donnerstag, 12. Juli 2007 15:25 schrieb Stefan Kaltenbrunner: a lot of those are simply noise (like the LOOP VECTORIZED stuff from the icc boxes or the statement not reached spam from the sun compilers) but others might indicate real

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-13 Thread Zdenek Kotala
Tom Lane wrote: Heikki Linnakangas [EMAIL PROTECTED] writes: Zdenek Kotala wrote: I don't see any const keyword there. Right after that: where int conv(int num_msg, const struct pam_message **msg, struct pam_response **resp, void *appdata_ptr); How confusing... And the pam_start

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-13 Thread Zdenek Kotala
Kris Jurka wrote: On Thu, 12 Jul 2007, Tom Lane wrote: static int pam_passwd_conv_proc(int num_msg, const struct pam_message ** msg, struct pam_response ** resp, void *appdata_ptr); which exactly matches what my Fedora 6 pam header file says it should be. What is it on

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-13 Thread Stefan Kaltenbrunner
Zdenek Kotala wrote: Stefan Kaltenbrunner wrote: Peter Eisentraut wrote: Am Donnerstag, 12. Juli 2007 15:25 schrieb Stefan Kaltenbrunner: a lot of those are simply noise (like the LOOP VECTORIZED stuff from the icc boxes or the statement not reached spam from the sun compilers) but others

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-13 Thread Chris Browne
[EMAIL PROTECTED] (Stefan Kaltenbrunner) writes: Tom Lane wrote: [...] animal: clownfish warnings: 12 dynloader.c, line 4: warning: empty translation unit postgres.c, line 3758: warning: loop not entered at top The first of these is not a bug, the second seems to be some weird

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-12 Thread Tom Lane
Stefan Kaltenbrunner [EMAIL PROTECTED] writes: What is the official stance on handling compiler warnings? The compilers I use give me 1 or 2 warnings on HEAD, coming from flex's sloppiness about not generating unused code. I wouldn't care to work with a compiler that generated more than a few.

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-12 Thread Peter Eisentraut
Am Donnerstag, 12. Juli 2007 15:25 schrieb Stefan Kaltenbrunner: a lot of those are simply noise (like the LOOP VECTORIZED stuff from the icc boxes or the statement not reached spam from the sun compilers) but others might indicate real issues. To find warnings that might be a real problem we

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-12 Thread Stefan Kaltenbrunner
Tom Lane wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: What is the official stance on handling compiler warnings? The compilers I use give me 1 or 2 warnings on HEAD, coming from flex's sloppiness about not generating unused code. I wouldn't care to work with a compiler that

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-12 Thread Stefan Kaltenbrunner
Peter Eisentraut wrote: Am Donnerstag, 12. Juli 2007 15:25 schrieb Stefan Kaltenbrunner: a lot of those are simply noise (like the LOOP VECTORIZED stuff from the icc boxes or the statement not reached spam from the sun compilers) but others might indicate real issues. To find warnings that

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-12 Thread Tom Lane
Stefan Kaltenbrunner [EMAIL PROTECTED] writes: ok I did that for a few members (removing all the statement not reached ones as well as some purely informal notices and all the flex related warnings) and came up with something similiar to: [snip] Yeah, this looks like a good list. I can't

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-12 Thread Magnus Hagander
Tom Lane wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: ok I did that for a few members (removing all the statement not reached ones as well as some purely informal notices and all the flex related warnings) and came up with something similiar to: [snip] Yeah, this looks like a good

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-12 Thread Tom Lane
Magnus Hagander [EMAIL PROTECTED] writes: Tom Lane wrote: Yeah, this looks like a good list. I can't readily check the ones from eel as they appear to be in Windows-specific code; anyone else want to fix those? The pg_ctl one is a windows one, I'll deal with that one. The dirmod one

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-12 Thread Magnus Hagander
Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: Tom Lane wrote: Yeah, this looks like a good list. I can't readily check the ones from eel as they appear to be in Windows-specific code; anyone else want to fix those? The pg_ctl one is a windows one, I'll deal with that one.

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-12 Thread Stefan Kaltenbrunner
Tom Lane wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: ok I did that for a few members (removing all the statement not reached ones as well as some purely informal notices and all the flex related warnings) and came up with something similiar to: [snip] Yeah, this looks like a good

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-12 Thread Alvaro Herrera
Stefan showed me via Jabber this warning: /tmp/ccM7MfqX.s: Assembler messages: /tmp/ccM7MfqX.s:703: Warning: 0003fffc shortened to fffc /tmp/ccM7MfqX.s:738: Warning: 0003fffc shortened to fffc He says that this comes from trgm_op.c file. I don't get the

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-12 Thread Stefan Kaltenbrunner
Alvaro Herrera wrote: Stefan showed me via Jabber this warning: /tmp/ccM7MfqX.s: Assembler messages: /tmp/ccM7MfqX.s:703: Warning: 0003fffc shortened to fffc /tmp/ccM7MfqX.s:738: Warning: 0003fffc shortened to fffc He says that this comes from

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-12 Thread Heikki Linnakangas
Alvaro Herrera wrote: Stefan showed me via Jabber this warning: /tmp/ccM7MfqX.s: Assembler messages: /tmp/ccM7MfqX.s:703: Warning: 0003fffc shortened to fffc /tmp/ccM7MfqX.s:738: Warning: 0003fffc shortened to fffc He says that this comes from trgm_op.c

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-12 Thread Alvaro Herrera
Heikki Linnakangas wrote: Alvaro Herrera wrote: Stefan showed me via Jabber this warning: /tmp/ccM7MfqX.s: Assembler messages: /tmp/ccM7MfqX.s:703: Warning: 0003fffc shortened to fffc /tmp/ccM7MfqX.s:738: Warning: 0003fffc shortened to fffc He says

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-12 Thread Gregory Stark
Heikki Linnakangas [EMAIL PROTECTED] writes: Alvaro Herrera wrote: Stefan showed me via Jabber this warning: /tmp/ccM7MfqX.s: Assembler messages: /tmp/ccM7MfqX.s:703: Warning: 0003fffc shortened to fffc /tmp/ccM7MfqX.s:738: Warning: 0003fffc shortened to

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-12 Thread Heikki Linnakangas
Alvaro Herrera wrote: Heikki Linnakangas wrote: Alvaro Herrera wrote: Stefan showed me via Jabber this warning: /tmp/ccM7MfqX.s: Assembler messages: /tmp/ccM7MfqX.s:703: Warning: 0003fffc shortened to fffc /tmp/ccM7MfqX.s:738: Warning: 0003fffc shortened to

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-12 Thread Tom Lane
Heikki Linnakangas [EMAIL PROTECTED] writes: Hmm. It looks like I get that warning on my laptop as well. I tracked it down to these two places: Line 209: while (ptr - GETARR(trg) ARRNELEM(trg)) { text *item = (text *) palloc(VARHDRSZ + 3); SET_VARSIZE(item,

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-12 Thread Gregory Stark
Heikki Linnakangas [EMAIL PROTECTED] writes: The warning seems to be in related array indexing. If you replace ptr - GETARR(trg) with a constant, the warning goes away. But having i = ptr - GETARR(trg) in there doesn't give a warning. Can you compile with -save-temps and send the

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-12 Thread Tom Lane
Gregory Stark [EMAIL PROTECTED] writes: If it does constant propagation without handling overflow it could end up with: (olddatum 2 2) 0x3FFFC note that in fact truncating the high two bits as the assembler did would in fact be the correct thing to do here which would explain why it

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-12 Thread Heikki Linnakangas
Tom Lane wrote: Heikki Linnakangas [EMAIL PROTECTED] writes: Hmm. It looks like I get that warning on my laptop as well. I tracked it down to these two places: Line 209: while (ptr - GETARR(trg) ARRNELEM(trg)) { text *item = (text *) palloc(VARHDRSZ + 3);

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-12 Thread Heikki Linnakangas
Tom Lane wrote: Heikki Linnakangas [EMAIL PROTECTED] writes: Hmm. It looks like I get that warning on my laptop as well. I tracked it down to these two places: Line 209: while (ptr - GETARR(trg) ARRNELEM(trg)) { text *item = (text *) palloc(VARHDRSZ + 3);

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-12 Thread Tom Lane
Stefan Kaltenbrunner [EMAIL PROTECTED] writes: ok I did that for a few members (removing all the statement not reached ones as well as some purely informal notices and all the flex related warnings) and came up with something similiar to: I've cleaned up most of this first batch. Open issues

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-12 Thread Heikki Linnakangas
Gregory Stark wrote: Heikki Linnakangas [EMAIL PROTECTED] writes: The warning seems to be in related array indexing. If you replace ptr - GETARR(trg) with a constant, the warning goes away. But having i = ptr - GETARR(trg) in there doesn't give a warning. Can you compile with -save-temps and

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-12 Thread Tom Lane
Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: Somebody needs to figure out whether we are supposed to be using pgsymlink on Cygwin. According to port.h: * Cygwin has its own symlinks which work on Win95/98/ME where * junction points don't, so use it instead. We have no way

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-12 Thread Andrew Dunstan
Tom Lane wrote: animal: eel warnings: 4 dirmod.c:206: warning: no previous prototype for 'pgsymlink' Somebody needs to figure out whether we are supposed to be using pgsymlink on Cygwin. According to port.h: * Cygwin has its own symlinks which work on Win95/98/ME

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-12 Thread Tom Lane
Heikki Linnakangas [EMAIL PROTECTED] writes: FWIW, this patch makes the warnings go away, and makes the code a little bit more readable as well. It would be nice to understand why exactly it's complaining, though. Let's apply the patch. We are clearly tickling a bug or near-bug in gcc, and

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-12 Thread Tom Lane
Stefan Kaltenbrunner [EMAIL PROTECTED] writes: animal: dragonfly warnings: 67 auth.c:61: warning: initialization from incompatible pointer type animal: emperor_mothwarnings: 10 auth.c:61: warning: initialization from incompatible pointer type Apparently, Solaris 9 and 10

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-12 Thread Heikki Linnakangas
Tom Lane wrote: At the same time, if anyone wants to trim the existing code down to a small test case, I'm sure the gcc boys would appreciate a bug report. I reduced it to a self-contained test case, and filed bug in GCC bugzilla: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32750

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-12 Thread Kris Jurka
On Thu, 12 Jul 2007, Tom Lane wrote: static int pam_passwd_conv_proc(int num_msg, const struct pam_message ** msg, struct pam_response ** resp, void *appdata_ptr); which exactly matches what my Fedora 6 pam header file says it should be. What is it on those Solaris

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-12 Thread Tom Lane
Kris Jurka [EMAIL PROTECTED] writes: So pam_message ** isn't const. Ah, thanks. I see luna_moth is giving the same warning, so it's still not const in Solaris 11 either. Is it worth working around this? It's strictly cosmetic AFAICS. The main issue in my mind would be how to determine

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-12 Thread Jeremy Drake
On Thu, 12 Jul 2007, Stefan Kaltenbrunner wrote: What would probably be useful if you want to pursue this is to filter out the obvious spam like statement-not-reached, and see what's left. I had gone through and looked at the warnings on mongoose before, but I am running it against the

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-12 Thread Tom Lane
Stefan Kaltenbrunner [EMAIL PROTECTED] writes: animal: lionfishwarnings: 16 scan.l:180: warning, the character range [80-FF] is ambiguous in a case-insensitive scanner scan.l:180: warning, the character range [80-FF] is ambiguous in a case-insensitive scanner scan.l:302: warning,

Re: [HACKERS] compiler warnings on the buildfarm

2007-07-12 Thread Tom Lane
Stefan Kaltenbrunner [EMAIL PROTECTED] writes: some more(I have removed duplicates and ones that should be fixed by your latest commits though): I did what I could with this batch. Some comments: animal: salamander warnings: 27 cash.c: In function `cash_in': cash.c:244: warning:

Re: [HACKERS] Compiler warnings

2007-04-19 Thread Alvaro Herrera
Bruce Momjian wrote: I am seeing the following compiler warnings in CVS HEAD: analyze.c:471: warning: `diff' might be used uninitialized in this function vacuumlazy.c:220: warning: `diff' might be used uninitialized in this function Are you using too old a compiler? Mine

Re: [HACKERS] Compiler warnings

2007-04-19 Thread Bruce Momjian
Alvaro Herrera wrote: Bruce Momjian wrote: I am seeing the following compiler warnings in CVS HEAD: analyze.c:471: warning: `diff' might be used uninitialized in this function vacuumlazy.c:220: warning: `diff' might be used uninitialized in this function Are you using

Re: [HACKERS] Compiler warnings

2007-04-19 Thread Alvaro Herrera
Bruce Momjian wrote: Alvaro Herrera wrote: Bruce Momjian wrote: I am seeing the following compiler warnings in CVS HEAD: analyze.c:471: warning: `diff' might be used uninitialized in this function vacuumlazy.c:220: warning: `diff' might be used uninitialized in this

Re: [HACKERS] compiler warnings from cvs tip

2002-07-18 Thread Tom Lane
Joe Conway [EMAIL PROTECTED] writes: I'm getting the warnings below from current cvs. I see the same. gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include -c -o conv.o conv.c -MMD conv.c:41: warning: `euc_kr2mic' defined but not used conv.c:67: warning:

  1   2   >