Mark Dilger writes:
>> On Feb 17, 2017, at 3:37 PM, Peter Eisentraut
>> wrote:
>> If your compiler isn't warning about anything with that, then there is
>> something wrong with it.
> $ gcc --version
> Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
> --with-gxx-include
> On Feb 17, 2017, at 3:37 PM, Peter Eisentraut
> wrote:
>
> On 2/17/17 16:13, Mark Dilger wrote:
>> + PGAC_PROG_CC_CFLAGS_OPT([-Wc++-compat])
>
> If your compiler isn't warning about anything with that, then there is
> something wrong with it.
$ gcc --version
Configured with: --prefix=/App
On 2/17/17 16:13, Mark Dilger wrote:
> + PGAC_PROG_CC_CFLAGS_OPT([-Wc++-compat])
If your compiler isn't warning about anything with that, then there is
something wrong with it.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Trainin
I wrote:
> Right now I'd rather focus on getting to where we can have -Werror on in
> the buildfarm at all. longfin says we've got work to do on that, at least
> in the back branches. It may be that we can't expect near-EOL branches to
> always compile perfectly cleanly on newer compilers.
I fou
Mark Dilger writes:
> if test "$GCC" = yes -a "$ICC" = no; then
>CFLAGS="-Wall -Wmissing-prototypes -Wpointer-arith"
> + PGAC_PROG_CC_CFLAGS_OPT([-Wempty-body])
> + PGAC_PROG_CC_CFLAGS_OPT([-Wignored-qualifiers])
> + PGAC_PROG_CC_CFLAGS_OPT([-Wimplicit-fallthrough])
> + PGAC_PROG_CC_CFLAG
On February 17, 2017 1:13:10 PM PST, Mark Dilger
wrote:
>How about we add (some of) these extra warnings, plus -Werror,
>in a section that is only active for platforms/compilers where we
>know there aren't spurious warnings? That would make detecting
>unintentionally introduced warnings simple
> On Feb 17, 2017, at 12:21 PM, Tom Lane wrote:
>
> Thomas Munro writes:
>> On Sat, Feb 18, 2017 at 9:04 AM, Tom Lane wrote:
>>> [ pokes around... ] Ah, that's called COPT, and it's entirely
>>> undocumented :-(. Probably ought to fix that.
>
>> One way to set that up is like this:
>
>> $
Thomas Munro writes:
> On Sat, Feb 18, 2017 at 9:04 AM, Tom Lane wrote:
>> [ pokes around... ] Ah, that's called COPT, and it's entirely
>> undocumented :-(. Probably ought to fix that.
> One way to set that up is like this:
> $ cat src/Makefile.custom
> COPT=-Wall -Werror $(CC_OPT)
Well, we
On Sat, Feb 18, 2017 at 9:04 AM, Tom Lane wrote:
> Andres Freund writes:
>> On February 17, 2017 11:40:57 AM PST, Tom Lane wrote:
>>> AFAICS, if you want to build with -Werror, you have to configure
>>> without that and then inject it afterwards. I wonder how people who
>>> use -Werror are hand
Andres Freund writes:
> On February 17, 2017 11:40:57 AM PST, Tom Lane wrote:
>> AFAICS, if you want to build with -Werror, you have to configure
>> without that and then inject it afterwards. I wonder how people who
>> use -Werror are handling that. Is it possible to do at all in a
>> buildfar
> On Feb 17, 2017, at 11:40 AM, Tom Lane wrote:
>
> I wrote:
>> Yeah. I have longfin which is running Apple's clang, and is on a machine
>> that doesn't have much to do otherwise. I propose to turn on -Werror in
>> its configuration, and to configure a second critter on the same hardware
>> th
On February 17, 2017 11:40:57 AM PST, Tom Lane wrote:
>I wrote:
>> Yeah. I have longfin which is running Apple's clang, and is on a
>machine
>> that doesn't have much to do otherwise. I propose to turn on -Werror
>in
>> its configuration, and to configure a second critter on the same
>hardware
I wrote:
> Yeah. I have longfin which is running Apple's clang, and is on a machine
> that doesn't have much to do otherwise. I propose to turn on -Werror in
> its configuration, and to configure a second critter on the same hardware
> that runs with -Werror as well as --disable-integer-datetimes
Alvaro Herrera writes:
> Tom Lane wrote:
>> My own compilers don't generate errors either, only warnings. Maybe
>> we could catch this sort of thing mechanically with a critter configured
>> with -Werror as well as --disable-integer-datetimes, but I'm a tad
>> hesitant to have a buildfarm machine
Tom Lane wrote:
> My own compilers don't generate errors either, only warnings. Maybe
> we could catch this sort of thing mechanically with a critter configured
> with -Werror as well as --disable-integer-datetimes, but I'm a tad
> hesitant to have a buildfarm machine configured with -Werror. We
I wrote:
> Thomas Munro writes:
>> Since commit 7c030783a5bd07cadffc2a1018bc33119a4c7505 it seems that $SUBJECT.
> Hmm ... I thought we had at least one buildfarm member still testing
> --disable-integer-datetimes. Evidently somebody needs to close that
> gap.
The plot thickens: we *do* have on
Thomas Munro writes:
> Since commit 7c030783a5bd07cadffc2a1018bc33119a4c7505 it seems that $SUBJECT.
Hmm ... I thought we had at least one buildfarm member still testing
--disable-integer-datetimes. Evidently somebody needs to close that
gap.
> Maybe the attached is the right fix for that?
I'l
Thomas Munro wrote:
> Hi,
>
> Since commit 7c030783a5bd07cadffc2a1018bc33119a4c7505 it seems that $SUBJECT.
Added it to open items list.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hac
Hi,
Since commit 7c030783a5bd07cadffc2a1018bc33119a4c7505 it seems that $SUBJECT.
pg_recvlogical.c:501:37: error: incompatible pointer types passing
'int64 *' (aka 'long *') to parameter of type 'TimestampTz *' (aka
'double *') [-Werror,-Wincompatible-pointer-types]
19 matches
Mail list logo
