Thread

Commits

  1. Disable clang 16's -Wcast-function-type-strict.

  2. Fix -Wcast-function-type warnings

  1. Clang function pointer type warnings in v14, v15

    Thomas Munro <thomas.munro@gmail.com> — 2024-07-06T00:23:26Z

    Hi,
    
    REL_14_STABLE and REL_15_STABLE have commit de8feb1f3, which turned on
    -Wcast-function-type, but don't have commit 101c37cd, which disabled
    -Wcast-function-type-strict as we agreed to do[1].  I noticed this on
    my local system that has clang 18 as compiler, but you can see it on
    any build farm animal using clang 16+.
    
    So I propose to back-patch 101c37cd to those two branches.
    
    [1] https://www.postgresql.org/message-id/flat/CA%2BhUKGKpHPDTv67Y%2Bs6yiC8KH5OXeDg6a-twWo_xznKTcG0kSA%40mail.gmail.com
    
    
    
    
  2. Re: Clang function pointer type warnings in v14, v15

    Tom Lane <tgl@sss.pgh.pa.us> — 2024-07-06T02:35:55Z

    Thomas Munro <thomas.munro@gmail.com> writes:
    > REL_14_STABLE and REL_15_STABLE have commit de8feb1f3, which turned on
    > -Wcast-function-type, but don't have commit 101c37cd, which disabled
    > -Wcast-function-type-strict as we agreed to do[1].  I noticed this on
    > my local system that has clang 18 as compiler, but you can see it on
    > any build farm animal using clang 16+.
    
    > So I propose to back-patch 101c37cd to those two branches.
    
    +1.  I see that there are a boatload of related warnings in older
    branches too; do we want to try to do anything about that?  (I doubt
    code changes would be in-scope, but maybe adding a -Wno-foo switch
    to the build flags would be appropriate.)
    
    			regards, tom lane
    
    
    
    
  3. Re: Clang function pointer type warnings in v14, v15

    Thomas Munro <thomas.munro@gmail.com> — 2024-07-12T01:17:23Z

    On Sat, Jul 6, 2024 at 2:35 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
    > Thomas Munro <thomas.munro@gmail.com> writes:
    > > So I propose to back-patch 101c37cd to those two branches.
    >
    > +1.
    
    Done.
    
    > I see that there are a boatload of related warnings in older
    > branches too; do we want to try to do anything about that?  (I doubt
    > code changes would be in-scope, but maybe adding a -Wno-foo switch
    > to the build flags would be appropriate.)
    
    I don't see any on clang 16 in the 12 and 13 branches.  Where are you
    seeing them?
    
    Has anyone thought about the -Wclobbered warnings from eg tamandua?
    
    
    
    
  4. Re: Clang function pointer type warnings in v14, v15

    Tom Lane <tgl@sss.pgh.pa.us> — 2024-07-12T02:26:47Z

    Thomas Munro <thomas.munro@gmail.com> writes:
    > On Sat, Jul 6, 2024 at 2:35 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
    >> I see that there are a boatload of related warnings in older
    >> branches too; do we want to try to do anything about that?  (I doubt
    >> code changes would be in-scope, but maybe adding a -Wno-foo switch
    >> to the build flags would be appropriate.)
    
    > I don't see any on clang 16 in the 12 and 13 branches.  Where are you
    > seeing them?
    
    In the buildfarm.  "adder" and a bunch of other machines are throwing
    -Wcast-function-type in about two dozen places in v13, and "jay" is
    emitting several hundred -Wdeprecated-non-prototype warnings.
    
    > Has anyone thought about the -Wclobbered warnings from eg tamandua?
    
    I decided long ago that gcc's algorithm for emitting that warning
    has no detectable connection to real problems.  Maybe it's worth
    silencing them on general principles, but I've seen no sign that
    it would actually fix any bugs.
    
    			regards, tom lane
    
    
    
    
  5. Re: Clang function pointer type warnings in v14, v15

    Thomas Munro <thomas.munro@gmail.com> — 2024-07-12T04:29:00Z

    On Fri, Jul 12, 2024 at 2:26 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
    > Thomas Munro <thomas.munro@gmail.com> writes:
    > > On Sat, Jul 6, 2024 at 2:35 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
    > >> I see that there are a boatload of related warnings in older
    > >> branches too; do we want to try to do anything about that?  (I doubt
    > >> code changes would be in-scope, but maybe adding a -Wno-foo switch
    > >> to the build flags would be appropriate.)
    >
    > > I don't see any on clang 16 in the 12 and 13 branches.  Where are you
    > > seeing them?
    >
    > In the buildfarm.  "adder" and a bunch of other machines are throwing
    > -Wcast-function-type in about two dozen places in v13, and "jay" is
    > emitting several hundred -Wdeprecated-non-prototype warnings.
    
    Ah, I see.  A few animals running with -Wextra.  Whereas in v14+ we
    have -Wcast-function-type in the actual tree, which affects people's
    workflows more directly.  Like my regular machine, or CI, when a
    couple of the OSes' house compilers eventually reach clang 16.
    
    I gess we have to decide if it's a matter for the tree, or for the
    people who add -Wextra, ie to decide if they want to filter that down
    a bit with some -Wno-XXX.  Adder already has some of those:
    
                                         'CFLAGS' => '-O1 -ggdb -g3
    -fno-omit-frame-pointer -Wall -Wextra -Wno-unused-parameter
    -Wno-sign-compare -Wno-missing-field-initializers -O0',
    
    
    
    
  6. Re: Clang function pointer type warnings in v14, v15

    Tom Lane <tgl@sss.pgh.pa.us> — 2024-07-12T04:34:13Z

    Thomas Munro <thomas.munro@gmail.com> writes:
    > On Fri, Jul 12, 2024 at 2:26 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
    >> Thomas Munro <thomas.munro@gmail.com> writes:
    >>> I don't see any on clang 16 in the 12 and 13 branches.  Where are you
    >>> seeing them?
    
    >> In the buildfarm.  "adder" and a bunch of other machines are throwing
    >> -Wcast-function-type in about two dozen places in v13, and "jay" is
    >> emitting several hundred -Wdeprecated-non-prototype warnings.
    
    > Ah, I see.  A few animals running with -Wextra.
    
    Oh, got it.
    
    > I gess we have to decide if it's a matter for the tree, or for the
    > people who add -Wextra, ie to decide if they want to filter that down
    > a bit with some -Wno-XXX.
    
    I think it's reasonable to say that if you add -Wextra then it's
    up to you to deal with the results.  If we were contemplating
    enabling -Wextra as standard, then it'd be our problem --- but
    nobody has proposed that AFAIR.  In any case we'd surely not
    add it now to near-dead branches.
    
    			regards, tom lane