Re: [Linaro-TCWG-CI] gdb patch #109371: 5 regressions on aarch64
Hello, Christophe Lyon writes: > On Tue, 1 Apr 2025 at 07:22, Martin Simmons wrote: >> >> > On Sun, 30 Mar 2025 23:58:18 + (UTC), ci notify said: >> > ... >> > In gdb_check master-aarch64, after: >> > | gdb patch https://patchwork.sourceware.org/patch/109371 >> > ... >> > Used configuration : >> > *CI config* tcwg_gdb_check master-aarch64 >> > *configure and test flags:* none, autodetected on >> > aarch64-unknown-linux-gnu >> > >> > If you have any questions regarding this report, please ask on >> > linaro-toolchain@lists.linaro.org mailing list. >> > >> > -8<--8<--8<-- >> > >> > The information below contains the details of the failures, and the ways >> > to reproduce >> > a debug environment: >> > >> > You can find the failure logs in *.log.1.xz files in >> > * >> > https://ci.linaro.org/job/tcwg_gdb_check--master-aarch64-precommit/4627/artifact/artifacts/artifacts.precommit/00-sumfiles/ >> > The full lists of regressions and improvements as well as configure and >> > make commands >> > are in >> > * >> > https://ci.linaro.org/job/tcwg_gdb_check--master-aarch64-precommit/4627/artifact/artifacts/artifacts.precommit/notify/ >> > The list of [ignored] baseline and flaky failures are in >> > * >> > https://ci.linaro.org/job/tcwg_gdb_check--master-aarch64-precommit/4627/artifact/artifacts/artifacts.precommit/sumfiles/xfails.xfail >> > >> > Current build : >> > https://ci.linaro.org/job/tcwg_gdb_check--master-aarch64-precommit/4627/artifact/artifacts >> > Reference build : >> > https://ci.linaro.org/job/tcwg_gdb_check--master-aarch64-build/2461/artifact/artifacts >> >> In >> https://ci.linaro.org/job/tcwg_gdb_check--master-aarch64-precommit/4627/artifact/artifacts/artifacts.precommit/00-sumfiles/gdb.log.1.xz >> it appears that the "info set" test started at line 1159 and failed with >> >> FAIL: gdb.base/default.exp: info set (timeout) >> >> at line 1533. Then a few more tests failed with timeout and finally >> over 100 tests failed with no obvious reason. >> >> Was this caused by a problem on the CI machine? > > Hi, > Thanks for the heads-up. > > I'm not aware of any problem with that CI machine, although it's > slightly slower than others we have. > > We do have a system to detect "flaky" tests, so this should normally > be excluded. > > Maybe Thiago has already noticed random results with this particular test? > Maybe it just needs an extended timeout factor to cope with large > numbers of environment variables? Yes, default.exp has a lot of flaky failures and they are normally discounted by our flaky detection system. The problem was that we recently lost history for the tcwg_gdb_check job and the system is still redetecting the flaky tests. Sorry about the false regression report. -- Thiago ___ linaro-toolchain mailing list -- linaro-toolchain@lists.linaro.org To unsubscribe send an email to linaro-toolchain-le...@lists.linaro.org
Re: [Patch, fortran] PR85836: Implement the F2018 reduce intrinsic
Hi!
On Wed, 19 Mar 2025 at 19:22, Paul Richard Thomas
wrote:
>
> Hi Andre,
>
> Thanks for the review - I'll act on the points that you raised.
>
> The Linaro people reported a failure in reduce_1.f90 execution, which I
> believe is due to incorrect casting of 'dim' and a wrong specification of its
> kind. I am waiting to hear back from them as to whether or not I have fixed
> the failure.
>
Sorry I notice this message just today, so it's a bit outdated...
I've looked at bugzilla, so I've noticed that the are proper bug
reports about this now (and I've just checked, the problem is still
present on arm).
When you say you are "waiting to hear back from them as to whether or
not I have fixed the failure", did you contact us directly? (I'm
trying to understand if we missed your message, or how we could
improve communication).
Thanks,
Christophe
> Cheers
>
> Paul
>
>
> On Wed, 19 Mar 2025 at 12:39, Andre Vehreschild wrote:
>>
>> Hi Paul,
>>
>> I took a look at your patch and think I found some improvements needed. In
>>
>> +bool
>> +gfc_check_reduce (gfc_expr *array, gfc_expr *operation, gfc_expr *dim,
>> + gfc_expr *mask, gfc_expr *identity, gfc_expr *ordered)
>> +{
>>
>> ...
>>
>> + if (formal->sym->attr.allocatable || formal->sym->attr.allocatable
>> + || formal->sym->attr.pointer || formal->sym->attr.pointer
>> + || formal->sym->attr.optional || formal->sym->attr.optional
>> + || formal->sym->ts.type == BT_CLASS || formal->sym->ts.type ==
>> BT_CLASS)
>> +{
>> + gfc_error ("Each argument of OPERATION at %L shall be a scalar, "
>> +"non-allocatable, non-pointer, non-polymorphic and "
>> +"nonoptional", &operation->where);
>> + return false;
>> +}
>>
>> The if is only looking at the first formal argument. The right-hand sides
>> of the || miss a ->next-> to look at the second formal argument, right?
>>
>> May be you also want to extend the tests!?
>>
>> Without having looked at it, but can't you extract the whole block of
>>
>> + if (array->ts.type == BT_CHARACTER)
>> +{
>> + unsigned long actual_size, formal_size1, formal_size2, result_size;
>> ...
>> + return false;
>> + }
>> +}
>>
>> and share it with the checks for co_reduce? I figure way to many DRY
>> principle
>> violations are in gfortran. So when we can start this, why not do it? And a
>> call to a routine, like check_char_arg_conformance() speaks way better, then
>> having to read all that code ;-)
>>
>> In gfc_resolve_reduce() identity and ordered are marked as UNUSED. Should
>> these
>> not a least be resolved?
>>
>> Please run contrib/check_GNU_style on your patch. It reports several issues
>> (haven't look into their validity).
>>
>> In the Changelog:
>>
>> - (gfc_check_rename): Add prototype for intrinsic with 6 arguments.
>> + * gfortran.h: Add prototype for intrinsic with 6 arguments.
>>
>> s/discription/description/
>>
>> I also encountered that nit with the executable stack when working in
>> OpenCoarrays, but haven't had time (or desire) to look into it. I will put
>> myself into CC of the pr Jerry mentioned.
>>
>> Besides the mentions above, this looks good to me.
>>
>> Thanks for the patch and
>>
>> Regards,
>> Andre
>>
>>
>>
>> On Sun, 16 Mar 2025 17:26:55 +
>> Paul Richard Thomas wrote:
>>
>> > Hi All,
>> >
>> > This version of the REDUCE intrinsic patch has evolved somewhat since the
>> > posting on 2nd March. The most important changes are to the wrapper
>> > function and the addition of two testsuite entries.
>> >
>> > The wrapper function now effects:
>> > subroutine wrapper (a, b, c)
>> > type_of_ARRAY, intent(inout) :: a, c
>> > type_of_ARRAY, intent(inout), optional :: b
>> > if (present (b)) then
>> > c = OPERATION (a,b )
>> > else
>> > c = a
>> > end if
>> > end subroutine
>> >
>> > The reason for wrapping OPERATION in a subroutine is to allow pointer
>> > arithmetic to be used throughout in the library function. The only thing
>> > that needs to be known about the type and kind of ARRAY is the element
>> > size. The second branch in the wrapper allows deep copies to be done in the
>> > library function, such that derived types with allocatable components do
>> > not leak memory. This is needed at the final step of the algorithm to copy
>> > the result from each iteration to the result and then nullify it.
>> >
>> > This is undoubtedly a bit heavy going for intrinsic types and so, one day
>> > soon I will possibly do a bit of M4ery. That said, the present version
>> > works for all types of ARRAY and I worry a bit about how much this
>> > intrinsic will be used. Thoughts?
>> >
>> > A slight niggle is the linker error that comes up if compiled without any
>> > optimization:
>> > /usr/bin/ld: warning: /tmp/cc9cx9Rw.o: requires executable stack (because
>> > the .note.GNU-stack section is executable)
>> > I
Re: [Patch, fortran] PR85836: Implement the F2018 reduce intrinsic
Hello Christophe,
I wrote to Thiago Bauermann, who was very helpful on the last occasion that
you picked up a bug in one of my patches.
As it happens, Harald Anlauf pointed out that the problem occurs with -m32
on x86_64 systems and so I am able to investigate it on my system. Thus
far, I have drawn a total blank with finding a fix. If necessary, I will
comment out the offending test.
Best regards
Paul
On Wed, 2 Apr 2025 at 10:12, Christophe Lyon
wrote:
> Hi!
>
> On Wed, 19 Mar 2025 at 19:22, Paul Richard Thomas
> wrote:
> >
> > Hi Andre,
> >
> > Thanks for the review - I'll act on the points that you raised.
> >
> > The Linaro people reported a failure in reduce_1.f90 execution, which I
> believe is due to incorrect casting of 'dim' and a wrong specification of
> its kind. I am waiting to hear back from them as to whether or not I have
> fixed the failure.
> >
>
> Sorry I notice this message just today, so it's a bit outdated...
> I've looked at bugzilla, so I've noticed that the are proper bug
> reports about this now (and I've just checked, the problem is still
> present on arm).
>
> When you say you are "waiting to hear back from them as to whether or
> not I have fixed the failure", did you contact us directly? (I'm
> trying to understand if we missed your message, or how we could
> improve communication).
>
> Thanks,
>
> Christophe
>
>
>
> > Cheers
> >
> > Paul
> >
> >
> > On Wed, 19 Mar 2025 at 12:39, Andre Vehreschild wrote:
> >>
> >> Hi Paul,
> >>
> >> I took a look at your patch and think I found some improvements needed.
> In
> >>
> >> +bool
> >> +gfc_check_reduce (gfc_expr *array, gfc_expr *operation, gfc_expr *dim,
> >> + gfc_expr *mask, gfc_expr *identity, gfc_expr *ordered)
> >> +{
> >>
> >> ...
> >>
> >> + if (formal->sym->attr.allocatable || formal->sym->attr.allocatable
> >> + || formal->sym->attr.pointer || formal->sym->attr.pointer
> >> + || formal->sym->attr.optional || formal->sym->attr.optional
> >> + || formal->sym->ts.type == BT_CLASS || formal->sym->ts.type ==
> BT_CLASS)
> >> +{
> >> + gfc_error ("Each argument of OPERATION at %L shall be a scalar, "
> >> +"non-allocatable, non-pointer, non-polymorphic and "
> >> +"nonoptional", &operation->where);
> >> + return false;
> >> +}
> >>
> >> The if is only looking at the first formal argument. The right-hand
> sides
> >> of the || miss a ->next-> to look at the second formal argument, right?
> >>
> >> May be you also want to extend the tests!?
> >>
> >> Without having looked at it, but can't you extract the whole block of
> >>
> >> + if (array->ts.type == BT_CHARACTER)
> >> +{
> >> + unsigned long actual_size, formal_size1, formal_size2,
> result_size;
> >> ...
> >> + return false;
> >> + }
> >> +}
> >>
> >> and share it with the checks for co_reduce? I figure way to many DRY
> principle
> >> violations are in gfortran. So when we can start this, why not do it?
> And a
> >> call to a routine, like check_char_arg_conformance() speaks way better,
> then
> >> having to read all that code ;-)
> >>
> >> In gfc_resolve_reduce() identity and ordered are marked as UNUSED.
> Should these
> >> not a least be resolved?
> >>
> >> Please run contrib/check_GNU_style on your patch. It reports several
> issues
> >> (haven't look into their validity).
> >>
> >> In the Changelog:
> >>
> >> - (gfc_check_rename): Add prototype for intrinsic with 6
> arguments.
> >> + * gfortran.h: Add prototype for intrinsic with 6 arguments.
> >>
> >> s/discription/description/
> >>
> >> I also encountered that nit with the executable stack when working in
> >> OpenCoarrays, but haven't had time (or desire) to look into it. I will
> put
> >> myself into CC of the pr Jerry mentioned.
> >>
> >> Besides the mentions above, this looks good to me.
> >>
> >> Thanks for the patch and
> >>
> >> Regards,
> >> Andre
> >>
> >>
> >>
> >> On Sun, 16 Mar 2025 17:26:55 +
> >> Paul Richard Thomas wrote:
> >>
> >> > Hi All,
> >> >
> >> > This version of the REDUCE intrinsic patch has evolved somewhat since
> the
> >> > posting on 2nd March. The most important changes are to the wrapper
> >> > function and the addition of two testsuite entries.
> >> >
> >> > The wrapper function now effects:
> >> > subroutine wrapper (a, b, c)
> >> > type_of_ARRAY, intent(inout) :: a, c
> >> > type_of_ARRAY, intent(inout), optional :: b
> >> > if (present (b)) then
> >> > c = OPERATION (a,b )
> >> > else
> >> > c = a
> >> > end if
> >> > end subroutine
> >> >
> >> > The reason for wrapping OPERATION in a subroutine is to allow pointer
> >> > arithmetic to be used throughout in the library function. The only
> thing
> >> > that needs to be known about the type and kind of ARRAY is the element
> >> > size. The second branch in the wrapper allows deep copies to be done
> in the
> >> > lib
[Linaro-TCWG-CI] glibc-2.41.9000-229-g7f163bd2106: 1 regressions on arm
Dear contributor, Our automatic CI has detected problems related to your patch(es). Please find some details below. In master-arm, after: | commit glibc-2.41.9000-229-g7f163bd2106 | Author: Joseph Myers | Date: Tue Apr 1 12:44:26 2025 + | | Update syscall lists for Linux 6.14 | | Linux 6.14 has no new syscalls. Update the version number in | syscall-names.list to reflect that it is still current for 6.14. | | ... 1 lines of the commit log omitted. Produces 1 regressions: | | regressions.sum: | Running glibc:misc ... | FAIL: misc/tst-glibcsyscalls Used configuration : *CI config* tcwg_gnu_native_check_glibc master-arm *configure and test flags:* none, autodetected on armv8l-unknown-linux-gnueabihf We track this bug report under https://linaro.atlassian.net/browse/GNU-1557. Please let us know if you have a fix. If you have any questions regarding this report, please ask on linaro-toolchain@lists.linaro.org mailing list. -8<--8<--8<-- The information below contains the details of the failures, and the ways to reproduce a debug environment: You can find the failure logs in *.log.1.xz files in * https://ci.linaro.org/job/tcwg_gnu_native_check_glibc--master-arm-build/1121/artifact/artifacts/00-sumfiles/ The full lists of regressions and improvements as well as configure and make commands are in * https://ci.linaro.org/job/tcwg_gnu_native_check_glibc--master-arm-build/1121/artifact/artifacts/notify/ The list of [ignored] baseline and flaky failures are in * https://ci.linaro.org/job/tcwg_gnu_native_check_glibc--master-arm-build/1121/artifact/artifacts/sumfiles/xfails.xfail Current build : https://ci.linaro.org/job/tcwg_gnu_native_check_glibc--master-arm-build/1121/artifact/artifacts Reference build : https://ci.linaro.org/job/tcwg_gnu_native_check_glibc--master-arm-build/1117/artifact/artifacts Instruction to reproduce the build : https://git-us.linaro.org/toolchain/ci/interesting-commits.git/plain/glibc/sha1/7f163bd2106f96e2925e9bb3e0e545cfae7ba1af/tcwg_gnu_native_check_glibc/master-arm/reproduction_instructions.txt Full commit : https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=7f163bd2106f96e2925e9bb3e0e545cfae7ba1af ___ linaro-toolchain mailing list -- linaro-toolchain@lists.linaro.org To unsubscribe send an email to linaro-toolchain-le...@lists.linaro.org
