April 2021 - petsc-dev - mailman3.cels.anl.gov

Error on Fugaku
by Mark Adams 14 Apr '21

14 Apr '21

I get this error with p4est on Fugaku. It is a Fortran error. Odd. Mark

1 0

Re: [petsc-dev] CI error
by Satish Balay 13 Apr '21

13 Apr '21

https://gitlab.com/petsc/petsc/-/merge_requests/3865 Satish On Tue, 13 Apr 2021, Satish Balay via petsc-dev wrote: > gcc-11 is giving a bunch of warnings - have to go through them and see if they are fixable.. > [its not in CI] > > Satish > > On Mon, 12 Apr 2021, Barry Smith wrote: > > > > > Yes, this is annoying and frustrating for us to have deal with this kind of thing, but imagine how annoying and frustrating it is for an average user who has 1/100th the HPC experience we do. This is why I like to have these fully resolved at the library level; yes it is more work for us; but less for the average user. > > > > Barry > > > > > > > On Apr 12, 2021, at 11:21 PM, Barry Smith <bsmith(a)petsc.dev> wrote: > > > > > > > > > I like the diversity of slightly different test boxes. If all test boxes are the same than that limits what variants we test and reduces the usefulness of the CI; since users will face this diversity in their machines and end up with errors we never see before hand (which is bad). > > > > > > This kind of "after the fact initialization "for (q = 0; q < LANDAU_MAX_Q_FACE; q++) col_scale[q] = 0.0; " is unlikely to satisfy the various compilers and optimization levels. Best to figure out universally how to indicate when the variable is declared that it gets initialized suitably (for confused compilers that don't realize the initialized values are never used and so print warning messages). > > > > > > > > > This seems to work for C++? https://icarus.cs.weber.edu/~dab/cs1410/textbook/7.Arrays/initialize.html <https://icarus.cs.weber.edu/~dab/cs1410/textbook/7.Arrays/initialize.html> > > > > > > https://stackoverflow.com/questions/201101/how-to-initialize-all-members-of… <https://stackoverflow.com/questions/201101/how-to-initialize-all-members-of…> seems to indicate one can initialize all entries in C with one {0} but who trusts the web or all compilers. > > > > > > Have you tried the C form? > > > > > > Barry > > > > > > > > > > > > > > >> On Apr 12, 2021, at 8:06 AM, Satish Balay via petsc-dev <petsc-dev(a)mcs.anl.gov <mailto:[email protected]>> wrote: > > >> > > >> This job gets run on either pj01 or pj02 - each have slightly different version of gcc. (and they behave differently wrt certain warnings) > > >> > > >> [trade-off with diversity in testing and having redundancy in available work machines - so jobs are not stuck on a single box] > > >> > > >> I guess I should somehow fix this (perhaps switch them all to same OS/versions]. > > >> > > >> Satish > > >> > > >> On Sun, 11 Apr 2021, Mark Adams wrote: > > >> > > >>> This warning went away. i don't know why. > > >>> > > >>> On Sun, Apr 11, 2021 at 2:10 PM Mark Adams <mfadams(a)lbl.gov <mailto:[email protected]>> wrote: > > >>> > > >>>> I get this error in CI with complex float: > > >>>> https://gitlab.com/petsc/petsc/-/jobs/1170144554 <https://gitlab.com/petsc/petsc/-/jobs/1170144554> > > >>>> > > >>>> I put in code earlier to fix this warning about uninitialized vars, but > > >>>> now it does not seem to work: > > >>>> > > >>>> /home/glci/builds-stage1/AbTGp5-t/0/petsc/petsc/src/ts/utils/dmplexlandau/plexland.c:414:94: > > >>>> error: ‘col_scale[4]’ may be used uninitialized in this function > > >>>> [-Werror=maybe-uninitialized] > > >>>> 2251 <https://gitlab.com/petsc/petsc/-/jobs/1170144554#L2251> PetscScalar > > >>>> vals[LANDAU_MAX_Q_FACE*LANDAU_MAX_Q_FACE],row_scale[LANDAU_MAX_Q_FACE],col_scale[LANDAU_MAX_Q_FACE]; > > >>>> > > >>>> Yet I have code to initialize col_scale: > > >>>> > > >>>> for (q = 0; q < LANDAU_MAX_Q_FACE; q++) col_scale[q] = 0.0; // > > >>>> suppress warnings > > >>>> > > >>>> I get a similar error with an integer array. > > >>>> > > >>>> Any suggestions? > > >>>> > > >>> > > > > > > > >

1 0

Re: [petsc-dev] CI error
by Barry Smith 13 Apr '21

13 Apr '21

Why bother reading the standard when you are hacking on compiler code, your intuition is better anyways :-). > On Apr 13, 2021, at 9:46 AM, Lawrence Mitchell <wence(a)gmx.li> wrote: > > > >> On 13 Apr 2021, at 05:21, Barry Smith <bsmith(a)petsc.dev> wrote: >> >> https://stackoverflow.com/questions/201101/how-to-initialize-all-members-of… seems to indicate one can initialize all entries in C with one {0} but who trusts the web or all compilers. >> >> Have you tried the C form? > > This is in the C99 standard (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf) > > Section 6.7.8/21 > > "If there are fewer initializers in a brace-enclosed list than there are elements or members of an aggregate, or fewer characters in a string literal used to initialize an array of known size than there are elements in the array, the remainder of the aggregate shall be initialized implicitly the same as objects that have static storage duration." > > So if I write > > int foo[4] = {0}; > > then the first entry is initialised to zero and subsequent entries are initialised according to the rules for static storage. Those rules are 6.7.8/10 > > "[...] If an object that has static storage duration is not initialized explicitly, then: > > — if it has pointer type, it is initialized to a null pointer; > — if it has arithmetic type, it is initialized to (positive or unsigned) zero; > — if it is an aggregate, every member is initialized (recursively) according to these rules; > — if it is a union, the first named member is initialized (recursively) according to these rules" > > We're an aggregate, so we recurse and find that each member is an arithmetic type, so each entry is initialised to zero. > > So a conforming C99 compiler _must_ accept {0} as an initializer list and initialise all entries of the array to zero. > > Lawrence

1 0

Re: [petsc-dev] CI error
by Lawrence Mitchell 13 Apr '21

13 Apr '21

> On 13 Apr 2021, at 05:21, Barry Smith <bsmith(a)petsc.dev> wrote: > > https://stackoverflow.com/questions/201101/how-to-initialize-all-members-of… seems to indicate one can initialize all entries in C with one {0} but who trusts the web or all compilers. > > Have you tried the C form? This is in the C99 standard (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf) Section 6.7.8/21 "If there are fewer initializers in a brace-enclosed list than there are elements or members of an aggregate, or fewer characters in a string literal used to initialize an array of known size than there are elements in the array, the remainder of the aggregate shall be initialized implicitly the same as objects that have static storage duration." So if I write int foo[4] = {0}; then the first entry is initialised to zero and subsequent entries are initialised according to the rules for static storage. Those rules are 6.7.8/10 "[...] If an object that has static storage duration is not initialized explicitly, then: — if it has pointer type, it is initialized to a null pointer; — if it has arithmetic type, it is initialized to (positive or unsigned) zero; — if it is an aggregate, every member is initialized (recursively) according to these rules; — if it is a union, the first named member is initialized (recursively) according to these rules" We're an aggregate, so we recurse and find that each member is an arithmetic type, so each entry is initialised to zero. So a conforming C99 compiler _must_ accept {0} as an initializer list and initialise all entries of the array to zero. Lawrence

1 0

Re: [petsc-dev] CI error
by Satish Balay 13 Apr '21

13 Apr '21

gcc-11 is giving a bunch of warnings - have to go through them and see if they are fixable.. [its not in CI] Satish On Mon, 12 Apr 2021, Barry Smith wrote: > > Yes, this is annoying and frustrating for us to have deal with this kind of thing, but imagine how annoying and frustrating it is for an average user who has 1/100th the HPC experience we do. This is why I like to have these fully resolved at the library level; yes it is more work for us; but less for the average user. > > Barry > > > > On Apr 12, 2021, at 11:21 PM, Barry Smith <bsmith(a)petsc.dev> wrote: > > > > > > I like the diversity of slightly different test boxes. If all test boxes are the same than that limits what variants we test and reduces the usefulness of the CI; since users will face this diversity in their machines and end up with errors we never see before hand (which is bad). > > > > This kind of "after the fact initialization "for (q = 0; q < LANDAU_MAX_Q_FACE; q++) col_scale[q] = 0.0; " is unlikely to satisfy the various compilers and optimization levels. Best to figure out universally how to indicate when the variable is declared that it gets initialized suitably (for confused compilers that don't realize the initialized values are never used and so print warning messages). > > > > > > This seems to work for C++? https://icarus.cs.weber.edu/~dab/cs1410/textbook/7.Arrays/initialize.html <https://icarus.cs.weber.edu/~dab/cs1410/textbook/7.Arrays/initialize.html> > > > > https://stackoverflow.com/questions/201101/how-to-initialize-all-members-of… <https://stackoverflow.com/questions/201101/how-to-initialize-all-members-of…> seems to indicate one can initialize all entries in C with one {0} but who trusts the web or all compilers. > > > > Have you tried the C form? > > > > Barry > > > > > > > > > >> On Apr 12, 2021, at 8:06 AM, Satish Balay via petsc-dev <petsc-dev(a)mcs.anl.gov <mailto:[email protected]>> wrote: > >> > >> This job gets run on either pj01 or pj02 - each have slightly different version of gcc. (and they behave differently wrt certain warnings) > >> > >> [trade-off with diversity in testing and having redundancy in available work machines - so jobs are not stuck on a single box] > >> > >> I guess I should somehow fix this (perhaps switch them all to same OS/versions]. > >> > >> Satish > >> > >> On Sun, 11 Apr 2021, Mark Adams wrote: > >> > >>> This warning went away. i don't know why. > >>> > >>> On Sun, Apr 11, 2021 at 2:10 PM Mark Adams <mfadams(a)lbl.gov <mailto:[email protected]>> wrote: > >>> > >>>> I get this error in CI with complex float: > >>>> https://gitlab.com/petsc/petsc/-/jobs/1170144554 <https://gitlab.com/petsc/petsc/-/jobs/1170144554> > >>>> > >>>> I put in code earlier to fix this warning about uninitialized vars, but > >>>> now it does not seem to work: > >>>> > >>>> /home/glci/builds-stage1/AbTGp5-t/0/petsc/petsc/src/ts/utils/dmplexlandau/plexland.c:414:94: > >>>> error: ‘col_scale[4]’ may be used uninitialized in this function > >>>> [-Werror=maybe-uninitialized] > >>>> 2251 <https://gitlab.com/petsc/petsc/-/jobs/1170144554#L2251> PetscScalar > >>>> vals[LANDAU_MAX_Q_FACE*LANDAU_MAX_Q_FACE],row_scale[LANDAU_MAX_Q_FACE],col_scale[LANDAU_MAX_Q_FACE]; > >>>> > >>>> Yet I have code to initialize col_scale: > >>>> > >>>> for (q = 0; q < LANDAU_MAX_Q_FACE; q++) col_scale[q] = 0.0; // > >>>> suppress warnings > >>>> > >>>> I get a similar error with an integer array. > >>>> > >>>> Any suggestions? > >>>> > >>> > > > >

1 0

Re: [petsc-dev] CI error
by Mark Adams 13 Apr '21

13 Apr '21

On Tue, Apr 13, 2021 at 12:21 AM Barry Smith <bsmith(a)petsc.dev> wrote: > > I like the diversity of slightly different test boxes. If all test boxes > are the same than that limits what variants we test and reduces the > usefulness of the CI; since users will face this diversity in their > machines and end up with errors we never see before hand (which is bad). > > This kind of "after the fact initialization "for (q = 0; q < > LANDAU_MAX_Q_FACE; q++) col_scale[q] = 0.0; " is unlikely to satisfy the > various compilers and optimization levels. Best to figure out universally > how to indicate when the variable is declared that it gets initialized > suitably (for confused compilers that don't realize the initialized values > are never used and so print warning messages). > > > This seems to work for C++? > https://icarus.cs.weber.edu/~dab/cs1410/textbook/7.Arrays/initialize.html > > > https://stackoverflow.com/questions/201101/how-to-initialize-all-members-of… seems > to indicate one can initialize all entries in C with one {0} but who trusts > the web or all compilers. > Wow, 2M views and 1334 +1. > > Have you tried the C form? > int arr[SIZE] = {}; failed on mswin but arr[SIZE] = {0}; seemed to work. > Barry > > > > > On Apr 12, 2021, at 8:06 AM, Satish Balay via petsc-dev < > petsc-dev(a)mcs.anl.gov> wrote: > > This job gets run on either pj01 or pj02 - each have slightly different > version of gcc. (and they behave differently wrt certain warnings) > > [trade-off with diversity in testing and having redundancy in available > work machines - so jobs are not stuck on a single box] > > I guess I should somehow fix this (perhaps switch them all to same > OS/versions]. > > Satish > > On Sun, 11 Apr 2021, Mark Adams wrote: > > This warning went away. i don't know why. > > On Sun, Apr 11, 2021 at 2:10 PM Mark Adams <mfadams(a)lbl.gov> wrote: > > I get this error in CI with complex float: > https://gitlab.com/petsc/petsc/-/jobs/1170144554 > > I put in code earlier to fix this warning about uninitialized vars, but > now it does not seem to work: > > > /home/glci/builds-stage1/AbTGp5-t/0/petsc/petsc/src/ts/utils/dmplexlandau/plexland.c:414:94: > error: ‘col_scale[4]’ may be used uninitialized in this function > [-Werror=maybe-uninitialized] > 2251 <https://gitlab.com/petsc/petsc/-/jobs/1170144554#L2251> PetscScalar > > vals[LANDAU_MAX_Q_FACE*LANDAU_MAX_Q_FACE],row_scale[LANDAU_MAX_Q_FACE],col_scale[LANDAU_MAX_Q_FACE]; > > Yet I have code to initialize col_scale: > > for (q = 0; q < LANDAU_MAX_Q_FACE; q++) col_scale[q] = 0.0; // > suppress warnings > > I get a similar error with an integer array. > > Any suggestions? > > > >

1 0

Re: [petsc-dev] CI error
by Barry Smith 12 Apr '21

12 Apr '21

Yes, this is annoying and frustrating for us to have deal with this kind of thing, but imagine how annoying and frustrating it is for an average user who has 1/100th the HPC experience we do. This is why I like to have these fully resolved at the library level; yes it is more work for us; but less for the average user. Barry > On Apr 12, 2021, at 11:21 PM, Barry Smith <bsmith(a)petsc.dev> wrote: > > > I like the diversity of slightly different test boxes. If all test boxes are the same than that limits what variants we test and reduces the usefulness of the CI; since users will face this diversity in their machines and end up with errors we never see before hand (which is bad). > > This kind of "after the fact initialization "for (q = 0; q < LANDAU_MAX_Q_FACE; q++) col_scale[q] = 0.0; " is unlikely to satisfy the various compilers and optimization levels. Best to figure out universally how to indicate when the variable is declared that it gets initialized suitably (for confused compilers that don't realize the initialized values are never used and so print warning messages). > > > This seems to work for C++? https://icarus.cs.weber.edu/~dab/cs1410/textbook/7.Arrays/initialize.html <https://icarus.cs.weber.edu/~dab/cs1410/textbook/7.Arrays/initialize.html> > > https://stackoverflow.com/questions/201101/how-to-initialize-all-members-of… <https://stackoverflow.com/questions/201101/how-to-initialize-all-members-of…> seems to indicate one can initialize all entries in C with one {0} but who trusts the web or all compilers. > > Have you tried the C form? > > Barry > > > > >> On Apr 12, 2021, at 8:06 AM, Satish Balay via petsc-dev <petsc-dev(a)mcs.anl.gov <mailto:[email protected]>> wrote: >> >> This job gets run on either pj01 or pj02 - each have slightly different version of gcc. (and they behave differently wrt certain warnings) >> >> [trade-off with diversity in testing and having redundancy in available work machines - so jobs are not stuck on a single box] >> >> I guess I should somehow fix this (perhaps switch them all to same OS/versions]. >> >> Satish >> >> On Sun, 11 Apr 2021, Mark Adams wrote: >> >>> This warning went away. i don't know why. >>> >>> On Sun, Apr 11, 2021 at 2:10 PM Mark Adams <mfadams(a)lbl.gov <mailto:[email protected]>> wrote: >>> >>>> I get this error in CI with complex float: >>>> https://gitlab.com/petsc/petsc/-/jobs/1170144554 <https://gitlab.com/petsc/petsc/-/jobs/1170144554> >>>> >>>> I put in code earlier to fix this warning about uninitialized vars, but >>>> now it does not seem to work: >>>> >>>> /home/glci/builds-stage1/AbTGp5-t/0/petsc/petsc/src/ts/utils/dmplexlandau/plexland.c:414:94: >>>> error: ‘col_scale[4]’ may be used uninitialized in this function >>>> [-Werror=maybe-uninitialized] >>>> 2251 <https://gitlab.com/petsc/petsc/-/jobs/1170144554#L2251> PetscScalar >>>> vals[LANDAU_MAX_Q_FACE*LANDAU_MAX_Q_FACE],row_scale[LANDAU_MAX_Q_FACE],col_scale[LANDAU_MAX_Q_FACE]; >>>> >>>> Yet I have code to initialize col_scale: >>>> >>>> for (q = 0; q < LANDAU_MAX_Q_FACE; q++) col_scale[q] = 0.0; // >>>> suppress warnings >>>> >>>> I get a similar error with an integer array. >>>> >>>> Any suggestions? >>>> >>> >

1 0

Re: [petsc-dev] CI error
by Barry Smith 12 Apr '21

12 Apr '21

I like the diversity of slightly different test boxes. If all test boxes are the same than that limits what variants we test and reduces the usefulness of the CI; since users will face this diversity in their machines and end up with errors we never see before hand (which is bad). This kind of "after the fact initialization "for (q = 0; q < LANDAU_MAX_Q_FACE; q++) col_scale[q] = 0.0; " is unlikely to satisfy the various compilers and optimization levels. Best to figure out universally how to indicate when the variable is declared that it gets initialized suitably (for confused compilers that don't realize the initialized values are never used and so print warning messages). This seems to work for C++? https://icarus.cs.weber.edu/~dab/cs1410/textbook/7.Arrays/initialize.html <https://icarus.cs.weber.edu/~dab/cs1410/textbook/7.Arrays/initialize.html> https://stackoverflow.com/questions/201101/how-to-initialize-all-members-of… <https://stackoverflow.com/questions/201101/how-to-initialize-all-members-of…> seems to indicate one can initialize all entries in C with one {0} but who trusts the web or all compilers. Have you tried the C form? Barry > On Apr 12, 2021, at 8:06 AM, Satish Balay via petsc-dev <petsc-dev(a)mcs.anl.gov> wrote: > > This job gets run on either pj01 or pj02 - each have slightly different version of gcc. (and they behave differently wrt certain warnings) > > [trade-off with diversity in testing and having redundancy in available work machines - so jobs are not stuck on a single box] > > I guess I should somehow fix this (perhaps switch them all to same OS/versions]. > > Satish > > On Sun, 11 Apr 2021, Mark Adams wrote: > >> This warning went away. i don't know why. >> >> On Sun, Apr 11, 2021 at 2:10 PM Mark Adams <mfadams(a)lbl.gov> wrote: >> >>> I get this error in CI with complex float: >>> https://gitlab.com/petsc/petsc/-/jobs/1170144554 >>> >>> I put in code earlier to fix this warning about uninitialized vars, but >>> now it does not seem to work: >>> >>> /home/glci/builds-stage1/AbTGp5-t/0/petsc/petsc/src/ts/utils/dmplexlandau/plexland.c:414:94: >>> error: ‘col_scale[4]’ may be used uninitialized in this function >>> [-Werror=maybe-uninitialized] >>> 2251 <https://gitlab.com/petsc/petsc/-/jobs/1170144554#L2251> PetscScalar >>> vals[LANDAU_MAX_Q_FACE*LANDAU_MAX_Q_FACE],row_scale[LANDAU_MAX_Q_FACE],col_scale[LANDAU_MAX_Q_FACE]; >>> >>> Yet I have code to initialize col_scale: >>> >>> for (q = 0; q < LANDAU_MAX_Q_FACE; q++) col_scale[q] = 0.0; // >>> suppress warnings >>> >>> I get a similar error with an integer array. >>> >>> Any suggestions? >>> >>

1 0

Re: [petsc-dev] CI error
by Satish Balay 12 Apr '21

12 Apr '21

This job gets run on either pj01 or pj02 - each have slightly different version of gcc. (and they behave differently wrt certain warnings) [trade-off with diversity in testing and having redundancy in available work machines - so jobs are not stuck on a single box] I guess I should somehow fix this (perhaps switch them all to same OS/versions]. Satish On Sun, 11 Apr 2021, Mark Adams wrote: > This warning went away. i don't know why. > > On Sun, Apr 11, 2021 at 2:10 PM Mark Adams <mfadams(a)lbl.gov> wrote: > > > I get this error in CI with complex float: > > https://gitlab.com/petsc/petsc/-/jobs/1170144554 > > > > I put in code earlier to fix this warning about uninitialized vars, but > > now it does not seem to work: > > > > /home/glci/builds-stage1/AbTGp5-t/0/petsc/petsc/src/ts/utils/dmplexlandau/plexland.c:414:94: > > error: ‘col_scale[4]’ may be used uninitialized in this function > > [-Werror=maybe-uninitialized] > > 2251 <https://gitlab.com/petsc/petsc/-/jobs/1170144554#L2251> PetscScalar > > vals[LANDAU_MAX_Q_FACE*LANDAU_MAX_Q_FACE],row_scale[LANDAU_MAX_Q_FACE],col_scale[LANDAU_MAX_Q_FACE]; > > > > Yet I have code to initialize col_scale: > > > > for (q = 0; q < LANDAU_MAX_Q_FACE; q++) col_scale[q] = 0.0; // > > suppress warnings > > > > I get a similar error with an integer array. > > > > Any suggestions? > > >

1 0

Re: [petsc-dev] CI error
by Jacob Faibussowitsch 11 Apr '21

11 Apr '21

> It did seem to be non-deterministic. (how is that possible?). It can be a combination of the following: 1. Undefined behavior. 2. Dragons leaked from the undefined behavior. 3. In order to have 100% accuracy for detecting variable initializations the compiler must solve the halting problem, so compilers just silently give up after a certain point. For an example of UB skipping those checks, suppose you have the following: int func(int x) { int y; If (x) return y; return 0; } For reasonable optimization levels this function will __always__ return 0, see for yourself https://godbolt.org/z/z4bxTa43x <https://godbolt.org/z/z4bxTa43x> this is done on the same compiler and relevant options as the CI job you had. And best part is, gcc never complains about uninitialized y! Now if such a piece was thousands of lines deep, and obfuscated by many different optimization transformations (such as arbitrary branch predictions, etc), then the compiler may or may not get around to determining whether this value was initialized. Best regards, Jacob Faibussowitsch (Jacob Fai - booss - oh - vitch) Cell: (312) 694-3391 > On Apr 11, 2021, at 20:10, Mark Adams <mfadams(a)lbl.gov> wrote: > > It did seem to be non-deterministic. (how is that possible?). > I got this error, sent my message. > Tried Barry's idea and initialized them all (5) by hand. > It worked! > I tried initializing just one. > It worked. > I tried initializing none (yes, back to where I started) > And it worked :o > > I guess this error is another try-it-again CI error. > > On Sun, Apr 11, 2021 at 8:06 PM <jacob.fai(a)gmail.com <mailto:[email protected]>> wrote: > I ran into a similar problem months ago and the long and short of it is that any compilers uninitialized variable detection is incredibly dependent on optimization level, which the higher you go becomes non-deterministic. > > > > That being said, gcc is pretty terrible at getting this particular warning right :) https://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=may%20be%20uninitializ… <https://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=may%20be%20uninitializ…> > > > Best regards, > > > > Jacob Faibussowitsch > > (Jacob Fai - booss - oh - vitch) > > Cell: (312) 694-3391 > > > > From: petsc-dev <petsc-dev-bounces(a)mcs.anl.gov <mailto:[email protected]>> On Behalf Of Barry Smith > Sent: Sunday, April 11, 2021 17:51 > To: Mark Adams <mfadams(a)lbl.gov <mailto:[email protected]>> > Cc: For users of the development version of PETSc <petsc-dev(a)mcs.anl.gov <mailto:[email protected]>> > Subject: Re: [petsc-dev] CI error > > > > > > You might be able to do: > > > > col_scale[LANDAU_MAX_Q_FACE = {0}; > > > > but then the compiler may complain about not initializing enough values. Googling this type of initialization might help, something C initialize arrays "may be used uninitialized" > > > > > > > > > > > On Apr 11, 2021, at 2:05 PM, Mark Adams <mfadams(a)lbl.gov <mailto:[email protected]>> wrote: > > > > This warning went away. i don't know why. > > > > On Sun, Apr 11, 2021 at 2:10 PM Mark Adams <mfadams(a)lbl.gov <mailto:[email protected]>> wrote: > > I get this error in CI with complex float: https://gitlab.com/petsc/petsc/-/jobs/1170144554 <https://gitlab.com/petsc/petsc/-/jobs/1170144554> > > > I put in code earlier to fix this warning about uninitialized vars, but now it does not seem to work: > > > > /home/glci/builds-stage1/AbTGp5-t/0/petsc/petsc/src/ts/utils/dmplexlandau/plexland.c:414:94: error: ‘col_scale[4]’ may be used uninitialized in this function [-Werror=maybe-uninitialized] > > 2251 <https://gitlab.com/petsc/petsc/-/jobs/1170144554#L2251> PetscScalar vals[LANDAU_MAX_Q_FACE*LANDAU_MAX_Q_FACE],row_scale[LANDAU_MAX_Q_FACE],col_scale[LANDAU_MAX_Q_FACE]; > > > Yet I have code to initialize col_scale: > > > > for (q = 0; q < LANDAU_MAX_Q_FACE; q++) col_scale[q] = 0.0; // suppress warnings > > > > I get a similar error with an integer array. > > > > Any suggestions? > > >

1 0