On Fri, Aug 14, 2015 at 1:56 PM, Thomas Schwinge
tho...@codesourcery.com wrote:
Hi!
(Can a Fortran person please comment on this: as it's nontrivial to write
to stderr, let's just write to stdout followed by a flush, which does
have the same ordering effect -- OK?)
If you want to write to
(Can a Fortran person please comment on this: as it's nontrivial to write
to stderr, let's just write to stdout followed by a flush, which does
have the same ordering effect -- OK?)
Although there are no absolute guarantees on flushing, it should work in
practice.
Note that the FLUSH
As outlined in the PR, this fixes one ICE. The code in question here
tries to determine whether OP can be derived as non-NULL. In case the
function has the nonnull attribute that applies to all the arguments,
we want to see whether OP is in this argument list. But nonnull only
appertains to
On Thu, Aug 13, 2015 at 7:56 PM, Aditya K hiradi...@msn.com wrote:
Date: Thu, 13 Aug 2015 12:02:43 +0200
Subject: Re: [PATCH] [graphite] Constrain only on INTEGER_TYPE
From: richard.guent...@gmail.com
To: tob...@grosser.es
CC: hiradi...@msn.com; gcc-patches@gcc.gnu.org; s@samsung.com;
On Thu, Aug 13, 2015 at 7:47 PM, Mike Stump mikest...@comcast.net wrote:
On Aug 13, 2015, at 3:05 AM, Richard Biener richard.guent...@gmail.com
wrote:
Ok, then guard the with __GCC__ and do the expensive bit stuff
otherwise. Just to cater for other host compilers doing sth unsensibly
On Thu, Aug 13, 2015 at 11:31 PM, Jeff Law l...@redhat.com wrote:
On 08/13/2015 04:00 AM, Richard Biener wrote:
On Wed, Aug 12, 2015 at 6:47 PM, Jeff Law l...@redhat.com wrote:
On 08/12/2015 10:24 AM, Ian Lance Taylor wrote:
On Wed, Aug 12, 2015 at 9:21 AM, Tom Tromey t...@tromey.com
On Fri, Aug 14, 2015 at 2:55 AM, Mikhail Maltsev malts...@gmail.com wrote:
Hi all.
These two patches are refactoring of dominator-related code.
The comment in dominance.c says: We work in a poor-mans object oriented
fashion, and carry an instance of this structure through all our 'methods'.
The attached patch fixes PR 62296
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62296). The Fortran
interpretation there was a bit confused (see links to comp.lang.fortran thread
from the PR), but the consensus is that the standard makes a difference between
the command-line returning with
2015-08-14 11:47 GMT+02:00 Thomas Schwinge tho...@codesourcery.com:
On Wed, 5 Aug 2015 18:09:04 +0300, Ilya Verbin iver...@gmail.com wrote:
@@ -1095,6 +1092,8 @@ GOMP_target (int device, void (*fn) (void *),
const void *unused,
return gomp_target_fallback (fn, hostaddrs);
Hello!
Use libbacktrace (instead of our own unwind-based code) to display backtraces
from libgfortran
upon error or user request.
1. In toplevel Makefile.def, make libgfortran depend on libbacktrace (needs
global reviewer
approval)
2. In gcc/fortran/config-lang.in, add libbacktrace
On Fri, Aug 14, 2015 at 1:32 AM, FX fxcoud...@gmail.com wrote:
Use libbacktrace (instead of our own unwind-based code) to display backtraces
from libgfortran upon error or user request.
1. In toplevel Makefile.def, make libgfortran depend on libbacktrace (needs
global reviewer approval)
On Fri, Aug 14, 2015 at 03:14:10PM +0200, Richard Biener wrote:
On Fri, Aug 14, 2015 at 1:20 PM, Marek Polacek pola...@redhat.com wrote:
As outlined in the PR, this fixes one ICE. The code in question here
tries to determine whether OP can be derived as non-NULL. In case the
function has
On Thu, Aug 13, 2015 at 03:48:22PM +0100, Matthew Wahab wrote:
On 12/08/15 22:26, Joseph Myers wrote:
On Tue, 11 Aug 2015, Matthew Wahab wrote:
PR target/67143
* gcc.target/aarch64/pr67143.c: New
What's architecture-specific about this test? That is, why doesn't it
just go in
Tests for the code generated by the Aarch64 backends for the __sync and
__atomic builtins assume that they are implemented using sequences based
on load-exclusive and store-exclusive instructions. ARMv8.1 introduces
atomic instructions which can be used to implement __sync and __atomic
builtins.
On Tue, Jul 28, 2015 at 11:36 AM, Bin Cheng bin.ch...@arm.com wrote:
Hi,
Loop niter computes inaccurate bound information for different loops. This
patch is to improve it by using loop initial condition in
determine_value_range. Generally, loop niter is computed by subtracting
start var
On Fri, Aug 14, 2015 at 3:04 AM, Mikhail Maltsev malts...@gmail.com wrote:
The second part removes all global state accesses (i.e. accesses to cfun and
it's members) from dominance.c. This requires to change lots of code, but I
hope
that this is a step in right direction (if my understanding
On Tue, Jul 28, 2015 at 11:38 AM, Bin Cheng bin.ch...@arm.com wrote:
Hi,
For now, SCEV may compute iv base in the form of (signed T)((unsigned
T)base + step)). This complicates other optimizations/analysis depending
on SCEV because it's hard to dive into type conversions. For many cases,
Use libbacktrace (instead of our own unwind-based code) to display backtraces
from libgfortran upon error or user request.
1. In toplevel Makefile.def, make libgfortran depend on libbacktrace (needs
global reviewer approval)
2. In gcc/fortran/config-lang.in, add libbacktrace to target_libs
Hi,
I spotted that these are missing from the is_neon_type attribute:
neon_fp_abs_s, neon_fp_abs_s_q, neon_fp_abs_d, neon_fp_abs_d_q,
neon_fp_neg_s, neon_fp_neg_s_q, neon_fp_neg_d, neon_fp_neg_d_q,
neon_fp_to_int_d, neon_fp_to_int_d_q,
neon_int_to_fp_d,
On 14/08/15 08:43, Richard Biener wrote:
So what about removing classpath from the repository? We still
retain basic language support via java/ javax/ and gnu/ that way
I believe.
I don't think we do.
Andrew.
Date: Fri, 14 Aug 2015 09:31:32 +0200
Subject: Re: [PATCH] [graphite] Constrain only on INTEGER_TYPE
From: richard.guent...@gmail.com
To: hiradi...@msn.com
CC: tob...@grosser.es; gcc-patches@gcc.gnu.org; s@samsung.com;
seb...@gmail.com
On
Use libbacktrace (instead of our own unwind-based code) to display
backtraces from libgfortran
upon error or user request.
1. In toplevel Makefile.def, make libgfortran depend on libbacktrace (needs
global reviewer
approval)
2. In gcc/fortran/config-lang.in, add libbacktrace to
Date: Fri, 14 Aug 2015 11:47:05 +0200
Subject: Re: [PATCH] [graphite] Constrain only on INTEGER_TYPE
From: richard.guent...@gmail.com
To: hiradi...@msn.com
CC: tob...@grosser.es; gcc-patches@gcc.gnu.org; s@samsung.com;
seb...@gmail.com
On
On 08/14/2015 07:29 AM, Marek Polacek wrote:
On Fri, Aug 14, 2015 at 03:14:10PM +0200, Richard Biener wrote:
On Fri, Aug 14, 2015 at 1:20 PM, Marek Polacek pola...@redhat.com wrote:
As outlined in the PR, this fixes one ICE. The code in question here
tries to determine whether OP can be
On 25 January 2015 at 22:33, Christophe Lyon christophe.l...@linaro.org wrote:
On 17 December 2014 at 18:02, Tejas Belagod tejas.bela...@arm.com wrote:
On 17/12/14 16:46, Marcus Shawcroft wrote:
On 17 December 2014 at 15:15, Tejas Belagod tejas.bela...@arm.com wrote:
It isn;t clear to me how
On August 14, 2015 4:31:23 PM GMT+02:00, Aditya K hiradi...@msn.com wrote:
Date: Fri, 14 Aug 2015 11:47:05 +0200
Subject: Re: [PATCH] [graphite] Constrain only on INTEGER_TYPE
From: richard.guent...@gmail.com
To: hiradi...@msn.com
CC:
This patch fixes PR 47571 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571)
by providing an adequate configure check (with AC_LINK_IFELSE) for weakref
(which we use in intrinsics/system_clock.c).
Tested by building libgfortran on x86_64-pc-linux-gnu, where SUPPORTS_WEAKREF
gets defined to 1
Thanks Uros.
Will it be fine for you if I split core2.md to instruction reservation
definition for core2 (old core2.md got old cpu core2) and new
nehalem.md (my changes for core2.md but for cpu nehalem only)?
Thanks.
Yuri.
2015-08-14 13:20 GMT+03:00 Uros Bizjak ubiz...@gmail.com:
On Fri, Aug
Subject: RE: [PATCH] [graphite] Constrain only on INTEGER_TYPE
From: richard.guent...@gmail.com
Date: Fri, 14 Aug 2015 16:47:41 +0200
To: hiradi...@msn.com
CC: tob...@grosser.es; gcc-patches@gcc.gnu.org; s@samsung.com;
seb...@gmail.com
On
On 14/08/15 14:36, Matthew Wahab wrote:
Tests for the code generated by the Aarch64 backends for the __sync and
__atomic builtins assume that they are implemented using sequences based
on load-exclusive and store-exclusive instructions. ARMv8.1 introduces
atomic instructions which can be used to
On Fri, Aug 14, 2015 at 08:50:22AM -0600, Jeff Law wrote:
On 08/14/2015 07:29 AM, Marek Polacek wrote:
On Fri, Aug 14, 2015 at 03:14:10PM +0200, Richard Biener wrote:
On Fri, Aug 14, 2015 at 1:20 PM, Marek Polacek pola...@redhat.com wrote:
As outlined in the PR, this fixes one ICE. The code
This is the second fix for this PR. Here the problem was that we were
accessing arguments that don't exist. We first need to check that the
call stmt has sufficient number of arguments. For details see the PR.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2015-08-14 Marek Polacek
There are 3 patches left in the basic IEEE 128-bit floating point support for
the compiler. I will submit these at the same time. They are split to make the
review process similar. Patch #5 and #6 are indpendent of each other and can
be applied in either order. Patch #7 assumes that patches 1-6
There are 3 patches left in the basic IEEE 128-bit floating point support for
the compiler. I will submit these at the same time. They are split to make the
review process similar. Patch #5 and #6 are indpendent of each other and can
be applied in either order. Patch #7 assumes that patches 1-6
On 08/14/2015 09:32 AM, Marek Polacek wrote:
On Fri, Aug 14, 2015 at 08:50:22AM -0600, Jeff Law wrote:
On 08/14/2015 07:29 AM, Marek Polacek wrote:
On Fri, Aug 14, 2015 at 03:14:10PM +0200, Richard Biener wrote:
On Fri, Aug 14, 2015 at 1:20 PM, Marek Polacek pola...@redhat.com wrote:
As
On 08/13/2015 10:51 AM, Jonathan Wakely wrote:
On 13/08/15 10:37 -0400, Ed Smith-Rowland wrote:
Greetings,
Now that most systems have uchar.h for conversion between char16_t*
and char32_t* to multibyte (analogue of wchar.h and cwchar) i think
we should check off this last little crumb of
While looking into something else I noticed this.
Applying to trunk.
2015-08-14 Marek Polacek pola...@redhat.com
* tree-core.h (tree_base): Fix typo.
diff --git gcc/tree-core.h gcc/tree-core.h
index 560ce4b..64d1fe4 100644
--- gcc/tree-core.h
+++ gcc/tree-core.h
@@ -1088,7 +1088,7 @@
On Fri, Aug 14, 2015 at 09:33:46AM -0600, Jeff Law wrote:
Ok, I'll investigate and come back to y'all when/if I find something.
Thanks. I still regret using the TREE_TYPE as a way to chain elements in
the free list:( I didn't want to add another pointer field...
It's actually plain to see
On 08/14/2015 11:40 AM, Jiong Wang wrote:
* Figuring out whether the shift source is coming from sign extension
by checking SSA_NAME_DEF_STMT instead of deducing from tree range
info. I fell checking the gimple statement is more reliable and
straigtforward.
I suspect it'll
On 08/14/2015 01:58 PM, Marek Polacek wrote:
On Fri, Aug 14, 2015 at 09:33:46AM -0600, Jeff Law wrote:
Ok, I'll investigate and come back to y'all when/if I find something.
Thanks. I still regret using the TREE_TYPE as a way to chain elements in
the free list:( I didn't want to add another
Hi Jason,
Are you going to be able to review this patch sometime soon?
Thanks,
Catherine
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Moore, Catherine
Sent: Thursday, July 30, 2015 4:15 PM
To: gcc-patches@gcc.gnu.org
Cc:
Hi Matthew,
-Original Message-
From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
Sent: Wednesday, July 22, 2015 6:19 PM
Subject: [PATCH, MIPS] Compact branch support for MIPS32R6/MIPS64R6
This patch looks really good. I have a couple of questions and a couple of
nits that
Hi,
There are some useless variables, class Gt, and struct CompLast in
testsuite/25_algorithms/*
This patch is to remove those useless variables, class Gt and struct
CompLast.
The patch is attached.
commit d13ea592473ccbd29276908782877156e669b28a
Author: Kai Zhao loversz...@gmail.com
Date:
On Aug 11, 2015, Patrick Marlier patrick.marl...@gmail.com wrote:
On Mon, Aug 10, 2015 at 5:14 PM, Jeff Law l...@redhat.com wrote:
On 08/10/2015 02:23 AM, James Greenhalgh wrote:
For what it is worth, I bootstrapped and tested the consolidated patch
on arm-none-linux-gnueabihf and
On Fri, 2015-08-14 at 12:25 -0600, Jeff Law wrote:
On 08/14/2015 02:02 AM, Richard Biener wrote:
On Fri, Aug 14, 2015 at 3:04 AM, Mikhail Maltsev malts...@gmail.com wrote:
The second part removes all global state accesses (i.e. accesses to cfun
and
it's members) from dominance.c. This
Evidently I attached the wrong file for patch #6.
2015-08-13 Michael Meissner meiss...@linux.vnet.ibm.com
* config/rs6000/rs6000-protos.h (rs6000_expand_float128_convert):
Add declaration.
* config/rs6000/rs6000.c (rs6000_emit_le_vsx_store): Fix a
comment.
On 08/14/2015 01:54 AM, Richard Biener wrote:
On Fri, Aug 14, 2015 at 2:55 AM, Mikhail Maltsev malts...@gmail.com wrote:
Hi all.
These two patches are refactoring of dominator-related code.
The comment in dominance.c says: We work in a poor-mans object oriented
fashion, and carry an instance
This patch teaches the c and c++ front ends not to add a 'copy' clause
for each non-loop OpenACC reduction. Without this patch, this construct
would error with a duplicate mapping for 'sum':
#pragma acc parallel num_gangs (10) copy (sum) reduction (+:sum)
While the intent behind adding a
This patch by Chris Manghane fixes the Go frontend to issue an error
for invalid receiver types, rather than crashing. This fixes
https://golang.org/issue/11557 . Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
Jeff Law writes:
On 04/29/2015 03:36 PM, Jiong Wang wrote:
Jeff Law writes:
On 04/27/2015 02:21 PM, Jiong Wang wrote:
Jeff,
Sorry, I can't understand the meaning of overlap between t_low and
low,
assume right in right value means the opposite of left not
correct.
On 14 August 2015 at 17:01, Ed Smith-Rowland wrote:
OK.
This tested clean because it didn't install the headers.
So Jonathan. I am going to throw in the sponge on the configury.
:-)
Could you have a look and carry this over the finish line?
Will do, getting that stuff right is always a
On August 14, 2015 5:27:15 PM GMT+02:00, Marek Polacek pola...@redhat.com
wrote:
This is the second fix for this PR. Here the problem was that we were
accessing arguments that don't exist. We first need to check that the
call stmt has sufficient number of arguments. For details see the PR.
On 08/13/2015 09:06 PM, Bin.Cheng wrote:
Thanks for the comment.
IIUC, the niter information in struct tree_niter_desc means the number
of executions of the latch of the loop, so it's 254, rather than 255.
And same the bound information. Of course, statements in the loop
body could execute
On Fri, 14 Aug 2015, Thomas Schwinge wrote:
This function »generate[s] a C source file containing a constructor call
to GOMP_set_offload_targets [...], and adds that as an infile«. This
basically works ;-) -- but really only for C source code, and for C++
and Fortran it fails if there are
On 08/13/2015 06:55 PM, Mikhail Maltsev wrote:
Hi all.
These two patches are refactoring of dominator-related code.
The comment in dominance.c says: We work in a poor-mans object oriented
fashion, and carry an instance of this structure through all our 'methods'. So,
the first patch converts
On 08/14/2015 02:17 AM, Richard Biener wrote:
On Tue, Jul 28, 2015 at 11:36 AM, Bin Cheng bin.ch...@arm.com wrote:
Hi,
Loop niter computes inaccurate bound information for different loops. This
patch is to improve it by using loop initial condition in
determine_value_range. Generally, loop
I meant to say splitting the patches was meant to make the reviewing simpler,
not similar.
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
On 08/14/2015 02:02 AM, Richard Biener wrote:
On Fri, Aug 14, 2015 at 3:04 AM, Mikhail Maltsev malts...@gmail.com wrote:
The second part removes all global state accesses (i.e. accesses to cfun and
it's members) from dominance.c. This requires to change lots of code, but I hope
that this is a
There are plenty of targets that do not require -fPIC because they always
generate position independent code, but none of them feels the need to
complain with the user about an unnecessary but perfectly valid option,
on each and every .c-.o rule, and without a way to disable it.
Adding insult to
On Fri, 14 Aug 2015, Thomas Schwinge wrote:
Can you suggest off-hand where you'd expect this option filtering to
happen? Should this be during specs parsing in the driver; something
like adding a lang_mask to gcc/gcc.c:struct switchstr, and then in
gcc/gcc.c:give_switch ignore any switches
-Original Message-
From: Robert Suchanek [mailto:robert.sucha...@imgtec.com]
Sent: Friday, August 14, 2015 8:01 AM
To: Mike Stump; Richard Sandiford
Cc: Moore, Catherine; Matthew Fortune; gcc-patches@gcc.gnu.org
Subject: RE: [PATCH][MIPS] Fix register renaming in the interrupt
On Thu, Aug 13, 2015 at 07:56:47PM +0300, Mikhail Maltsev wrote:
On 08/12/2015 11:36 PM, Trevor Saunders wrote:
In many places gcc puts classes in the anon namespace so the compiler can
tell
they do not get inheritted from to enable better devirtualization.
C++ does not allow class
On Fri, Aug 14, 2015 at 02:32:20PM -0600, Jeff Law wrote:
On 08/14/2015 01:58 PM, Marek Polacek wrote:
On Fri, Aug 14, 2015 at 09:33:46AM -0600, Jeff Law wrote:
Ok, I'll investigate and come back to y'all when/if I find something.
Thanks. I still regret using the TREE_TYPE as a way to chain
Hi!
On Fri, 14 Aug 2015 16:56:25 +, Joseph Myers jos...@codesourcery.com
wrote:
On Fri, 14 Aug 2015, Thomas Schwinge wrote:
This function »generate[s] a C source file containing a constructor call
to GOMP_set_offload_targets [...], and adds that as an infile«. This
basically works
Jeff Law writes:
On 08/14/2015 11:40 AM, Jiong Wang wrote:
* Figuring out whether the shift source is coming from sign extension
by checking SSA_NAME_DEF_STMT instead of deducing from tree range
info. I fell checking the gimple statement is more reliable and
On 08/14/2015 10:54 AM, Richard Biener wrote:
Putting in m_fn looks backwards to me - it looks like we only need to remember
the entry and exit BBs and the number of blocks.
Fixed.
In fact initializing
dom_info from that would allow it to work on SESE regions as well?
Can't tell for sure.
There are 3 patches left in the basic IEEE 128-bit floating point support for
the compiler. I will submit these at the same time. They are split to make the
review process similar. Patch #5 and #6 are indpendent of each other and can
be applied in either order. Patch #7 assumes that patches 1-6
Hi!
On Fri, 14 Aug 2015 12:56:00 +0200, I wrote:
(Can a Fortran person please comment on this: as it's nontrivial to write
to stderr, let's just write to stdout followed by a flush, which does
have the same ordering effect -- OK?)
OK, turns out it's actually not very difficult to write to
On Fri, Aug 14, 2015 at 5:09 PM, Yuri Rumyantsev ysrum...@gmail.com wrote:
Will it be fine for you if I split core2.md to instruction reservation
definition for core2 (old core2.md got old cpu core2) and new
nehalem.md (my changes for core2.md but for cpu nehalem only)?
I'm looking at [1],
OK.
This tested clean because it didn't install the headers.
So Jonathan. I am going to throw in the sponge on the configury.
Could you have a look and carry this over the finish line?
Ed
Hi!
Approved long ago:
On Fri, 05 Dec 2014 16:38:32 -0700, Jeff Law l...@redhat.com wrote:
On 11/14/14 11:17, Bernd Schmidt wrote:
The situation with debugging on ptx is a little strange - it allows
.file and .loc directives for line numbers, and it provides a way to
define dwarf2 debug
Hi!
(Can a Fortran person please comment on this: as it's nontrivial to write
to stderr, let's just write to stdout followed by a flush, which does
have the same ordering effect -- OK?)
On Thu, 30 Apr 2015 14:47:03 +0200, I wrote:
Here is a patch, prepared by Jim Norris, to fix dg-shouldfail
And another one. Committed to trunk.
commit 6c9731439357e2a385b16ad6521c05776ecf0562
Author: Jonathan Wakely jwak...@redhat.com
Date: Thu Aug 13 16:11:43 2015 +0100
* include/experimental/array: Add feature-test macro.
* testsuite/experimental/array/neg.cc: Update dg-error.
diff
On 30/07/15 11:00 +0100, Jonathan Wakely wrote:
When I fixed any's copying of non-trivial types I broke the
self-assignment case. This adds an explicit check for it.
Thanks to Axel Menzel for noticing the bug.
Similar checks in move-assign and swap members, and a better test.
Tested
Hi,
The patch below disables generation of the branch likely instructions for -Os
but only for generic architecture. The branch likely may result in some
code size reduction but the cost of running the code on R6 core is significant.
Disabling this for generic architecture would therefore be
Hi,
You also need to do the same thing for TARGET_HARD_REGNO_SCRATCH_OK,
to stop peephole2 from using unsaved registers as scratch registers.
I should dig out my patches to clean up this interface. It's just
too brittle to have two macros that say what registers can be used
after
Hi All,
Here is patch which contains
(1) modifying of core2.md to conform Haswell pipeline and adding of
missed instruction reservation for instructions with vector operands.
(2) increase reassociation width for float-point operations for
Haswell family and 64-bit target, this allows to get +10%
Cary,
Thank you for your answer!
On 08/13/2015 09:01 PM, Cary Coutant wrote:
I don't think you really need a new TAG here -- DW_TAG_constant could
just as easily take DW_AT_GNU_numerator and DW_AT_GNU_denominator as
an alternative to DW_AT_const_value.
Good idea! I updated the patch
Hi all,
I'm seeing these warnings when building arm.c:
warning: format ‘%lld’ expects argument of type ‘long long int’, but argument 5
has type ‘long int’ [-Wformat=]
These appear in the bounds_check function when it tries to print out
HOST_WIDE_INTs using the %lld format.
I believe the right
On Fri, Aug 14, 2015 at 11:44 AM, Yuri Rumyantsev ysrum...@gmail.com wrote:
Hi All,
Here is patch which contains
(1) modifying of core2.md to conform Haswell pipeline and adding of
missed instruction reservation for instructions with vector operands.
(2) increase reassociation width for
On 14/08/15 10:23, James Greenhalgh wrote:
Hi,
I spotted that these are missing from the is_neon_type attribute:
neon_fp_abs_s, neon_fp_abs_s_q, neon_fp_abs_d, neon_fp_abs_d_q,
neon_fp_neg_s, neon_fp_neg_s_q, neon_fp_neg_d, neon_fp_neg_d_q,
neon_fp_to_int_d,
As mentioned at
https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00251.html
some assemblers don't support -mcpu=thunderx, so the dg-do assemble test will
FAIL.
Mark this test as compile-only as assembling it is not essential to the
functionality it tests.
Committed as obvious with r226886.
On Fri, Aug 14, 2015 at 11:25 AM, Aditya K hiradi...@msn.com wrote:
Date: Fri, 14 Aug 2015 09:31:32 +0200
Subject: Re: [PATCH] [graphite] Constrain only on INTEGER_TYPE
From: richard.guent...@gmail.com
To: hiradi...@msn.com
CC: tob...@grosser.es;
Hi!
Assuming that the overall approach (my option a) is fine, this is now
primarily a question about how to teach the driver to the right thing.
(Joseph CCed as driver reviewer.)
On Wed, 5 Aug 2015 18:09:04 +0300, Ilya Verbin iver...@gmail.com wrote:
On Wed, Aug 05, 2015 at 10:40:44 +0200,
Hi all,
Some of the new target attribute tests fail when testing with an explicit -fPIC:
NA-FAIL: gcc.target/aarch64/target_attr_14.c scan-assembler-not bl.*bar
NA-FAIL: gcc.target/aarch64/target_attr_5.c scan-assembler-not bl.*bar
NA-FAIL:
On Fri, Aug 14, 2015 at 1:20 PM, Marek Polacek pola...@redhat.com wrote:
As outlined in the PR, this fixes one ICE. The code in question here
tries to determine whether OP can be derived as non-NULL. In case the
function has the nonnull attribute that applies to all the arguments,
we want to
86 matches
Mail list logo
