On 14.03.2016 21:39, Jeff Law wrote:
On 03/14/2016 03:56 AM, Andrey Belevantsev wrote:
Thank you for checking this in. I've also tested this patch in the
similar way (forcing selective scheduling for 2nd and both schedulers)
both on x86-64 and ia64. I've posted the patches for remaining
sel-s
Hi,
This patch makes an integer vector type to always be used for
type checks when building a vector conditional expression.
With no this patch we may get a type of vector comparison
which may have non-vector mode and different size in case
of scalar masks usage.
Bootstrapped and regetsted on x86
Hello,
Attached patch blocks third alternative of broadcast pattern
when compiled w/ -mavx512vl.
Issue is that third alternative is subject for subsequent splitting.
AVX-512VL allows higher XMM regnums (than SSE), so split generate
AVX2 broadcast insns, which will use XMMN, N>15.
We have separate
Hi, this is the set of patches from
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01411.html
revised again, this time also with audits for the HSA plugin.
The changes are pretty minor, mainly that the unload_image hook now
receives similar error handling treatment.
Tested again without regressio
As attached.
Thanks,
Chung-Lin
* plugin/plugin-nvptx.c (CUDA_CALL_ERET): New convenience macro.
(CUDA_CALL): Likewise.
(CUDA_CALL_ASSERT): Likewise.
(map_init): Change return type to bool, use CUDA_CALL* macros.
(map_fini): Likewise.
(init_streams_f
Hi Martin, I think you're the one to CC for this,
as I mentioned in the first email, this has been build tested, however I did
not know if I could test this without a Radeon card. If convenient,
could you or anyone familiar with the setup do a make check-target-libgomp
with this patch series?
Tha
Hi Jakub, your earlier concern about the return after abort
was naturally resolved after the gomp_target_fini changes.
Thanks,
Chung-Lin
* plugin/libgomp-plugin-intelmic.cpp (offload): Change return type
to bool, adjust return code.
(GOMP_OFFLOAD_init_device): Likewise.
On 03/17/2016 07:21 PM, Martin Jambor wrote:
> Hopefully the linear search in m_global_symbols never becomes
> prohibitively expensive. But it is only necessary when
> is_in_global_vars is true, so at least we could do something like:
>
> if (is_in_global_vars && !sym->m_emitted_to_brig)
>
On Mon, 21 Mar 2016, Kirill Yukhin wrote:
> Hello,
>
> Attached patch blocks third alternative of broadcast pattern
> when compiled w/ -mavx512vl.
> Issue is that third alternative is subject for subsequent splitting.
> AVX-512VL allows higher XMM regnums (than SSE), so split generate
> AVX2 broa
On Thu, Mar 17, 2016 at 4:39 PM, Andre Vieira (lists)
wrote:
> Hello,
>
> This patch skips four tests that assume a target supports ARM mode when
> testing M-profiles.
> Tested it by running the four tests for A-profiles and M-profiles.
>
> Is this ok?
OK.
Ramana
>
> Cheers,
> Andre
>
> gcc/test
On Fri, Mar 11, 2016 at 3:32 PM, Kyrill Tkachov
wrote:
> Hi all,
>
> As reported in the PR we can end up calling fclose twice on a file, causing
> an error.
> This patch fixes that by reorganising the logic a bit to ensure we return
> after closing
> the file the first time.
>
> Bootstrapped and t
On Mon, Feb 29, 2016 at 4:08 PM, Kyrill Tkachov
wrote:
> Hi all,
>
> I've had this one sitting in my tree for some time.
> The arm1020e automaton has no business being as large as it is (3185
> states).
> Most of the bloat is due to overly large reservation durations for calls and
> FP division.
>
On 21 Mar 11:37, Richard Biener wrote:
> On Mon, 21 Mar 2016, Kirill Yukhin wrote:
>
> > Hello,
> >
> > Attached patch blocks third alternative of broadcast pattern
> > when compiled w/ -mavx512vl.
> > Issue is that third alternative is subject for subsequent splitting.
> > AVX-512VL allows highe
Hi,
I'd like to note that I have a small patch on gomp-nvptx branch that deals
with the worst user-visible regression in a non-intrusive manner:
https://gcc.gnu.org/ml/gcc-patches/2016-03/msg01109.html
Alexander
Hello.
Following patch enhances dump output for SBR instructions and
provides a BRIG offset of HSA symbols. The change does not touch any
code generation snippet and I hope it can be installed during the stage4?
Patch can bootstrap on x86_64-linux-gnu and survives
make check-target-libgomp.
Read
On 2016/3/21 07:01 PM, Alexander Monakov wrote:
> Hi,
>
> I'd like to note that I have a small patch on gomp-nvptx branch that deals
> with the worst user-visible regression in a non-intrusive manner:
>
> https://gcc.gnu.org/ml/gcc-patches/2016-03/msg01109.html
>
> Alexander
>
That error condi
Hi!
On Tue, 22 Dec 2015 21:46:19 -0700, Martin Sebor wrote:
> The attached patch rejects invocations of atomic fetch_op intrinsics
> on objects of _Bool type as discussed in the context of PR c/68908.
>
> Tested on x86_64.
I'd noticed something "strange". ;-)
For reference:
> --- gcc/c-famil
Uros Bizjak writes:
> On Thu, Mar 17, 2016 at 11:40 PM, Rainer Orth
> wrote:
>> gcc.target/i386/pr58218.c currently FAILs on 64-bit Solaris/x86 with the
>> native assembler:
>>
>> FAIL: gcc.target/i386/pr58218.c (test for excess errors)
>>
>> Excess errors:
>> Assembler: pr58218.c
>> "/v
Hello.
Following patch fixes an invalid write in HSA plug-in.
I've been running bootstrap and regression tests on x86-linux-gnu.
Ready after it finishes?
Thanks,
Martin
>From 2674ceb5fddeaeb26ff87d26a43bddaf40060ea2 Mon Sep 17 00:00:00 2001
From: marxin
Date: Mon, 21 Mar 2016 13:34:04 +0100
Subj
I realized I didn't make the necessary edits for gfortran.
gcc/fortran/ChangeLog
-
2016-03-21 Daniel Sabogal
PR preprocessor/51259
* cpp.c (print_line): Allow replacement when calling
"cpp_quote_string".
(pp_dir_change): Allow replacement when calling "cpp_
This series of patches makes the rs6000 backend properly honour
-ffixed-reg in that compiler generated code should never write them,
even when restoring saved copies of registers.
Patch 1 and 2 are the bugfix. Patch 3 and 4 allow saving regs using
stmw or out-of-line save functions, even when the
This makes the conditions look the same as other places that deal with
RS6000_PIC_OFFSET_TABLE_REGNUM, eg. first_reg_to_save. No functional
changes.
* config/rs6000/rs6000.c (rs6000_conditional_register_usage):
Remove redundant PIC_OFFSET_TABLE_REGNUM test. Replace with
f
Treat -ffixed-reg as we do for global asm regs. The only slightly
complicated part of this patch is that the rs6000 backend itself sets
fixed_regs[RS6000_PIC_OFFSET_TABLE_REGNUM] in some cases, which means
we can't simply test fixed_regs[] to determine whether a reg appeared
as -ffixed-reg.
No functional change here. A single bit becomes two bits, which
always have the same value at the moment. In preparation for the
next patch.
* config/rs6000/rs6000.c (SAVRES_MULTIPLE): Replace with..
(SAVE_STRATEGY, REST_STRATEGY): ..this. Renumber and sort enum.
Update
As I noted a long time ago in the comment on fixed_reg_p, the real
problem with saving fixed/global regs is that exception frame
unwinding might restore them. So don't emit eh_frame info for any
such reg, and the unwinder won't restore them.
Also, tidy rs6000_savres_strategy. Delaying some check
On 03/17/2016 08:17 PM, Richard Henderson wrote:
With -g, and a code section that ends unaligned, the assembler complains of
"unaligned opcodes detected". Except there are no such unaligned opcodes, nor
dwarf2 code ranges covering the end of the section, which arguably makes this
an assembler bu
On 17/03/16 19:17, Richard Henderson wrote:
PR target/70120
* varasm.c (for_each_section): New.
* varasm.h (for_each_section): Declare.
* config/aarch64/aarch64.c (aarch64_align_code_section): New.
(aarch64_asm_file_end): New.
(TARGET_ASM_FILE_END): Redefin
On 03/21/2016 02:37 AM, Alan Modra wrote:
This series tidies some of the early ira code, in the process making a
tiny improvement to register pressure. Patches 1 to 3 are fairly
simple tidies, with zero impact on generated code. Patch 4 also is
mainly a tidy, but could see some extra REG_EQUIV
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2016-03-21 Richard Biener
PR tree-optimization/70310
* tree-vect-generic.c (expand_vector_condition): Fold the built
condition.
* gcc.dg/torture/pr70310.c: New testcase.
Index: gcc/tree-v
Hello,
1s in mask in i386.c/builtin_description enables
built-ins for corresponding bits.
So, actually if there're 2 1s in it - any bit set
enables built-in.
AVX-512VL exploits mask in opposite way.
E.g.:
{ OPTION_MASK_ISA_AVX512BW | OPTION_MASK_ISA_AVX512VL,
CODE_FOR_avx512vl_loaddquv16hi_mask
On Mon, 21 Mar 2016, Kirill Yukhin wrote:
> Hello,
> 1s in mask in i386.c/builtin_description enables
> built-ins for corresponding bits.
> So, actually if there're 2 1s in it - any bit set
> enables built-in.
>
> AVX-512VL exploits mask in opposite way.
> E.g.:
> { OPTION_MASK_ISA_AVX512BW | O
On Fri, Mar 18, 2016 at 10:34:49PM +0100, Jakub Jelinek wrote:
> Hi!
>
> The following testcase is diagnosed as errorneous, because the preprocessor
> mishandles
>
> #define c(x) x
> vector c;
>
> and
>
> #define int(x) x
> vector int n;
>
> The thing is if a function-like macro is not followe
Hi!
www.cilkplus.org/sites/default/files/open_specifications/Intel_Cilk_plus_lang_spec_1.2.htm
says:
In C++, the control variable shall be declared and initialized within the
initialization clause of the _Cilk_for loop. The variable shall have automatic
storage duration. The variable shall b
On Mon, Mar 21, 2016 at 9:06 AM, Alan Modra wrote:
> This makes the conditions look the same as other places that deal with
> RS6000_PIC_OFFSET_TABLE_REGNUM, eg. first_reg_to_save. No functional
> changes.
>
> * config/rs6000/rs6000.c (rs6000_conditional_register_usage):
> Remove
On Mon, Mar 21, 2016 at 9:06 AM, Alan Modra wrote:
> Treat -ffixed-reg as we do for global asm regs. The only slightly
> complicated part of this patch is that the rs6000 backend itself sets
> fixed_regs[RS6000_PIC_OFFSET_TABLE_REGNUM] in some cases, which means
> we can't simply test fixed_regs[
non_const_var_error() does not expect to complain about a decl whose
DECL_INITIAL is a constant. But it is not sufficient to check that the
DECL_INITIAL is a constant since it could be the case that it was folded
to a constant and yet was originally initialized by a non-constant
expression. So to
On Mon, Mar 21, 2016 at 9:07 AM, Alan Modra wrote:
> No functional change here. A single bit becomes two bits, which
> always have the same value at the moment. In preparation for the
> next patch.
>
> * config/rs6000/rs6000.c (SAVRES_MULTIPLE): Replace with..
> (SAVE_STRATEGY, R
Ping.
Bernd
On 03/14/2016 02:20 PM, Bernd Schmidt wrote:
On 03/11/2016 11:09 PM, David Malcolm wrote:
+ cpp_error (pfile, CPP_DL_ERROR,
+ "file \"%s\" left but not entered", new_file);
Although it looks like
On 21/03/16 13:08 +0100, Thomas Schwinge wrote:
Per my (admittedly, not in-depth) reading of libstdc++-v3 source code,
the _GLIBCXX_ATOMIC_BUILTINS conditional is only used in combination with
the _Atomic_word data type, which in
libstdc++-v3/doc/xml/manual/concurrency_extensions.xml is described
On Mon, Mar 21, 2016 at 05:45:52PM +0300, Ilya Verbin wrote:
> www.cilkplus.org/sites/default/files/open_specifications/Intel_Cilk_plus_lang_spec_1.2.htm
> says:
> In C++, the control variable shall be declared and initialized within the
> initialization clause of the _Cilk_for loop. The variab
On Mon, Mar 21, 2016 at 9:08 AM, Alan Modra wrote:
> As I noted a long time ago in the comment on fixed_reg_p, the real
> problem with saving fixed/global regs is that exception frame
> unwinding might restore them. So don't emit eh_frame info for any
> such reg, and the unwinder won't restore th
Hi,
After patch fixing PR69042 at
https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00887.html, GCC hits bound (30)
for parameter PARAM_IV_CONSIDER_ALL_CANDIDATES_BOUND in case 173.applu, which
causes ~4% regression on AArch64. Since adding more candidates is inevitable
(Well, we might be able to
Hi,
The second issue revealed by PR69489 is tree ifcvt could not convert PHI nodes
with more than 2 arguments. Among these nodes, there is a special kind of PHI
which can be handled. Precisely, if the PHI node satisfies below two
conditions:
1) Number of PHI arguments with different value
Hi!
On Thu, 10 Mar 2016 16:14:34 +0300 (MSK), Alexander Monakov
wrote:
> On Thu, 10 Mar 2016, Nathan Sidwell wrote:
> > Hm, something must have changed since I found that sorry neccessary.
>
> As I already said in my opening sentence (not quoted in your response), you
> removed the unnecessary
On 21/03/16 10:39, Ramana Radhakrishnan wrote:
> On Thu, Mar 17, 2016 at 4:39 PM, Andre Vieira (lists)
> wrote:
>> Hello,
>>
>> This patch skips four tests that assume a target supports ARM mode when
>> testing M-profiles.
>> Tested it by running the four tests for A-profiles and M-profiles.
>>
>>
Hi!
On Mon, 21 Mar 2016 15:01:49 +, Jonathan Wakely wrote:
> On 21/03/16 13:08 +0100, Thomas Schwinge wrote:
> >Per my (admittedly, not in-depth) reading of libstdc++-v3 source code,
> >the _GLIBCXX_ATOMIC_BUILTINS conditional is only used in combination with
> >the _Atomic_word data type, wh
On 03/21/2016 09:14 AM, Bin Cheng wrote:
Hi,
After patch fixing PR69042 at
https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00887.html, GCC hits bound (30)
for parameter PARAM_IV_CONSIDER_ALL_CANDIDATES_BOUND in case 173.applu, which
causes ~4% regression on AArch64. Since adding more candidates
Hello.
Following patch skips static {c,d}tors in IPA ICF.
Patch can bootstrap and survives regtests on x86_64-linux-gnu.
Ready for trunk?
Thanks,
Martin
>From 7a5748b38e173702c88b97420d6b4d8969ae7e85 Mon Sep 17 00:00:00 2001
From: marxin
Date: Mon, 21 Mar 2016 13:51:32 +0100
Subject: [PATCH] Ski
On 03/21/2016 10:38 AM, Patrick Palka wrote:
non_const_var_error() does not expect to complain about a decl whose
DECL_INITIAL is a constant. But it is not sufficient to check that the
DECL_INITIAL is a constant since it could be the case that it was folded
to a constant and yet was originally i
Hi,
On Mon, Mar 21, 2016 at 12:14:19PM +0100, Martin Liska wrote:
> Hello.
>
> Following patch enhances dump output for SBR instructions and
> provides a BRIG offset of HSA symbols. The change does not touch any
> code generation snippet and I hope it can be installed during the stage4?
yes, but
On 03/21/2016 06:40 AM, Jiong Wang wrote:
On 17/03/16 19:17, Richard Henderson wrote:
PR target/70120
* varasm.c (for_each_section): New.
* varasm.h (for_each_section): Declare.
* config/aarch64/aarch64.c (aarch64_align_code_section): New.
(aarch64_asm_file_end): New.
(TARGET
On 03/18/2016 01:04 PM, Jeff Law wrote:
On 03/17/2016 03:16 PM, Martin Sebor wrote:
The difficulty I've run into with detecting these problems in later
phases is that some invalid expressions have already been simplified
by the front end. The example that applies here (even though this
is still
This PR points out to a GC problem: when we freed a duplicate typedef, we were
leaving its type in the variants list, with its TYPE_NAME still pointing to the
now-freed TYPE_DECL, leading to a crash. I was lucky to discover that the
exact same problem was fixed in November for the C++ FE, so I co
> Hello.
>
> Following patch skips static {c,d}tors in IPA ICF.
> Patch can bootstrap and survives regtests on x86_64-linux-gnu.
OK, (it woudl make more sense to turn them into wrappers that can be easily
done, too, but we can do that next stage1)
thanks!
Honza
>
> Ready for trunk?
> Thanks,
>
Hi,
On Mon, Mar 21, 2016 at 01:49:25PM +0100, Martin Liska wrote:
> Hello.
>
> Following patch fixes an invalid write in HSA plug-in.
> I've been running bootstrap and regression tests on x86-linux-gnu.
>
> Ready after it finishes?
> Thanks,
> Martin
> From 2674ceb5fddeaeb26ff87d26a43bddaf40060
As noted last week, find_removable_extensions initializes several
bitmaps, but doesn't clear them.
This is not strictly a leak as the GC system should find dead data, but
it's better to go ahead and clear the bitmaps. That releases the
elements back to the cache and presumably makes things
On 03/21/2016 08:06 PM, Jeff Law wrote:
As noted last week, find_removable_extensions initializes several
bitmaps, but doesn't clear them.
This is not strictly a leak as the GC system should find dead data, but
it's better to go ahead and clear the bitmaps. That releases the
elements back to t
On 03/21/2016 06:44 PM, Martin Jambor wrote:
...please remove the added newlines here...
>+ if (symbol->m_directive_offset)
>+fprintf (f, " /* BRIG offset: %u",
symbol->m_directive_offset);
...and I think you are missing an ending "*/" in the string you dump.
Sure, fixed.
I'm not sure why the decl must be left on the local_decl list -- the same decl
ought to also be in the BIND_EXPR for the function. But it's a fact that the
DECL_INITIAL doesn't get processed during clone_body without the local_decl
list processing.
So in the meantime, set the has_forced_label
Hello!
We have to expand SSE moves through x86_expand_vector_operand,
otherwise unsupported push instructions are generated among other
possible troubles.
2016-03-21 Uros Bizjak
PR target/70327
* config/i386/i386.md (movxi): Use ix86_expand_vector_move instead
of ix86_expand_move.
Hi!
vec_interleave_lowv4sf only supports =x, x, x alternative, not =v, v, v
(which should be supportable for AVX512VL only anyway, but probably
stage1 material), without AVX512VL and with ext sse reg input operand
we have to either due to interleaving or broadcast in the destination,
or disable th
On Mon, 2016-03-14 at 14:20 +0100, Bernd Schmidt wrote:
> On 03/11/2016 11:09 PM, David Malcolm wrote:
> > > + cpp_error (pfile, CPP_DL_ERROR,
> > > + "file \"%s\" left but not entered",
> > > new_file);
> >
> > Altho
Hi!
The ix86_expand_vecop_qihi function has been adjusted for AVX512* just
by changing i < 32 to i < 64 (where both were sometimes wasteful), but
for !full_interleave that is even wrong, swapping the second and third
quarter is something that works to undo AVX256 unpacks only,
where we want
0,2,4,
Hi!
An instruction with scratches is deleted during LRA inheritance,
and we ICE because restore_scratches wants to query its
lra_get_insn_recog_data even when it is a NOTE, but insn_extract
doesn't work on notes.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
Hi!
HONOR_NANS when called on a tree or its type handles properly
vector/complex element modes, but HONOR_NANS (TYPE_MODE (TREE_TYPE (...)))
does not.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2016-03-21 Marc Glisse
Jakub Jelinek
On 03/21/2016 01:10 PM, Bernd Schmidt wrote:
On 03/21/2016 08:06 PM, Jeff Law wrote:
As noted last week, find_removable_extensions initializes several
bitmaps, but doesn't clear them.
This is not strictly a leak as the GC system should find dead data, but
it's better to go ahead and clear the
Hi!
On the Wnonnull-compare-8.C testcase we emit false positive warning, because
the this != NULL artificial comparison appears together with && optimized
into &, and so it is gimplified as assignment to temporary instead of
GIMPLE_COND.
Unfortunately, this regresses one test in nonnull-1.c, beca
On 03/21/2016 02:21 PM, Jakub Jelinek wrote:
Hi!
HONOR_NANS when called on a tree or its type handles properly
vector/complex element modes, but HONOR_NANS (TYPE_MODE (TREE_TYPE (...)))
does not.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2016-03-21 Mar
On 03/21/2016 02:19 PM, Jakub Jelinek wrote:
Hi!
An instruction with scratches is deleted during LRA inheritance,
and we ICE because restore_scratches wants to query its
lra_get_insn_recog_data even when it is a NOTE, but insn_extract
doesn't work on notes.
Fixed thusly, bootstrapped/regtested
On Mon, Mar 21, 2016 at 02:43:23PM -0600, Jeff Law wrote:
> On 03/21/2016 02:21 PM, Jakub Jelinek wrote:
> >Hi!
> >
> >HONOR_NANS when called on a tree or its type handles properly
> >vector/complex element modes, but HONOR_NANS (TYPE_MODE (TREE_TYPE (...)))
> >does not.
> >
> >Fixed thusly, bootst
On 03/21/2016 07:23 PM, Martin Jambor wrote:
This is strange. The pointer to the shadow data structure is, from
the HSA perspective, a normal kernel argument and therefore should
already be included in the kernel->kernarg_segment_size. Have you
checked that the values are indeed off?
Hi Marti
On March 21, 2016 6:55:28 PM GMT+01:00, Marek Polacek
wrote:
>This PR points out to a GC problem: when we freed a duplicate typedef,
>we were
>leaving its type in the variants list, with its TYPE_NAME still
>pointing to the
>now-freed TYPE_DECL, leading to a crash. I was lucky to discover that
Hi all,
For several years I’ve been eager to find the time to fix the bugs in C++
exceptions on VAX to get them working on NetBSD, because they’ve been broken
for many years and it looked like only a few changes were needed to get them
working. Without C++ exceptions, the NetBSD test suite can’
The C++ front end builds COND_EXPR where the arms can have a different
type from the combined expression, if they are bit-fields.
cp_genericize_r already fixes this up, but now cp_fold needs to handle
it too.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit c1b91b53f85c8a00c5067dbfc15f5fb
OK.
Jason
I'm looking for a review of the patch below. I noticed a piece
of commented out code in there. Please assume that I will remove
it before the final commit.
As a heads up, I'm traveling this Thursday through Sunday and
won't have access to email to answer questions or address
comments until next
On 03/21/2016 11:54 AM, Jason Merrill wrote:
Both b0 and b1 are invalid and should be diagnosed, but only b1
is. b1 isn't because because by the time we see its initializer
in constexpr.c it's been transformed into the equivalent of "b1
= (int*)ps" (though we don't see the cast which would also
On 03/21/2016 02:40 PM, Jakub Jelinek wrote:
Hi!
On the Wnonnull-compare-8.C testcase we emit false positive warning, because
the this != NULL artificial comparison appears together with && optimized
into &, and so it is gimplified as assignment to temporary instead of
GIMPLE_COND.
Unfortunatel
Given
template
void foo () { T A::*fptr; }
We don't know whether fptr is a pointer-to-member-function or a
pointer-to-data-member until we know what T is. But until then, fptr
gets the type OFFSET_TYPE.
If we later instantiate foo with e.g. T = void() then we know that fptr
is a pointer-to
Richard Henderson writes:
> On 03/21/2016 06:40 AM, Jiong Wang wrote:
>> On 17/03/16 19:17, Richard Henderson wrote:
>>> PR target/70120
>>> * varasm.c (for_each_section): New.
>>> * varasm.h (for_each_section): Declare.
>>> * config/aarch64/aarch64.c (aarch64_align_code_section): New
On 03/21/2016 09:15 PM, David Malcolm wrote:
On Mon, 2016-03-14 at 14:20 +0100, Bernd Schmidt wrote:
On 03/11/2016 11:09 PM, David Malcolm wrote:
+ cpp_error (pfile, CPP_DL_ERROR,
+"file \"%s\" left but not entered",
new_file);
OK.
Jason
Hi Jakub,
On 21 Mar 21:10, Jakub Jelinek wrote:
> vec_interleave_lowv4sf only supports =x, x, x alternative, not =v, v, v
> (which should be supportable for AVX512VL only anyway, but probably
> stage1 material), without AVX512VL and with ext sse reg input operand
> we have to either due to interlea
Hi,
Please find attached the patch that enhances the existing pattern.
Please review the patch at the following link and let me know
if there should be any modifications in it:-
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01035.html
Thanks,
Naveen
84 matches
Mail list logo
