Re: [RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)

On 12/23/20 9:01 AM, abebeos wrote: > > > On Sun, 13 Dec 2020 at 20:14, abebeos +abeb...@gmail.com > > wrote: > > > > On Fri, 11 Dec 2020 at 20:32, Jeff Law > wrote: > > > > On 12/9/20 6:12 AM, abebeos via

Re: [committed] doc: Remove HSAIL from Language Standards

On Tue, 29 Dec 2020, Martin Jambor wrote: >> commit 7e999bd84f47205dc44b0f2dc90b53b3c888ca48 >> Author: Gerald Pfeifer >> Date: Mon Dec 28 21:41:55 2020 +0100 >> >> doc: Remove HSAIL from Language Standards >> >> Support for HSAIL has been deprecated with GCC 10 and their web

Re: [committed] doc: Remove HSAIL from Language Standards

Hi Gerald, On Mon, Dec 28 2020, Gerald Pfeifer wrote: > Pushed. > > There's quite a number of further references in gcc/doc; is anyone > planning on continuing the deprecation and removing the actual bits? > > Gerald > > > commit 7e999bd84f47205dc44b0f2dc90b53b3c888ca48 > Author: Gerald Pfeifer

Re: disable some aapcs/vfp*.c test if not arm_fp16_alternative_ok

On Dec 22, 2020, at 1:47 PM, Alexandre Oliva wrote: > > The tests use -mfp16-format=alternative, and so should not be run > if that option isn't supported. > > Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2. > Ok to install? Ok.

Re: fix testsuite/g++.dg/init/new26.C for C++-14 and later

On Dec 22, 2020, at 1:40 PM, Alexandre Oliva wrote: > > This test fails during the execution on VxWorks 7 when using > C++-14 and C++-17. > > Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2. > Ok to install? Ok.

Re: g++.dg/tls/pr79288.C: Skip on vxworks_kernel (TLS model not supported)

On Dec 22, 2020, at 1:57 PM, Alexandre Oliva wrote: > > The only TLS model supported in VxWorks kernel mode is local-exec. > > Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2. > Ok to install? Ok.

Re: compile gcc.target/arm/{pr78255-2.c, memset-inline-2.c} with -mno-long-calls

On Dec 22, 2020, at 1:56 PM, Alexandre Oliva wrote: > > This change adds -mno-long-calls to the list of compiler options > to make sure we generate short call code, allowing the assembly > matching to pass. > > This is added unconditionally to the dg-options (as opposed to using >

Re: Fix testsuite/g++.old-deja/g++.mike/p658.C build failure on VxWorks RTP

On Dec 22, 2020, at 1:45 PM, Alexandre Oliva wrote: > > The conflicting definition of OK is present in VxWorks RTP headers too. > > Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2. > Ok to install? Ok. Ok to stylize all the #undef in the same way. This is one happens

Re: Fix testsuite/g++.dg/opt/20050511-1.C compilation error on VxWorks 7

On Dec 22, 2020, at 1:44 PM, Alexandre Oliva wrote: > > In VxWorks 7, UINT32 is defined in both modes, kernel and rtp. Adjust > the work around accordingly. > > Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2. > Ok to install? Ok.

Re: Fix testsuite/g++.dg/cpp1y/constexpr-66093.C execution failure...

On Dec 22, 2020, at 1:44 PM, Alexandre Oliva wrote: > > The constexpr iteration dereferenced an array element past the end of > the array. > > Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2. > Ok to install? How about: a[i-1] = i; instead? This I think better

Re: Skip testsuite/g++.old-deja/g++.pt/const2.C on vxworks_kernel

On Dec 22, 2020, at 1:43 PM, Alexandre Oliva wrote: > > Linking in vxworks kernel-mode is partial linking, so missing symbols > are not detected. > > Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2. > Ok to install? Ok. Generally nicer to bunch all like ones ("partial

Re: Remove VxWorks-specific test directives in g++.dg/warn/miss-format-1.C

On Dec 22, 2020, at 1:42 PM, Alexandre Oliva wrote: > > These are no longer applicable. > > Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2. > Ok to install? Ok.

Re: Undefine ERROR in g++.dg/tree-ssa/copyprop.C

On Dec 22, 2020, at 1:41 PM, Alexandre Oliva wrote: > > VxWorks headers define ERROR as a macro, which conflicts with the use > in the test. > > Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2. > Ok to install? Ok.

Re: skip testsuite/g++.dg/other/anon5.C on vxworks_kernel targets

On Dec 22, 2020, at 1:40 PM, Alexandre Oliva wrote: > > The vxworks kernel-mode linking is partial linking, so it cannot > detect missing symbols. > > Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2. > Ok to install? Ok.

Re: Add conditions on VxWorks versions for gcc.dg/vxworks/initpri?.c

On Dec 22, 2020, at 1:37 PM, Alexandre Oliva wrote: > > Adjust vxworks initpri expectations, given that vxworks7 has switched > to .init_array. > > Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2. > Ok to install? Ok. I suppose I should say that if the port maintainers

Re: gcc.dg/intmax_t-1.c compiles without error on VxWorks 7 SR06x0

On Dec 22, 2020, at 1:36 PM, Alexandre Oliva wrote: > > This test currently fails on VxWorks 7 SR06x0 targets when in kernel > mode, because it expects a discrepancy between built-in and system > intmax_t for all VxWorks targets when in kernel mode. Fortunately, > this has now been fixed when

Re: Fix VxWorks xfail filters on pthread-init-?.c

On Dec 22, 2020, at 1:34 PM, Alexandre Oliva wrote: > Match xfail on kernel instead of rtp mode. > > Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2. > Ok to install? Ok. Longer term, would be nice to fix includes the relevant file to have the relevant definition.

Re: Add conditional include of vxWorks.h for kernel mode

On Dec 22, 2020, at 1:14 PM, Alexandre Oliva wrote: > > In kernel mode, an application must include vxWorks.h before any other > system header, this patch adds exactly that to the test that were > failing due to a missing declaration that was found in vxWorks.h. I'm inclined to rather have a

Re: [Patch, fortran] PR97612 [F08] Structure constructor of type with nested allocatable array components fails to compile

Hi Thomas, Thanks - applied to master in r11-6365-geeb145317b42d5203056851435457d9189a7303d . I wonder if this one deserves backporting? Cheers Paul On Tue, 29 Dec 2020 at 09:06, Thomas Koenig wrote: > > Hi Paul, > > > Regtests on FC33/x86_64 - OK for master? > > OK. Thanks for the

Re: [Patch, fortran] PR93833 - [8/9/10 Regression] ICE in trans_array_constructor, at fortran/trans-array.c:2566

Hi Thomas, Thanks for taking a look at the patch. Applied to master as r11-6364-gfeae0af82753e06fbff6103da5fbb3b28e1ddbd7 . The branches will follow in a week or so. Regards Paul On Mon, 28 Dec 2020 at 17:10, Thomas Koenig wrote: > Hi Paul, > > >> > > Retested on FC33/x86_64 - OK for

[committed 6/6] arc: generate mac(u) insn instead of macd(u) when destination is accl

Generate MAC(U) instruction instead of MACD(U) when the destination register is already choosen as ACCL register. gcc/ 2020-12-29 Claudiu Zissulescu * config/arc/arc.md (maddsidi4_split): Skip macd gen, use mac insn instead. (macd): Update register letters.

[committed 5/6] arc: flip if-condition predicates in secondary reload hook

The ARC code contains code which should only work with the old reload pass. Such code is found in arc_secondary_reload hook, however it was not properly quarded. Reverse the if-condition predicate such that req_equiv_mem is called when lra is not in progress. gcc/ 2020-12-29 Claudiu Zissulescu

[committed 4/6] arc: Make use reg_renumber safe.

The REGNO_OK_FOR_BASE_P is using reg_renumber array. However, it is not always defined. Use it only when it is defined. gcc/ 2020-12-29 Claudiu Zissulescu * config/arc/arc.h (REGNO_OK_FOR_BASE_P): Check if defined reg_renumber. Signed-off-by: Claudiu Zissulescu ---

[committed 3/6] arc: Update test pattern.

gcc/testsuite 2020-12-29 Claudiu Zissulescu * gcc.target/arc/loop-3.c: Update test pattern. Signed-off-by: Claudiu Zissulescu --- gcc/testsuite/gcc.target/arc/loop-3.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/testsuite/gcc.target/arc/loop-3.c

[committed 2/6] arc: Fix cached to uncached moves.

We need an temporary register when moving data from a cached memory to an uncached memory. Fix this issue and add a test for it. gcc/ 2020-12-29 Claudiu Zissulescu * config/arc/arc.c (prepare_move_operands): Use a temporary registers when we have cached mem-to-uncached mem

[committed 1/6] arc: Don't use predicated vadd2 instructions in mov patterns.

Update movdi, movdf and mov vectors not to use predicated vadd2 instructions. vadd2 is used as a "fast" move in these patterns. This fixes a number of failures in dejagnu. gcc/ 2020-12-29 Claudiu Zissulescu * config/arc/arc.md (movdi_insn): Update pattern, no predicated vadd2

Re: Add missing vxworks filters to lib/target-supports.exp functions

Alexandre Oliva writes: > Explicitly disable some vxworks-missing features in the testsuite, that > the current feature tests detect as present. > > Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2. > Ok to install? > > > from Olivier Hainque > for gcc/testsuite/ChangeLog

Re: -mno-long-calls for mve_libcall tests

Alexandre Oliva writes: > The implicit -mlong-calls used in our vxworks configurations changes > the call sequences from those expected in the mve_libcall testcases. > > This patch brings the test output in line with the expectations, with > an explicit -mno-long-calls. > > Regstrapped on

Re: -mno-long-calls for arm/no_unique_address tests

Alexandre Oliva writes: > The implicit -mlong-calls from our vxworks configurations makes the > tail-call instructions differ from those expected by the > no_unique_address tests in gcc.target/arm. > > This patch adds -mno-long-calls to the compilation commands, so that > we generate the expected

Re: -mno-long-calls for arm/headmerge tests

Alexandre Oliva writes: > The headmerge tests pass a constant to conditional calls, so that the > same constant is always passed to a function, though it's a different > function depending on which path is taken. > > The test checks that the constant appears only once in the assembly > output, as

Re: -mno-long-calls for expected regalloc in arm/fp16-aapcs-2.c test

Alexandre Oliva writes: > The implicit -mlong-calls used in our arm-vxworks configurations > changes the register allocation patterns in the arm/fp16-aapcs-2.c > test: r3 ends up used in the long-call sequence, and we end up using > ip as a temporary, which doesn't match the expected mov

Re: [Patch, fortran] PR97612 [F08] Structure constructor of type with nested allocatable array components fails to compile

Hi Paul, Regtests on FC33/x86_64 - OK for master? OK. Thanks for the patch! Best regards Thomas