=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= writes:
> Tom Lane writes:
>> So maybe we should revive that idea, though I'd definitely target
>> autoconf 2.72 not 2.71.
> Just a data point: autoconf 2.72 came out under a year ago, so the most
> recent Debian Stable (12) and Ubuntu LTS (24.04) only h
Tom Lane writes:
> Alvaro Herrera writes:
>> Ah, yeah. That was 2.71 actually:
>> https://postgr.es/m/3838336.1657985...@sss.pgh.pa.us
>> 1.72 seems to have been released with some fixes from that one. Per
>> that thread, the related problem you noticed was with m4, and apparently
>> it was bec
Alvaro Herrera writes:
> Ah, yeah. That was 2.71 actually:
> https://postgr.es/m/3838336.1657985...@sss.pgh.pa.us
> 1.72 seems to have been released with some fixes from that one. Per
> that thread, the related problem you noticed was with m4, and apparently
> it was because macOS ships a version
On 2024-Oct-25, Tom Lane wrote:
> As I recall, we looked at adopting it some years ago and decided it
> was too much churn for the value (seeing that the long-term plan is
> to go to meson only). Maybe C23 is a reason to rethink, but from
> what I recall of that, it won't be a painless update.
A
Alvaro Herrera writes:
> On 2024-Oct-22, Peter Eisentraut wrote:
>> One thing I didn't realize until today is that currently C23 compilations
>> only work with meson. The autoconf version we are using doesn't support it,
>> and the configure results it produces are somehow faulty and then you get
On 2024-Oct-22, Peter Eisentraut wrote:
> One thing I didn't realize until today is that currently C23 compilations
> only work with meson. The autoconf version we are using doesn't support it,
> and the configure results it produces are somehow faulty and then you get a
> bunch of compilation er
On 22.10.24 08:41, Tom Lane wrote:
Peter Eisentraut writes:
Committed with that change. Thanks.
Should we back-patch this? (And also a67a49648d9?) It's
not hard to imagine people wanting to compile our stable
branches with C23 compilers. I might leave out v12, which
is just days away from
Peter Eisentraut writes:
> Committed with that change. Thanks.
Should we back-patch this? (And also a67a49648d9?) It's
not hard to imagine people wanting to compile our stable
branches with C23 compilers. I might leave out v12, which
is just days away from EOL, but this seems like a reasonabl
On 20.10.24 17:56, Tom Lane wrote:
Peter Eisentraut writes:
This no longer works because in C23, because an empty argument list is
now equivalent to (void), rather than an indeterminate one as before.
And so this results in an incompatible function pointer type and
compiler warnings. (gcc and
Peter Eisentraut writes:
> This no longer works because in C23, because an empty argument list is
> now equivalent to (void), rather than an indeterminate one as before.
> And so this results in an incompatible function pointer type and
> compiler warnings. (gcc and clang agree on this.)
> I
Commit a67a49648d9 fixed a compiler error under C23. After that, there
is one compiler warning left under C23. It has to do with this in
src/include/nodes/pathnodes.h:
struct IndexOptInfo
{
...
/* AM's cost estimator */
/* Rather than include amapi.h here, we de
On 2024-04-11 Th 16:17, Andres Freund wrote:
128k is probably not going to be an issue in practice. However, it also seems
not great from a performance POV to use this much stack in a function that's
called fairly often. I'd allocate the buffer in verify_backup_checksums() and
reuse it across a
Hi,
On 2024-04-11 15:07:11 -0700, Andres Freund wrote:
> On 2024-04-11 16:35:58 -0400, Tom Lane wrote:
> > Indeed. I recall reading, not long ago, some Linux kernel docs to the
> > effect that automatic stack growth is triggered by a reference into
> > the page just below what is currently mapped
Andres Freund writes:
> On 2024-04-11 16:35:58 -0400, Tom Lane wrote:
>> Indeed. I recall reading, not long ago, some Linux kernel docs to the
>> effect that automatic stack growth is triggered by a reference into
>> the page just below what is currently mapped as your stack, and
>> therefore all
Hi,
On 2024-04-11 16:35:58 -0400, Tom Lane wrote:
> Andres Freund writes:
> > d8f5acbdb9b made me wonder if we should add a compiler option to warn when
> > stack frames are large. gcc compatible compilers have -Wstack-usage=limit,
> > so
> > that's not hard.
>
> > Huge stack frames are somewha
Andres Freund writes:
> d8f5acbdb9b made me wonder if we should add a compiler option to warn when
> stack frames are large. gcc compatible compilers have -Wstack-usage=limit, so
> that's not hard.
> Huge stack frames are somewhat dangerous, as they can defeat our stack-depth
> checking logic. T
Hi,
On 2024-04-11 15:16:57 -0400, Andrew Dunstan wrote:
> On 2024-04-11 Th 15:01, Andres Freund wrote:
> > [1345/1940 42 69%] Compiling C object
> > src/bin/pg_verifybackup/pg_verifybackup.p/pg_verifybackup.c.o
> > ../../../../../home/andres/src/postgresql/src/bin/pg_verifybackup/pg_verifybackup
On 2024-04-11 Th 15:01, Andres Freund wrote:
Hi,
d8f5acbdb9b made me wonder if we should add a compiler option to warn when
stack frames are large. gcc compatible compilers have -Wstack-usage=limit, so
that's not hard.
Huge stack frames are somewhat dangerous, as they can defeat our stack-dep
Hi,
d8f5acbdb9b made me wonder if we should add a compiler option to warn when
stack frames are large. gcc compatible compilers have -Wstack-usage=limit, so
that's not hard.
Huge stack frames are somewhat dangerous, as they can defeat our stack-depth
checking logic. There are also some cases whe
On Wed, Nov 8, 2023 at 8:13 AM Alvaro Herrera wrote:
> On 2023-Nov-08, Thomas Munro wrote:
> > On Wed, Nov 8, 2023 at 4:46 AM Alvaro Herrera
> > wrote:
> > > On 2023-Aug-25, Daniel Westermann (DWE) wrote:
> > >
> > > Yeah, I get this one too. I thought commit 37d5babb5cfa ("jit: Support
> > > o
On 2023-Nov-08, Thomas Munro wrote:
> On Wed, Nov 8, 2023 at 4:46 AM Alvaro Herrera wrote:
> > On 2023-Aug-25, Daniel Westermann (DWE) wrote:
> >
> > Yeah, I get this one too. I thought commit 37d5babb5cfa ("jit: Support
> > opaque pointers in LLVM 16.") was going to silence it, but I was quite
On Wed, Nov 8, 2023 at 4:46 AM Alvaro Herrera wrote:
> On 2023-Aug-25, Daniel Westermann (DWE) wrote:
> > I've just noticed this warning when building on Debian 12:
> >
> > In file included from
> > /usr/lib/llvm-14/include/llvm/Analysis/ModuleSummaryAnalysis.h:17,
> > from llvmj
On 2023-Aug-25, Daniel Westermann (DWE) wrote:
> I've just noticed this warning when building on Debian 12:
>
> In file included from
> /usr/lib/llvm-14/include/llvm/Analysis/ModuleSummaryAnalysis.h:17,
> from llvmjit_inline.cpp:51:
> /usr/lib/llvm-14/include/llvm/IR/ModuleSumma
On Thu, Aug 31, 2023 at 03:25:09PM -0400, Bruce Momjian wrote:
> Being a new user of Debian 12/gcc 12.2.0, I wrote the following shell
> script to conditionally add gmake rules with compiler flags to
> src/Makefile.custom to suppress warnings for certain files. This allows
> me to compile all supp
Being a new user of Debian 12/gcc 12.2.0, I wrote the following shell
script to conditionally add gmake rules with compiler flags to
src/Makefile.custom to suppress warnings for certain files. This allows
me to compile all supported Postgres releases without warnings.
I actually didn't how simple
Peter Eisentraut has applied a patch to fix this.
---
On Wed, Aug 30, 2023 at 10:07:24AM -0400, David Steele wrote:
> On 8/30/23 08:10, Aleksander Alekseev wrote:
> >
> > > I am seeing a new gcc 12.2.
On 8/30/23 08:10, Aleksander Alekseev wrote:
I am seeing a new gcc 12.2.0 compiler warning from
src/backend/commands/sequence.c:
Yep, the compiler is just not smart enough to derive that this
actually is not going to happen.
Here is a proposed fix.
Here's an alternate way to deal
Hi,
> I am seeing a new gcc 12.2.0 compiler warning from
> src/backend/commands/sequence.c:
Yep, the compiler is just not smart enough to derive that this
actually is not going to happen.
Here is a proposed fix.
--
Best regards,
Aleksander Alekseev
v1-0001-Silence-GCC-12-warning
I am seeing a new gcc 12.2.0 compiler warning from
src/backend/commands/sequence.c:
sequence.c: In function ‘DefineSequence’:
sequence.c:196:35: warning: ‘coldef’ may be used uninitialized
[-Wmaybe-uninitialized]
196 | stmt->tableElts = lappend(s
Hi,
I've just noticed this warning when building on Debian 12:
In file included from
/usr/lib/llvm-14/include/llvm/Analysis/ModuleSummaryAnalysis.h:17,
from llvmjit_inline.cpp:51:
/usr/lib/llvm-14/include/llvm/IR/ModuleSummaryIndex.h: In constructor
‘llvm::ModuleSummaryIndex::M
On Wed, Jun 01, 2022 at 05:08:03PM -0400, Tom Lane wrote:
> Hmm, if we're following amcheck's example it should be more like this:
>
> diff --git a/src/backend/access/brin/brin.c b/src/backend/access/brin/brin.c
> index 52f171772d..0de1441dc6 100644
> --- a/src/backend/access/brin/brin.c
> +++ b/s
Nathan Bossart writes:
> On Wed, Jun 01, 2022 at 01:06:21PM -0400, Tom Lane wrote:
>> It looks like
>> AtEOXact_GUC asserts nestLevel > 0, so that either 0 or -1 would
>> do as an "invalid" value; I'd lean a bit to using 0.
> I only chose -1 to follow a117ceb's example in amcheck. I have no
> pr
Zhihong Yu writes:
> Hi,
> if (heapRel == NULL || heapoid != IndexGetRelation(indexoid, false))
> ereport(ERROR,
> I wonder why the above check is not placed in the else block:
> else
> heapRel = NULL;
Because we don't want to throw that error until we've exhausted the
On Wed, Jun 1, 2022 at 10:06 AM Tom Lane wrote:
> Zhihong Yu writes:
> > On Wed, Jun 1, 2022 at 9:35 AM Nathan Bossart
> > wrote:
> >> I'm seeing a compiler warning in brin.c with an older version of gcc.
> >> Specifically, it seems worried that a variable
On Wed, Jun 01, 2022 at 01:06:21PM -0400, Tom Lane wrote:
> Zhihong Yu writes:
>> It seems the variable can be initialized to the value of GUCNestLevel since
>> later in the func:
>> /* Roll back any GUC changes executed by index functions */
>> AtEOXact_GUC(false, save_nestlevel);
>
> Th
Zhihong Yu writes:
> On Wed, Jun 1, 2022 at 9:35 AM Nathan Bossart
> wrote:
>> I'm seeing a compiler warning in brin.c with an older version of gcc.
>> Specifically, it seems worried that a variable might not be initialized.
>> AFAICT there is no real risk, so I
On Wed, Jun 1, 2022 at 9:35 AM Nathan Bossart
wrote:
> Hi hackers,
>
> I'm seeing a compiler warning in brin.c with an older version of gcc.
> Specifically, it seems worried that a variable might not be initialized.
> AFAICT there is no real risk, so I've attached a s
Hi hackers,
I'm seeing a compiler warning in brin.c with an older version of gcc.
Specifically, it seems worried that a variable might not be initialized.
AFAICT there is no real risk, so I've attached a small patch to silence the
warning.
--
Nathan Bossart
Amazon Web Servi
That approach seems fine. Thanks.--
Peter Geoghegan
I just noticed that if I build without asserts on my Mac laptop
(using Apple's latest clang, 13.1.6) I get
nbtdedup.c:68:8: warning: variable 'pagesaving' set but not used
[-Wunused-but-set-variable]
Sizepagesaving = 0;
^
1 warning generated.
Apparentl
Bruce Momjian writes:
> I see a compiler warning on git master:
>sharedfileset.c:288:8: warning: variable ‘found’ set but not used
> [-Wunused-but-set-variable]
Could get rid of the variable entirely: change the "break" to "return"
and then the fina
I see a compiler warning on git master:
sharedfileset.c:288:8: warning: variable ‘found’ set but not used
[-Wunused-but-set-variable]
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its
I see that buildfarm member caiman is generating a warning [1]:
jsonb_plpython.c: In function \xe2\x80\x98PLyObject_ToJsonbValue\xe2\x80\x99:
cc1: warning: function may return address of local variable
[-Wreturn-local-addr]
jsonb_plpython.c:413:13: note: declared here
413 | JsonbValue buf;
On Fri, Jul 05, 2019 at 10:13:25AM -0400, Jeff Janes wrote:
One of the recent mcv commits introduced an unused variable warning.
mcv.c: In function 'statext_mcv_serialize':
mcv.c:914:7: warning: unused variable 'itemlen' [-Wunused-variable]
int itemlen = ITEM_SIZE(dim);
The attached fixes i
One of the recent mcv commits introduced an unused variable warning.
mcv.c: In function 'statext_mcv_serialize':
mcv.c:914:7: warning: unused variable 'itemlen' [-Wunused-variable]
int itemlen = ITEM_SIZE(dim);
The attached fixes it.
Cheers,
Jeff
mcv_assert_warning.patch
Description: Bin
On Sat, May 4, 2019 at 3:15 AM Noah Misch wrote:
>
> I pushed Jeff's patch.
>
Thank you. I've re-tested it and I get warning-free compilation now.
Cheers,
Jeff
On Sat, May 04, 2019 at 12:15:19AM -0700, Noah Misch wrote:
> I pushed Jeff's patch.
Upon resolution, could you move the related open item on the wiki
page to the list of resolved issues [1]?
[1]:
https://wiki.postgresql.org/wiki/PostgreSQL_12_Open_Items#resolved_before_12beta1
--
Michael
sig
On Wed, May 01, 2019 at 09:18:02AM -0700, Andres Freund wrote:
> On 2019-03-23 00:02:36 -0700, Noah Misch wrote:
> > On Sat, Mar 23, 2019 at 10:20:16AM +0900, Michael Paquier wrote:
> > > On Fri, Mar 22, 2019 at 08:20:53PM -0400, Jeff Janes wrote:
> > > > PostgreSQL 12devel on aarch64-unknown-linux
Hi Noah,
On 2019-03-23 00:02:36 -0700, Noah Misch wrote:
> On Sat, Mar 23, 2019 at 10:20:16AM +0900, Michael Paquier wrote:
> > On Fri, Mar 22, 2019 at 08:20:53PM -0400, Jeff Janes wrote:
> > > PostgreSQL 12devel on aarch64-unknown-linux-gnu, compiled by gcc
> > > (Ubuntu/Linaro 7.3.0-27ubuntu1~18
On Sat, Mar 23, 2019 at 10:20:16AM +0900, Michael Paquier wrote:
> On Fri, Mar 22, 2019 at 08:20:53PM -0400, Jeff Janes wrote:
> > PostgreSQL 12devel on aarch64-unknown-linux-gnu, compiled by gcc
> > (Ubuntu/Linaro 7.3.0-27ubuntu1~18.04) 7.3.0, 64-bit
>
> Adding Noah in CC as he has done the updat
On Fri, Mar 22, 2019 at 08:20:53PM -0400, Jeff Janes wrote:
> PostgreSQL 12devel on aarch64-unknown-linux-gnu, compiled by gcc
> (Ubuntu/Linaro 7.3.0-27ubuntu1~18.04) 7.3.0, 64-bit
Adding Noah in CC as he has done the update of imath lately.
> The attached patch adds PG_USED_FOR_ASSERTS_ONLY to s
When compiling on an AWS 64 bit Arm machine, I get this compiler warning:
imath.c: In function 's_ksqr':
imath.c:2590:6: warning: variable 'carry' set but not used
[-Wunused-but-set-variable]
carry;
^
With this version():
PostgreSQL 12devel on aarch64-unknown
On 11/18/2017 10:40 PM, Tom Lane wrote:
> Tomas Vondra writes:
>> while compiling on gcc 7.2.0 (on ARM), I got this warning:
>
>> rangetypes_spgist.c: In function 'spg_range_quad_inner_consistent':
>> rangetypes_spgist.c:559:29: warning: comparison between pointer and
>> zero charac
Tomas Vondra writes:
> while compiling on gcc 7.2.0 (on ARM), I got this warning:
> rangetypes_spgist.c: In function 'spg_range_quad_inner_consistent':
> rangetypes_spgist.c:559:29: warning: comparison between pointer and
> zero character constant [-Wpointer-compare]
> if (i
18 Nov 2017 20:25:02 +0100
Subject: [PATCH] Fix compiler warning when comparing traversalValue
On gcc 7.2.0, comparing pointer to (Datum)0 produces a warning. Treat
it as a simple pointer to fix that.
---
src/backend/utils/adt/rangetypes_spgist.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
55 matches
Mail list logo
