On Thu, Aug 13, 2015 at 7:56 PM, Aditya K 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;
>> seb.
On Thu, Aug 13, 2015 at 7:47 PM, Mike Stump wrote:
> On Aug 13, 2015, at 3:05 AM, Richard Biener
> wrote:
>> Ok, then guard the << >> with __GCC__ and do the expensive bit stuff
>> otherwise. Just to cater for other host compilers doing sth unsensibly
>> implementation defined.
>
> Ick. The gu
On Thu, Aug 13, 2015 at 11:31 PM, Jeff Law wrote:
> On 08/13/2015 04:00 AM, Richard Biener wrote:
>>
>> On Wed, Aug 12, 2015 at 6:47 PM, Jeff Law wrote:
>>>
>>> On 08/12/2015 10:24 AM, Ian Lance Taylor wrote:
On Wed, Aug 12, 2015 at 9:21 AM, Tom Tromey wrote:
>
>
> Jef
On Fri, Aug 14, 2015 at 2:55 AM, 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,
> th
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 nonz
On Fri, Aug 14, 2015 at 3:04 AM, Mikhail Maltsev 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 of ongoing
> re
On Tue, Jul 28, 2015 at 11:36 AM, Bin Cheng 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 from end var in
On Tue, Jul 28, 2015 at 11:38 AM, Bin Cheng 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,
> such type con
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, neon_int
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 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,
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%
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.
2015-
On Fri, Aug 14, 2015 at 11:25 AM, Aditya K 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; gcc-pat
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 wrote:
> On Wed, Aug 05, 2015 at 10:40:44 +0200, Richard Biener wrot
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 according
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: gcc.target/aarch64/target_att
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 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 float-point oper
Hi!
Approved long ago:
On Fri, 05 Dec 2014 16:38:32 -0700, Jeff Law 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 sections -
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 us
On Fri, Aug 14, 2015 at 1:56 PM, Thomas Schwinge
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 stderr, with gfortran
> (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 subro
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 poin
And another one. Committed to trunk.
commit 6c9731439357e2a385b16ad6521c05776ecf0562
Author: Jonathan Wakely
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 --git a/libstdc++-v3/i
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 powerpc64
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
>
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 des
On Fri, Aug 14, 2015 at 1:20 PM, Marek Polacek 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 see whether OP
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 libback
2015-08-14 11:47 GMT+02:00 Thomas Schwinge :
> On Wed, 5 Aug 2015 18:09:04 +0300, Ilya Verbin wrote:
>> > > @@ -1095,6 +1092,8 @@ GOMP_target (int device, void (*fn) (void *),
>> > > const void *unused,
>> > > return gomp_target_fallback (fn, hostaddrs);
>> > >
>> > >void *fn_addr = gomp
On Fri, Aug 14, 2015 at 03:14:10PM +0200, Richard Biener wrote:
> On Fri, Aug 14, 2015 at 1:20 PM, Marek Polacek 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
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 i
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. T
On Fri, Aug 14, 2015 at 1:32 AM, FX 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)
This change (an
>> 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 libbackt
> 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 August 14, 2015 4:31:23 PM GMT+02:00, Aditya K 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: tob...@grosser.es; g
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 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
On 25 January 2015 at 22:33, Christophe Lyon wrote:
> On 17 December 2014 at 18:02, Tejas Belagod wrote:
>> On 17/12/14 16:46, Marcus Shawcroft wrote:
>>>
>>> On 17 December 2014 at 15:15, Tejas Belagod wrote:
>>>
> It isn;t clear to me how far through the various BE patches we need to
>
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 :
> On Fri, Aug 14, 2015 at 11:44
> 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 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 wrote:
> >>>As outlined in the PR, this fixes one ICE. The code in questio
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
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 wrote:
As outlined in the PR, thi
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 C++1
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 ha
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 ha
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 ha
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 s
On Fri, Aug 14, 2015 at 5:09 PM, Yuri Rumyantsev 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], where targets from
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
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
Evidently I attached the wrong file for patch #6.
2015-08-13 Michael Meissner
* config/rs6000/rs6000-protos.h (rs6000_expand_float128_convert):
Add declaration.
* config/rs6000/rs6000.c (rs6000_emit_le_vsx_store): Fix a
comment.
(rs6000_cannot_change_mo
On August 14, 2015 5:27:15 PM GMT+02:00, Marek Polacek
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.
>
>Bootstrapped/reg
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 alway
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 'copy'
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 a
On 08/14/2015 01:54 AM, Richard Biener wrote:
On Fri, Aug 14, 2015 at 2:55 AM, 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
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 oppo
While looking into something else I noticed this.
Applying to trunk.
2015-08-14 Marek Polacek
* 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 @@ struct GTY(()) tre
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:02 AM, Richard Biener wrote:
On Fri, Aug 14, 2015 at 3:04 AM, Mikhail Maltsev 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 direct
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 boun
On 08/14/2015 02:17 AM, Richard Biener wrote:
On Tue, Jul 28, 2015 at 11:36 AM, Bin Cheng 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
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
Date: Sat Aug 15 02:23:14 2
On Aug 11, 2015, Patrick Marlier wrote:
> On Mon, Aug 10, 2015 at 5:14 PM, Jeff Law 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 aarch64-none-linux-gnu with trunk at
>>> r
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
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 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 wrote:
> >> The second part removes all global state accesses (i.e. accesses to cfun
> >> and
> >> it's members) from dominance.c. This requires
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 also
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 t
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 po
> -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 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 t
Hi!
On Fri, 14 Aug 2015 16:56:25 +, Joseph Myers
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 ;-) -- but rea
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
>> str
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 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, 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 switche
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 sur
On 08/14/2015 11:02 AM, Richard Biener wrote:
> So the last time I did similar refactoring I wondered if we can somehow avoid
> the "noise" in non-IPA passes. Ideas I came up with are
>
> a) Inherit gimple/rtl pass classes from a class which is initialized with
> the
> function the pass
This patch resets the lambda scope based sequence numbering used to assign
numbers to lambdas during parsing when we pop a module scope. This resets
the numbering for subsequent modules imported during LIPO compilation.
It also renames cp_clear_deferred_fns to reset_parsing_state, as that
routine
On August 14, 2015 8:20:18 PM GMT+02:00, Jeff Law wrote:
>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 o
89 matches
Mail list logo
