Hi Michael,
-Original Message-
From: Michael Eager [mailto:ea...@eagerm.com]
Sent: Thursday, 14 March 2013 1:34 am
To: David Holsgrove
Cc: gcc-patches@gcc.gnu.org; Edgar Iglesias; John Williams; Vinod Kathail;
Vidhumouli Hunsigida; Nagaraju Mekala; Tom Shui
Subject: Re: [Patch,
On 8 March 2013 09:32, Jakub Jelinek ja...@redhat.com wrote:
On Fri, Mar 08, 2013 at 09:04:19AM +, Marcus Shawcroft wrote:
On 07/03/13 16:45, Jakub Jelinek wrote:
On Thu, Mar 07, 2013 at 08:29:06AM -0800, Andrew Pinski wrote:
On Thu, Mar 7, 2013 at 3:15 AM, Jakub Jelinek ja...@redhat.com
On Wed, 13 Mar 2013, Diego Novillo wrote:
This patch adds an initial implementation for a new helper type for
generating GIMPLE statements.
The type is called gimple_builder. There are two main variants:
gimple_builder_normal and gimple_builder_ssa. The difference between
the two is the
On Wed, 13 Mar 2013, Xinliang David Li wrote:
Nice -- GCC LOC will be significantly reduced with these interfaces.
Using 'add' as interface name can be confusing -- new, or new_stmt, or
new_assignment/new_call etc might be better -- but we can delay the
bike shedding later.
Note that we
On Thu, 14 Mar 2013, Richard Biener wrote:
On Wed, 13 Mar 2013, Diego Novillo wrote:
This patch adds an initial implementation for a new helper type for
generating GIMPLE statements.
The type is called gimple_builder. There are two main variants:
gimple_builder_normal and
On Wed, 13 Mar 2013, Jakub Jelinek wrote:
Hi!
This patch is an attempt to warn about undefined behavior in simple loops
with known constant number of latch executions, which probably is the most
common case where gcc 4.8 started to turn finite loops involving undefined
behavior before
On 13/02/13 23:35, Vladimir Makarov wrote:
On 13-02-07 2:11 PM, Tom de Vries wrote:
Vladimir,
On 25/01/13 16:36, Vladimir Makarov wrote:
On 01/25/2013 08:05 AM, Tom de Vries wrote:
Vladimir,
this patch adds analysis of register usage of functions for usage by IRA.
The patch:
- adds
Hi!
Usually I bootstrap/regtest without graphite, so haven't seen these 3 test
FAILs with my recent patch. Fixed thusly, tested on x86_64-linux, committed
to trunk as obvious.
2013-03-14 Jakub Jelinek ja...@redhat.com
PR tree-optimization/53265
* gcc.dg/graphite/scop-3.c
It still references memcpy in -Wsizeof-pointer-memaccess section. Let me
suggest instead:
To fix, properly pass the size of cleared memory as the last argument:
either dereference the pointer argument to sizeof when clearing *one
pointed-to element*, or in addition to that multiply
Hi,
On Thu, 14 Mar 2013, Richard Biener wrote:
That said - can we please pass in the type of the operation (and thus
the newly created result temporary) _explicitely_ please? Thus
I'm mostly with you (not adding gimple_builder_ssa, but improving the
existing interface), except for this
On Thu, Mar 14, 2013 at 03:07:36PM +0400, Alexander Monakov wrote:
It still references memcpy in -Wsizeof-pointer-memaccess section. Let me
suggest instead:
To fix, properly pass the size of cleared memory as the last argument:
either dereference the pointer argument to sizeof
Hi,
On Wed, 13 Mar 2013, Diego Novillo wrote:
To use the builder:
1- Declare an instance 'gb' of gimple_builder_normal or
gimple_builder_ssa. E.g., gimple_builder_ssa gb;
2- Use gb.add_* to add a new statement to it. This
returns an SSA name or VAR_DECL with the value of the
Hi,
Attached is a patch that implements the framework necessary for implementing
NEON Intrinsics' builtins in Tree/Gimple rather than RTL. For this it uses the
target hook TARGET_FOLD_BUILTIN and folds all the builtins for NEON Intrinsics
into equivalent trees. This framework is accompanied by
Hi,
Attached is a patch that implements the framework necessary for implementing
NEON Intrinsics' builtins in Tree/Gimple rather than RTL. For this it uses the
target hook TARGET_FOLD_BUILTIN and folds all the builtins for NEON Intrinsics
into equivalent trees. This framework is accompanied by
Removing the DECL_ARTIFICIAL check meant warning about TARGET_EXPR
temporaries, which we don't want; instead, let's check for 'this' directly.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 2139bd24c219d1b665738d2b630e90dd25cc9cd1
Author: Jason Merrill ja...@redhat.com
Date: Thu Mar 14
This extracts pieces from the already posted patch series that are
most worthwhile and applicable for backporting to both 4.8 and 4.7.
It also re-implements the limiting of the maximum number of memory
references to consider for LIMs dependence analysis. This limiting
is now done per loop-nest
Hi,
As it stands, potential_constant_expression_1 does not handle
REDUC_PLUS_EXPR trees.
For some cross-lane add-reduce neon intrinsics we would like to
use the TARGET_FOLD_BUILTIN hook to fold these calls to a
REDUC_PLUS_EXPR. As an example, see Tejas Belagod's patch at:
Hello!
From: Andi Kleen a...@linux.intel.com
+Returns _XBEGIN_STARTED when the transaction
+started successfully (not this is not 0, so the constant has to be
not this is not 0? Or note?
note
Thanks. Will fix before comitting.
I think (somewhere else) we agreed to only
On Wed, 13 Mar 2013, Diego Novillo wrote:
This patch adds an initial implementation for a new helper type for
generating GIMPLE statements.
I hope you'll forgive the naive newbie question: why is the gimplifier
used so little outside of the gimplification pass? For instance, after a
call to
On 03/14/2013 05:34 AM, Tom de Vries wrote:
On 13/02/13 23:35, Vladimir Makarov wrote:
Sorry for the delay with the answer. I was and am quite busy with other
more urgent things. I'll work on it when I have more free time. In any
case, I'll do it before stage1 to have your patch ready.
We couldn't generate EXTR for AArch64 ... until now!
This patch includes the pattern and a test.
Full regression testing for Linux and bare-metal passed.
OK for trunk stage-1?
Thanks,
Ian
2013-03-14 Ian Bolton ian.bol...@arm.com
gcc/
* config/aarch64/aarch64.md (*extrmode5_insn):
We couldn't generate ROR (preferred alias of EXTR when both source
registers are the same) for AArch64, when rotating by an immediate,
... until now!
This patch includes the pattern and a test.
Full regression testing for Linux and bare-metal passed.
OK for trunk stage-1?
Thanks,
Ian
On 03/14/2013 01:07 AM, David Holsgrove wrote:
Hi Michael,
-Original Message-
From: Michael Eager [mailto:ea...@eagerm.com]
Sent: Thursday, 14 March 2013 1:34 am
To: David Holsgrove
Cc: gcc-patches@gcc.gnu.org; Edgar Iglesias; John Williams; Vinod Kathail;
Vidhumouli Hunsigida;
We couldn't generate SBC for AArch64 ... until now!
This really patch includes the main pattern, a zero_extend form
of it and a test.
Full regression testing for Linux and bare-metal passed.
OK for trunk stage-1?
Thanks,
Ian
2013-03-14 Ian Bolton ian.bol...@arm.com
gcc/
*
I am with you for simple cases where straightline code is generated.
Helper class will be very useful when control flow manipulation is
involved. People can simply just write 'straight line like code'
using gimple_label, goto_label etc without worrying about how split
blocks and create new cfg
On Thu, Mar 14, 2013 at 7:55 AM, Marc Glisse marc.gli...@inria.fr wrote:
On Wed, 13 Mar 2013, Diego Novillo wrote:
This patch adds an initial implementation for a new helper type for
generating GIMPLE statements.
I hope you'll forgive the naive newbie question: why is the gimplifier used
Since Solaris 11.1, libgo compilation was failing with
sysinfo.go:676:267: error: use of undefined type '_ns_postinit_s'
sysinfo.go had
type _netstack struct { netstack_u struct { nu_modules [20+1]*byte; };
netstack_m_state [20+1]uint32; netstack_lock _kmutex_t; netstack_next
*_netstack;
Xinliang David Li davi...@google.com wrote:
I am with you for simple cases where straightline code is generated.
Helper class will be very useful when control flow manipulation is
involved. People can simply just write 'straight line like code'
using gimple_label, goto_label etc without
Am 14.03.2013 16:37, schrieb Marcus Shawcroft:
On 8 March 2013 09:32, Jakub Jelinek ja...@redhat.com wrote:
On Fri, Mar 08, 2013 at 09:04:19AM +, Marcus Shawcroft wrote:
On 07/03/13 16:45, Jakub Jelinek wrote:
On Thu, Mar 07, 2013 at 08:29:06AM -0800, Andrew Pinski wrote:
On Thu, Mar 7,
On Thu, Mar 14, 2013 at 9:53 AM, Rainer Orth wrote:
I found that this patch
2012-12-04 Ian Lance Taylor
* godump.c (find_dummy_types): Output a dummy type if we couldn't
output the real type.
fixes the problem, so I'd like to backport it.
i386-pc-solaris2.11 bootstrap
On Fri, Mar 15, 2013 at 02:07:12AM +0800, Matthias Klose wrote:
sorry, didn't comment about this patch because it didn't seem to affect
multiarch. However this patch assumes that every system does have at least a
*/lib64 symlink, if it doesn't have a */lib64 directory. I think that is a
Tom 2013-02-27 Tom Tromey tro...@redhat.com
Tom* libsupc++/unwind-cxx.h: Include sys/sdt.h if detected.
Tom(PROBE2): New macro.
Tom* libsupc++/eh_throw.cc (__cxa_throw, __cxa_rethrow): Add probe.
Tom* libsupc++/eh_catch.cc (__cxa_begin_catch): Add probe.
Tom* configure.ac:
On Thu, Mar 14, 2013 at 10:54 AM, Richard Biener rguent...@suse.de wrote:
Xinliang David Li davi...@google.com wrote:
I am with you for simple cases where straightline code is generated.
Helper class will be very useful when control flow manipulation is
involved. People can simply just write
On 03/14/2013 09:48 AM, James Greenhalgh wrote:
Is this OK to commit to 4.9 when stage 1 opens up?
Yes, but please add the other new tree codes as well.
Jason
2013-02-20 Seth LaForge set...@google.com
Backport
2012-10-22 Julian Brown jul...@codesourcery.com
* config/arm/arm.h (CANNOT_CHANGE_MODE_CLASS): Avoid subreg'ing
VFP D registers in big-endian mode.
Applied to the 4.7 branch after QEMU-testing for arm-eabi in
On Thu, Mar 14, 2013 at 02:51:30PM -0400, Jason Merrill wrote:
On 03/14/2013 09:48 AM, James Greenhalgh wrote:
Is this OK to commit to 4.9 when stage 1 opens up?
Yes, but please add the other new tree codes as well.
I wonder if it wouldn't be better to fold the target builtins only later on
On Thu, Mar 14, 2013 at 1:55 PM, Jakub Jelinek ja...@redhat.com wrote:
On Thu, Mar 14, 2013 at 02:51:30PM -0400, Jason Merrill wrote:
On 03/14/2013 09:48 AM, James Greenhalgh wrote:
Is this OK to commit to 4.9 when stage 1 opens up?
Yes, but please add the other new tree codes as well.
I
Moore, Catherine catherine_mo...@mentor.com writes:
-Original Message-
From: Richard Sandiford [mailto:rdsandif...@googlemail.com]
Sent: Tuesday, March 05, 2013 4:06 PM
To: Moore, Catherine
Cc: gcc-patches@gcc.gnu.org; Rozycki, Maciej
Subject: Re: FW: [PATCH] [MIPS] microMIPS gcc
Hi Richard,
I updated this patch using your suggestions. I'm having a problem though, that
I'm having trouble nailing. Building libstdc++ for microMIPS is failing trying
to generate dwarf2 CFI info:
_Unwind_Ptr base_of_encoded_value(unsigned char, _Unwind_Context*)
Analyzing compilation unit
On Thu, 14 Mar 2013, Jakub Jelinek wrote:
I wonder if it wouldn't be better to fold the target builtins only later on
(e.g. guard the folding with cfun gimple_in_ssa_p (cfun) (or if we have
any predicate that is set starting with gimplification or so)).
Having all the FEs have to deal with
Moore, Catherine catherine_mo...@mentor.com writes:
Hi Richard,
I updated this patch using your suggestions. I'm having a problem
though, that I'm having trouble nailing. Building libstdc++ for
microMIPS is failing trying to generate dwarf2 CFI info:
_Unwind_Ptr
This fixes a regression. Technically we shouldn't call construct() for
the node, only for the value within it, but I plan to fix that for
4.9, this just restores the previous behaviour when using a type
meeting the C++03 Allocator requirements.
PR libstdc++/56613
*
42 matches
Mail list logo
