Hi,
this patch moves init and fini priorities to symbol table instead of trees.
They are already in on-side hashtables, but the hashtables are now maintaned
by symbol table. This is needed for correctness with LTO.
Currently tree merging may load declaration with priority and then ggc_free
it cre
On 2014/6/18 上午 06:26, Ramana Radhakrishnan wrote:
> On Sun, Jun 8, 2014 at 12:27 PM, Chung-Lin Tang
> wrote:
>> > Hi Richard, Ramana,
>> >
>> > Attached is a small fix for resolving a g++.old-deja/g++.jason/thunk2.C
>> > regression we found under a TARGET_THUMB1_ONLY multilib (-mthumb
>> > -marc
Ping.
On 2014/6/9 10:03 PM, Chung-Lin Tang wrote:
> Hi Richard,
> As we talked about earlier, here's a patch to add a compiler option to
> work around Cortex-A9 MPCore errata 761319:
> http://infocenter.arm.com/help/topic/com.arm.doc.uan0004a/UAN0004A_a9_read_read.pdf
>
> What the option does bas
Tobias Burnus wrote:
This patches fixes a few bugs related to CO_MIN/MAX/SUM:
Committed as Rev. 211816.
That patch required also the attached testsuite changes, committed as
Rev. 211833.
Tobias
Index: gcc/testsuite/ChangeLog
===
> -Original Message-
> From: Mike Stump [mailto:mikest...@comcast.net]
> Sent: 2014年6月19日 1:42
> To: Richard Biener
> Cc: Hale Wang; Mike Stump; GCC Patches
> Subject: Re: [PATCH] PR61123 : Fix the ABI mis-matching error caused by
LTO
>
> On Jun 18, 2014, at 3:22 AM, Richard Biener
> wr
> Ping.
>
> Thanks,
>
> Martin
>
>
> On Sat, May 31, 2014 at 12:46:03AM +0200, Martin Jambor wrote:
> > Hi,
> >
> > after a clone is materialized, its clone_of field is cleared which in
> > PR 61211 leads to a failure in the skipped_thunk path in clone_of_p in
> > cgraph.c, which then leads to
On 02/28/2014 01:32 AM, Ramana Radhakrishnan wrote:
> Hi,
>
> This defines TARGET_FLAGS_REGNUM for AArch64 to be CC_REGNUM. Noticed this
> turns on the cmpelim pass after reload and in a few examples and a couple of
> benchmarks I noticed a number of comparisons getting deleted. A similar patc
Hi,
This change removes an extraneous NOP instruction placed at the end of
code produced by each of byte-swap patterns due to the expansion of the
(const_int 0) RTL unnecessarily produced by `define_split' definitions.
Updated patterns follow what other targets do in corresponding situations.
[Am I really supposed to CC this to gcc@ like binutils/MAINTAINERS
says I should?]
Individual users will still have to:
1. Install git-merge-changelog
2. Set up the merge driver in their git config
See gnulib's lib/git-merge-changelog.c [1] for details.
For example, I:
1. Patched Debian's
> "Jakub" == Jakub Jelinek writes:
Jakub> If you plan to implement this for other frontends (cc1plus,
Jakub> f951?) in the future, would that be still libcc1 and perhaps new
Jakub> plugins in there, or are we going to have new toplevel
Jakub> directories for each such a plugin?
We're plannin
On Thu, Jun 19, 2014 at 02:52:12PM -0600, Tom Tromey wrote:
> Tom> I've edited this one down by removing the auto-generated stuff , and
> Tom> then compressed it.
>
> Here's a new version of patch #5.
> I've removed the generated code; let's see if it gets through without
> compression.
>
> I thi
On Sun, 1 Jun 2014, Herman, Andrei wrote:
>+ /* The -fforce-dwarf-lexical-blocks option is only relevant when debug
>+ info is in DWARF4 format */
>+ if (flag_force_dwarf_blocks) {
Watch coding style: the opening '{' always goes on the next line.
>+fforce-dwarf-lexical-blocks
>+C C++ Var(f
Joseph> I don't see anything obvious that would disable the plugin if
Joseph> plugins are unsupported (e.g. on Windows host) or disabled
Joseph> (--disable-plugin). Probably the relevant support from
Joseph> gcc/configure.ac needs to go somewhere it can be used at
Joseph> toplevel.
Here's the pat
Joseph> I'd say this global actually belongs somewhere in the
Joseph> diagnostic_context (i.e., instead of the
Joseph> diagnostic_context_auxiliary_data (DC) actually being a tree as
Joseph> it is at present, it should point to a structure with whatever
Joseph> extra information clients wish to use
> "Jeff" == Jeff Law writes:
>> One other random idea was something like:
>> GCC_METHOD7 (gcc_decl, build_decl,
>> const char *, /* Argument NAME. */
>> enum gcc_c_symbol_kind, /* Argument SYM_KIND. */
Jeff> Works for me.
I took this approach. Other changes in this version
Jeff> Just a nit. C-style comment would be appreciated. It might also help
Jeff> to clarify what "much more sane" really means here.
Jeff> Otherwise, it looks OK to me.
Here's the updated patch.
Tom
2014-06-19 Phil Muldoon
Tom Tromey
* c-tree.h (enum c_oracle_request
> "Tom" == Tom Tromey writes:
Tom> This patch series is half of a project to let gdb reuse gcc (which
Tom> half depends on which list you are seeing this on), so that users can
Tom> compile small snippets of code and evaluate them in the current
Tom> context of the inferior.
We've updated th
> Thirdly, we also need to fix movhi_bytes (for pre-v4) thumb2_movhi_insn
> (for thumb2) and, quite possibly, thumb1_movhi_insn (for thumb1). There
> may well be additional changes for movqi variants as well.
A general question: how should one test ARM backend patches? Is it
enough to regtest ARM
On 06/19/2014 12:36 PM, Jan Hubicka wrote:
>> On 06/19/2014 09:06 AM, Tom de Vries wrote:
>>>
>>> 2014-06-19 Tom de Vries
>>>
>>> * final.c (collect_fn_hard_reg_usage): Don't save function_used_regs if
>>> it contains all call_used_regs.
>>
>> Ok.
>
> When we now have way to represent d
> On 06/19/2014 09:06 AM, Tom de Vries wrote:
> >
> > 2014-06-19 Tom de Vries
> >
> > * final.c (collect_fn_hard_reg_usage): Don't save function_used_regs if
> > it contains all call_used_regs.
>
> Ok.
When we now have way to represent different reg usages for functions, what
would
On 06/19/2014 11:25 AM, Tom de Vries wrote:
> On 19-06-14 05:53, Richard Henderson wrote:
>> On 06/01/2014 03:00 AM, Tom de Vries wrote:
>>> >+aarch64_emit_call_insn (rtx pat)
>>> >+{
>>> >+ rtx insn = emit_call_insn (pat);
>>> >+
>>> >+ rtx *fusage = &CALL_INSN_FUNCTION_USAGE (insn);
>>> >+ clo
On 19-06-14 05:53, Richard Henderson wrote:
On 06/01/2014 03:00 AM, Tom de Vries wrote:
>+aarch64_emit_call_insn (rtx pat)
>+{
>+ rtx insn = emit_call_insn (pat);
>+
>+ rtx *fusage = &CALL_INSN_FUNCTION_USAGE (insn);
>+ clobber_reg (fusage, gen_rtx_REG (word_mode, IP0_REGNUM));
>+ clobber_re
On Thu, Jun 19, 2014 at 04:56:53PM +0200, Marek Polacek wrote:
> + /* Don't instrument this FMA-like array in non-strict
Also, please don't use FMA to mean flexible member array, it is
flexible array member, but more importantly, FMA is used for fused
multiply-add, so IMHO it is better to spel
Hi!
On Thu, Jun 19, 2014 at 04:56:53PM +0200, Marek Polacek wrote:
Thanks for working on this.
> --- gcc/asan.c
> +++ gcc/asan.c
> @@ -2761,6 +2761,9 @@ pass_sanopt::execute (function *fun)
> case IFN_UBSAN_NULL:
> ubsan_expand_null_ifn (gsi);
> break;
> +
> Hi,
>
> On Wed, Jun 18, 2014 at 06:12:34PM +0200, Bernhard Reutner-Fischer wrote:
> > On 18 June 2014 10:24:16 Martin Jambor wrote:
> >
> > >@@ -3002,10 +3014,8 @@ try_make_edge_direct_virtual_call (struct
> > >cgraph_edge *ie,
> > >
> > > if (target)
> > > {
> > >-#ifdef ENABLE_CHECKING
On 06/19/2014 09:40 AM, Richard Henderson wrote:
> It appears that regs_ever_live includes any register mentioned explicitly, and
> thus the only registers it doesn't contain are those killed by the callees.
> That should be an easier scan than the rtl, since we have those already
> collected in th
On 06/19/2014 09:37 AM, Tom de Vries wrote:
> On 19-06-14 05:59, Richard Henderson wrote:
>> On 06/01/2014 04:27 AM, Tom de Vries wrote:
>>> + if (TARGET_AAPCS_BASED)
>>> +{
>>> + /* For AAPCS, IP and CC can be clobbered by veneers inserted by the
>>> + linker. We need to add these t
On 06/19/2014 09:07 AM, Tom de Vries wrote:
>
> 2014-06-19 Tom de Vries
>
> * final.c (collect_fn_hard_reg_usage): Add separate IOR_HARD_REG_SET for
> get_call_reg_set_usage.
Ok, as far as it goes, but...
It seems like there should be quite a bit of overlap with regs_ever_live he
On 19-06-14 05:59, Richard Henderson wrote:
On 06/01/2014 04:27 AM, Tom de Vries wrote:
+ if (TARGET_AAPCS_BASED)
+{
+ /* For AAPCS, IP and CC can be clobbered by veneers inserted by the
+linker. We need to add these to allow
+arm_call_fusage_contains_non_callee_clobbe
On 19/06/14 16:12, Kyrill Tkachov wrote:
On 19/06/14 16:05, Marat Zakirov wrote:
Hi all,
Here's a patch for PR 61561
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61561).
It fixes ICE.
Thanks for your contribution.
However, this is *really* not the way to submit a patch and is the sort
On 06/19/2014 09:06 AM, Tom de Vries wrote:
>
> 2014-06-19 Tom de Vries
>
> * final.c (collect_fn_hard_reg_usage): Don't save function_used_regs if
> it contains all call_used_regs.
Ok.
r~
On Thu, Jun 19, 2014 at 04:56:53PM +0200, Marek Polacek wrote:
> Regtested/bootstrapped on x86_64-linux. How does this look?
Now even bootstrap-ubsan passed, with 92258 runtime errors:
index 1 out of bounds for type 'rtunion [1]' - heh.
Marek
Hi,
from a recent discussion on g...@gcc.gnu.org I have learned that the default of
--param allow-store-data-races is still 1, and it is causing problems.
Therefore I would like to suggest to change the default of this option to 0.
Boot-strapped and regression tested on x86_64-linux-gnu.
Ok for t
Richard,
atm the moment, when processing a call in collect_fn_hard_reg_usage, we get the
used regs from the callee, but forget to register the regs in the call insn
itself (ouch). This patch fixes this by introducing an extra IOR_HARD_REG_SET.
We also switch the order of find_all_hard_reg_se
On 19-06-14 07:13, Richard Henderson wrote:
On 05/19/2014 07:30 AM, Tom de Vries wrote:
+ for (insn = get_insns (); insn != NULL_RTX; insn = next_insn (insn))
+{
+ HARD_REG_SET insn_used_regs;
+
+ if (!NONDEBUG_INSN_P (insn))
+ continue;
+
+ find_all_hard_reg_sets (insn
On 19/06/14 16:05, Marat Zakirov wrote:
> Hi all,
>
> Here's a patch for PR 61561
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61561).
>
> It fixes ICE.
>
> Reg. tested on arm15.
>
> --Marat
>
>
> arm.md.diff.diff
>
>
> gcc/ChangeLog:
>
> 2014-06-19 Marat Zakirov
>
> * config
> + (if_then_else (match_operand 1 "const_int_operand"
> "")
> +(const_string "mov_imm" )
> +(const_string "mov_reg"))])]
Why not just mov_reg?
> * config/arm/arm.md: New templates see pr6156
On 06/19/2014 01:39 AM, Tom de Vries wrote:
> On 19-06-14 05:53, Richard Henderson wrote:
>> Do we in fact make sure this isn't an ifunc resolver? I don't immediately
>> see
>> how those get wired up in the cgraph...
>
> Richard,
>
> using the patch below I changed the
> gcc/testsuite/gcc.targe
On 06/19/2014 05:39 AM, Tom de Vries wrote:
>
> 2014-06-19 Tom de Vries
>
> * final.c (collect_fn_hard_reg_usage): Add and use variable
> function_used_regs.
Looks good, thanks.
r~
On 19/06/14 16:05, Marat Zakirov wrote:
Hi all,
Here's a patch for PR 61561
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61561).
It fixes ICE.
Reg. tested on arm15.
CC'ing the arm maintainers...
Kyrill
--Marat
Hi all,
Here's a patch for PR 61561
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61561).
It fixes ICE.
Reg. tested on arm15.
--Marat
arm.md.diff.diff
Description: Binary data
On Mon, Jun 16, 2014 at 01:23:04PM +0200, Jakub Jelinek wrote:
> On Mon, Jun 16, 2014 at 12:39:07PM +0200, Marek Polacek wrote:
> > Jason/Joseph, could you please look at the C++/C FE parts?
>
> As mentioned on IRC, you need to differentiate between taking address
> and not taking address.
>
> st
Hi,
This patch updates a number of aapcs64 tests to make them big-endian
friendly. Changes are mainly:
* checking the W regs instead of X regs for integral arguments less than
8 bytes
* correcting the corresponding stack location checks in big-endian mode
With this patch, make check-gcc RU
This backports straightforwardly; no regressions on arm-none-eabi or
armeb-none-eabi, and FAIL->PASS of the new ZIP, UZP, and TRN execution tests
from r209908, r209947 and r210422 (running locally).
--Alandiff --git a/gcc/config/arm/arm_neon.h b/gcc/config/arm/arm_neon.h
index 4d945ce..a930e05
On Fri, May 16, 2014 at 11:30:38AM +0100, James Greenhalgh wrote:
> On Fri, Mar 28, 2014 at 03:39:53PM +, James Greenhalgh wrote:
> > On Fri, Mar 28, 2014 at 03:09:22PM +, pins...@gmail.com wrote:
> > > > On Mar 28, 2014, at 7:48 AM, James Greenhalgh
> > > > wrote:
> > > > On Fri, Mar 28,
On 19-06-14 07:13, Richard Henderson wrote:
On 05/19/2014 07:30 AM, Tom de Vries wrote:
>+ for (insn = get_insns (); insn != NULL_RTX; insn = next_insn (insn))
>+{
>+ HARD_REG_SET insn_used_regs;
>+
>+ if (!NONDEBUG_INSN_P (insn))
>+ continue;
>+
>+ find_all_hard_reg_sets (
> On 06/16/14 14:13, Zamyatin, Igor wrote:
> > Hi All!
> >
> > The patch fixes ICE in array notation for the cases of incorrect arguments
> > of
> Cilk+ builtins and undeclared initial index.
> >
> > Is it ok for trunk and 4.9?
> >
> > Thanks,
> > Igor
> >
> > diff --git a/gcc/c/ChangeLog b/gcc/c/
This updates the .md files to generate V1DFmode patterns instead of DFmode for
create and reinterpret, and the corresponding __builtins.
The various other float64x1_t intrinsics can then be rewritten, generally I've
tried to use gcc vector extensions rather than unnecessary/custom builtins wher
On 19-06-14 05:21, Richard Henderson wrote:
On 06/01/2014 03:00 AM, Tom de Vries wrote:
+/* Emit call insn with PAT and do aarch64-specific handling. */
+
+bool
+aarch64_emit_call_insn (rtx pat)
+{
+ rtx insn = emit_call_insn (pat);
+
+ rtx *fusage = &CALL_INSN_FUNCTION_USAGE (insn);
+ clobb
According to the ARM C Language Extensions the 64x1 types should all be passed
in the SIMD registers rather than GPRs, and should not be assignment-compatible
with [u]int64_t / float64_t (as they are at present). These two patches (first
for float64x1_t, second for [u]int64x1_t) make these types
> Not only is it 'obvious' but it can do no harm in any circumstances
> :-) OK to commit
True! Committed as rev. 211822
FX
Hi,
On Wed, Jun 18, 2014 at 06:12:34PM +0200, Bernhard Reutner-Fischer wrote:
> On 18 June 2014 10:24:16 Martin Jambor wrote:
>
> >@@ -3002,10 +3014,8 @@ try_make_edge_direct_virtual_call (struct
> >cgraph_edge *ie,
> >
> > if (target)
> > {
> >-#ifdef ENABLE_CHECKING
> >- gcc_assert
On Thu, 19 Jun 2014, Jason Merrill wrote:
We were treating a const & member function like a normal const reference, and
binding an rvalue object argument to it. But it doesn't work that way.
That looks weird to me. The const&& version is a better match than the
const&, so we should pick that
Dear FX,
Not only is it 'obvious' but it can do no harm in any circumstances
:-) OK to commit
Thanks
Paul
On 19 June 2014 13:14, FX wrote:
> In expr.c:scalarize_intrinsic_call(), we don't deal correctly with intrinsics
> that have an optional kind argument, while simplifying initialization
In expr.c:scalarize_intrinsic_call(), we don't deal correctly with intrinsics
that have an optional kind argument, while simplifying initialization
expressions. The attached one-line patch fixes it, and adds a testcase so we
don’t regress.
Bootstrapped and regtested on x86_64-apple-darwin13.
OK
On 18 Jun 16:22, Bernd Schmidt wrote:
> What I think you need to do is
> For the first compiler:
> --enable-as-accelerator-for=x86_64-pc-linux-gnu
> --target=x86_64-intelmic-linux-gnu --prefix=/somewhere
>
> No --enable-accelerator options at all. This should work, if it
> doesn't let me know what
Hello Nicholas,
First of all, thank you for taking the time to dive into this code and
provide such a detailed analysis along with a patch. This is
appreciated.
Please find below my comments to some parts of your message.
Nicholas Ormrod a écrit:
> PR preprocessor/60723
>
> Description:
>
>
On 17 June 2014 17:42, Zhenqiang Chen wrote:
> On 17 June 2014 16:15, Richard Biener wrote:
>> On Tue, Jun 17, 2014 at 4:11 AM, Zhenqiang Chen
>> wrote:
>>> Hi,
>>>
>>> For some large constant, ports like ARM, need one more instructions to
>>> operate it. e.g
>>>
>>> #define MASK 0xfe00ff
>>> vo
Hi Richard,
Please find attached the patch implementing load-load/store-store bonding
supported by P5600.
In P5600, 2 consecutive loads/stores of same type which access contiguous
memory locations are bonded together by instruction issue unit to dispatch
single load/store instruction which acc
On 06/19/2014 12:12 AM, Jason Merrill wrote:
We were treating a const & member function like a normal const
reference, and binding an rvalue object argument to it. But it doesn't
work that way.
In 4.9 we also need to set LOOKUP_NO_TEMP_BIND.
commit 48ca9803695872d984b0f4efa56f7f58987d0928
A
On 19-06-14 05:53, Richard Henderson wrote:
Do we in fact make sure this isn't an ifunc resolver? I don't immediately see
how those get wired up in the cgraph...
Richard,
using the patch below I changed the
gcc/testsuite/gcc.target/i386/fuse-caller-save.c testcase to use an ifunc
resolver,
This patches fixes a few bugs related to CO_MIN/MAX/SUM:
* The recent patch missed to update the argument in trans-intrinsic, it
had the changes only in trans-decl and libgfortran/caf.
* in libcaf_single, setting stat to 0 had a bug
* There were several multi-image bugs in the collective_2.
Ad
62 matches
Mail list logo
