Hi Maintainers,
The below patch changes multiplication cost for -march=znver1 target.
GCC Bootstrap tested with BOOT_CFLAGS="-O2 -g -march=znver1".
(---Snip---)
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index d8a2909..b5dde5e 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/con
Hi Uros,
> -Original Message-
> From: Uros Bizjak [mailto:ubiz...@gmail.com]
> Sent: Friday, March 04, 2016 1:10 AM
> To: Kumar, Venkataramanan
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [Patch X86_64] : Fix type attribute for sseimul reservations in
> znver1.md
>
> On Thu, Mar 3, 2016
On Sat, Mar 5, 2016 at 1:13 PM, Kumar, Venkataramanan
wrote:
> Hi Maintainers,
>
> The below patch changes multiplication cost for -march=znver1 target.
> GCC Bootstrap tested with BOOT_CFLAGS="-O2 -g -march=znver1".
>
> (---Snip---)
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
Hi Uros,
> -Original Message-
> From: Uros Bizjak [mailto:ubiz...@gmail.com]
> Sent: Saturday, March 05, 2016 9:06 PM
> To: Kumar, Venkataramanan
> Cc: gcc-patches@gcc.gnu.org; Richard Beiner (richard.guent...@gmail.com)
> Subject: Re: [Patch X86_64]: Fix multiplication cost for -march=znv
When I went to apply my symbol versioning patch to upstream,
I discovered that upstream had already bumped their soname to
6.4.0, beyond the bump that I'd applied to gcc to 5.0.0.
So I bumped upstream to 7.0.0, including the symbol versioning,
and this adjusts gcc to match.
r~
2016-03-02 Richa
The problem is that we are emitting copy sequences to edges without caring
for deferred popping of arguments. Thus when we began emitting code for the
first block, which in this case starts with a label, we had 32 bytes of
pending stack adjustment, which emit_label flushed. The ICE is due to the
Changes for v2 -> v3:
- rebased
Changes for v1 -> v2:
- subroutines using interfaces
- keyword arguments (named parameters)
Rewrite C++ autovec in plain C.
Factor out levenshtein distance handling into a commonly used
gfc_closest_fuzzy_match().
gcc/fortran/ChangeLog
2015-12-27 Bernhard Reutn
On 02/08/2016 12:19 AM, Patrick Palka wrote:
Here, we are calling template_class_depth on a FIELD_DECL corresponding
to a lambda that is used inside variable template. template_class_depth
however does not see that this FIELD_DECL is used inside a variable
template binding because its chain of D
Lewis reported another testcase which hits the "accessing uninitialized
member" error, and can lead to wrong values.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 1bfb2997968d18b337cbd144a698b7be3bf6b28e
Author: Jason Merrill
Date: Sat Mar 5 14:44:31 2016 -0500
PR c++/67364
