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
* include/bits/stl
"Moore, Catherine" 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 base_of_encoded_value(unsigned char, _Unwind
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 my
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
"Moore, Catherine" 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 support:
>>
>>
On Thu, Mar 14, 2013 at 1:55 PM, Jakub Jelinek 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 wonder
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
> 2013-02-20 Seth LaForge
>
> Backport
> 2012-10-22 Julian Brown
> * 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 big-endian mode.
It also fixes a fair n
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
On Thu, Mar 14, 2013 at 10:54 AM, Richard Biener wrote:
> Xinliang David Li 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'
>
Tom> 2013-02-27 Tom Tromey
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: Check for sys/
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
> w
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
Am 14.03.2013 16:37, schrieb Marcus Shawcroft:
> On 8 March 2013 09:32, Jakub Jelinek 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, 201
Xinliang David Li 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 worrying about how sp
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; netst
On Thu, Mar 14, 2013 at 7:55 AM, Marc Glisse 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
> so little ou
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 ed
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
gcc/
* config/aarch64/aarch64.md (
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; Nagaraju
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
2013-03-
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
gcc/
* config/aarch64/aarch64.md (*extr5_insn): New pattern.
(*
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.
Vlad
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
Hello!
> >> >From: Andi Kleen
> >>
> >> >+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 t
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:
http://gcc.gnu.org/ml/gc
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 an
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
Date: Thu Mar 14 08:35:24 2013 -0
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 a
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 an
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 t
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 sizeo
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
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 s
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
PR tree-optimization/53265
* gcc.dg/graphite/scop-3.c (toto): Increase arra
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.
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 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 an
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 w
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
On 8 March 2013 09:32, Jakub Jelinek 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 wrote:
>> >>>AFAIK aarch
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: [Patc
42 matches
Mail list logo
