warnings with gcc9.0.1 and clang 8

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

warnings with gcc9.0.1 and clang 8

Dmitri A. Sergatskov
I have upgraded fedora's buildbot to fedora 30  that comes with
gcc version 9.0.1 20190312
and
clang version 8.0.0

Those give quite a few new warnings.
See:


and


(and may be newer)

I am not sure how serious are those, perhaps somebody more qualified can have a look.

Dmitri.
--


Reply | Threaded
Open this post in threaded view
|

Re: warnings with gcc9.0.1 and clang 8

John W. Eaton
Administrator
On 4/2/19 11:43 PM, Dmitri A. Sergatskov wrote:

> I have upgraded fedora's buildbot to fedora 30  that comes with
> gcc version 9.0.1 20190312
> and
> clang version 8.0.0
>
> Those give quite a few new warnings.
> See:
>
> http://buildbot.octave.org:8010/#/builders/9/builds/853/steps/5/logs/stdio
>
> and
>
> http://buildbot.octave.org:8010/#/builders/11/builds/854/steps/5/logs/stdio
>
> (and may be newer)
>
> I am not sure how serious are those, perhaps somebody more qualified can
> have a look.

I pushed the following change on default:

   http://hg.savannah.gnu.org/hgweb/octave/rev/fc256e9d882e

This change eliminates many warnings in Octave for me with GCC 9 but
there are still many others due to similar issues in Qt class declarations.

It does not fix problems found with clang due to
-Wdefaulted-function-deleted.  I'll try to take a look at that as well.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: warnings with gcc9.0.1 and clang 8

Dmitri A. Sergatskov


On Wed, Apr 3, 2019 at 11:13 AM John W. Eaton <[hidden email]> wrote:
On 4/2/19 11:43 PM, Dmitri A. Sergatskov wrote:
> I have upgraded fedora's buildbot to fedora 30  that comes with
> gcc version 9.0.1 20190312
> and
> clang version 8.0.0
>
> Those give quite a few new warnings.
> See:
>
> http://buildbot.octave.org:8010/#/builders/9/builds/853/steps/5/logs/stdio
>
> and
>
> http://buildbot.octave.org:8010/#/builders/11/builds/854/steps/5/logs/stdio
>
> (and may be newer)
>
> I am not sure how serious are those, perhaps somebody more qualified can
> have a look.

I pushed the following change on default:

   http://hg.savannah.gnu.org/hgweb/octave/rev/fc256e9d882e

This change eliminates many warnings in Octave for me with GCC 9 but
there are still many others due to similar issues in Qt class declarations.

It does not fix problems found with clang due to
-Wdefaulted-function-deleted.  I'll try to take a look at that as well.

jwe


lto has at least one lto-specific warning:

../liboctave/external/quadpack/dqagi.f:188:5: warning: type of 'xerror' does not match original declaration [-Wlto-type-mismatch]
  188 |       IF(IER.GT.0) CALL XERROR('ABNORMAL RETURN FROM DQAGI',26,IER,LVL)
      |     ^
../liboctave/external/quadpack/xerror.f:1:5: note: type mismatch in parameter 5
    1 |       SUBROUTINE XERROR(MESSG,NMESSG,NERR,LEVEL)
      |     ^
../liboctave/external/quadpack/xerror.f:1:5: note: type 'void' should match type 'long int'
../liboctave/external/quadpack/xerror.f:1:5: note: 'xerror' was previously declared here
../liboctave/external/quadpack/xerror.f:1:5: note: code may be misoptimized unless '-fno-strict-aliasing is used'
../liboctave/external/odepack/sintdy.f:100:5: warning: type of 'xerrwd' does not match original declaration [-Wlto-type-mismatch]
  100 |      1     30, 51, 0, 1, K, 0, 0, 0.0E0, 0.0E0)
      |     ^
../liboctave/external/quadpack/xerror.f:37:5: warning: type of 'xerrwd' does not match original declaration [-Wlto-type-mismatch]
   37 |       CALL XERRWD(MESSG,NMESSG,NERR,LEVEL,0,0,0,0,0.,0.)
      |     ^
../liboctave/external/slatec-err/xerrwd.f:3:5: note: type mismatch in parameter 11
    3 |       SUBROUTINE XERRWD (MSG, NMES, NERR, LEVEL, NI, I1, I2, NR, R1, R2)
      |     ^
../liboctave/external/slatec-err/xerrwd.f:3:5: note: type 'long int' should match type 'void'
../liboctave/external/slatec-err/xerrwd.f:3:5: note: 'xerrwd' was previously declared here
../liboctave/external/slatec-err/xerrwd.f:3:5: note: code may be misoptimized unless '-fno-strict-aliasing is used'

But gcc also segfaults here (I filled the bug to redhat), so may be it is not real...

Dmitri.
--




 
Reply | Threaded
Open this post in threaded view
|

Re: warnings with gcc9.0.1 and clang 8

John W. Eaton
Administrator
On 4/3/19 12:52 PM, Dmitri A. Sergatskov wrote:

> lto has at least one lto-specific warning:
>
> ../liboctave/external/quadpack/dqagi.f:188:5: warning: type of 'xerror'
> does not match original declaration [-Wlto-type-mismatch]
>    188 |       IF(IER.GT.0) CALL XERROR('ABNORMAL RETURN FROM
> DQAGI',26,IER,LVL)
>        |     ^
> ../liboctave/external/quadpack/xerror.f:1:5: note: type mismatch in
> parameter 5
>      1 |       SUBROUTINE XERROR(MESSG,NMESSG,NERR,LEVEL)
>        |     ^
> ../liboctave/external/quadpack/xerror.f:1:5: note: type 'void' should
> match type 'long int'
> ../liboctave/external/quadpack/xerror.f:1:5: note: 'xerror' was
> previously declared here
> ../liboctave/external/quadpack/xerror.f:1:5: note: code may be
> misoptimized unless '-fno-strict-aliasing is used'
> ../liboctave/external/odepack/sintdy.f:100:5: warning: type of 'xerrwd'
> does not match original declaration [-Wlto-type-mismatch]
>    100 |      1     30, 51, 0, 1, K, 0, 0, 0.0E0, 0.0E0)
>        |     ^
> ../liboctave/external/quadpack/xerror.f:37:5: warning: type of 'xerrwd'
> does not match original declaration [-Wlto-type-mismatch]
>     37 |       CALL XERRWD(MESSG,NMESSG,NERR,LEVEL,0,0,0,0,0.,0.)
>        |     ^
> ../liboctave/external/slatec-err/xerrwd.f:3:5: note: type mismatch in
> parameter 11
>      3 |       SUBROUTINE XERRWD (MSG, NMES, NERR, LEVEL, NI, I1, I2,
> NR, R1, R2)
>        |     ^
> ../liboctave/external/slatec-err/xerrwd.f:3:5: note: type 'long int'
> should match type 'void'
> ../liboctave/external/slatec-err/xerrwd.f:3:5: note: 'xerrwd' was
> previously declared here
> ../liboctave/external/slatec-err/xerrwd.f:3:5: note: code may be
> misoptimized unless '-fno-strict-aliasing is used'
>
> But gcc also segfaults here (I filled the bug to redhat), so may be it
> is not real...

I pushed the following changeset for the Fortran problems:

   http://hg.savannah.gnu.org/hgweb/octave/rev/ac5e5da675e3

jwe