Hi Kwok!
On 2020-07-22T16:08:20+0100, Kwok Cheung Yeung wrote:
> This test fails because the "'seq' overrides other OpenACC loop specifiers"
> error is not appearing in the compiler output. The C-equivalent version of the
> test (c-c++-common/goacc/loop-2-kernels.c) has these tests XFAILed in
On Sat, Jul 18, 2020 at 8:55 AM H.J. Lu wrote:
>
> On Sat, Jul 18, 2020 at 8:15 AM Jan Hubicka wrote:
> >
> > > On Sun, Jul 12, 2020 at 5:05 AM H.J. Lu wrote:
> > > >
> > > > On Fri, Jun 26, 2020 at 2:02 PM H.J. Lu wrote:
> > > > >
> > > > > Define ASM_OUTPUT_ALIGNED_DECL_LOCAL for large local
Hi!
On 2020-06-30T18:35:36+0200, I wrote:
> On 2020-06-22T11:32:46-0300, Alexandre Oliva wrote:
>> --- /dev/null
>> +++ b/gcc/testsuite/lib/scanoffload.exp
>
>> +# Utility for scanning offloading dump output, used by libgomp.exp.
>
> ;-) Yeah, I was about to say that having this file in
>
Hi!
Just some random comments...
On Thu, Jul 23, 2020 at 04:44:21PM +0800, Hu Jiangping wrote:
> + // fix PR96247
/* See PR96247. */
> + if (0 == atoi(arg)) {
Either
if (atoi (arg) == 0)
{
blalalala
or
if (!atoi (arg))
{
Hi Julian!
On 2020-06-22T05:14:44-0700, Julian Brown wrote:
> As mentioned in the parent email, this is a fix for PR95590 that detects
> updates of attached pointers in blocks, and rewrites the attached pointer
> and resets its attachment counter appropriately. I am however not entirely
> sure
On Fri, Jul 24, 2020 at 10:13 AM Rainer Orth
wrote:
>
> Jojo R writes:
>
> > gcc/ChangeLog:
> >
> > * genemit.c (main): Print 'split line'.
> > * Makefile.in (insn-emit.c): Define split count and file
> [...]
> > diff --git a/gcc/Makefile.in b/gcc/Makefile.in
> > index
Hi Matthew,
> -Original Message-
> From: Matthew Malcomson
> Sent: 21 July 2020 16:16
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Earnshaw ; Kyrylo Tkachov
> ; Ross Burton
> Subject: SLS Mitigation patches backported for GCC9
>
> Hello,
>
> Eventually we will want to backport the SLS
Hi!
On Fri, Jul 24, 2020 at 09:01:33AM +0200, Andrea Corallo wrote:
> Segher Boessenkool writes:
> >> Correct, it's a sliding window only because the real load address is not
> >> known to the compiler and the algorithm is conservative. I believe we
> >> could use ASM_OUTPUT_ALIGN_WITH_NOP if
Lewis Hyatt via Gcc-patches writes:
> On Thu, Jul 23, 2020 at 05:47:28PM -0400, David Malcolm wrote:
>> On Thu, 2020-07-23 at 12:28 -0400, Lewis Hyatt via Gcc-patches wrote:
>> > Hello-
>> >
>> > The attached patch is complete including docs, but I tagged as RFC
>> > because I am not sure if
Hi Julian!
Quoting your parent email:
On 2020-06-22T05:14:42-0700, Julian Brown wrote:
> Investigating PR95590, I realised that we can do better at diagnosing
> some potentially troublesome usage of OpenACC "attach" behaviour, namely
> updating blocks with attached pointers. Updating either the
On Fri, 24 Jul 2020, Jojo R wrote:
> + -csplit insn-$*.c /parallel\ compilation/ -k -s
> {$(insn-generated-split-num)} -f insn-$* -b "%d.c"
> + -( [ ! -s insn-$*0.c ] && for i in {1..$(insn-generated-split-num)}; do
> touch insn-$*$$i.c; done && echo "" > insn-$*.c)
Ignoring errors
Jozef Lawrynowicz writes:
> On Wed, Jul 22, 2020 at 09:33:47AM +0100, Richard Sandiford wrote:
>> Jozef Lawrynowicz writes:
>> > is_int_mode does not allow MODE_PARTIAL_INT modes, so convert_modes was
>> > not allowing a constant value to be converted to a MODE_PARTIAL_INT for
>> > use as
Hi Segher,
Thanks for having a look at the patch.
On Thu, Jul 23, 2020 at 01:34:22PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Jul 23, 2020 at 04:56:14PM +0100, Jozef Lawrynowicz wrote:
> > +static int
> > +msp430_insn_cost (rtx_insn *insn, bool speed ATTRIBUTE_UNUSED)
> > +{
> > +
Hi Szabolcs,
> -Original Message-
> From: Szabolcs Nagy
> Sent: 23 July 2020 17:24
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH 2/2] aarch64: add PAC-RET protection to libitm sjlj.S
>
> _ITM_beginTransaction is a 'returns_twice' function that saves x30
> on the
On Fri, Jul 24, 2020 at 12:03:16PM +0200, Richard Biener via Gcc-patches wrote:
> On Fri, Jul 24, 2020 at 10:13 AM Rainer Orth
> wrote:
> > Jojo R writes:
> > > +insn-generated-split-num = $(shell grep -c ^processor /proc/cpuinfo)
> >
> > This is highly unportable, probably Linux-only. It
Matthias Klose writes:
> Trying to build a nvptx offload compiler on aarch64-linux-gnu, the libgomp
> tests
> error out with
>
> unrecognizable argument of option -foffload-abi
>
> Passing that option goes a step further, hitting PR target/96265. Define that
> hook, as it was done for rs6000 in
Hi Kwok!
On 2020-07-22T16:27:10+0100, Kwok Cheung Yeung wrote:
> The testcase gfortran.dg/goacc/routine-module-mod-1.f90 fails due to an extra
> 'warning: region is worker partitioned but does not contain worker partitioned
> code' message in subroutine g_1. subroutine g_1 is marked with '!$acc
Thanks Martin.
> -Original Message-
> From: Martin Liška [mailto:mli...@suse.cz]
> Sent: Thursday, July 23, 2020 9:03 PM
> To: gcc-patches@gcc.gnu.org
> Cc: dongjianqiang (A)
> Subject: [PATCH] gcov-tool: Fix merging of different endian coverage data
> [PR96267]
>
> Hi.
>
> There's one
Hi Szabolcs,
> -Original Message-
> From: Szabolcs Nagy
> Sent: 23 July 2020 17:24
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH 1/2] aarch64: add PAC GNU property note to libgcc lse.S
>
> This note is not used anywhere currently but it is supposed to mark
>
Hi Richard,
This is the updated version that could pass all regression test on
Power9-LE.
Just need another "maybe_lt (GET_MODE_SIZE (new_mode), access_size)"
before generating shift for store_info->const_rhs to ensure correct
constant is generated, take testsuite/gfortran1/equiv_2.x for
On 7/23/20 5:01 PM, Qing Zhao wrote:
Hi,
Thanks a lot for the info.
On Jul 23, 2020, at 5:07 AM, Martin Liška wrote:
On 7/21/20 6:24 PM, Qing Zhao wrote:
4.
Our company is waiting for this patch to be committed to upstream.
Hello.
Please note that patch review can sometimes take some
V1 of this series can be found here:
https://sourceware.org/pipermail/gdb-patches/2020-July/170649.html
v2 addresses all comments from Kevin Buettner and Luis Machado in Patch2.
This is sent to the gcc-patches mailing list to review the changes
in include/ and libiberty/.
Regards,
Felix
Felix
This adds support for the bfloat16 datatype, which can be seen as a short
version of FP32, skipping the least significant 16 bits of the mantissa.
Since the datatype is currently only supported by the AVX512 registers,
the printing of bfloat16 values is only supported for xmm, ymm and zmm
As with C/C++, the offloading requires are not implemented
an rejected early with a 'sorry'.
The mem-setting default for atomic is handled, but only 'seq_cst'
as currently gfortran's only supports this one. (C/C++ support more.)
In C/C++, the 'requires' has to be at file scope. For Fortran,
gdb/Changelog:
2020-07-02 Felix Willgerodt
* i386-tdep.c (i386_zmm_type): Fix field names.
(i386_ymm_type): Fix field names.
---
gdb/i386-tdep.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/gdb/i386-tdep.c b/gdb/i386-tdep.c
Description:
This patch adds the support to build 64bit GCC applications on AIX 7.1
Changelog:
2020-07-24 Clement Chigot
* config.gcc: Use t-aix64, biarch64 and default64 for cpu_is_64bit.
* config/rs6000/aix71.h (ASM_SPEC): Remove aix64 option.
(ASM_SPEC32): New.
The wording of the description of -fprofile-exclude-files is easy to
misunderstand. One can be led to believe a file is excluded only if
it matches all of the patterns, not just one. This patch tries to
clarify the function. It also adjusts the wording of
-fprofile-filter-files accordingly.
On Thu, Jul 23, 2020 at 08:15:42PM -0500, Peter Bergner wrote:
> We get an ICE when using -mpower10 and a -mcpu= value that is older
> than power10. The -mpower10 option requires -mcpu=power10 or later.
> The following patch enforces that.
Hi!
> + /* If the user explicitly uses -mpower10,
Hi Jozef,
On Fri, Jul 24, 2020 at 12:50:48PM +0100, Jozef Lawrynowicz wrote:
> On Thu, Jul 23, 2020 at 01:34:22PM -0500, Segher Boessenkool wrote:
> > On Thu, Jul 23, 2020 at 04:56:14PM +0100, Jozef Lawrynowicz wrote:
> > > + /* The returned cost must be relative to COSTS_N_INSNS (1). An insn
>
On 7/24/20 1:02 PM, Göran Uddeborg wrote:
The wording of the description of -fprofile-exclude-files is easy to
misunderstand. One can be led to believe a file is excluded only if
it matches all of the patterns, not just one. This patch tries to
clarify the function. It also adjusts the
2020-07-24 Uroš Bizjak
gcc/ChangeLog:
PR target/95750
* config/i386/sync.md (mmem_thread_fence): Emit mfence_sse2 for -Os.
Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
Uros.
diff --git a/gcc/config/i386/sync.md b/gcc/config/i386/sync.md
index
Hi!
It's been a while... ;-)
On 2012-06-26T11:29:44-0700, Janis Johnson wrote:
> Procedure scan-dump-times in scandump.exp uses a printable version of
> the scanned pattern in the line reported to the test summary but others
> in that file don't. This patch fixes that in the remaining
Segher Boessenkool writes:
> Hi!
>
> On Fri, Jul 24, 2020 at 09:01:33AM +0200, Andrea Corallo wrote:
>> Segher Boessenkool writes:
>> >> Correct, it's a sliding window only because the real load address is not
>> >> known to the compiler and the algorithm is conservative. I believe we
>> >>
In the below testcase, we're ICEing from alias_ctad_tweaks ultimately
because the implied deduction guide for X's user-defined constructor
already has constraints associated with it. We then carry over these
constraints to 'fprime', the overlying deduction guide for the alias
template Y, via
Hello!
I just got a notification that the Bountysource campaign I created to modernize
the
AVR backend - primarily converting it to MODE_CC - has been bumped to $7,150
by Microchip [1].
I hope this will finally convince someone to complete the task :-).
Adrian
> [1]
>
On Jul 24, 2020, Thomas Schwinge wrote:
> we also need to move the '-dump*' arguments later in one place, so that
> they'll override those that appear via the loop over 'argv', which also
> contains '-dump*' arguments. With that changed, it appears to work fine.
Aah, thanks. Here's the
We correctly reject this testcase since r11-434, i.e. since the fix for
PR c++/57943.
gcc/testsuite/ChangeLog:
PR c++/81339
* g++.dg/cpp0x/decltype78.C: New test.
---
gcc/testsuite/g++.dg/cpp0x/decltype78.C | 24
1 file changed, 24 insertions(+)
create
On Fri, Jul 24, 2020 at 11:10:29AM -0500, Peter Bergner wrote:
> On 7/24/20 6:32 AM, Segher Boessenkool wrote:
> > On Thu, Jul 23, 2020 at 08:15:42PM -0500, Peter Bergner wrote:
> >> + /* If the user explicitly uses -mpower10, ensure our ISA flags are
> >> + compatible with it. */
> >> + if
Hi Julian!
On 2020-06-16T15:39:45-0700, Julian Brown wrote:
> This patch fixes a set of XFAILs
The overall goal of couse is not to resolve XFAILs, but to implement the
expected behavior. :-)
> in some recently-added patches by
> skipping a detach operation on "no-op" exit data operations for
On 7/24/20 6:32 AM, Segher Boessenkool wrote:
> On Thu, Jul 23, 2020 at 08:15:42PM -0500, Peter Bergner wrote:
>> + /* If the user explicitly uses -mpower10, ensure our ISA flags are
>> + compatible with it. */
>> + if (TARGET_POWER10
>> + && (rs6000_isa_flags_explicit &
On Fri, 24 Jul 2020 10:59:35 +0200
Felix Willgerodt via Gdb-patches wrote:
> * features/i386/64bit-avx512.c
> (create_feature_i386_64bit_avx512): Add vector v8bf.
> (create_feature_i386_64bit_avx512): Add field v8_bfloat16.
> * features/i386/64bit-avx512.xml: Likewise.
>
Hu Jiangping writes:
> Thanks, Richard!
>
> I think your suggestion is very good, so I made a new patch.
>
> v2: at a high level handles -falign-foo=0 like -falign-foo
> v1: at the target level overides the -falign-foo=0 option values
>
> Obviously, v2 is better than v1. In addition, anthor
On 24/07/2020 12:01, Kyrylo Tkachov wrote:
Hi Matthew,
-Original Message-
From: Matthew Malcomson
Sent: 21 July 2020 16:16
To: gcc-patches@gcc.gnu.org
Cc: Richard Earnshaw ; Kyrylo Tkachov
; Ross Burton
Subject: SLS Mitigation patches backported for GCC9
Hello,
Eventually we will
Stefan Schulze Frielinghaus via Gcc-patches writes:
> This is a follow up to commit 5c9669a0e6c respectively discussion
> https://gcc.gnu.org/pipermail/gcc-patches/2020-June/549132.html
>
> In case that an alignment constraint is less than the size of a
> corresponding scalar type, ensure that we
Committed.
No dots in labels for MMIX: internal labels instead contain ":".
gcc/testsuite:
* c-c++-common/pr56493.c: Allow ":" in label, for mmix.
--- gcc/gcc/testsuite/c-c++-common/pr56493.c.orig Mon Jan 13 22:30:46 2020
+++ gcc/gcc/testsuite/c-c++-common/pr56493.cSat Jul 25
On Fri, 2020-07-24 at 18:05 -0400, David Malcolm via Gcc-patches wrote:
[...]
> I haven't thought this through in detail, and I'm not sure exactly
> how
> it would work for arbitrary types, but I thought it worth sharing.
> (For example I can think of nasty issues if we ever want to support
>
This test case, extracted from PR 95645, was failing because alignment
of local long long variable got lowered from 8 bytes to 4 bytes in
adjust alignment pass, which triggered assert failure.
This test case passes now because PR 95237 fix only allows lowering of
alignment of local variables in
Hi!
[ Btw, the mailing list archive will not show your attachments (just lets
me download them); naming the files *.txt probably works, but you can
also use a sane mime type (like, text/plain) ].
On Wed, Jul 22, 2020 at 12:09:08PM +0200, Andrea Corallo wrote:
> this second patch implements the
On Fri, 24 Jul 2020 16:18:34 +0200
Thomas Schwinge wrote:
> Hi Julian!
>
> On 2020-06-16T15:39:45-0700, Julian Brown
> wrote:
> > This patch fixes a set of XFAILs
>
> The overall goal of couse is not to resolve XFAILs, but to implement
> the expected behavior. :-)
Eh, details :-).
> > in
Mixing -fcf-protection and -fcf-protection=none objects are allowed.
Linker just merges -fcf-protection values from all input objects.
Add -fcf-protection=check for the final link with LTO. An error is
issued if LTO object files are compiled with different -fcf-protection
values. Otherwise,
On Wed, 2020-07-01 at 18:14 +0200, Andrea Corallo wrote:
> Andrea Corallo writes:
>
> > > It occurred to me that the entrypoint is combining two things:
> > > - creating a global char[]
> > > - creating an initializer for that global
> > >
> > > which got me wondering if we should instead have
From: Aaron Sawdey
This option is mostly being added to provide -mno-block-ops-unaligned-vsx.
The default is set the same as -mefficient-unaligned-vsx. This option will
control the use of unaligned VSX loads/stores in the inline expansion
of memcpy() and memmove(). The use case for this would be
The only way to enable or disable Power10 insns (ISA 3.1 insns) should
be via the -mcpu= switch. This patch disables the -mpower10 options the
same way the -mdirect-move switch is neutered already. That is not an
ideal way, but it works, it is not the first, and doing it properly is
more work,
Hi Dominique,
I have committed the patch after regression-testing.
Dou you want to backport this, as well?
(And if one of my e-mails bounced, you can try the other one.
Originally, I wanted to switch completely, but the bouncing
problem made that impossible...)
Best regards
Thomas
Hi Andrea,
On Wed, Jul 22, 2020 at 12:02:33PM +0200, Andrea Corallo wrote:
> This first patch implements the addition of a new RTX instruction class
> FILLER_INSN, which has been white listed to allow placement of NOPs
> outside of a basic block. This is to allow padding after unconditional
>
Le 2020-07-24 20:50, Thomas Koenig a écrit :
Hi Dominique,
I have committed the patch after regression-testing.
Thanks.
Dou you want to backport this, as well?
IMO it is worth the work.
(And if one of my e-mails bounced, you can try the other one.
What is the other one?
Dominique
Hi Aaron,
On Fri, Jul 24, 2020 at 05:05:25PM -0500, acsaw...@linux.ibm.com wrote:
> This option is mostly being added to provide -mno-block-ops-unaligned-vsx.
> The default is set the same as -mefficient-unaligned-vsx. This option will
> control the use of unaligned VSX loads/stores in the inline
On Fri, 24 Jul 2020 16:04:02 +0200
Thomas Schwinge wrote:
> Hi Julian!
>
> On 2020-06-22T05:14:44-0700, Julian Brown
> wrote:
> > As mentioned in the parent email, this is a fix for PR95590 that
> > detects updates of attached pointers in blocks, and rewrites the
> > attached pointer and
Hi Dominique,
also committed.
Regards
Thomas
On Tue, Jul 21, 2020 at 2:11 PM Aaron Merey wrote:
>
> On Tue, Jul 21, 2020 at 11:20 AM Tom Tromey wrote:
> >
> > Simon> Since it's debuginfo.m4 that is using PKG_CHECK_MODULES, can you put
> > the include
> > Simon> of pkg.m4 in debuginfo.m4, instead of in {binutils,gdb}/configure.ac?
> >
> >
On Fri, Jul 24, 2020 at 2:08 PM Sunil K Pandey wrote:
>
> This test case, extracted from PR 95645, was failing because alignment
> of local long long variable got lowered from 8 bytes to 4 bytes in
> adjust alignment pass, which triggered assert failure.
>
> This test case passes now because PR
Committed.
There's no reason anyone would want to use the "patchable function"
feature for MMIX and also no reason to exclude those tests. For MMIX,
the NOP equivalent is SWYM ("swymming" is a healthy exercise).
Text-wise, making the tests pass by adjusting the regexp, is shorter,
and it seems
On Fri, Jul 24, 2020 at 5:01 AM CHIGOT, CLEMENT wrote:
>
> Description:
> This patch adds the support to build 64bit GCC applications on AIX 7.1
The patch was not correct because defaultaix64.h substitutes POWER7
target default in 64 bit mode, which AIX 7.1 defaults to POWER4.
PPC64 Linux
> -Original Message-
> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> Sent: Tuesday, July 21, 2020 2:49 AM
> To: yangyang (ET)
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH PR96195] aarch64: ICE during GIMPLE pass:vect
>
> Sorry for the slow reply.
>
> "yangyang
I didn't find anything using EDGE_DFS_BACK in RTL infrastructure
used by var-tracking or var-tracking itself, the following removes
this computation.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
I'll push this on Monday unless somebody points out my obvious mistake.
Richard.
2020-07-24
"Kewen.Lin" writes:
> Hi,
>
> Sorry, please ignore the previously attached file, which isn't the latest one
> although almost are the same. The latest tested is attached here.
>
> Sorry for the inconvenience.
>
> BR,
> Kewen
>
> on 2020/7/22 下午11:48, Kewen.Lin via Gcc-patches wrote:
>>
>>
On Jul 24, 2020, Thomas Schwinge wrote:
> Please merge in the attached incremental patch to resolve syntax errors.
Thanks, sorry about those. I found out about lset after I posted the
proposed patch, and I switched to it over set from [lreplace] to avoid
further embarrassing myself ;-) That
Jojo R writes:
> gcc/ChangeLog:
>
> * genemit.c (main): Print 'split line'.
> * Makefile.in (insn-emit.c): Define split count and file
[...]
> diff --git a/gcc/Makefile.in b/gcc/Makefile.in
> index 2ba76656dbf..75841e49127 100644
> --- a/gcc/Makefile.in
> +++ b/gcc/Makefile.in
> @@
Hi Alexandre!
On 2020-07-14T01:48:41-0300, Alexandre Oliva wrote:
> Sorry it took me so long to get back to you.
Well, likewise. :-|
> On Jun 30, 2020, Thomas Schwinge wrote:
>
>> For example, if there are two 'offload_targets' configured, and you do a:
>
>> PASS:
Hi Alexandre!
On 2020-07-14T02:46:32-0300, Alexandre Oliva wrote:
> On Jun 30, 2020, Thomas Schwinge wrote:
>> See 'gcc/config/i386/intelmic-mkoffload.c'. ;-)
>> Can you easily adjust that file as you did for the GCN and nvptx
>> 'mkoffload's? Due to other workload, resolving it myself would
On Thu, 23 Jul 2020, Alexandre Oliva wrote:
> The testglue object file gets interpreted as another input file,
> changing the dump and aux output names in GCC unless it is protected
> by -Wl, like board file-named extra inputs.
>
> Refactor the code that modifies the board settings so that it
On Thu, 23 Jul 2020, Alexandre Oliva wrote:
> On Jul 23, 2020, Richard Biener wrote:
>
> > On Thu, 23 Jul 2020, Zhanghaijian (A) wrote:
> >> # This option restores naming of aux and dump output files
> >> # after input files when multiple input files are named,
> >> # instead of getting them
Segher Boessenkool writes:
> On Wed, Jul 22, 2020 at 09:45:08PM +0200, Andrea Corallo wrote:
>> > Should that actually be a sliding window, or should there actually just
>> > not be more than N branches per aligned block of machine code? Like,
>> > per fetch group.
>> >
>> > Can you not use
Add CC to Richard.
> Thanks, Richard!
>
> I think your suggestion is very good, so I made a new patch.
>
> v2: at a high level handles -falign-foo=0 like -falign-foo
> v1: at the target level overides the -falign-foo=0 option values
>
> Obviously, v2 is better than v1. In addition, anthor
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the French team of translators. The file is available at:
https://translationproject.org/latest/gcc/fr.po
(This file, 'gcc-10.2.0.fr.po', has
Hi Kwok!
On 2020-07-22T13:31:30+0100, Kwok Cheung Yeung wrote:
> This test currently fails because some expected 'optimized: assigned OpenACC
> seq
> loop parallelism' messages are not being printed by the compiler. This is
> because the '.auto. conflicts with other OpenACC loop specifiers'
>
Hi Kwok!
On 2020-07-22T14:38:04+0100, Kwok Cheung Yeung wrote:
> This test fails due to expected warnings and errors not being emitted by GCC.
> The problem is that the 'gang reduction on an orphan loop' error is caught
> very
> early on in the frontends (c/c-typeck.c and cp/semantics.c), so
Hi Kwok!
On 2020-07-22T15:17:13+0100, Kwok Cheung Yeung wrote:
> gcc.dg/goacc/loop-processing-1.c fails mainly because the dg-final directive
> at
> the end has been incorrectly split into two lines, which breaks it completely.
> The pass that emits the tested tree output is now oaccloops, not
78 matches
Mail list logo
