> 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 <[email protected]> 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 <[email protected]
> <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%20uninitialized
> <https://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=may%20be%20uninitialized>
>
>
> Best regards,
>
>
>
> Jacob Faibussowitsch
>
> (Jacob Fai - booss - oh - vitch)
>
> Cell: (312) 694-3391
>
>
>
> From: petsc-dev <[email protected]
> <mailto:[email protected]>> On Behalf Of Barry Smith
> Sent: Sunday, April 11, 2021 17:51
> To: Mark Adams <[email protected] <mailto:[email protected]>>
> Cc: For users of the development version of PETSc <[email protected]
> <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 <[email protected]
> <mailto:[email protected]>> wrote:
>
>
>
> This warning went away. i don't know why.
>
>
>
> On Sun, Apr 11, 2021 at 2:10 PM Mark Adams <[email protected]
> <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?
>
>
>
