On Wed, 11 Sep 2024, Andrew Stubbs wrote: > On 10/09/2024 10:43, Andrew Stubbs wrote: > > On 06/09/2024 09:47, Robin Dapp wrote: > >>>> So we only found two instances of this problem and both were related to > >>>> _Bools. In case you have more cases, it would be greatly appreciated > >>>> to verify the series with them. If you don't mind, would it be possible > >>>> to comment out the zeroing, re-run the testsuite and check for FAILs? > >>> > >>> I looked it up, and it was an execution failure in testcase > >>> gfortran.dg/assumed_rank_1.f90 that prompted me to add the initialization. > >> > >> Ah, I saw that one as well here. Thanks, will have a look locally. > >> > > > > I ran the tests with the initialization removed, but I'm not too sure what > > to make of the results. There are 3 regressions and 8 progressions, but > > there's no consistency across the different devices (I tested gfx1100, > > gfx908, and gfx90a). > > > > I'm going to rerun the tests and see if it does the same again, or if > > there's some randomness. > > There's definitely some random chance at play here: two identical test runs > resulted in different results.
I guess that's what you expect when you have UD elements that in the end should have a defined value. Richard. > The problem test cases: > gfortran.dg/all_bounds_1.f90 > gfortran.dg/allocated_4.f90 > gfortran.dg/team_change_1.f90 > gfortran.dg/class_optional_1.f90 > gcc.dg/torture/pr92152.c > > Hope that helps > > Andrew > > -- Richard Biener <rguent...@suse.de> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
