Hi Thiago,
Great job tracking down such an obscure bug!
Thanks!
--
Maxim Kuvyrkov
https://www.linaro.org
> On Dec 28, 2024, at 11:13, Thiago Jung Bauermann
> wrote:
>
> Thiago Jung Bauermann writes:
>
>> Maxim Kuvyrkov writes:
>>
>>> Thiago, would yo
Oh, and for AArch64 as well:
https://ci.linaro.org/job/tcwg_kernel--gnu-master-aarch64-lts-allyesconfig-build/218/artifact/artifacts/06-build_linux/console.log.xz
--
Maxim Kuvyrkov
https://www.linaro.org
> On Dec 20, 2024, at 17:57, Maxim Kuvyrkov wrote:
>
> Hi Nick,
>
> Yo
Hi Nick,
Your patch causes kernel build failure for 32-bit ARM. See build log at [1].
Is this expected?
Thanks!
[1]
https://ci.linaro.org/job/tcwg_kernel--gnu-master-arm-mainline-allnoconfig-build/183/artifact/artifacts/06-build_linux/console.log.xz
--
Maxim Kuvyrkov
https://www.linaro.org
Thanks,
--
Maxim Kuvyrkov
https://www.linaro.org
> On Dec 19, 2024, at 12:44, Thiago Jung Bauermann
> wrote:
>
> Hello,
>
> Maxim Kuvyrkov writes:
>
>> Thiago, would you please investigate this?
>
> Ok, on it.
>
>> Start with confirming that the test
Hi Jan,
Sorry, this has slipped through cracks.
The failures are reproducible and are still present in the latest test run.
Thiago, would you please investigate this? Start with confirming that the
tests pass with current mainline with Jan's patch reverted.
Thank you!
--
Maxim Kuv
Hi Alexey,
It seems your patch below causes build failure of 654.roms_s for "-O3 -flto" on
aarch64-linux-gnu. Has this been reported already?
Let me know if not, and I'll help with the reporting and reproduction.
Thanks!
--
Maxim Kuvyrkov
https://www.linaro.org
> On Nov
Hi Sergei,
It seems your patch below breaks build of several SPEC CPU2017 benchmarks on
32-bit ARM.
Could you please investigate? Please let me know if you need any assistance in
reproducing build failures.
Thanks,
--
Maxim Kuvyrkov
https://www.linaro.org
> On Nov 21, 2024, at 20
-ld:
tmpdir/zlibbegin.o: final close failed: invalid operation
collect2: error: ld returned 1 exit status
Does this help?
Kind regards,
--
Maxim Kuvyrkov
https://www.linaro.org
> On Nov 20, 2024, at 03:12, Jan Beulich wrote:
>
> On 19.11.2024 05:29, ci_not...@linaro.org wrote:
>> D
struction to reproduce the build :
https://git-us.linaro.org/toolchain/ci/interesting-commits.git/plain/llvm/sha1/40c8938ff8447fc46bd2aa1605e3147cc38ffb8d/tcwg_flang_test/main-aarch64-O3-neoverse_v1-sve_vla-mpipeliner-stack_arrays/reproduction_instructions.txt
Full commit :
https://github.com/llvm/llvm-pr
a private email and I'll create a docker container for you on
one of Linaro machines.
--
Maxim Kuvyrkov
https://www.linaro.org
> Pan
>
> -Original Message-
> From: Sam James
> Sent: Sunday, October 27, 2024 3:37 PM
> To: Li, Pan2
> Cc: gcc-regress...@gcc.g
a private email and I'll create a docker container for you on
one of Linaro machines.
--
Maxim Kuvyrkov
https://www.linaro.org
> Pan
>
> -Original Message-
> From: Sam James
> Sent: Sunday, October 27, 2024 3:37 PM
> To: Li, Pan2
> Cc: gcc-regression@gcc.g
Hi Abdul,
Sorry for the delay.
Indeed, the report seems wrong. I see the test failing in the baseline
results, but the xfails file generated from those results does not include the
test. We will investigate.
Thanks!
--
Maxim Kuvyrkov
https://www.linaro.org
> On Oct 29, 2024, at 11
at -mcpu=unset has been added to the test name).
>
> That's not a regression, it's a simple FAIL->FAIL
Yes, that's correct.
Unfortunately, when a FAILed test is renamed, it appears as a new failure in
the result comparison, and it would be difficult to automatically ign
at -mcpu=unset has been added to the test name).
>
> That's not a regression, it's a simple FAIL->FAIL
Yes, that's correct.
Unfortunately, when a FAILed test is renamed, it appears as a new failure in
the result comparison, and it would be difficult to automatically ign
Hi Mark,
I believe this was caused by Christophe's binutils patch, which has now been
fixed.
Christophe, please correct me if I'm wrong.
Thanks!
--
Maxim Kuvyrkov
https://www.linaro.org
> On Sep 12, 2024, at 00:34, Mark Wielaard wrote:
>
> Hi,
>
> ci_not...@l
tifacts/06-build_linux/console.log.xz
.
Thanks!
--
Maxim Kuvyrkov
https://www.linaro.org
> On Sep 2, 2024, at 19:11, ci_not...@linaro.org wrote:
>
> Dear contributor, our automatic CI has detected problems related to your
> patch(es). Please find some details below. If you have an
Hi Julian,
Your patch below breaks Flang build [on aarch64]. Would you please investigate?
The interesting log is at
https://ci.linaro.org/job/tcwg_flang_build--main-aarch64-build/174/artifact/artifacts/03-build_llvm/console.log.xz
.
Thanks!
--
Maxim Kuvyrkov
https://www.linaro.org
>
itsu-Fortran-0153_0237.test
> FAIL: test-suite :: Fujitsu/Fortran/0153/Fujitsu-Fortran-0153_0234.test
> FAIL: test-suite :: Fujitsu/Fortran/0153/Fujitsu-Fortran-0153_0235.test
>
> ... and 5 more entries
Please investigate, and let me know if you need any help in reproducing or
troublesho
.
Let me know if you need any assistance in troubleshooting this.
Thanks!
--
Maxim Kuvyrkov
https://www.linaro.org
> On Jul 29, 2024, at 11:37, Tobias Burnus wrote:
>
> Hi all,
>
> what should I do with this – I have no idea what artifacts are nor is it
> clear to me w
for excess errors)
--
Maxim Kuvyrkov
https://www.linaro.org
> On Jul 28, 2024, at 09:28, ci_not...@linaro.org wrote:
>
> Dear contributor, our automatic CI has detected problems related to your
> patch(es). Please find some details below. If you have any questions,
> plea
for excess errors)
--
Maxim Kuvyrkov
https://www.linaro.org
> On Jul 28, 2024, at 09:28, ci_not...@linaro.org wrote:
>
> Dear contributor, our automatic CI has detected problems related to your
> patch(es). Please find some details below. If you have any questions,
> plea
Hi Christudasan,
Please ignore this report; it wasn't supposed to be posted publicly.
We are setting up additional testing of Flang, and this CI is in testing.
Kind regards,
--
Maxim Kuvyrkov
https://www.linaro.org
> On Jul 26, 2024, at 23:02, ci_not...@linaro.org wrote:
>
> De
++.dg/musttail6.C (test for excess errors)
It wasn't included in the report due to typo in the scripts.
Kind regards,
--
Maxim Kuvyrkov
https://www.linaro.org
> On Jul 26, 2024, at 19:38, ci_not...@linaro.org wrote:
>
> Dear contributor, our automatic CI has detected problems r
++.dg/musttail6.C (test for excess errors)
It wasn't included in the report due to typo in the scripts.
Kind regards,
--
Maxim Kuvyrkov
https://www.linaro.org
> On Jul 26, 2024, at 19:38, ci_not...@linaro.org wrote:
>
> Dear contributor, our automatic CI has detected problems r
Hi Jason,
The regression is ...
=== g++ tests ===
Running g++:g++.dg/dg.exp ...
FAIL: g++.dg/abi/arm_rtti1.C -std=gnu++26 scan-assembler _ZNKSt9type_infoeqERKS_
It wasn't included in the report due to typo in the scripts.
Kind regards,
--
Maxim Kuvyrkov
https://www.linaro.org
> O
Hi Jason,
The regression is ...
=== g++ tests ===
Running g++:g++.dg/dg.exp ...
FAIL: g++.dg/abi/arm_rtti1.C -std=gnu++26 scan-assembler _ZNKSt9type_infoeqERKS_
It wasn't included in the report due to typo in the scripts.
Kind regards,
--
Maxim Kuvyrkov
https://www.linaro.org
> O
f you need any assistance in troubleshooting the FAIL.
Kind regards,
--
Maxim Kuvyrkov
https://www.linaro.org
> On Jul 27, 2024, at 20:19, Simon Marchi wrote:
>
> On 2024-07-27 03:34, ci_not...@linaro.org wrote:
>> Dear contributor, our automatic CI has detected problems related
problem is introduced and then fixed in the same patch series. My
understanding is that all GNU toolchain projects strive to be "correct" at
every revision. This, of course, is not an issue if you plan to squash your
changes before merging them.
Does this answer your question?
T
be guarded on the target supporting vectorization? I.e.,
maybe add
// { dg-require-effective-target vect_int }
?
[1] https://linaro.atlassian.net/browse/GNU-1265
--
Maxim Kuvyrkov
https://www.linaro.org
> On Jun 21, 2024, at 19:03, Matthias Kretz via Gcc-regression
> wrote:
>
>
be guarded on the target supporting vectorization? I.e.,
maybe add
// { dg-require-effective-target vect_int }
?
[1] https://linaro.atlassian.net/browse/GNU-1265
--
Maxim Kuvyrkov
https://www.linaro.org
> On Jun 21, 2024, at 19:03, Matthias Kretz via Gcc-regression
> wrote:
>
>
Hi David,
Your patch below breaks linux kernel build on 32-bit ARM -- see [1]. Would you
please investigate?
[1]
https://ci.linaro.org/job/tcwg_kernel--gnu-master-arm-stable-allmodconfig-build/144/artifact/artifacts/06-build_linux/console.log.xz
Thanks!
--
Maxim Kuvyrkov
https
post-commit and pre-commit tests with the same flags -- the default
ones. I'm guessing the -pedantic-errors is coming from
gcc/testsuite/gfortran.dg/dg.exp via DEFAULT_FFLAGS.
Does this answer your question?
King regards,
--
Maxim Kuvyrkov
https://www.linaro.org
les. Also, some patches
fail to apply to current mainline, so we skip them. See [2] for more details.
[1] https://patchwork.sourceware.org/project/gcc/list/?series=33005
[2] https://patchwork.sourceware.org/project/gcc/list/
Kind regards,
--
Maxim Kuvyrkov
https://www.linaro.org
>
> Qin
your question?
Kind regards,
--
Maxim Kuvyrkov
https://www.linaro.org
> On Apr 22, 2024, at 17:33, Qing Zhao wrote:
>
> Hi,
>
> I am wondering why I got the following message?
>
> I only sent patch review request to
> gcc-patc...@gcc.gnu.org<mailto:gcc-patc...@gcc.gn
it~master-stage2/armv8l-unknown-linux-gnueabihf/./libatomic/.libs
-lm -o ./pr113363.exe
It should run on any stock ubuntu-22.04 rootfs for armhf architecture.
Kind regards,
--
Maxim Kuvyrkov
https://www.linaro.org
> On Apr 10, 2024, at 18:31, Paul Richard Thomas
> wrote:
>
> Hi ther
Hi Christina,
This is false-positive report -- see
https://sourceware.org/bugzilla/show_bug.cgi?id=31575 for details.
--
Maxim Kuvyrkov
https://www.linaro.org
> On Mar 29, 2024, at 10:22, ci_not...@linaro.org wrote:
>
> Dear contributor, our automatic CI has detected problems relate
Hi Kevin,
This is false-positive report -- see
https://sourceware.org/bugzilla/show_bug.cgi?id=31575 for details.
--
Maxim Kuvyrkov
https://www.linaro.org
> On Mar 29, 2024, at 10:48, ci_not...@linaro.org wrote:
>
> Dear contributor, our automatic CI has detected problems relate
Hi Abdul,
Hi Nils,
This is false-positive report -- see
https://sourceware.org/bugzilla/show_bug.cgi?id=31575 for details.
--
Maxim Kuvyrkov
https://www.linaro.org
> On Mar 29, 2024, at 10:52, ci_not...@linaro.org wrote:
>
> Dear contributor, our automatic CI has detected problems r
Hi Gustavo,
This is false-positive report -- see
https://sourceware.org/bugzilla/show_bug.cgi?id=31575 for details.
--
Maxim Kuvyrkov
https://www.linaro.org
> On Mar 29, 2024, at 10:54, ci_not...@linaro.org wrote:
>
> Dear contributor, our automatic CI has detected problems relate
https://gcc.gnu.org/g:b8e7aaaf350a4584d9b76e8dd69daa2203bac339
commit r14-9706-gb8e7aaaf350a4584d9b76e8dd69daa2203bac339
Author: Maxim Kuvyrkov
Date: Wed Mar 13 06:48:47 2024 +
[testsuite] Fixup dg-options in {gcc,g++,gfortran}.dg/vect.exp tests
Testsuites driven by vect.exp
Hi Richard,
Heads up, our benchmarking CI flagged your commit to cause 23% regression in
549.fotonik3d_r on Cortex-A57 at -O3.
Do you have internal benchmarks for this change?
Thanks!
--
Maxim Kuvyrkov
https://www.linaro.org
> On Mar 24, 2024, at 03:43, ci_not...@linaro.org wr
Changes in v2:
- Better changelog entry.
- NFC.
This patch has been tested on
- aarch64-linux-gnu
- arm-linux-gnueabihf (VFP, NEON disabled by default),
- arm-none-eabi (Soft-FP)
with the following [expected] differences in the test results:
- FAIL now PASS [FAIL => PASS]:
Execut
> On Mar 13, 2024, at 15:25, Richard Earnshaw
> wrote:
>
>
>
> On 13/03/2024 10:58, Maxim Kuvyrkov wrote:
>> This patch has been tested on
>> - aarch64-linux-gnu
>> - arm-linux-gnueabihf (VFP, NEON disabled by default),
>> - arm-none-eabi (Soft-FP)
&g
This patch has been tested on
- aarch64-linux-gnu
- arm-linux-gnueabihf (VFP, NEON disabled by default),
- arm-none-eabi (Soft-FP)
with the following [expected] differences in the test results:
- FAIL now PASS [FAIL => PASS]:
Executed from: gcc:gcc.dg/vect/vect.exp
gcc:gcc.dg/v
> On Mar 11, 2024, at 20:52, Jonathan Wakely wrote:
>
> On Mon, 11 Mar 2024 at 16:38, Maxim Kuvyrkov
> wrote:
>>
>>> On Jan 30, 2024, at 23:03, ci_not...@linaro.org wrote:
>>>
>>> Dear contributor, our automatic CI has detected problems rela
> On Mar 12, 2024, at 00:14, Tom Tromey wrote:
>
>>>>>> Maxim Kuvyrkov writes:
>
>>> | commit gdb-14-branchpoint-1356-g7737b133640
>>> | Author: Tom Tromey
>>> | Date: Tue Jan 9 11:47:17 2024 -0700
>>> |
>>> |
patch seems to regress the above 3 tests for all 32-bit ARM targets (see
[1]). Would you please check if the regressions can be avoided?
For reference, here are configure options we use for arm-linux-gnueabihf
cross-toolchain: [2].
[1] https://linaro.atlassian.net/browse/GNU-1140
[2]
https://c
patch seems to regress the above 3 tests for all 32-bit ARM targets (see
[1]). Would you please check if the regressions can be avoided?
For reference, here are configure options we use for arm-linux-gnueabihf
cross-toolchain: [2].
[1] https://linaro.atlassian.net/browse/GNU-1140
[2]
https://c
_cat'
warning: RTTI symbol not found for class 'main::custom_cat'
got: $36 = warning: RTTI symbol not found for class 'main::custom_cat'
FAIL: libstdc++-prettyprinters/cxx11.cc print ecmiaow
===
Which way should I dig -- GDB or libstdc++? Does this look like libstdc++
te
sts now consistently failing across all 32-bit ARM
configurations that we track (see [1]).
As an example, our configure options for arm-linux-gnueabihf that show the
failure are at [2].
[1] https://linaro.atlassian.net/browse/GNU-1132
[2]
https://ci.linaro.org/job/tcwg_gcc_check--master-arm-bui
sts now consistently failing across all 32-bit ARM
configurations that we track (see [1]).
As an example, our configure options for arm-linux-gnueabihf that show the
failure are at [2].
[1] https://linaro.atlassian.net/browse/GNU-1132
[2]
https://ci.linaro.org/job/tcwg_gcc_check--master-arm-bui
value => 126, another_value => 12, color => red)
(gdb) FAIL: gdb.ada/scalar_storage.exp: print V_BE
===
Any idea what can be causing this?
This failure happens in CI configurations where we track tip-of-trunk GCC.
[1]
https://ci.linaro.org/job/tcwg_gnu_native_check_gdb--master-aarch6
ent some support for TLS_DTV_AT_TP
> htl: Add an AArch64 implementation
> hurd: Add expected aarch64-gnu abistlists
Hi Sergey,
Would you please update and re-post your patch series, so that reviewers can
check that it doesn't break existing targets? We (Linaro) had our pre-commit
CI down in late December / early January, so most of your patches weren't
tested, see [1].
[1] https://patchwork.sourceware.org/project/glibc/list/?series=29086
Thank you,
--
Maxim Kuvyrkov
https://www.linaro.org
> On Feb 29, 2024, at 21:59, Richard Earnshaw (lists)
> wrote:
>
> On 29/02/2024 17:55, Andrew Pinski (QUIC) wrote:
>>> -Original Message-
>>> From: Maxim Kuvyrkov
>>> Sent: Thursday, February 29, 2024 9:46 AM
>>> To: Andrew Pins
> On Feb 29, 2024, at 21:35, Andrew Pinski (QUIC)
> wrote:
>
>
>
>> -Original Message-
>> From: Evgeny Karpov
>> Sent: Thursday, February 29, 2024 8:46 AM
>> To: Andrew Pinski
>> Cc: Richard Sandiford ; gcc-
>> patc...@gc
Hi Evgeny,
Great job!
For reference, here is a test build of this patch series using Linaro Toolchain
CI:
https://ci.linaro.org/view/tcwg-build/job/tcwg_gnu_mingw_build--master-woa64-build/9/artifact/artifacts/
--
Maxim Kuvyrkov
https://www.linaro.org
> On Feb 21, 2024, at 21:47, Evg
> On Feb 21, 2024, at 12:44, Tiezhu Yang wrote:
>
>
>
> On 02/21/2024 03:16 PM, Maxim Kuvyrkov wrote:
>>> On Feb 21, 2024, at 05:46, Tiezhu Yang wrote:
>>>
>>>
>>>
>>> On 02/21/2024 03:52 AM, ci_not...@linaro.org wrote:
>>&g
1]
https://ci.linaro.org/job/tcwg_gdb_check--master-arm-precommit/1725/artifact/artifacts/artifacts.precommit/sumfiles/xfails.xfail/*view*/
--
Maxim Kuvyrkov
https://www.linaro.org
___
linaro-toolchain mailing list -- linaro-toolchain@lists.linaro.org
To unsubscribe send an email to linaro-toolchain-le...@lists.linaro.org
Hi Richard,
This is a false positive. We had a bit of instability in our CI yesterday, and
it should be all fixed now.
Thanks,
--
Maxim Kuvyrkov
https://www.linaro.org
> On Feb 14, 2024, at 23:00, ci_not...@linaro.org wrote:
>
> Dear contributor, our automatic CI has detected
o
open tst-gnu2-tls2mod2.so
close tst-gnu2-tls2mod0.so
close tst-gnu2-tls2mod1.so
open tst-gnu2-tls2mod0.so
open tst-gnu2-tls2mod1.so
Didn't expect signal from child: got `Segmentation fault'
===
Let me know if you need any help investigating this.
Thanks!
--
Maxim Kuvyrkov
https://www.li
Hi Nathaniel,
We enabled guality tests in our CI setup yesterday, and this is part of the
fallout. Please ignore this report.
Kind regards,
--
Maxim Kuvyrkov
https://www.linaro.org
> On Feb 14, 2024, at 09:55, ci_not...@linaro.org wrote:
>
> Dear contributor, our automatic CI has
Hi H.J.,
We enabled guality tests in our CI setup yesterday, and this is part of the
fallout. Please ignore this report.
Kind regards,
--
Maxim Kuvyrkov
https://www.linaro.org
> On Feb 14, 2024, at 09:36, ci_not...@linaro.org wrote:
>
> Dear contributor, our automatic CI has
Hi Andrew,
We enabled guality tests in our CI setup yesterday, and this is part of the
fallout. Please ignore this report.
Kind regards,
--
Maxim Kuvyrkov
https://www.linaro.org
> On Feb 14, 2024, at 09:39, Andrew Pinski (QUIC)
> wrote:
>
> This does not make sense at all. Th
Hi Robin,
Please ignore this report. We had a bit of instability in CI testing yesterday.
--
Maxim Kuvyrkov
https://www.linaro.org
> On Feb 14, 2024, at 09:11, ci_not...@linaro.org wrote:
>
> Dear contributor, our automatic CI has detected problems related to your
> patch(es).
Hi Jakub,
Please ignore this. I'm going to investigate, but most likely this is due to
instability of guality tests.
--
Maxim Kuvyrkov
https://www.linaro.org
> On Feb 14, 2024, at 01:43, ci_not...@linaro.org wrote:
>
> Dear contributor, our automatic CI has detected problems r
pr41447-1.c -O0 execution test
>
> Running gcc:gcc.dg/ipa/ipa.exp ...
> UNRESOLVED: gcc.dg/ipa/iinline-4.c scan-ipa-dump inline "hooray4[^\\n]*inline
> copy in test4"
> UNRESOLVED: gcc.dg/ipa/iinline-4.c scan-ipa-dump inline "hooray1[^\\n]*inline
> copy in test1&qu
Hi Richard,
Ack. Thanks for the follow up!
--
Maxim Kuvyrkov
https://www.linaro.org
> On Feb 12, 2024, at 18:46, Richard Earnshaw
> wrote:
>
> I think all of these actually fall under
>
> "I suspect there are still some further issues to address here, since
&
Hi Arjun,
This is not a real regression. We have a problem in our CI that causes
container tests fail for 32-bit ARM. Therefore, any new container test shows
up as a regression.
We are working on fixing this.
Thanks,
--
Maxim Kuvyrkov
https://www.linaro.org
> On Jan 31, 2024, at 06
1.xz
.
Hi Thiago,
Would you please investigate whether ending up in pthread_join() is
expected/reasonable for 32-bit ARM? In other words, whether we have a GDB bug
exposed by staticthreads.exp or the testcase needs to be generalized a bit.
Thank you,
--
Maxim Kuvyrkov
https://www.linaro.or
> On Jan 25, 2024, at 19:04, Guinevere Larsen wrote:
>
> On 25/01/2024 10:10, Maxim Kuvyrkov wrote:
>>> On Jan 25, 2024, at 04:08, ci_not...@linaro.org wrote:
>>>
>>> Dear contributor, our automatic CI has detected problems related to your
>>> patch
tional-options "-march=skylake-avx512" } */
Please adjust the testcase; this fails on non-x86_64 targets, see [1] and [2].
[1]
https://patchwork.sourceware.org/project/gcc/patch/20240124144159.51c503858...@sourceware.org/
[2]
https://ci.linaro.org/job/tcwg_gcc_check--master-aarch
After fwprop improvement in r14-8319-g86de9b66480, codegen in
bics_3.c test changed from "bics" to "bic" instruction, with
the overall instruction stream remaining at the same quality.
This patch makes the scan-assembler directive accept both
"bics" and "bic".
BEFORE r14-8319-g86de9b66480:
0xf7eadb04 in ?? ()
7LWP 4764470xf7eadb04 in ?? ()
(gdb) FAIL: gdb.threads/threadcrash.exp: test_gcore: $thread_count == 7
===
Could you please look into fixing the testcase? [I assume "LWP" output is
expected, but I'm not an expert in GDB.]
Thanks!
--
Maxim
> On Jan 19, 2024, at 17:31, H.J. Lu wrote:
>
> On Thu, Jan 18, 2024 at 11:15 PM Maxim Kuvyrkov
> wrote:
>>
>> Hi H.J.,
>>
>> Did the email below made it to your inbox? I wonder if some of our
>> precommit CI emails are not reaching developer
Hi H.J.,
Did the email below made it to your inbox? I wonder if some of our precommit
CI emails are not reaching developers.
Kind regards,
--
Maxim Kuvyrkov
https://www.linaro.org
> On Jan 10, 2024, at 02:24, ci_not...@linaro.org wrote:
>
> Dear contributor, our automatic CI has
.
>
> Please let me know if the issue is something else and I can take
> another look.
Thanks!
--
Maxim Kuvyrkov
https://www.linaro.org
>
> Yours,
> Nathaniel.
>
> On Thu, Jan 18, 2024 at 07:12:12AM +, ci_not...@linaro.org wrote:
>> Dear contributor, our
> On Jan 17, 2024, at 19:05, Maxim Kuvyrkov wrote:
>
>> On Jan 17, 2024, at 19:02, Richard Biener wrote:
>>
>> On Wed, Jan 17, 2024 at 8:39 AM Maxim Kuvyrkov
>> wrote:
>>>
>>>> On Jan 17, 2024, at 10:51, Richard Biener
>>>> wr
... caused by scheduler fix for PR96388 and PR111554.
This patch adjusts decision sched-deps.cc:find_inc() to use
length of dependency lists sans any DEBUG_INSN instructions.
gcc/ChangeLog:
* haifa-sched.cc (dep_list_size): Make global.
* sched-deps.cc (find_inc): Use instead of
> On Jan 17, 2024, at 19:02, Richard Biener wrote:
>
> On Wed, Jan 17, 2024 at 8:39 AM Maxim Kuvyrkov
> wrote:
>>
>>> On Jan 17, 2024, at 10:51, Richard Biener
>>> wrote:
>>>
>>> On Tue, Jan 16, 2024 at 3:52 PM Jeff Law wrote:
>>
> On Jan 17, 2024, at 10:51, Richard Biener wrote:
>
> On Tue, Jan 16, 2024 at 3:52 PM Jeff Law wrote:
>>
>>
>>
>> On 1/15/24 05:56, Maxim Kuvyrkov wrote:
>>> Hi Vladimir,
>>> Hi Jeff,
>>>
>>> Richard and Alexander have re
Dear scheduler maintainers,
Gentle ping. This patch improves debugging output, it does not touch
scheduling logic.
On Wed, 22 Nov 2023 at 15:15, Maxim Kuvyrkov
wrote:
> Scheduler dependency analysis uses two main data structures:
> 1. reg_pending_* data contains effects of INSN
Dear scheduler maintainers,
Gentle ping. This patch improves debugging output, it does not touch
scheduling logic.
On Wed, 22 Nov 2023 at 15:15, Maxim Kuvyrkov
wrote:
> Scheduler dependency analysis uses two main data structures:
> 1. reg_pending_* data contains effects of INSN
Dear scheduler maintainers,
Gentle ping. This is a trivial cleanup.
On Wed, 22 Nov 2023 at 15:14, Maxim Kuvyrkov
wrote:
> gcc/ChangeLog:
>
> * sched-deps.cc (init_deps, init_deps_reg_last): Simplify.
> (free_deps): Remove useless code.
> ---
> gcc/
Dear scheduler maintainers,
Gentle ping. This is a trivial patch, which makes debugging sched-deps.cc
slightly more enjoyable.
On Wed, 22 Nov 2023 at 15:14, Maxim Kuvyrkov
wrote:
> gcc/ChangeLog:
>
> * sched-deps.cc (sd_add_dep, find_inc): Add logging about
>
Dear scheduler maintainers,
Gentle ping. This patch is borderline trivial and affects only the lucky
few who debug sched-deps.cc code. OK to merge?
On Wed, 22 Nov 2023 at 15:14, Maxim Kuvyrkov
wrote:
> Better propagate flags from dump_lists() into dump_dep() and
> add a missing
Dear RTL maintainers,
Gently ping. This patch adds a couple of new functions to lists.cc, which
then are used to simplify logic in the scheduler. OK to merge?
On Wed, 22 Nov 2023 at 15:14, Maxim Kuvyrkov
wrote:
> This patch simplifies logic behind deps_join(), which will be
> importa
Hi Vladimir,
Hi Jeff,
Richard and Alexander have reviewed this patch and [I assume] have no
further comments. OK to merge?
On Wed, 22 Nov 2023 at 15:14, Maxim Kuvyrkov
wrote:
> This patch avoids sched-deps.cc:find_inc() creating exponential number
> of dependencies, which become memo
Hi Ian,
[Apologies for late reply, your email got caught in moderation queue.]
Do you still need help in reproducing the build?
On our side we are working to include configure/make lines into reports to
simplify reproduction.
Kind regards,
--
Maxim Kuvyrkov
https://www.linaro.org
> On
Hi Lehua,
[Apologies for late reply, your email got caught in moderation queue.]
Do you still need help in reproducing the build?
On our side we are working to include configure/make lines into reports to
simplify reproduction.
Kind regards,
--
Maxim Kuvyrkov
https://www.linaro.org
> On
regards,
--
Maxim Kuvyrkov
https://www.linaro.org
> On Nov 29, 2023, at 19:20, Rainer Orth wrote:
>
> ci_not...@linaro.org writes:
>
>> Dear contributor, our automatic CI has detected problems related to your
>> patch(es). Please find some details below. If you have
d.
> In this case, is GCC configured to include neon by default? If so then the
> testcase needs to be updated to add an option to disable neon.
Hi Andrew,
We'll soon have configure and make info in the report.
> If not, then someone else will need to look into why the tes
://linaro.atlassian.net/browse/GNU-1084).
Would you please investigate this? And don't hesitate to ask for our
assistance in reproducing this.
Kind regards,
--
Maxim Kuvyrkov
https://www.linaro.org
> On Dec 21, 2023, at 03:20, ci_not...@linaro.org wrote:
>
> Dear contributor, our automatic C
Hi kernel folks,
It seems a new gcc patch uncovered a potential problem in btrfs code, see the
warning/error below.
Does this look like a legit kernel problem?
--
Maxim Kuvyrkov
https://www.linaro.org
> On Dec 22, 2023, at 06:54, ci_not...@linaro.org wrote:
>
> Dear contrib
lated
> to my patch.
Hi Tamar,
Linaro benchmarking builds the whole sysroot with the "new" compiler, including
glibc. It may be interesting to double-check code-gen differences on glibc's
exp() and make sure they are no obvious bad choices.
--
Maxim Kuvyrkov
https://www.linaro.
Scheduler dependency analysis uses two main data structures:
1. reg_pending_* data contains effects of INSN on the register file,
which is then incorporated into ...
2. deps_desc object, which contains commulative information about all
instructions processed from deps_desc object's initializa
Better propagate flags from dump_lists() into dump_dep() and
add a missing "]" in dump_lists().
gcc/ChangeLog:
* sched-deps.cc (DUMP_DEP_PRO): Improve comment.
(dump_dep_flags): Remove.
(DUMP_LISTS_SIZE, DUMP_LISTS_DEPS, DUMP_LISTS_ALL): Continue
numbering from DUM
This patch simplifies logic behind deps_join(), which will be
important for the upcoming improvements of sched-deps.cc logging.
The only functional change is that when deps_join() is called with
empty state for the 2nd argument, it will not reverse INSN_ and
EXPR_LISTs in the 1st argument. Before
Scheduler dependency analysis uses two main data structures:
1. reg_pending_* data contains effects of INSN on the register file,
which is then incorporated into ...
2. deps_desc object, which contains commulative information about all
instructions processed from deps_desc object's initializa
We currently have 3 implementations of print_hard_reg_set()
(all with the same name!) in ira-color.cc, ira-conflicts.cc, and
sel-sched-dump.cc. This patch generalizes implementation in
ira-color.cc, and uses it in all other places. The declaration
is added to hard-reg-set.h.
The motivation for t
gcc/ChangeLog:
* sched-deps.cc (init_deps, init_deps_reg_last): Simplify.
(free_deps): Remove useless code.
---
gcc/sched-deps.cc | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/gcc/sched-deps.cc b/gcc/sched-deps.cc
index 2a87158ba4b..e0d3c97d935
1 - 100 of 1010 matches
Mail list logo
