Jason Merrill ja...@redhat.com 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?
On 09/30/2014 12:47 PM, Olivier Hainque wrote:
2014-09-30 Olivier Hainque hain...@adacore.com
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
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?
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:
On Wed, Nov 12, 2014 at 4:38 PM, Kyrill Tkachov kyrylo.tkac...@arm.com 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
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 argue
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
On Wed, Nov 12, 2014 at 5:08 PM, James Greenhalgh
james.greenha...@arm.com 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
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
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
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-
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 VARn-1. 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.
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
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 can
On Mon, Nov 17, 2014 at 5:06 AM, Hale Wang hale.w...@arm.com 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
On 17 November 2014 06:58, Yangfei (Felix) felix.y...@huawei.com 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 kyrylo.tkac...@arm.com 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
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 remember
On Mon, Nov 17, 2014 at 5:43 PM, Jonathan Wakely jwak...@redhat.com 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
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 kyrylo.tkac...@arm.com
wrote:
Hi all,
Some configurations of Cortex-A53 and Cortex-A57 don't ship with crypto,
so enabling it by default for
On Tue, Nov 18, 2014 at 2:59 AM, David Malcolm dmalc...@redhat.com wrote:
On Mon, 2014-11-17 at 11:06 +0100, Richard Biener wrote:
On Sat, Nov 15, 2014 at 12:00 PM, David Malcolm dmalc...@redhat.com wrote:
On Thu, 2014-11-13 at 11:45 +0100, Richard Biener wrote:
On Thu, Nov 13, 2014 at 2:41
On Tue, Nov 18, 2014 at 3:59 AM, Jeff Law l...@redhat.com 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
On Mon, Nov 10, 2014 at 3:02 PM, Christophe Lyon
christophe.l...@linaro.org wrote:
On 30 October 2014 23:02, Christophe Lyon christophe.l...@linaro.org wrote:
On 29 October 2014 16:28, Ramana Radhakrishnan
ramana@googlemail.com wrote:
On Wed, Oct 29, 2014 at 3:26 PM, Christophe Lyon
On Thu, Nov 13, 2014 at 9:42 AM, Kyrill Tkachov kyrylo.tkac...@arm.com 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
On 10/29/2014 04:31 AM, Andi Kleen wrote:
2014-10-28 Andi Kleen a...@linux.intel.com
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 ...
On 17 November 2014 07:59, Yangfei (Felix) felix.y...@huawei.com wrote:
+2014-11-13 Felix Yang felix.y...@huawei.com
+
+ * 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
On Nov 18, 2014, at 04:01 , Jeff Law l...@redhat.com 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
On 18 November 2014 10:14, David Sherwood david.sherw...@arm.com 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
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 should
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
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
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
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 kyrylo.tkac...@arm.com
*
Hi all,
This is a rebase of Andrews' CMP+BRANCH fusion patch on top of my macro
fusion patches.
I've assigned the number 14 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 apin...@cavium.com
*
On Mon, 17 Nov 2014, Richard Biener wrote:
On Sun, Nov 16, 2014 at 6:53 PM, Marc Glisse marc.gli...@inria.fr 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
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,
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.
2014-11-18 5:56 GMT+03:00 Jeff Law l...@redhat.com:
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
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 14 to AARCH64_FUSE_CMP_BRANCH.
I've given it a test on top of my fusion patches.
Ok for trunk together with the rest?
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 part consists of all
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
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
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 part consists
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 felix.y...@huawei.com
+
+ * 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
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.
I'm in two minds
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
On 18 November 2014 11:28, Yangfei (Felix) felix.y...@huawei.com wrote:
Yeah, that's a good idea. See my updated patch :-)
Index: gcc/ChangeLog
===
--- gcc/ChangeLog (revision 217394)
+++ gcc/ChangeLog (working
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) felix.y...@huawei.com 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 marc.gli...@inria.fr wrote:
On Mon, 17 Nov 2014, Richard Biener wrote:
On Sun, Nov 16, 2014 at 6:53 PM, Marc Glisse marc.gli...@inria.fr wrote:
On Sun, 16 Nov 2014, Richard Biener wrote:
I think the element_mode is the way to go.
The
On Tue, Nov 18, 2014 at 11:51 AM, Ilya Enkovich enkovich@gmail.com wrote:
2014-11-18 5:56 GMT+03:00 Jeff Law l...@redhat.com:
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
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,
possibly
2014-11-18 15:04 GMT+03:00 Richard Biener richard.guent...@gmail.com:
On Tue, Nov 18, 2014 at 11:51 AM, Ilya Enkovich enkovich@gmail.com
wrote:
2014-11-18 5:56 GMT+03:00 Jeff Law l...@redhat.com:
On 11/17/14 13:43, Ilya Enkovich wrote:
I don't fully understand how this problem appears.
On Tue, Nov 18, 2014 at 1:13 PM, Ilya Enkovich enkovich@gmail.com wrote:
2014-11-18 15:04 GMT+03:00 Richard Biener richard.guent...@gmail.com:
On Tue, Nov 18, 2014 at 11:51 AM, Ilya Enkovich enkovich@gmail.com
wrote:
2014-11-18 5:56 GMT+03:00 Jeff Law l...@redhat.com:
On 11/17/14
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
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
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.
This patch
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 collected object from
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) felix.y...@huawei.com
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
2014-11-14 7:08 GMT-03:00 Richard Biener richard.guent...@gmail.com:
On Thu, Nov 13, 2014 at 6:42 PM, Andres Tiraboschi
andres.tirabos...@tallertechnologies.com wrote:
Hi, this patch adds a new plugin event PLUGIN_START_FUNCTION and
PLUGIN_FINISH_FUNCTION that are invoked at start_function
Jakub Jelinek ja...@redhat.com 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 -
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 renlin...@arm.com 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 renlin...@arm.com
On 13 November 2014 10:38, Alan Lawrence alan.lawre...@arm.com 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;
On 18/11/14 12:51, Yangfei (Felix) wrote:
On Tue, Nov 18, 2014 at 11:51 AM, Yangfei (Felix) felix.y...@huawei.com
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
2014-11-18 15:18 GMT+03:00 Richard Biener richard.guent...@gmail.com:
On Tue, Nov 18, 2014 at 1:13 PM, Ilya Enkovich enkovich@gmail.com wrote:
2014-11-18 15:04 GMT+03:00 Richard Biener richard.guent...@gmail.com:
On Tue, Nov 18, 2014 at 11:51 AM, Ilya Enkovich enkovich@gmail.com
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
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
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 why not.
On Tue, Nov 18, 2014 at 8:33 AM, Ilya Enkovich enkovich@gmail.com wrote:
2014-11-18 15:18 GMT+03:00 Richard Biener richard.guent...@gmail.com:
On Tue, Nov 18, 2014 at 1:13 PM, Ilya Enkovich enkovich@gmail.com
wrote:
2014-11-18 15:04 GMT+03:00 Richard Biener richard.guent...@gmail.com:
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 with
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
On Tue, Nov 18, 2014 at 2:44 PM, David Edelsohn dje@gmail.com wrote:
On Tue, Nov 18, 2014 at 8:33 AM, Ilya Enkovich enkovich@gmail.com wrote:
2014-11-18 15:18 GMT+03:00 Richard Biener richard.guent...@gmail.com:
On Tue, Nov 18, 2014 at 1:13 PM, Ilya Enkovich enkovich@gmail.com
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 after an
Jason Merrill ja...@redhat.com writes:
commit e52e82e56507d1de1932abcafd80683c4dc00d1e
Author: Jason Merrill ja...@redhat.com
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
On Tue, Nov 18, 2014 at 9:07 AM, Richard Biener
richard.guent...@gmail.com 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
-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, Andrew
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
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, 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:
+ ul
+ li The Thumb-1 assembly code are now generated in unified syntax. The
new option
+code-masm-syntax-unified/code can be used to specify whether
inline assembly
+code are using unified syntax. By default the option is off which
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
do in
On Nov 18, 2014, at 03:29 , Jason Merrill ja...@redhat.com 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
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
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
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
Please
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 collected
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.
On Mon, Nov 17, 2014 at 5:13 PM, Marcus Shawcroft
marcus.shawcr...@gmail.com wrote:
On 14 November 2014 14:35, Wilco Dijkstra wdijk...@arm.com wrote:
2014-11-14 Wilco Dijkstra wdijk...@arm.com
* gcc/config/aarch64/aarch64.c (generic_regmove_cost):
Increase FP move cost.
On Mon, Nov 17, 2014 at 10:38 AM, Jan Hubicka hubi...@ucw.cz 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.
On Fri, Nov 14, 2014 at 2:19 AM, Richard Biener
richard.guent...@gmail.com wrote:
On Fri, Nov 14, 2014 at 12:15 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Tue, Nov 11, 2014 at 8:02 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Mon, Nov 10, 2014 at 11:42 AM, H.J. Lu hjl.to...@gmail.com wrote:
On
1 - 100 of 180 matches
Mail list logo
