Seems like a odd thing for a param. If the compile time increase is very
small ( 1%?) I would just make the new threshold default.
I don't understand the 'odd' here... params are exactly for this purpose, i.e.
to avoid hardcoding magic numbers in the compiler, so please elaborate.
--
Eric
Hi,
with the attached patch we use call-clobbered floating point registers
as save slots for general purpose registers in leaf functions.
Bootstrapped and regtested with various options and -march levels.
Committed to mainline.
Bye,
-Andreas-
2013-10-09 Andreas Krebbel
Just a cleanup of the s390_frame_info function.
Committed to mainline after regression test was fine.
Bye,
-Andreas-
2013-10-09 Andreas Krebbel andreas.kreb...@de.ibm.com
* config/s390/s390.c (s390_frame_info): Restructure function.
---
gcc/config/s390/s390.c | 112
Hi,
for stdarg the floating point argument registers in the register save
area must reside at an ABI-defined offset relative to the start of the save
area. So far were not able to optimize away save instructions with
the packed stack layout since this changed the offsets.
With the attached
Hi!
On Tue, 8 Oct 2013 22:04:23 +0200, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Oct 08, 2013 at 09:17:35AM +0200, Thomas Schwinge wrote:
Here are a few cleanup patches, mostly in the realm of OpenMP, so Jakub
gets a CC. OK to commit?
They look ok to me, but I'd prefer if they could
On Wed, Oct 09, 2013 at 10:56:25AM +0200, Thomas Schwinge wrote:
On Tue, 8 Oct 2013 22:04:23 +0200, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Oct 08, 2013 at 09:17:35AM +0200, Thomas Schwinge wrote:
Here are a few cleanup patches, mostly in the realm of OpenMP, so Jakub
gets a CC. OK
Thomas Schwinge wrote:
Meanwhile, here's another series that I assumed had gotten lost, but now
recovered thanks to Âgit fsckÂ. Also OK to commit?
_OPENMP pre-processor checks, openmp_version Fortran instrinsic checks.
Two remarks:
* When Jakub's patch gets it, one needs to update the C/C++
Hi!
I've backported the following patch to 4.8 branch,
bootstrapped/regtested on x86_64-linux and i686-linux,
committed.
2013-10-09 Jakub Jelinek ja...@redhat.com
Backport from mainline
2013-09-26 Richard Biener rguent...@suse.de
PR tree-optimization/58539
*
Hi!
This is the minimal fix for the issue mentioned in
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00333.html
that is being fixed as part of gomp-4_0-branch merge to trunk,
but for 4.8 I've applied this fix instead.
The testcase also includes the follow-up fix from
Hi!
On Wed, 9 Oct 2013 11:04:29 +0200, Jakub Jelinek ja...@redhat.com wrote:
The testing _OPENMP value against 201107 won't work after merge, it will be
201307 instead. The Fortran openmp_version will be still 201107 for now,
as Fortran OpenMP 4.0 support isn't there yet.
And:
On Wed, 9 Oct
Hi Honza,
Yep, I think we need to merge only those autmatas tha are same for both:
(define_automaton bdver3,bdver3_ieu,bdver3_load,bdver3_fp,bdver3_agu)
probably can become
(define_automaton bdver3,bdver3_fp)
with the corresponding reservations using bdver3_ieu,bdver3_load,bdver3_agu
On Tue, Oct 8, 2013 at 4:15 PM, Andrew MacLeod amacl...@redhat.com wrote:
On 10/08/2013 09:18 AM, Richard Biener wrote:
On Tue, Oct 8, 2013 at 2:58 PM, Andrew MacLeod amacl...@redhat.com
wrote:
I just took a quick stab at it... I think its pretty involved and
someone
with better loop
Hello,
This patch is still far too large.
I think you should split it up based on every single mode iterator that
you need to add or change.
Here's 2nd subpatch. It fixes missing `v' constraints.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3. Spec 2000
Hello,
This patch is still far too large.
I think you should split it up based on every single mode iterator that
you need to add or change.
Here's 3rd subpatch. It extends VF1 and VI iterators.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3. Spec 2000
Hello,
This patch is still far too large.
I think you should split it up based on every single mode iterator that
you need to add or change.
Here's 4th subpatch. It extends V iterator.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3. Spec 2000 2006 build
Hello,
This patch is still far too large.
I think you should split it up based on every single mode iterator that
you need to add or change.
Here's 6th subpatch. It extends VI2 and VI124 iterators.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3. Spec 2000
Hello,
This patch is still far too large.
I think you should split it up based on every single mode iterator that
you need to add or change.
Here's 5th subpatch. It introduces `multdiv' code iterator.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3. Spec
Hello,
This patch is still far too large.
I think you should split it up based on every single mode iterator that
you need to add or change.
Here's 7th subpatch. It extends VI4 and VI8 iterators.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3. Spec 2000
Hello,
This patch is still far too large.
I think you should split it up based on every single mode iterator that
you need to add or change.
Here's 8th subpatch. It extends VI48 and VI48_AVX2 iterators.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3. Spec
Hello,
This patch is still far too large.
I think you should split it up based on every single mode iterator that
you need to add or change.
Here's 10th subpatch. It introduces VI248_AVX2_8_AVX512F and VI124_256_48_512
iterators.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check
Hello,
This patch is still far too large.
I think you should split it up based on every single mode iterator that
you need to add or change.
Here's 9th subpatch. It extends VI124_AVX2_48 and VI8F iterators.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3.
Hello,
This patch is still far too large.
I think you should split it up based on every single mode iterator that
you need to add or change.
Here's 11th subpatch. It introduces AVX-512 FMA instructions.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3. Spec
Hello,
This patch is still far too large.
I think you should split it up based on every single mode iterator that
you need to add or change.
Here's 13th subpatch. It introduces VI4_AVX iterator.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3. Spec 2000
Hello,
This patch is still far too large.
I think you should split it up based on every single mode iterator that
you need to add or change.
Here's 12th subpatch. It introduces VF_512 and VI_512 iterators.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3.
Hello,
This patch is still far too large.
I think you should split it up based on every single mode iterator that
you need to add or change.
Here's 15th subpatch. It introduces VI48F_512 iterator.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3. Spec 2000
Hello,
This patch is still far too large.
I think you should split it up based on every single mode iterator that
you need to add or change.
Here's 14th subpatch. It introduces VI48F_256_512 iterator.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3. Spec
Hello,
This patch is still far too large.
I think you should split it up based on every single mode iterator that
you need to add or change.
Here's 17th subpatch. It introduces V8FI and V16FI iterators.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3. Spec
Hello,
This patch is still far too large.
I think you should split it up based on every single mode iterator that
you need to add or change.
Here's 18th subpatch. It introduces various new insns.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3. Spec 2000
Hello,
This patch is still far too large.
I think you should split it up based on every single mode iterator that
you need to add or change.
Here's 20th subpatch. It introduces last insns of AVX-512F.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3. Spec
Hello,
This patch is still far too large.
I think you should split it up based on every single mode iterator that
you need to add or change.
Here's 19th subpatch. It extends extract and convert insn patterns.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
Hello,
This patch is still far too large.
I think you should split it up based on every single mode iterator that
you need to add or change.
Here's 1st subpatch. It extends VI4F_128 and introduces VI48_512 iterator.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no
On 01/10/13 11:15, Marcus Shawcroft wrote:
On 30 September 2013 14:23, Renlin Li renlin...@arm.com wrote:
OK for trunk?
Kind regards,
Renlin Li
gcc/ChangeLog:
2013-09-30 Renlin Li renlin...@arm.com
* config/arm/arm.c (arm_output_mi_thunk): Use plus_constant.
OK
/Marcus
Hi Renlin,
On Tue, Oct 8, 2013 at 7:52 PM, Eric Botcazou ebotca...@adacore.com wrote:
Probably because the actual accesses may overlap if we choose to
perform a bigger access.
Nope, simply because they share a byte.
The same can happen if we for struct { char c1; char c2; } perform
an HImode access in
On 8 October 2013 17:10, Alex Velenko alex.vele...@arm.com wrote:
gcc/testsuite/
2013-10-08 Alex Velenko alex.vele...@arm.com
* gcc.target/aarch64/vneg_f.c: New testcase.
* gcc.target/aarch64/vneg_s.c: New testcase.
gcc/
2013-10-08 Alex Velenko alex.vele...@arm.com
On Wed, Oct 9, 2013 at 1:31 AM, Andrew MacLeod amacl...@redhat.com wrote:
On 10/08/2013 07:44 AM, Andrew MacLeod wrote:
On 10/08/2013 06:22 AM, Richard Biener wrote:
graphite.h should be unnecessary with moving the pass struct like you
did for other loop opts. Likewise tree-parloops.h
On Tue, Oct 8, 2013 at 11:04 PM, Easwaran Raman era...@google.com wrote:
In cfgexpand.c, variables in non-overlapping lexical scopes are
assigned same stack locations at -O1 and above. At -O0, this is
attempted only if the size of the stack objects is above a threshold
(32). The rationale is
Hi,
this is a completely different approach at fixing the bug, which overall
I like better.
In this case most of the patch touches cp_parser_decltype_expr: instead
of using cp_parser_postfix_expression only for member access
expressions, we accept all its valid return values (still
In my opinion the MEM_EXPR is wrong, as it is supposed to be
the tree equivalent of the memory access. At gimple level we
handle accesses at bit-granularity so bit-accesses are fine.
Not so at RTL level it seems.
[this also shows we probably should lower bit-granular accesses
at the
Hi!
On Tue, 8 Oct 2013 17:24:14 +0200, Jakub Jelinek ja...@redhat.com wrote:
These tests were expecting 5 loopfn matches, 3 on the fn definition, one
as GOMP_parallel_start argument and one called in between
GOMP_parallel_start and GOMP_parallel_end. But the new API is
to call GOMP_parallel
On 8 October 2013 17:25, Alex Velenko alex.vele...@arm.com wrote:
gcc/testsuite/
2013-09-10 Alex Velenko alex.vele...@arm.com
* gcc.target/aarch64/vdiv_f.c: New testcase.
gcc/
2013-09-10 Alex Velenko alex.vele...@arm.com
* config/aarch64/arm_neon.h
On 8 October 2013 17:35, Alex Velenko alex.vele...@arm.com wrote:
2013-10-08 Alex Velenko alex.vele...@arm.com
* gcc.target/aarch64/vadd_f64.c: New testcase.
* gcc.target/aarch64/vsub_f64.c: New testcase.
gcc/
2013-10-08 Alex Velenko alex.vele...@arm.com
*
On Wed, Oct 9, 2013 at 1:36 PM, Eric Botcazou ebotca...@adacore.com wrote:
In my opinion the MEM_EXPR is wrong, as it is supposed to be
the tree equivalent of the memory access. At gimple level we
handle accesses at bit-granularity so bit-accesses are fine.
Not so at RTL level it seems.
On 8 October 2013 17:45, Alex Velenko alex.vele...@arm.com wrote:
2013-10-08 Alex Velenko alex.vele...@arm.com
* gcc.target/aarch64/vclz.c: New testcase.
gcc/
2013-10-08 Alex Velenko alex.vele...@arm.com
* config/aarch64/arm_neon.h (vclz_s8): Asm replaced with
== Administrivia ==
This is my first patch. I have emailed in the signed copyright transfer
documents already.
== Description ==
This patch is a fix for Bug 53001
As required by the C and C++ standards, gcc automatically converts
floating point numbers to lower precision or integer values.
Well, ok. Please adjust the comment
+ /* Different fields of the same record type cannot overlap, unless
they +are both bitfields and we are at the RTL level. */
to sth like
??? Bitfields can overlap at RTL level so punt if we end up at
them.
or sth
Before merging the insn reservations, I need to compare the latency values
for bdver1 and bdver3. I know that they are different for some of the
instructions.
In that case, the merging should prop up another subset of latency
differences. I would like to keep these insn reservations in
Hi!
I've noticed that this testcase doesn't clean up after itself.
Fixed thusly, committed as obvious to trunk.
2013-10-09 Jakub Jelinek ja...@redhat.com
* gcc.dg/vect/bb-slp-31.c: Add cleanup-tree-dump.
--- gcc/testsuite/gcc.dg/vect/bb-slp-31.c.jj2013-08-30 14:38:40.0
On 10/08/2013 07:03 PM, Paolo Carlini wrote:
.. a curiosity: the cp_parser_commit_to_tentative_parse at the end of
cp_parser_pseudo_destructor_name, which didn't exist in 4.6.x and we can
consider the root of this issue, is also my fault:
The test case add here:
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00474.html
Introduced an unprototyped call to abort() resulting in failures due to
unexepected warnings in aarch64-none-elf cross testing.
Committed to trunk as obvious.
Cheers
/Marcus
2013-10-09 Marcus Shawcroft
Hi all,
I've committed this trivial patch as r203322.
It moves the comment for the arm_early_load_addr_dep from above the #includes in
the file to above the function definition.
Thanks,
Kyrill
2013-10-09 Kyrylo Tkachov kyrylo.tkac...@arm.com
* config/arm/aarch-common.c
OK.
Jason
Hi,
On 10/09/2013 03:56 PM, Jason Merrill wrote:
On 10/08/2013 07:03 PM, Paolo Carlini wrote:
.. a curiosity: the cp_parser_commit_to_tentative_parse at the end of
cp_parser_pseudo_destructor_name, which didn't exist in 4.6.x and we can
consider the root of this issue, is also my fault:
On 10/07/2013 07:02 AM, Jakub Jelinek wrote:
duplicates anywhere, but during error diagnostics. Without those two decl.c
hunks (either of them), pushdecl will sometimes return a different decl from
the original or error_mark_node, and the original fndecl passed to it has
ggc_free called on it,
On 9 October 2013 15:26, Marcus Shawcroft wrote:
The test case add here:
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00474.html
Introduced an unprototyped call to abort() resulting in failures due to
unexepected warnings in aarch64-none-elf cross testing.
Committed to trunk as obvious.
Ping.
On 03 Oct 20:05, Ilya Tocar wrote:
On 26 Sep 21:21, Ilya Tocar wrote:
On 25 Sep 15:48, Richard Biener wrote:
On Wed, Sep 25, 2013 at 3:29 PM, Ilya Tocar tocarip.in...@gmail.com
wrote:
On 24 Sep 11:02, Richard Biener wrote:
On Mon, Sep 23, 2013 at 3:29 PM, Ilya Tocar
On Wed, Oct 09, 2013 at 04:12:21PM +0100, Jonathan Wakely wrote:
On 9 October 2013 15:26, Marcus Shawcroft wrote:
The test case add here:
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00474.html
Introduced an unprototyped call to abort() resulting in failures due to
unexepected
Most of loop-doloop.c is wrapped by
#ifdef HAVE_doloop_end
...
#endif
so on my bootstraps/builds, it doesn't exercise the code. It was
pointed out to me the restructuring broke this file on some targets.
This should fix it by calling the refactored get_max_loop_iterations()
function. cross
On 10/08/2013 06:22 AM, Richard Biener wrote:
unvisit_body isn't generic enough to warrant moving out of gimplify.c
(the only user).
Bah, now I remember.. so there *are* other users.. this routine is
called from various front ends.. fortran, c-family and cp all call it.
That is why I wanted
On Wed, Oct 9, 2013 at 11:37 AM, Andrew MacLeod amacl...@redhat.com wrote:
bootstraps on x86_64-unknown-linux-gnu, regressions test are still running.
OK?
Sure.
On 10/08/2013 11:37 AM, Uros Bizjak wrote:
As shown in the attached testcase, arguments of various __atomic
builtins should be converted as signed, so the immediates get properly
extended.
2013-10-08 Uros Bizjak ubiz...@gmail.com
* optabs.c (maybe_emit_atomic_exchange): Convert
On Wed, Oct 09, 2013 at 10:47:22AM -0400, Jason Merrill wrote:
On 10/07/2013 07:02 AM, Jakub Jelinek wrote:
duplicates anywhere, but during error diagnostics. Without those two decl.c
hunks (either of them), pushdecl will sometimes return a different decl from
the original or error_mark_node,
Andrew MacLeod amacl...@redhat.com wrote:
On 10/08/2013 06:22 AM, Richard Biener wrote:
unvisit_body isn't generic enough to warrant moving out of gimplify.c
(the only user).
Bah, now I remember.. so there *are* other users.. this routine is
called from various front ends.. fortran, c-family
On Wed, Oct 9, 2013 at 4:11 AM, Richard Biener
richard.guent...@gmail.com wrote:
On Tue, Oct 8, 2013 at 11:04 PM, Easwaran Raman era...@google.com wrote:
In cfgexpand.c, variables in non-overlapping lexical scopes are
assigned same stack locations at -O1 and above. At -O0, this is
attempted
This patch simply moves std_gimplify_va_arg_expr() and the related
build_va_arg_indirect_ref to gimplify.c where I think it belongs.
It also moves gimple_fold_indirect_ref out of gimplfy.c and into
gimple-fold.c.
bootstraps on x86_64-unknown-linux-gnu... regressions running. OK?
Andrew
*
On 10/09/2013 01:48 PM, Richard Biener wrote:
Andrew MacLeod amacl...@redhat.com wrote:
On 10/08/2013 06:22 AM, Richard Biener wrote:
unvisit_body isn't generic enough to warrant moving out of gimplify.c
(the only user).
Bah, now I remember.. so there *are* other users.. this routine is
On 10/09/2013 02:15 PM, Andrew MacLeod wrote:
On 10/09/2013 01:48 PM, Richard Biener wrote:
Andrew MacLeod amacl...@redhat.com wrote:
On 10/08/2013 06:22 AM, Richard Biener wrote:
unvisit_body isn't generic enough to warrant moving out of gimplify.c
(the only user).
Bah, now I remember.. so
On 9 October 2013 16:15, Jakub Jelinek wrote:
On Wed, Oct 09, 2013 at 04:12:21PM +0100, Jonathan Wakely wrote:
On 9 October 2013 15:26, Marcus Shawcroft wrote:
The test case add here:
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00474.html
Introduced an unprototyped call to abort()
Hi Cary,
The enclosed patch stops declaration dies from generating
gnu-pubnames. Declaration dies don't include enough information to be
useful to gdb, so it has to scan all the entries in the index until it
finds a definition. Not including declarations prevents this problem.
Google ref:
On 09/30/13 03:29, Zhenqiang Chen wrote:
Hi,
The patch enhances phiopt to handle cases like:
if (a == 0 (...))
return 0;
return a;
Boot strap and no make check regression on X86-64 and ARM.
Is it OK for trunk?
Thanks!
-Zhenqiang
ChangeLog:
2013-09-30 Zhenqiang Chen
On 10/08/13 21:39, Zhenqiang Chen wrote:
I'll go ahead and pull the common bits into a single function and commit on
Zhenqiang's behalf.
Thank you!
No problem. If you think you'll be contributing regularly, you might
want to go ahead and ask for write-after-approval privileges.
jeff
On 09/28/13 09:30, Mikael Pettersson wrote:
This patch fixes PR58369, an ICE in subreg_get_info when compiling
boost for m68k-linux.
choose_reload_regs attempts to reload a DFmode (8-byte) reg, finds
an XFmode (12-byte) reg in last_reg, and calls subreg_regno_offset
with these two modes and a
On 08/21/13 03:21, Andreas Krebbel wrote:
[RFC] Allow functions calling mcount before prologue to be leaf functions
http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00993.html
I don't think this is necessarily correct for all targets. ISTM the
ability to consider a function calling mcount as a
On Wed, Oct 9, 2013 at 6:23 PM, Richard Henderson r...@redhat.com wrote:
This doesn't seem right at all.
The bug is that I gets set to UINT64_MAX, right? Where's the
incorrect conversion from int to __int128_t? Surely you can
Please see Comment #5 of PR58542:
--cut here--
The problem
On Wed, 9 Oct 2013, Joshua J Cogliati wrote:
Because this changes -Wextra, when compiling with -Werror and -Wextra,
some code will not compile now. The code in gcc that this occurred in
was changed to use explicit casts. The patch would be shorter if
I think those changes should be
Also note that this patch needs to add testcases to the testsuite
(gcc/testsuite/c-c++-common/, probably) testing what cases generate
warnings with the new option and what cases don't.
--
Joseph S. Myers
jos...@codesourcery.com
On 10/09/2013 03:24 AM, Kirill Yukhin wrote:
Here's 2nd subpatch. It fixes missing `v' constraints.
And one v constraint that shouldn't have been.
Ok.
r~
On 10/09/2013 03:24 AM, Kirill Yukhin wrote:
Here's 3rd subpatch. It extends VF1 and VI iterators.
Ok.
r~
On 10/09/2013 03:25 AM, Kirill Yukhin wrote:
Here's 4th subpatch. It extends V iterator.
And much much more that's totally unrelated to changing V.
That said, I didn't see anything wrong in there.
Ok.
r~
On 10/09/2013 02:18 PM, Andrew MacLeod wrote:
On 10/09/2013 02:15 PM, Andrew MacLeod wrote:
Fair enough. I'll adjust... the front end files which use that
routine will just have to include gimplify.h
Unless maybe we should expand the gimplify module to have a
gimplfy-fe.[ch] which
On 10/09/2013 03:25 AM, Kirill Yukhin wrote:
Here's 5th subpatch. It introduces `multdiv' code iterator.
This is the sort of patch I like to see. It's the first one
you've sent that's done exactly one thing. Congratulations.
Ok.
r~
On 10/09/2013 03:26 AM, Kirill Yukhin wrote:
Here's 6th subpatch. It extends VI2 and VI124 iterators.
Ok.
r~
On 10/09/2013 03:26 AM, Kirill Yukhin wrote:
Here's 7th subpatch. It extends VI4 and VI8 iterators.
Ok.
r~
On 10/09/2013 03:27 AM, Kirill Yukhin wrote:
Here's 8th subpatch. It extends VI48 and VI48_AVX2 iterators.
Ok.
r~
On 10/09/2013 03:27 AM, Kirill Yukhin wrote:
Here's 9th subpatch. It extends VI124_AVX2_48 and VI8F iterators.
Ok.
r~
2013-10-09 Sterling Augustine saugust...@google.com
* dwarf2out.c (include_pubname_in_output): Add conditional on
is_declaration_die
and debug_generate_pubnames.
OK for google 4.8 branch. Thanks!
-cary
A rather obvious fix; the memory is freed by the caller
(gfc_simplify_compiler_options). It is unlikely that the compiler has no
arguments as the driver tends to send some, e.g. -mtune=generic
-march=x86-64 on my system. However, it is better to be safe than sorry.
Build and regtested on
On 10/09/2013 03:27 AM, Kirill Yukhin wrote:
Here's 10th subpatch. It introduces VI248_AVX2_8_AVX512F and VI124_256_48_512
iterators.
Ok.
r~
On 10/09/2013 03:28 AM, Kirill Yukhin wrote:
+;; CPUID bit AVX512F enables evex encoded scalar and 512-bit fma. It doesn't
+;; care about FMA bit, so we enable fma for TARGET_AVX512F even when
TARGET_FMA
+;; and TARGET_FMA4 are both false.
How do you force an evex encoding of the
On 10/09/2013 03:28 AM, Kirill Yukhin wrote:
Here's 12th subpatch. It introduces VF_512 and VI_512 iterators.
Ok.
r~
On 10/09/2013 03:29 AM, Kirill Yukhin wrote:
Here's 13th subpatch. It introduces VI4_AVX iterator.
Ok.
r~
On 10/09/2013 03:29 AM, Kirill Yukhin wrote:
Here's 14th subpatch. It introduces VI48F_256_512 iterator.
Ok.
r~
Hi,
This patch is a first small sample of dejagnu-ization of my ARM Neon
intrinsics tests.
It's derived from my previous work at
http://gitorious.org/arm-neon-tests/arm-neon-tests which supports all
the ARM intrinsics, with executable tests. As I have to manually
transform each test (to include
This patch to the Go frontend and libgo fixes complex division of NaN /
0. Go expects that to produce NaN. When using libgcc it could produce
Inf. Specifically NaN+1i / 0+0i produced NaN+Infi, which by the rules
of C99 Annex G is Inf. This may be correct for C, but it's not correct
for Go.
On Wed, Oct 09, 2013 at 11:51:30PM +0200, Tobias Burnus wrote:
A rather obvious fix; the memory is freed by the caller
(gfc_simplify_compiler_options). It is unlikely that the compiler has no
arguments as the driver tends to send some, e.g. -mtune=generic
-march=x86-64 on my system.
Hi Richard,
This patch implements a workaround for errors on the PMC-Sierra RM7000 cpu
while executing the dmult or dmultu instruction. The workaround is to insert
three nops after the dmult/dmultu.
Does this look okay to commit?
Thanks,
Catherine
gcc/
2013-10-09 Catherine Moore
Hi,
This is a follow-up to the recent patch that fixed constant permute
control vectors for little endian. When the control vector is constant,
we can adjust the constant and use a vperm without increasing code size.
When the control vector is unknown, however, we have to generate two
additional
This patch updates the AutoFDO profile propagation of equivalence
class: instead of looking just immediate dominators, traverse all
dominators. This helps improving profile accuracy.
Bootstrapped and passed regression test.
OK for google-4_8 branch?
Thanks,
Dehao
Index: gcc/auto-profile.c
ok.
David
On Wed, Oct 9, 2013 at 4:47 PM, Dehao Chen de...@google.com wrote:
This patch updates the AutoFDO profile propagation of equivalence
class: instead of looking just immediate dominators, traverse all
dominators. This helps improving profile accuracy.
Bootstrapped and passed
In legacy AutoFDO, callsite is represented as a (lineno, callee_name)
pair because there could be multiple calls in one line. However, as we
enhanced the debug info by assigning discriminators for each function
call in the same line, callee_name is not needed when indexing the
callsite.
This
In Go a type conversion of a constant is not necessarily itself a
constant, as in []byte(nil). This patch fixes the Go frontend to
recognize that. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline. Will commit to 4.8
branch when it reopens.
Ian
diff -r
1 - 100 of 115 matches
Mail list logo
