Jason Merrill writes:
> When I was fixing attribute deprecated for C++ templates, I found it
> odd that the source location for the deprecated decl was embedded in
> the warning rather than in a separate inform. This patch moves it
> out.
>
> Tested x86_64-pc-linux-gnu. OK for trunk?
Yes. Tha
On 09/30/2014 12:47 PM, Olivier Hainque wrote:
> 2014-09-30 Olivier Hainque
>
> libgcc/
> * unwind-dw2.c (DWARF_REG_TO_UNWIND_COLUMN): Move default def to ...
>
> gcc/
> * defaults.h: ... here.
> * dwarf2cfi.c (init_one_dwarf_reg_size): New helper, proce
Hi,
This is the patch implementing ldp/stp optimization for aarch64. It
consists of two parts. The first one is peephole part, which further
includes ldp/stp patterns (both peephole patterns and the insn match
patterns) and auxiliary functions (both checking the validity and merging).
The second
On 06/11/14 08:35, Yangfei (Felix) wrote:
The idea is simple: Use movw for certain const source operand instead of
ldrh. And exclude the const values which cannot be handled by
mov/mvn/movw.
I am doing regression test for this patch. Assuming no issue pops up,
OK for trunk?
So
Hi,
This patch converts more intrinsics to use builtin functions instead of
the previous inline assembly syntax.
Passed the glorious testsuite of Christophe Lyon.
Three testcases are added for the testing of intriniscs which are not
covered by the testsuite:
gcc.target/aar
On Wed, Nov 12, 2014 at 4:38 PM, Kyrill Tkachov wrote:
> Hi all,
>
> This is a much-delayed respin of the patch in response to Richards feedback
> at:
> http://gcc.gnu.org/ml/gcc-patches/2014-05/msg00068.html
>
> We now let recursion do its magic and just add the cost of the arithmetic
> operation
Yeah, I agree that your approach is better. I missed this point. Thanks.
>
> Ah, sorry for the duplication of effort. And thanks for the heads-up about
> upcoming work! I don't think I have any plans for any of those others at the
> moment.
>
> In the case of vld1_dup, however, I'm going to a
> Now - I can see how that is easily confused by the static chain
> being address-taken. But I also remember that Eric did some
> preparatory work to fix that, for nested functions, that is,
> possibly setting DECL_NONADDRESSABLE_P? Don't remember exactly.
The preparatory work is DECL_NONLOCAL_F
On Wed, Nov 12, 2014 at 5:08 PM, James Greenhalgh
wrote:
> Hi,
>
> I was taking a look at fixing the issues in the ARM back-end exposed
> by Marc Glisse's patch in [1], and hoped to fix them by adapting the
> patch recently commited by Tejas ([2]).
>
> As I looked, I realised that the ARM target a
On 12/11/14 17:10, James Greenhalgh wrote:
Hi,
As part of some wider cleanup I'd like to do to ARM's Neon Builtin
infrastructure, my first step will be to remove the "Magic Words" used
to decide which variant of an instruction should be emitted.
The "Magic Words" interface allows a single bu
On 12/11/14 17:10, James Greenhalgh wrote:
Hi,
If we want to move all the code relating to "builtin" initialisation and
expansion to a common file, we must share the processor flags with that
common file.
This patch pulls those definitions out to config/arm/arm-protos.h
Bootstrapped and reg
Hi Christophe,
Ah sorry. My mistake - it fixes this in bugzilla:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59810
This change is needed in order to remove the CANNOT_CHANGE_MODE_CLASS
#define, which will be committed as a separate patch.
Regards,
David Sherwood.
-Original Message-
Fr
On 12/11/14 17:10, James Greenhalgh wrote:
Hi,
The config/arm/arm.c file has always seemed a worrying size to me.
This patch pulls out the builtin related code to its own file. I think
this will be a good idea as we move forward. It seems a more sensible
separation of concerns. There are no
On 12/11/14 17:10, James Greenhalgh wrote:
Hi,
These macros can always be defined as a base case of VAR1 and a "recursive"
case of VAR. At the moment, the body of VAR1 is duplicated to each
macro.
This patch makes that change.
Regression tested on arm-none-linux-gnueabihf with no issues.
O
On 12/11/14 17:10, James Greenhalgh wrote:
Hi,
Now we have everything we need to start keeping track of the correct
"qualifiers" for each Neon builtin class in the arm back-end.
Some of the ARM Neon itypes are redundant when mapped to the qualifiers
framework. For now, don't change these, we
On 12/11/14 17:10, James Greenhalgh wrote:
Hi,
The poly types end up going through the default mangler, but only
sometimes.
We don't want to change the mangling for poly types with the next patch in
this series, so add a test which should pass before and after.
I've checked that the new tes
On 12/11/14 17:10, James Greenhalgh wrote:
Hi,
This patch wires up builtin initialisation similar to the AArch64 backend,
making use of the "qualifiers" arrays to decide on types for each builtin
we hope to initialise.
We could take an old snapshot of the qualifiers code from AArch64, but as
On 12/11/14 17:10, James Greenhalgh wrote:
Hi,
This final patch clears up the remaining data structures which we no
longer have any use for...
* "_QUALIFIERS" macros which do not name a distinct pattern of
arguments/return types.
* The neon_builtin_type_mode enum is not needed, we ca
On Mon, Nov 17, 2014 at 5:06 AM, Hale Wang wrote:
> Hi,
>
> Refer to the previous small multiply patch (r217175).
>
> The conditions in the small multiply test cases are not restrictive enough.
> If forcing the march=armv4t/armv5t, these cases will fail.
> These cases can be used only if we define
On 17 November 2014 06:58, Yangfei (Felix) wrote:
> PING?
> BTW: It seems that Alan's way of improving vld1(q?)_dup intrinsic is more
> elegant.
> So is the improvement of vcls(q?) vcnt(q?) OK for trunk? Thanks.
Please rebase over Alan's patch and repost, thank you /Marcus
On 17/11/14 16:59, Ramana Radhakrishnan wrote:
On Mon, Nov 17, 2014 at 2:48 PM, Kyrill Tkachov wrote:
Hi all,
Some configurations of Cortex-A53 and Cortex-A57 don't ship with crypto,
so enabling it by default for -mcpu=cortex-a53 and cortex-a57 is
inappropriate.
Tested aarch64-none-elf. Remi
On Tue, 18 Nov 2014, Eric Botcazou wrote:
> > Now - I can see how that is easily confused by the static chain
> > being address-taken. But I also remember that Eric did some
> > preparatory work to fix that, for nested functions, that is,
> > possibly setting DECL_NONADDRESSABLE_P? Don't remembe
On Mon, Nov 17, 2014 at 5:43 PM, Jonathan Wakely wrote:
> On 17/11/14 13:06 +0100, Markus Trippelsdorf wrote:
>>
>> On 2014.11.14 at 15:43 +, Jonathan Wakely wrote:
>>>
>>> Tested on x86_64-linux and powerpc64-linux, also with
>>> --disable-libstdcxx11-abi to verify all the incompatible change
On 18/11/14 09:38, Kyrill Tkachov wrote:
>
> On 17/11/14 16:59, Ramana Radhakrishnan wrote:
>> On Mon, Nov 17, 2014 at 2:48 PM, Kyrill Tkachov
>> wrote:
>>> Hi all,
>>>
>>> Some configurations of Cortex-A53 and Cortex-A57 don't ship with crypto,
>>> so enabling it by default for -mcpu=cortex-a53
On Tue, Nov 18, 2014 at 2:59 AM, David Malcolm wrote:
> On Mon, 2014-11-17 at 11:06 +0100, Richard Biener wrote:
>> On Sat, Nov 15, 2014 at 12:00 PM, David Malcolm wrote:
>> > On Thu, 2014-11-13 at 11:45 +0100, Richard Biener wrote:
>> >> On Thu, Nov 13, 2014 at 2:41 AM, David Malcolm
>> >> wro
On Tue, Nov 18, 2014 at 3:59 AM, Jeff Law wrote:
> On 11/17/14 13:05, Ilya Enkovich wrote:
>
>>
>> How comes you emit debug info for functions that do not exist and thus
>> are never used? Is problem caused by builtins going after
>> END_CHKP_BUILTINS? Or some info generated for all builtins igno
On Mon, Nov 10, 2014 at 3:02 PM, Christophe Lyon
wrote:
> On 30 October 2014 23:02, Christophe Lyon wrote:
>> On 29 October 2014 16:28, Ramana Radhakrishnan
>> wrote:
>>> On Wed, Oct 29, 2014 at 3:26 PM, Christophe Lyon
>>> wrote:
Hi,
In PR61153, the vbic and vorn tests fail beca
On Thu, Nov 13, 2014 at 9:42 AM, Kyrill Tkachov wrote:
> Hi all,
>
> Following the trend in i386 and alpha, this patch uses std::swap to perform
> swapping of values in the arm backend instead of declaring temporaries.
> Tested and bootstrapped on arm-none-linux-gnueabihf.
>
> Ok for trunk?
OK -
On 10/29/2014 04:31 AM, Andi Kleen wrote:
> 2014-10-28 Andi Kleen
>
> PR target/63672
> * config/i386/i386.c (ix86_expand_builtin): Generate memory
> barrier after abort.
> * config/i386/i386.md (xbegin): Add memory barrier.
> (xend): Rename to ...
> (xend_1)
On 17 November 2014 07:59, Yangfei (Felix) wrote:
>> +2014-11-13 Felix Yang
>> +
>> + * config/aarch64/aarch64.md (doloop_end): New pattern.
>> +
This looks like a straight copy of the ARM code, but without the
TARGET_CAN_USE_DOLOOP_P definition. If the reason for including this
code is
On Nov 18, 2014, at 04:01 , Jeff Law wrote:
> Best for Jason, Richard or Jakub. My knowledge of dwarf2 and our
> implementation in dwarf*out.c is minimal at best.
Thanks for your answer Jeff. Richard & Jason have provided feedback
(thanks for this as well :) on which I'll followup.
Olivier
On 18 November 2014 10:14, David Sherwood wrote:
> Hi Christophe,
>
> Ah sorry. My mistake - it fixes this in bugzilla:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59810
I did look at that PR, but since it has no testcase attached, I was unsure.
And I am still not :-)
PR 59810 is "[AArch64]
On Wed, Nov 05, 2014 at 11:31:24PM +, James Greenhalgh wrote:
> On Wed, Nov 05, 2014 at 09:50:52PM +, Marc Glisse wrote:
> > Thanks. Do you know if anyone is planning to "port" this patch to the arm
> > target (which IIRC has the same issue)? No pressure, this is just so I
> > know if I s
Hi all,
This is another iteration of this patch posted earlier with a bug fixed
pointed out by Andrew
It implements the target hooks for macro fusion and implements fusion of
MOV+MOVK instructions
and enables them for cores that support these fusions.
Bootstrapped and tested aarch64-none-elf.
Hi all,
I've decided to organise the aarch64 macro fusion patches into a series.
Some of them have been posted last week and gotten review feedback
and have been reworked:
- [1/5] Implement TARGET_SCHED_MACRO_FUSION_PAIR_P:
This implements the hook itself and adds logic for fusing
MOV+MOVK instr
Hi all,
This patch is just rebased on top of the changes from the previous patch
in the series.
Otherwise it's the same as
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01263.html with some style
cleanup
There can be cases where we miss fusion of adrd+add because although
they are generated
Hi all,
Following up on the previous instruction fusion patches this one
implements the fusion of instruction pairs of the form:
movk Xn, imm16_1 lsl 32
movk Xn, imm16_2 lsl 48
which is usually generated as part of the immediate synthesis code. For
some cores we don't want to schedule them ap
On 11/14/2014 05:06 PM, Jan Hubicka wrote:
In a way I would like to see these to be methods of the underlying type rather
than
virtual methods of the summary, becuase these are operations on the data
themselves.
I was thinking to model these by specual constructor and copy constructor
(taking
Hi all,
Sometimes we want to fuse adrp+ldr pairs as described in the comment in
the patch.
This is enabled by default for the Cortex-A53.
Bootstrapped and tested on aarch64-none-linux.
Ok for trunk?
Thanks,
Kyrill
2014-11-18 Kyrylo Tkachov
* config/aarch64/aarch64.c (AARCH64_FUSE_AD
Hi all,
This is a rebase of Andrews' CMP+BRANCH fusion patch on top of my macro
fusion patches.
I've assigned the number 1<<4 to AARCH64_FUSE_CMP_BRANCH.
I've given it a test on top of my fusion patches.
Ok for trunk together with the rest?
2014-11-14 Andrew Pinski
* config/aarch64/a
On Mon, 17 Nov 2014, Richard Biener wrote:
On Sun, Nov 16, 2014 at 6:53 PM, Marc Glisse wrote:
On Sun, 16 Nov 2014, Richard Biener wrote:
I think the element_mode is the way to go.
The following passed bootstrap+testsuite.
2014-11-16 Marc Glisse
* tree.c (element_mode, intege
Hi all,
Following up from adding Cortex-A17 support this patch adds a big.LITTLE
option cortex-a17.cortex-a7.
Similar to the existing cortex-a15.cortex-a7 support we schedule for
Cortex-A7 and make the other tuning
decisions as for Cortex-A17.
Tested arm-none-eabi.
Ok for trunk?
Thanks,
Kyr
Yes, major code is borrowed from ARM port with the expected mode of loop pseudo
changed to DImode.
The function loop_canon_p called in sms_schedule can make sure that SMS is only
performed for innermost loops.
But I think it's a good idea to implement the TARGET_CAN_USE_DOLOOP_P hook
here.
Se
2014-11-18 5:56 GMT+03:00 Jeff Law :
> On 11/17/14 13:43, Ilya Enkovich wrote:
>
>>
>> I don't fully understand how this problem appears. Is it fully AIX
>> specific and doesn't affect any other target? May we put all _CHKP
>> codes to the end of enum and ignore them by AIX? Limiting number of
>>
On 18/11/14 10:34, Kyrill Tkachov wrote:
> Hi all,
>
> This is a rebase of Andrews' CMP+BRANCH fusion patch on top of my macro
> fusion patches.
> I've assigned the number 1<<4 to AARCH64_FUSE_CMP_BRANCH.
>
> I've given it a test on top of my fusion patches.
>
> Ok for trunk together with the r
On 11/18/2014 11:48 AM, Yangfei (Felix) wrote:
> +(define_expand "doloop_end"
> + [(use (match_operand 0 "" "")) ; loop pseudo
> + (use (match_operand 1 "" ""))] ; label
> + ""
> +{
> + /* Currently SMS relies on the do-loop pattern to recognize loops
> + where (1) the control par
Hi all,
This patch should fix PR63762.
Hard_reg allocated during IRA pass conflicts with hard_reg allocated in
LRA pass because of inconsistent information between allocno and reg_pref.
The staled reg_class information in reg_pref is used by LRA while doing
hard register assignment. LRA make
> On 06/11/14 08:35, Yangfei (Felix) wrote:
> >>> The idea is simple: Use movw for certain const source operand
> >>> instead of
> >> ldrh. And exclude the const values which cannot be handled by
> >> mov/mvn/movw.
> >>> I am doing regression test for this patch. Assuming no issue
> >
> On 11/18/2014 11:48 AM, Yangfei (Felix) wrote:
> > +(define_expand "doloop_end"
> > + [(use (match_operand 0 "" "")) ; loop pseudo
> > + (use (match_operand 1 "" ""))] ; label
> > + ""
> > +{
> > + /* Currently SMS relies on the do-loop pattern to recognize loops
> > + where (1)
Incorrect predefinitions for certain target architectures. E.g. arm7-m
does not contain NEON but the defintion __ARM_NEON_FP was switched on.
Similarly with armv6 and even armv2.
This patch fixes the predefines for each of the different chips
containing certain types of the FPU implementations.
On 11/18/2014 12:28 PM, Yangfei (Felix) wrote:
> +2014-11-13 Felix Yang
> +
> + * config/aarch64/aarch64.c (doloop_end): New pattern.
> + * config/aarch64/aarch64.md (TARGET_CAN_USE_DOLOOP_P): Implement.
Looks good to me. I'll leave it for aarch64 maintainers for final approval.
r~
Ping again? Any comment please?
>
> Ping? I hope this patch can catch up with stage 1 of GCC-5.0. Thanks.
>
>
>
>
> > > Hi Felix,
> > >
> > > Sorry for the delay responding, I've been out of the office recently
> > > and I'm only just catching up on a backlog of GCC related emails.
> > >
On 18/11/14 11:30, Mantas Mikaitis wrote:
> Incorrect predefinitions for certain target architectures. E.g. arm7-m
> does not contain NEON but the defintion __ARM_NEON_FP was switched on.
> Similarly with armv6 and even armv2.
>
> This patch fixes the predefines for each of the different chips
> c
On 18 November 2014 11:28, Yangfei (Felix) wrote:
> Yeah, that's a good idea. See my updated patch :-)
>
>
> Index: gcc/ChangeLog
> ===
> --- gcc/ChangeLog (revision 217394)
> +++ gcc/ChangeLog (working copy)
> @@ -1,3 +
On 18/11/14 11:02, Yangfei (Felix) wrote:
On 06/11/14 08:35, Yangfei (Felix) wrote:
The idea is simple: Use movw for certain const source operand
instead of
ldrh. And exclude the const values which cannot be handled by
mov/mvn/movw.
I am doing regression test for this patch.
On Tue, Nov 18, 2014 at 11:51 AM, Yangfei (Felix) wrote:
> Ping again? Any comment please?
Pinging daily is only going to irritate people. Please desist from doing so.
Ramana
>
>
>>
>> Ping? I hope this patch can catch up with stage 1 of GCC-5.0. Thanks.
>>
>>
>>
>>
>> > > Hi Felix,
>> > >
>
On Tue, Nov 18, 2014 at 11:36 AM, Marc Glisse wrote:
> On Mon, 17 Nov 2014, Richard Biener wrote:
>
>> On Sun, Nov 16, 2014 at 6:53 PM, Marc Glisse wrote:
>>>
>>> On Sun, 16 Nov 2014, Richard Biener wrote:
>>>
I think the element_mode is the way to go.
>>>
>>>
>>>
>>> The following passed bo
On Tue, Nov 18, 2014 at 11:51 AM, Ilya Enkovich wrote:
> 2014-11-18 5:56 GMT+03:00 Jeff Law :
>> On 11/17/14 13:43, Ilya Enkovich wrote:
>>
>>>
>>> I don't fully understand how this problem appears. Is it fully AIX
>>> specific and doesn't affect any other target? May we put all _CHKP
>>> codes
On Tue, 18 Nov 2014, Richard Biener wrote:
> On Tue, 18 Nov 2014, Eric Botcazou wrote:
>
> > > Now - I can see how that is easily confused by the static chain
> > > being address-taken. But I also remember that Eric did some
> > > preparatory work to fix that, for nested functions, that is,
> >
2014-11-18 15:04 GMT+03:00 Richard Biener :
> On Tue, Nov 18, 2014 at 11:51 AM, Ilya Enkovich
> wrote:
>> 2014-11-18 5:56 GMT+03:00 Jeff Law :
>>> On 11/17/14 13:43, Ilya Enkovich wrote:
>>>
I don't fully understand how this problem appears. Is it fully AIX
specific and doesn't af
On Tue, Nov 18, 2014 at 1:13 PM, Ilya Enkovich wrote:
> 2014-11-18 15:04 GMT+03:00 Richard Biener :
>> On Tue, Nov 18, 2014 at 11:51 AM, Ilya Enkovich
>> wrote:
>>> 2014-11-18 5:56 GMT+03:00 Jeff Law :
On 11/17/14 13:43, Ilya Enkovich wrote:
>
> I don't fully understand how thi
On 18/11/14 10:33, Kyrill Tkachov wrote:
diff --git a/gcc/config/arm/aarch-common-protos.h
b/gcc/config/arm/aarch-common-protos.h
index 264bf01..ad7ec43c 100644
--- a/gcc/config/arm/aarch-common-protos.h
+++ b/gcc/config/arm/aarch-common-protos.h
@@ -36,7 +36,6 @@ extern int arm_no_early_alu_sh
> On 18/11/14 11:02, Yangfei (Felix) wrote:
> >> On 06/11/14 08:35, Yangfei (Felix) wrote:
> >The idea is simple: Use movw for certain const source
> > operand instead of
> ldrh. And exclude the const values which cannot be handled by
> mov/mvn/movw.
> >I am d
On Mon, Nov 17, 2014 at 02:13:22PM -0700, Jeff Law wrote:
> On 11/14/14 12:19, Segher Boessenkool wrote:
> >If the result of combining some insns is a PARALLEL of two SETs, and that
> >is not a recognised insn, and one of the SETs is dead, combine tries to
> >use the remaining SET as insn.
> >
> >T
On Fri, Nov 14, 2014 at 08:59:10PM +0100, Jan Hubicka wrote:
> > >
> > > > b) with GTY, we cannot call destructor
> > >
> > > Everything in symbol table is expecitely memory managed (i.e. enver left
> > > to be freed by garbage collector). It resists in GTY only to allow linking
> > > garbage col
Sorry for missing the point. It seems to me that 't2' here will conflict with
condition of the pattern *movhi_insn_arch4:
"TARGET_ARM
&& arm_arch4
&& (register_operand (operands[0], HImode)
|| register_operand (operands[1], HImode))"
#define TARGET_ARM
> On Tue, Nov 18, 2014 at 11:51 AM, Yangfei (Felix)
> wrote:
> > Ping again? Any comment please?
>
>
> Pinging daily is only going to irritate people. Please desist from doing so.
>
> Ramana
Oh, thanks for reminding me. And sorry if this bothers you guys.
The end of stage1 of GCC 5.0 caus
2014-11-14 7:08 GMT-03:00 Richard Biener :
> On Thu, Nov 13, 2014 at 6:42 PM, Andres Tiraboschi
> wrote:
>> Hi, this patch adds a new plugin event PLUGIN_START_FUNCTION and
>> PLUGIN_FINISH_FUNCTION that are invoked at start_function and
>> finish_function respectively in the C and C++ frontends
Jakub Jelinek writes:
> On Tue, Oct 14, 2014 at 11:23:22AM -0600, Jeff Law wrote:
>> On 10/14/14 10:02, Jakub Jelinek wrote:
>> >When hacking on range reassoc opt, I've noticed we can emit
>> >code with undefined behavior even when there wasn't one originally,
>> >in particular for:
>> >(X - 4
The following fixes an ICE in CCPs set_lattice_value which is
confused when transitioning from { NaN, 0.0 } to { 0.0, 0.0 }.
The comment before canonicalize_value nicely explains what
happens here (with -ffinite-math-only) but the function fails
to handle float vectors or complex float constants.
On 17 November 2014 17:33, Renlin Li wrote:
> Hi all,
>
> This is a simple patch to add more conditional macros defined ACLE 2.0.
>
> aarch64-none-elf target is tested on the model, no new issues.
>
> Is this Okay for trunk?
>
>
> gcc/ChangeLog:
>
> 2014-11-17 Renlin Li
>
> * config/aarch64
On 13 November 2014 10:38, Alan Lawrence wrote:
> Hi,
>
> gcc/config/aarch64/iterators.md contains numerous duplicates - not always
> obvious as they are not always sorted the same. Sometimes, one copy is used
> is aarch64-simd-builtins.def and another in aarch64-simd.md; othertimes
> there is no
On 18/11/14 12:51, Yangfei (Felix) wrote:
On Tue, Nov 18, 2014 at 11:51 AM, Yangfei (Felix)
wrote:
Ping again? Any comment please?
Pinging daily is only going to irritate people. Please desist from doing so.
Ramana
Oh, thanks for reminding me. And sorry if this bothers you guys.
The
2014-11-18 15:18 GMT+03:00 Richard Biener :
> On Tue, Nov 18, 2014 at 1:13 PM, Ilya Enkovich wrote:
>> 2014-11-18 15:04 GMT+03:00 Richard Biener :
>>> On Tue, Nov 18, 2014 at 11:51 AM, Ilya Enkovich
>>> wrote:
2014-11-18 5:56 GMT+03:00 Jeff Law :
> On 11/17/14 13:43, Ilya Enkovich wrote
We need to allow copy-list-initialization of constexpr variables with
mutable members, too. The thing we need to avoid is not so much an
full-expression with mutable-containing type as assuming that a mutable
member of a variable hasn't changed since the variable was initialized.
Tested x86_6
Hi,
The atomic-compare-exchange-3.c and atomic-op-3.c tests are failing when
using the -mfix-r1 option. This is due to the fact that the delay
slot of the branch instruction that checks if the atomic operation was
not successful can be filled with an operation that returns the output
result
On Tue, Nov 18, 2014 at 06:38:49AM -0600, Segher Boessenkool wrote:
> > Does it help pr52714 where we'd like to rip apart a PARALLEL with two
> > sets, one of which is dead. If so, it might allow us to optimize that
> > code better.
>
> It does not seem to fix the testcase. I'll investigate w
On Tue, Nov 18, 2014 at 8:33 AM, Ilya Enkovich wrote:
> 2014-11-18 15:18 GMT+03:00 Richard Biener :
>> On Tue, Nov 18, 2014 at 1:13 PM, Ilya Enkovich
>> wrote:
>>> 2014-11-18 15:04 GMT+03:00 Richard Biener :
On Tue, Nov 18, 2014 at 11:51 AM, Ilya Enkovich
wrote:
> 2014-11-18 5:56
On Tue, 18 Nov 2014, Andrew Bennett wrote:
> The atomic-compare-exchange-3.c and atomic-op-3.c tests are failing when
> using the -mfix-r1 option. This is due to the fact that the delay
> slot of the branch instruction that checks if the atomic operation was
> not successful can be filled wi
On 11/18/2014 02:35 PM, Jason Merrill wrote:
We need to allow copy-list-initialization of constexpr variables with
mutable members, too. The thing we need to avoid is not so much an
full-expression with mutable-containing type as assuming that a
mutable member of a variable hasn't changed sinc
On Tue, Nov 18, 2014 at 2:44 PM, David Edelsohn wrote:
> On Tue, Nov 18, 2014 at 8:33 AM, Ilya Enkovich wrote:
>> 2014-11-18 15:18 GMT+03:00 Richard Biener :
>>> On Tue, Nov 18, 2014 at 1:13 PM, Ilya Enkovich
>>> wrote:
2014-11-18 15:04 GMT+03:00 Richard Biener :
> On Tue, Nov 18, 2014
On 11/18/14 0:38, Joseph Myers wrote:
> On Sat, 15 Nov 2014, Chen Gang wrote:
>
>> Also in c_common_read_pch(), when failure occurs, also need be sure the
>> 'fd' is not '-1' for the next close operation.
>
> Please clarify how c_common_read_pch gets called with fd == -1.
> Certainly checking a
Jason Merrill writes:
> commit e52e82e56507d1de1932abcafd80683c4dc00d1e
> Author: Jason Merrill
> Date: Sun Nov 16 17:14:12 2014 -0500
>
> * constexpr.c (use_new_call): Always use new call handling.
>
> diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
> index 57d0c46..8881271 100644
On Tue, Nov 18, 2014 at 9:07 AM, Richard Biener
wrote:
> Can we emit this particular STABS piece in "raw" form then? Thus
> does it work to have sth like
>
>.stabs ...
>.string "..."
>.stabs ...
>
> or whatever way to emit assembled data there?
The stabstring debug information is sa
> -Original Message-
> From: Maciej W. Rozycki [mailto:ma...@codesourcery.com]
> Sent: 18 November 2014 13:48
> To: Andrew Bennett
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] If using branch likelies in MIPS sync code fill the delay
> slot with a nop
>
> On Tue, 18 Nov 2014, Andre
While looking at 55992 I noticed that we weren't pushing into dependent
scope properly; we need to pass the "entering scope" flag to
tsubst_aggr_type so that we get the version of the type with the
members. This isn't enough to fix 55992, but may well fix other bugs.
Tested x86_64-pc-linux-gn
> The atomic-compare-exchange-3.c and atomic-op-3.c tests are failing when
> using the -mfix-r1 option. This is due to the fact that the delay
> slot of the branch instruction that checks if the atomic operation was
> not successful can be filled with an operation that returns the output
> res
On Tue, 18 Nov 2014, Andrew Bennett wrote:
> My fix places a nop in the delay slot of the branch likely instruction
> by using the %~ output operation. This then causes the sync code for the
> previous example to be correct:
>
> .setnoat
> sync # 15 sync_new_addsi/2
On 18/11/14 02:48, Terry Guo wrote:
+
+ The Thumb-1 assembly code are now generated in unified syntax. The
new option
+-masm-syntax-unified can be used to specify whether
inline assembly
+code are using unified syntax. By default the option is off which means
+
On 15 Nov 00:16, Jeff Law wrote:
> On 11/14/14 10:29, Ilya Enkovich wrote:
> >Hi,
> >
> >This patch adds wrapper calls. It's simply achieved by using proper name
> >for builtin clones. Patches apply over builtins instrumentation series.
> >
> >Thanks,
> >Ilya
> >--
> >2014-11-14 Ilya Enkovich
> OK, this does look to me like the correct way to address the issue, but
> where is the second NOP that you previously mentioned? I fail to see it
> here and this code can't be made any better, there isn't anything you
> could possibly schedule into the delay slot as there is nothing else to
> d
On Nov 18, 2014, at 03:29 , Jason Merrill wrote:
> What happens when the outer loop hits a register that we've already seen as
> part of a span?
Hmm, I was under the impression that this was supposed never to happen. I can
see that this is not so clear though.
What would happen with the cur
On 17/11/14 18:15, Jason Merrill wrote:
On 11/17/2014 05:29 AM, Richard Biener wrote:
can you rename it to copy_fn please? It really copies parameter and
result and then the body.
Ok with that change.
Done. Here's what I'm checking in, along with a second patch to enable
the new code for C+
Hi,
This patch disables the generation of sections with offload IR and offload
tables by default, when a compiler is configured without
--enable-offload-targets= .
Bootsrap and regtesting in progress, OK after it finished?
-- Ilya
PR regression/63868
gcc/
* cgraph.c (cgraph_no
On Tue, Nov 18, 2014 at 06:31:59PM +0300, Ilya Verbin wrote:
> @@ -8287,7 +8289,9 @@ expand_omp_target (struct omp_region *region)
>if (kind == GF_OMP_TARGET_KIND_REGION)
> {
>unsigned srcidx, dstidx, num;
> +#ifdef ENABLE_OFFLOADING
>struct cgraph_node *node;
> +#endif
Pl
> On Fri, Nov 14, 2014 at 08:59:10PM +0100, Jan Hubicka wrote:
> > > >
> > > > > b) with GTY, we cannot call destructor
> > > >
> > > > Everything in symbol table is expecitely memory managed (i.e. enver left
> > > > to be freed by garbage collector). It resists in GTY only to allow
> > > > link
Hi, this patch adds a new plugin event PLUGIN_START_PARSE_FUNCTION and
PLUGIN_FINISH_PARSE_FUNCTION that are invoked at start_function and
finish_function respectively in the C and C++ frontends.
PLUGIN_START_PARSE_FUNCTION is called before parsing the function body.
PLUGIN_FINISH_PARSE_FUNCTION
On Mon, Nov 17, 2014 at 5:13 PM, Marcus Shawcroft
wrote:
> On 14 November 2014 14:35, Wilco Dijkstra wrote:
>
>> 2014-11-14 Wilco Dijkstra
>>
>> * gcc/config/aarch64/aarch64.c (generic_regmove_cost):
>> Increase FP move cost.
>
> OK /Marcus
Changelog should probably indicate P
On Mon, Nov 17, 2014 at 10:38 AM, Jan Hubicka wrote:
> Hi,
> this patch makes us to store default optimization node same way as we stream
> target node. This means that command line options given at compile time
> prevail those given at linktime. Previously we sort of combined both.
>
> We still
On Fri, Nov 14, 2014 at 2:19 AM, Richard Biener
wrote:
> On Fri, Nov 14, 2014 at 12:15 AM, H.J. Lu wrote:
>> On Tue, Nov 11, 2014 at 8:02 AM, H.J. Lu wrote:
>>> On Mon, Nov 10, 2014 at 11:42 AM, H.J. Lu wrote:
On Mon, Nov 10, 2014 at 5:44 AM, Richard Biener
wrote:
> On Mon, Nov 1
1 - 100 of 180 matches
Mail list logo
