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:
>
>
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
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]:
> 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
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://ci.linaro.org/jo
ently 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-build/lastSuccessf
> 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
l-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-aarch64-pr
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:
> 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
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 o
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 o
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 m
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
> imp
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
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
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
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.
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
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
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
gcc/ChangeLog:
* sched-deps.cc (sd_add_dep, find_inc): Add logging about
dependency creation.
---
gcc/sched-deps.cc | 30 ++
1 file changed, 26 insertions(+), 4 deletions(-)
diff --git a/gcc/sched-deps.cc b/gcc/sched-deps.cc
index
/show_bug.cgi?id=111554
Maxim Kuvyrkov (8):
sched-deps.cc (find_modifiable_mems): Avoid exponential behavior
Unify implementations of print_hard_reg_set()
Simplify handling of INSN_ and EXPR_LISTs in sched-rgn.cc
Improve and fix sched-deps.cc: dump_dep() and dump_lists().
Add a bit more logging
This patch avoids sched-deps.cc:find_inc() creating exponential number
of dependencies, which become memory and compilation time hogs.
Consider example (simplified from PR96388) ...
===
sp=sp-4 // sp_insnA
mem_insnA1[sp+A1]
...
mem_insnAN[sp+AN]
sp=sp-4 // sp_insnB
mem_insnB1[sp+B1]
...
> On Nov 20, 2023, at 20:30, Alexander Monakov wrote:
>
>
> On Mon, 20 Nov 2023, Maxim Kuvyrkov wrote:
>
>>> On Nov 20, 2023, at 17:52, Alexander Monakov wrote:
>>>
>>>
>>> On Mon, 20 Nov 2023, Maxim Kuvyrkov wrote:
>>>
>>
> On Nov 20, 2023, at 17:45, Richard Biener wrote:
>
> On Mon, Nov 20, 2023 at 2:42 PM Maxim Kuvyrkov
> wrote:
>>
>>> On Nov 20, 2023, at 17:09, Richard Biener
>>> wrote:
>>>
>>> On Mon, Nov 20, 2023 at 1:08 PM Maxim Kuvyrkov
>>&
This patch avoids sched-deps.cc:find_inc() creating exponential number
of dependencies, which become memory and compilation time hogs.
Consider example (simplified from PR96388) ...
===
sp=sp-4 // sp_insnA
mem_insnA1[sp+A1]
...
mem_insnAN[sp+AN]
sp=sp-4 // sp_insnB
mem_insnB1[sp+B1]
...
> On Nov 20, 2023, at 17:52, Alexander Monakov wrote:
>
>
> On Mon, 20 Nov 2023, Maxim Kuvyrkov wrote:
>
>> This patch avoids sched-deps.cc:find_inc() creating exponential number
>> of dependencies, which become memory and compilation time hogs.
>> Consider
> On Nov 20, 2023, at 17:09, Richard Biener wrote:
>
> On Mon, Nov 20, 2023 at 1:08 PM Maxim Kuvyrkov
> wrote:
>>
>> This patch avoids sched-deps.cc:find_inc() creating exponential number
>> of dependencies, which become memory and compilation time hogs.
>&g
This patch avoids sched-deps.cc:find_inc() creating exponential number
of dependencies, which become memory and compilation time hogs.
Consider example (simplified from PR96388) ...
===
sp=sp-4 // sp_insnA
mem_insnA1[sp+A1]
...
mem_insnAN[sp+AN]
sp=sp-4 // sp_insnB
mem_insnB1[sp+B1]
...
to be
published, as it'll take me another week to clean them up.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96388
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111554
Maxim Kuvyrkov (1):
sched-deps.cc (find_modifiable_mems): Avoid exponential behavior
gcc/sched-deps.cc | 45
hen restore it if no real insns
have been scheduled.
Kind regards,
--
Maxim Kuvyrkov
https://www.linaro.org
> On Nov 8, 2023, at 06:49, Kewen.Lin wrote:
>
> Hi,
>
> Gentle ping this:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2023-October/634201.html
&g
s failed it.
Where the current script is located? These checks would be useful for all GNU
Toolchain projects -- binutils/GDB, GCC, Glibc and, maybe, Newlib -- so it
would be useful to put it in a separate "gnutools" repo. I think Siddhesh and
Carlos are looking into creating such a repo on gitlab?
Thanks,
--
Maxim Kuvyrkov
https://www.linaro.org
ct values,
and gotools.sum provided "Running ".
Note that libgo.sum, which also uses Makefile logic to generate
DejaGnu-like output, already has "..." suffix.
gotools/ChangeLog:
* Makefile.am: Update "Running ..." output
* Makefile.in: Re
> On Nov 2, 2023, at 21:02, rep.dot@gmail.com wrote:
>
> Hi Maxim!
>
> Many thanks for the patch! Quick question below..
>
> On 2 November 2023 13:48:55 CET, Maxim Kuvyrkov
> wrote:
>> ... to restore compatability with validate_failures.py .
>> The t
Patch proposed at
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635000.html
--
Maxim Kuvyrkov
https://www.linaro.org
> On Sep 27, 2023, at 18:47, Maxim Kuvyrkov wrote:
>
> Hi Bernhard,
>
> Thanks, I meant to fix this, but forgot.
>
> The underlying problem
... to restore compatability with validate_failures.py .
The testsuite script validate_failures.py expects
"Running ..." to extract values,
and gotools.sum provided "Running ".
Note that libgo.sum, which also uses Makefile logic to generate
DejaGnu-like output, already has "..." suffix.
Green/Red" in patchwork mean the usual PASS/FAIL.
It's only in post-commit CI in jenkins interface green and red mean something
different.
--
Maxim Kuvyrkov
https://www.linaro.org
.
My preferred way of fixing this is to make go's testsuite print out "..." . We
have a similar patch for glibc [1].
[1] https://sourceware.org/pipermail/libc-alpha/2023-June/148702.html
--
Maxim Kuvyrkov
https://www.linaro.org
> On Sep 26, 2023, at 19:46, Bernhard Reutner-Fischer
>
://patchwork.sourceware.org/project/gcc/patch/5ad7cdca-63e1-73af-b38d-d58898e21...@linux.ibm.com/
[2]
https://patchwork.sourceware.org/project/gcc/patch/65ed79a3-9964-dd50-39cb-98d5dbc72...@linux.ibm.com/
--
Maxim Kuvyrkov
https://www.linaro.org
> On Sep 18, 2023, at 09:59, Ajit Agarwal via
ist/
[2] https://sourceware.org/bugzilla/show_bug.cgi?id=29713
Thanks!
--
Maxim Kuvyrkov
https://www.linaro.org
> On Sep 12, 2023, at 02:58, ci_not...@linaro.org wrote:
>
> Dear contributor, our automatic CI has detected problems related to your
> patch(es). Please find some details be
mpiler error: Segmentation
fault)
FAIL: g++.dg/modules/map-2.C -std=c++2b (test for excess errors)
===
Thanks,
--
Maxim Kuvyrkov
https://www.linaro.org
>
> [P1689R5]: https://isocpp.org/files/papers/P1689R5.html
>
> I've also added patches to include imported module CMI files
mpiler error: Segmentation
fault)
FAIL: g++.dg/modules/map-2.C -std=c++2b (test for excess errors)
===
Thanks,
--
Maxim Kuvyrkov
https://www.linaro.org
>
> [P1689R5]: https://isocpp.org/files/papers/P1689R5.html
>
> I've also added patches to include imported module CMI files
FAIL: g++.dg/analyzer/pr100244.C -std=c++17 (test for warnings, line 17)
FAIL: g++.dg/analyzer/pr100244.C -std=c++20 (test for warnings, line 17)
=== gcc tests ===
Running gcc:gcc.dg/analyzer/analyzer.exp ...
FAIL: gcc.dg/analyzer/pr101962.c (test for warnings, line 19)
Thanks,
--
Maxim Ku
chmarks.
Hi Cui,
I'm seeing a 4% slowdown on 436.cactusADM from SPEC CPU2006 on
aarch64-linux-gnu (Cortex-A57) when compiling with "-O2 -flto". All other
benchmarks seem neutral to this patch, and I didn't observe the slow down with
plain -O2 no-LTO or with -O3.
Is this som
U2017 license, and I can post details to you privately.
Kind regards,
--
Maxim Kuvyrkov
https://www.linaro.org
> On Jun 1, 2023, at 19:09, Jonathan Wakely via Gcc-patches
> wrote:
>
> Tested powerpc64le-linux. Pusshed to trunk.
>
> -- >8 --
>
> My r14-1452-g
]) to(e
[len: 4]) from(d [len: 4]) from(present:b [len: 4000])
Let me know if you need any help in troubleshooting this.
--
Maxim Kuvyrkov
https://www.linaro.org
> On Jun 7, 2023, at 02:50, haochen.jiang via Gcc-patches
> wrote:
>
> On Linux/x86_64,
>
> 4ede915d5dde935a16df2c
> On Jun 3, 2023, at 19:17, Jeff Law wrote:
>
> On 6/2/23 09:20, Maxim Kuvyrkov via Gcc-patches wrote:
>> This patch adds tracking of current testsuite "tool" and "exp"
>> to the processing of .sum files. This avoids aliasing between
>> tests from
Hi David,
Hm, I'm seeing this failure only in pre-commit testing, but I don't see it in
our post-commit testing of gcc:master.
Does this patch rely on your other patch committed just before this one?
--
Maxim Kuvyrkov
https://www.linaro.org
> On Jun 3, 2023, at 09:23, Maxim Kuvyrkov wr
/results.compare/*view*/
Thanks!
--
Maxim Kuvyrkov
https://www.linaro.org
> On Jun 2, 2023, at 17:32, David Malcolm via Gcc-patches
> wrote:
>
> This patch implements many of the __atomic_* builtins from
> sync-builtins.def as known_function subclasses within the analyzer.
&g
This patch simplifies comparison of results that have filesystem
paths. E.g., (assuming different values of ):
Running
/home/user/gcc-N/gcc/testsuite/gcc.target/aarch64/sve/acle/aarch64-sve-acle-asm.exp
...
ERROR: tcl error sourcing
From: Christophe Lyon
This makes it easier to extract the $tool:$exp pair when iterating
over failures/flaky tests, which, in turn, simplifies re-running
testsuite parts that have unexpected failures or passes.
---
contrib/testsuite-management/validate_failures.py | 8 +---
1 file changed,
This option sets "today" date to compare expiration entries against.
Setting expiration date into the future allows re-detection of flaky
tests and creating fresh entries for them before the current flaky
entries expire.
---
.../testsuite-management/validate_failures.py | 24 +--
From: Thiago Bauermann
- Print message in case of broken sum file error.
- Print error messages to stderr. The script's stdout is, usually,
redirected to a file, and error messages shouldn't go there.
---
contrib/testsuite-management/validate_failures.py | 5 -
1 file changed, 4
... in the results. Python exits with code "1" on exceptions and
internal errors, which we use to detect failure to parse results.
---
contrib/testsuite-management/validate_failures.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
... to control validate_failures.py output
---
.../testsuite-management/validate_failures.py | 82 +++
1 file changed, 46 insertions(+), 36 deletions(-)
diff --git a/contrib/testsuite-management/validate_failures.py
b/contrib/testsuite-management/validate_failures.py
index
Before this patch we would identify malformed line
"UNRESOLVEDTest run by tcwg-buildslave on Mon Aug 23 10:17:50 2021"
as an interesting result, only to fail in TestResult:__init__ due
to missing ":" after UNRESOLVED.
This patch makes all places that parse result lines use a single
compiled
---
contrib/testsuite-management/validate_failures.py | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/contrib/testsuite-management/validate_failures.py
b/contrib/testsuite-management/validate_failures.py
index 94ba2e58b51..7351ba120b7 100755
---
This allows comparison of two build directories with a manifest
listing known flaky tests on the side.
---
contrib/testsuite-management/validate_failures.py | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/contrib/testsuite-management/validate_failures.py
This option is used to detect flaky tests that FAILed in the clean
build (or manifest), but PASSed in the current build (or manifest).
The option inverts output logic similar to what "-v/--invert-match"
does for grep.
---
.../testsuite-management/validate_failures.py | 34 +--
1
... and don't require a valid build directory when no data from it
is necessary.
---
contrib/testsuite-management/validate_failures.py | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/contrib/testsuite-management/validate_failures.py
This patch adds tracking of current testsuite "tool" and "exp"
to the processing of .sum files. This avoids aliasing between
tests from different testsuites with same name+description.
E.g., this is necessary for testsuite/c-c++-common, which is ran
for both gcc and g++ "tools".
This patch
This patch series extends and improves validate_failures.py script
to provide a powerful tool to handle DejaGnu test results in automated
CI environment.
Linaro TCWG uses validate_failures.py to ...
- compare test results without human oversight,
- detect unexpected FAILs vs baseline,
- detect
> On 8 Oct 2021, at 13:22, Martin Jambor wrote:
>
> Hi,
>
> On Fri, Oct 01 2021, Gerald Pfeifer wrote:
>> On Wed, 29 Sep 2021, Maxim Kuvyrkov via Gcc wrote:
>>> Configurations that track master branches have 3-day intervals.
>>> Configuratio
> On 29 Sep 2021, at 21:21, Andrew MacLeod wrote:
>
> On 9/29/21 7:59 AM, Maxim Kuvyrkov wrote:
>>
>>> Does it run like once a day/some-time-period, and if you note a
>>> regression, narrow it down?
>> Configurations that track master branches ha
> On 27 Sep 2021, at 19:02, Andrew MacLeod wrote:
>
> On 9/27/21 11:39 AM, Maxim Kuvyrkov via Gcc wrote:
>>> On 27 Sep 2021, at 16:52, Aldy Hernandez wrote:
>>>
>>> [CCing Jeff and list for broader audience]
>>>
>>> On 9/27/21 2:53 PM, Max
> On 27 Sep 2021, at 16:52, Aldy Hernandez wrote:
>
> [CCing Jeff and list for broader audience]
>
> On 9/27/21 2:53 PM, Maxim Kuvyrkov wrote:
>> Hi Aldy,
>> Your patch seems to slow down 471.omnetpp by 8% at -O3. Could you please
>> take a look if this is som
2019 at 01:57, Jeff Law wrote:
> On 8/29/19 9:44 AM, Maxim Kuvyrkov wrote:
> > Hi,
> >
> > The first patch adds ranking statistics for autoprefetcher heuristic.
> >
> > The second one makes it easier to diff scheduler debug dumps by adding
> more contex
). So I think your proposed patch is OK as is.
>
> Cheers,
> Wilco
>
>
--
Maxim Kuvyrkov
www.linaro.org
0001-Improve-autoprefetcher-heuristic-partly-fix-regressi.patch
Description: Binary data
U_8 *ptr);
#define __kernel_cmpxchg64 (*(__kernel_cmpxchg64_t *) 0x0f60)
/* Kernel helper for memory barrier. */
typedef void (__kernel_dmb_t) (void);
#define __kernel_dmb (*(__kernel_dmb_t *) 0x0fa0)
/* Kernel helper page version number. */
#define __kernel_helper_version (*(unsigned int *)0x0ffc)
===
--
Maxim Kuvyrkov
https://www.linaro.org
0.C -std=gnu++2a note (test for warnings,
> line 38)
> FAIL: g++.dg/warn/Warray-bounds-20.C -std=gnu++2a note (test for warnings,
> line 55)
> FAIL: g++.dg/warn/Warray-bounds-20.C -std=gnu++98 note (test for warnings,
> line 38)
> FAIL: g++.dg/warn/Warray-bounds
Hi Matthew,
Hi Sebastian,
This patch removes compareSumTests3, which appears to be broken. It tries to
call compareSumFiles(), which is
nowhere to be found and was never present in the GCC repo.
OK to remove?
Regards,
--
Maxim Kuvyrkov
https://www.linaro.org
0001-contrib-Remove-broken
> On Jul 2, 2021, at 5:44 PM, Christophe Lyon
> wrote:
>
>
>
> On Fri, Jul 2, 2021 at 4:29 PM Jakub Jelinek via Gcc-patches
> wrote:
> On Fri, Jul 02, 2021 at 05:20:33PM +0300, Maxim Kuvyrkov wrote:
> > Hi Jakub,
> >
> > Thanks for helping m
Hi Jakub,
Thanks for helping me on IRC with debugging testsuite problems. Does this
write up look good?
Regards,
--
Maxim Kuvyrkov
https://www.linaro.org
0001-Add-description-of-how-testsuite-parallelization-wor.patch
Description: Binary data
> On 16 Jun 2021, at 20:14, Andrew MacLeod wrote:
>
> On 6/16/21 5:41 AM, Maxim Kuvyrkov wrote:
>>
>>> + m_new_value_p = state;
>>> + return ret;
>>> }
>>>// Dump the caches for basic block BB to file F.
>> Thanks,
>>
>
;
> -}
> -
> -// Disable new value querying.
> -
> -void
> -ranger_cache::disable_new_values ()
> +bool
> +ranger_cache::enable_new_values (bool state)
> {
> - m_new_value_p = false;
> + bool ret = m_new_value_p;
I think changing this to
bool ret = (bool) m_new
movsi,
at config/arm/arm.md:6291
00:01:29 make[2]: *** [sound/drivers/serial-u16550.o] Error 1
Would you please investigate? Let me know if you need any help reproducing the
problem.
Kernel’s build line is (assuming cross-compilation):
make CC=/path/to/arm-linux-gnueabihf-gcc ARCH=arm
> On Feb 18, 2020, at 6:30 PM, Vladimir Makarov wrote:
>
> On 2/17/20 10:08 AM, Maxim Kuvyrkov wrote:
>> Hi Vladimir,
>>
>> This patch increases code size at -Os on arm-linux-gnueabihf by 1% (with no
>> code-size reductions) on several SPEC CPU2006
,99183,99863
Could you look into whether these regressions can be avoided?
Thanks,
--
Maxim Kuvyrkov
https://www.linaro.org
> On Feb 2, 2020, at 7:46 PM, Vladimir Makarov wrote:
>
> The previous patch for
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91333
>
> resulted
these can be avoided? [Let me know if you need
help reproducing this problem.]
Thank you,
--
Maxim Kuvyrkov
https://www.linaro.org
> On Jan 27, 2020, at 7:41 PM, Richard Sandiford
> wrote:
>
> In the gcc.target/aarch64/lsl_asr_sbfiz.c part of this PR, we have:
>
&g
> On Jan 10, 2020, at 6:15 PM, Joseph Myers wrote:
>
> On Fri, 10 Jan 2020, Maxim Kuvyrkov wrote:
>
>> To me this looks like cherry-picks of r182541 and r182547 from
>> redhat/gcc-4_7-branch into redhat/gcc-4_8-branch.
>
> r182541 is the first commit on /branch
> On Jan 10, 2020, at 10:33 AM, Maxim Kuvyrkov
> wrote:
>
>> On Jan 9, 2020, at 5:38 AM, Segher Boessenkool
>> wrote:
>>
>> On Wed, Jan 08, 2020 at 11:34:32PM +, Joseph Myers wrote:
>>> As noted on overseers, once Saturday's DATESTAMP updat
ay.
Unfortunately, the comparison is complicated by the fact that you uploaded only
"b" version of gcc-reposurgeon-8 repository, which uses modified branch layout
(or confirm that there are no substantial differences between "7" and "8"
reposurgeon conversions).
--
Maxim Kuvyrkov
https://www.linaro.org
> On Dec 30, 2019, at 7:08 PM, Richard Earnshaw (lists)
> wrote:
>
> On 30/12/2019 15:49, Maxim Kuvyrkov wrote:
>>> On Dec 30, 2019, at 6:31 PM, Richard Earnshaw (lists)
>>> wrote:
>>>
>>> On 30/12/2019 13:00, Maxim Kuvyrkov wrote:
>>&g
> On Dec 30, 2019, at 6:31 PM, Richard Earnshaw (lists)
> wrote:
>
> On 30/12/2019 13:00, Maxim Kuvyrkov wrote:
>>> On Dec 30, 2019, at 1:24 AM, Richard Earnshaw (lists)
>>> wrote:
>>>
>>> On 29/12/2019 18:30, Maxim Kuvyrkov wrote:
>>>
> On Dec 30, 2019, at 1:24 AM, Richard Earnshaw (lists)
> wrote:
>
> On 29/12/2019 18:30, Maxim Kuvyrkov wrote:
>> Below are several more issues I found in reposurgeon-6a conversion comparing
>> it against gcc-reparent conversion.
>>
>> I am sure, these an
to be split to represent it in git (there are about 1500
> such SVN commits, most of them automatic datestamp updates in the CVS era
> that cvs2svn turned into mixed-branch commits).
Thanks for catching this. This is fallout from incremental rebuilds (rather
than fresh builds) of gcc-reparent repository. Incremental builds take about
1h and full rebuilds take about 30h. I'll switch to doing full rebuilds.
--
Maxim Kuvyrkov
https://www.linaro.org
c.gnu.org" emails for many commits
where svn-git conversion manages to extract valid email from commit data. This
happens for hundreds of author entries.
Regards,
--
Maxim Kuvyrkov
https://www.linaro.org
> On Dec 26, 2019, at 7:11 PM, Maxim Kuvyrkov wrote:
>
>
>> On Dec
087.
So, while we are evaluating the conversion candidates, it is best to disable
conversion features that cause hard-to-workaround differences.
>
> I'll do another GCC conversion run to pick up all the accumulated fixes
> and improvements (including many more PR whitelist entries / fixes in
> Richard's script), once another ChangeLog-related fix is in.
--
Maxim Kuvyrkov
https://www.linaro.org
.in: Likewise.
* Makefile.in: Likewise.
* src/Makefile.in: Likewise.
* libsup++/Makefile.in: Likewise.
* po/Makefile.in: Likewise.
* doc/Makefile.in: Likewise.
Legacy-ID: 138087
--
Maxim Kuvyrkov
https://www.linaro.org
Is it possible to integrate Richard E.'s script to rewrite commit log
messages?
A5: Yes, absolutely. The scripts have a pass to rewrite commit
author/committer entries, and log rewrite easily fits in there. It would be
very helpful to have a version of Richard's script that runs on per-commit
basis, suitable for "git filter-branch" consumption.
Regards,
--
Maxim Kuvyrkov
https://www.linaro.org
all we care about is history of trunk and recent release branches
2. current gcc-mirror is really all we need
3. having vendor branches and author info would be nice, but not so nice as to
delay the switch any longer
Granted, the above is not the /official/ consensus of GCC community, and I
don't
1 - 100 of 520 matches
Mail list logo
