On 20 Aug 08:30, Richard Henderson wrote:
Hello,
> This is ok.
Checked into main trunk: http://gcc.gnu.org/ml/gcc-cvs/2013-08/msg00504.html
--
Thanks, K
[RFC] Allow functions calling mcount before prologue to be leaf functions
http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00993.html
[PATCH] PR57377: Fix mnemonic attribute
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01364.html
[PATCH] Doc: Add documentation for the mnemonic attribute
http://gcc.gn
Hi,
On Tue, Aug 20, 2013 at 11:01:04PM +0200, Jan Hubicka wrote:
[...]
> > Currently to access the base symtab fields of a cgraph or varpool
> > node, the code has e.g.
> >
> >node->symbol.decl
> >
> > whereas with C++ inheritance, the "symbol" field is no more, and we
> >
Hi,
Several ports in gcc support conditional compare instructions which is
an efficient way to handle SHORT_CIRCUIT. But the information is not
represented in TREE or GIMPLE. And it depends on BRANCH_COST and
combine pass to generate the instructions.
To explicitly represent the semantics of cond
Hi,
The attached patch is the basic support for conditional compare (CCMP). It
adds
a set of keywords on TREE to represent CCMP:
DEFTREECODE (TRUTH_ANDIF_LT_EXPR, "truth_andif_lt_expr", tcc_ccomparison, 3)
DEFTREECODE (TRUTH_ANDIF_LE_EXPR, "truth_andif_le_expr", tcc_ccomparison, 3)
DEFTREECODE (T
Hi,
The attached patch enables uninit pass to handle conditional compare (CCMP).
CCMP is a combine of BIT_AND_EXPR/BIT_IOR_EXPR and CMP expression. The codes
are similar with those to handle BIT_AND_EXPR/BIT_IOR_EXPR and CMP
expression.
Bootstrap on x86-64 and ARM Chromebook.
No ICE and runtime e
On 08/19/2013 11:05 PM, Jeff Law wrote:
> On 07/20/2013 03:02 AM, Alexey Makhalov wrote:
>> Hello!
>>
>> If delete_unmarked_insns deletes some insn, DF state might be
>> out of date, and, regs_ever_live might contain unused registers till
>> the end.
(I can't find the original mail either in my ma
Hi,
in mainline we don't ICE anymore. Tested x86_64-linux multilib.
Thanks,
Paolo.
2013-08-21 Paolo Carlini
PR c++/56134
* g++.dg/ext/attr-alias-3.C: New.
Index: g++.dg/ext/attr-alias-3.C
==
Just something else I saw while analyzing dumps from an unrelated set of
changes.
It's relatively common to see sequences like this:
# parent_1 = PHI
_11 = single_tree_10(D) != 0;
_12 = parent_1 == 0B;
_13 = _11 & _12;
if (_13 != 0)
goto ;
else
goto ;
Where VRP can deduc
On Wed, 2013-07-31 18:34:26 +0200, Jan-Benedict Glaw wrote:
> Hi!
>
> We've seen ICEs while outputting an operand (not even the excessive
> CISC of a VAX could do that), which should be fixed by this patch:
>
> 2013-07-31 Jan-Benedict Glaw
>
> * config/vax/constraints.md (T): Add missi
Hi,
this bug points out that we fail to emit deprecated warnings when
references are involved. Turns out that at the end of
finish_id_expression the VAR_DECL is wrapped in INDIRECT_REF. The
trivial patch below appears to work fine and should be pretty safe in
terms of false positives, because
> +/* Knob to control hot-caller heuristic. 0 means it is turned off, 1 means
> + it is always applied, and 2 means it is applied only if the footprint is
> + smaller than PARAM_HOT_CALLER_CODESIZE_THRESHOLD. */
> DEFPARAM (PARAM_INLINE_HOT_CALLER,
> "inline-hot-caller",
> "Co
Hi,
this is my attempt to bring GCC into wonderful era of multicore CPUs :)
It is a hack, but it seems to help quite a lot. About 50% of WPA time is spent
by streaming the individual ltrans .o files. This can be easily parallelized
by fork - we do nothing afterwards, just exit and pass the list t
Alexander Ivchenko writes:
> Hi Joseph, thanks for your comments.
>
> I updated the patch:
>
> 1) The function name as a second argument in libc_has_function target
> hook was removed - was not usefull so far.
> 2) By using contrib/config-list.mk (thanks for the hint - great tool!)
> and analysin
Hi,
as Martin noticed, there is bug in ipa_profile that first allocate order array
and then introduce new local aliases before calling ipa_reverse_postorder.
Fixed thus and committed as obvious.
Honza
Index: ChangeLog
===
--- ChangeL
This patch has caused a bootstrap failure for powerpc-aix and probably
powerpc64-linux. GCC segfaults and core dumps during stage2
configure.
The motivation for this patch seems faulty and I strongly request that
it be reverted.
PR bootstrap/58206
Thanks, David
This patch adds a custom HTM fast path for RTM on x86_64, which moves
the core HTM fast path bits from gtm_thread::begin_transaction into the
x86-specific ITM_beginTransaction implementation. It extends/changes
the previous patch by Andi:
http://gcc.gnu.org/ml/gcc-patches/2013-01/msg01228.html
Th
Having a C++ type with the same name as the variable reg_equivs causes
trouble with gdb, so I renamed the struct.
Bootstrapped on i686-pc-linux-gnu.
Committed as obvious.
2013-08-21 Joern Rennecke
* reload.h (struct reg_equivs): Rename to ..
(struct reg_equivs_s): .. this.
I
On Wed, Aug 21, 2013 at 04:17:48PM +0200, Jan Hubicka wrote:
> Hi,
> this is my attempt to bring GCC into wonderful era of multicore CPUs :)
> It is a hack, but it seems to help quite a lot. About 50% of WPA time is
> spent
> by streaming the individual ltrans .o files. This can be easily parall
On 08/21/2013 08:25 AM, David Edelsohn wrote:
This patch has caused a bootstrap failure for powerpc-aix and probably
powerpc64-linux. GCC segfaults and core dumps during stage2
configure.
The motivation for this patch seems faulty and I strongly request that
it be reverted.
Instead of going ins
> >
> > Because offline COMDAT functoin will be porduced for every COMDAT used, I
> > think
> > it is bad to porduce any COMDAT (or any reachable function via calls with
> > non-0
> > count) that has empty profile (either because it got lost by COMDAT merging
> > or because of reading mismatch).
Even more review stuff. Are you keeping track of all this Balaji? :)
+ if (warn)
+warning (0, "suspicious use of _Cilk_spawn");
First, as I've mentioned, this error message is very ambiguous. You
should strive to provide better error messages. See my previous comment
on this same lin
On Wed, Aug 21, 2013 at 5:10 PM, Jeff Law wrote:
> On 08/21/2013 08:25 AM, David Edelsohn wrote:
>>
>> This patch has caused a bootstrap failure for powerpc-aix and probably
>> powerpc64-linux. GCC segfaults and core dumps during stage2
>> configure.
>>
>> The motivation for this patch seems faul
Andi Kleen wrote:
>On Wed, Aug 21, 2013 at 04:17:48PM +0200, Jan Hubicka wrote:
>> Hi,
>> this is my attempt to bring GCC into wonderful era of multicore CPUs
>:)
>> It is a hack, but it seems to help quite a lot. About 50% of WPA
>time is spent
>> by streaming the individual ltrans .o files. Th
Hi again,
On 08/21/2013 03:45 PM, Paolo Carlini wrote:
Hi,
this bug points out that we fail to emit deprecated warnings when
references are involved. Turns out that at the end of
finish_id_expression the VAR_DECL is wrapped in INDIRECT_REF. The
trivial patch below appears to work fine and sh
> I also fail to see why threads should not work here. Maybe simply annotate
> gcc with openmp?
Don't you have to set a environment variable to set the number of threads
for openmp?
Otherwise it sounds like a reasonable way to do it.
-Andi
On 08/08/13 14:38, Richard Earnshaw wrote:
> PR target/56979 is a bug where a parameter to a function has an
> alignment that is larger than its natural alignment. In this case this
> causes the mid-end to generate a mode for the argument that is
> incompatible with the registers that are assigned
> You are right, we need discriminator for non-CALL stmts too. Patch updated:
OK for google branches. Thanks!
-cary
Torvald Riegel writes:
> +#endif
> leaq8(%rsp), %rax
> - subq$56, %rsp
> - cfi_def_cfa_offset(64)
> + subq$64, %rsp
> + cfi_def_cfa_offset(72)
I don't see why you did this change and the addq change below.
The rest seems reasonable to me, although I haven't trie
> We already support the .blahblah syntax in the demangler in d_print_comp.
> (I think it deserve to be extended to special case some newly introduced
> mess, like .ltopriv and .local_alias)
> I wonder if we don't want to get the mangling here to be consistent, so
> users are facing the same type o
On 08/10/2013 06:03 AM, Richard Biener wrote:
Mike Stump wrote:
On Aug 9, 2013, at 3:36 PM, Diego Novillo wrote:
This patch is still WIP. It builds stage1, but I'm getting ICEs
during stage 2.
The patch splits tree.h into three files:
- tree-core.h: All data structures, enums and typedefs
> (I can't find the original mail either in my mailbox or in the archives).
It's PR rtl-optimization/57940.
--
Eric Botcazou
On Wed, 2013-08-21 at 10:14 -0700, Andi Kleen wrote:
> Torvald Riegel writes:
> > +#endif
> > leaq8(%rsp), %rax
> > - subq$56, %rsp
> > - cfi_def_cfa_offset(64)
> > + subq$64, %rsp
> > + cfi_def_cfa_offset(72)
>
> I don't see why you did this change and the addq change bel
> That's true for x86, but it seems that for s390, we can't easily put the
> xbegin/tbegin into the C++ code because of floating point register
> save/restore issues. The added complexity on the x86 side seemed to be
> a reasonable price for having a general HTM fast path retry handling on
> the C
> -#if defined(USE_HTM_FASTPATH) && !defined(HTM_CUSTOM_FASTPATH)
> +#ifdef USE_HTM_FASTPATH
>// HTM fastpath. Only chosen in the absence of transaction_cancel to allow
>// using an uninstrumented code path.
>// The fastpath is enabled only by dispatch_htm's method group, which uses
>
On Wed, 2013-08-21 at 19:41 +0200, Andi Kleen wrote:
> > That's true for x86, but it seems that for s390, we can't easily put the
> > xbegin/tbegin into the C++ code because of floating point register
> > save/restore issues. The added complexity on the x86 side seemed to be
> > a reasonable price
On 08/21/2013 10:14 AM, Andi Kleen wrote:
> The rest seems reasonable to me, although I haven't tried to untangle
> the full dependencies between C++ and asm code for retries.
> It would be likely cleaner to just keep the retries fully
> in C++ like the original patch did. There's no advantage
> of
Hi,
earlier today noticed three spots where we don't use the existing
INDIRECT_REF_P predicate. I think the patch qualifies as obvious, and
I'm going to apply it later today.
Thanks,
Paolo.
/
2013-08-21 Paolo Carlini
* call.c (build_new_method_call_1): Use
OK.
Jason
On 08/21/2013 11:32 AM, Eric Botcazou wrote:
(I can't find the original mail either in my mailbox or in the archives).
It's PR rtl-optimization/57940.
It was also on the mailing list too. If I'd had the reference to 57940,
I wouldn't have approved the patch given your comment from July 20.
On 08/21/2013 09:31 AM, Aldy Hernandez wrote:
May I stress again the importance of tests-- which are especially
critical for new language features. You don't want cilk silently
breaking thus rendering all your hard work moot, do you? :))
Agreed. While we don't have a strict policy for testing
Hi, there are still a couple of problems with my patch:
The build is broken for the following targets:
1) *linux* targets that do not include config/linux.h in their tm.h
(e.g alpha-linux, ppc64-linux etc). For them we have:
../../../../gcc/gcc/config/linux-android.c: In function ‘bool
linux_andr
Right now, the API to register a requested jump thread passes three
edges. The incoming edge we traverse, the outgoing edge we know will be
taken as a result of traversing the incoming edge and an optional edge
to allow us to find the joiner block when we thread through a join node.
Note th
I attached the wrong version of the patch in my last message. It was
missing the declaration of "e3". Fixed obviously.
Sorry,
Jeff
> -Original Message-
> From: Aldy Hernandez [mailto:al...@redhat.com]
> Sent: Wednesday, August 21, 2013 11:31 AM
> To: Iyer, Balaji V
> Cc: r...@redhat.com; Jeff Law; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] Cilk Keywords (_Cilk_spawn and _Cilk_sync) for C
>
> Even more review stu
Hi Mikael,
> Regression tested on x86_64-unknown-linux-gnu. OK for trunk/4.8?
OK for both. Thanks for the patch!
Thomas
On 08/21/2013 11:28 AM, Kirill Yukhin wrote:
>>> + && (mode == XImode
>>> + || VALID_AVX512F_REG_MODE (mode)
>>> + || VALID_AVX512F_SCALAR_MODE (mode)))
>>> + return true;
>>> +
>>> + /* In xmm16-xmm31 we can store only 512 bit modes. */
>>> + if (EXT_REX_SSE_REGNO_
On Mon, 2013-08-05 at 08:26 -0600, Tom Tromey wrote:
> > "David" == David Malcolm writes:
>
> David> GDB 7.0 onwards supports hooks written in Python to improve the
> David> quality-of-life within the debugger. The best known are the
> David> pretty-printing hooks [1], which we already use w
Hit this building with --enable-checking=yes,rtl,df. Seemed obvious
enough so I went ahead and applied it. The definition in rtl.c was
already OK.
Richard
gcc/
* rtl.h (hwivec_check_failed_bounds): Fix prototype.
Index: gcc/rtl.h
===
Ping? Ping?
On Wed, Aug 14, 2013 at 12:14 PM, Caroline Tice wrote:
> Ping?
>
> On Thu, Aug 8, 2013 at 3:16 PM, Caroline Tice wrote:
>> This patch replaces the fixed sized array that was holding vtable
>> pointers for a particular class hierarchy with a vector, allowing for
>> dynamic resizing.
In trunk this is a comparison between signed values, but uhwi probably
does make more sense here.
Tested on mips64-linux-gnu, where it fixes the build, and applied.
Richard
gcc/
* config/mips/mips.c (r10k_safe_mem_expr_p): Fixed signed vs.
unsigned warning.
Index: gcc/config/mi
> "David" == David Malcolm writes:
Tom> Naughty.
David> We chatted about this at Cauldron; I haven't yet had a chance to
David> implement the magic bullet approach we discussed there. In the
David> meantime, is there a API I can call to determine how safe this kludge
David> is?
Not right n
Le 19/08/2013 13:38, Janus Weil a écrit :
> Hi all,
>
> here is a small patch which does some cleanup to avoid an ICE on
> invalid SELECT TYPE statements.
>
> The first three hunks are just cosmetics, and the fourth one also
> contains minor refactoring, where I pull some common code out of the
>
On Aug 21, 2013, at 10:23 AM, Andrew MacLeod wrote:
> On 08/10/2013 06:03 AM, Richard Biener wrote:
>> Mike Stump wrote:
>>> On Aug 9, 2013, at 3:36 PM, Diego Novillo wrote:
This patch is still WIP. It builds stage1, but I'm getting ICEs
during stage 2.
The patch splits tre
> > We already support the .blahblah syntax in the demangler in d_print_comp.
> > (I think it deserve to be extended to special case some newly introduced
> > mess, like .ltopriv and .local_alias)
> > I wonder if we don't want to get the mangling here to be consistent, so
> > users are facing the s
> >
> >One risk is if someone streams to a spinning disk it may add more seeks
> >for
> >the parallel IO. But I think it's a reasonable tradeoffs.
>
> It'll also wreck all WPA dump files.
We do not dump anything during the main streaming. If we now stream 2GB for
firefox,
I think we can hope t
>
> We should also use a faster compressor
Yep, at least once it arrives higher in profiles. So far other stuff is a lot
slower.
>
> > For -flto=jobserver I simply fork all 32 processes. It may not be a
> > disaster,
> > but perhaps we should figure out how to communicate with jobserver. At
Hi,
this patch fixes some issues with ipa-devirt I noticed since the initial
commit.
1) I added fixes and comments Doji suggested (thanks!)
2) During the callgraph construction new external nodes may be created that
needs to be added into the inheritance graph get more complette andwers
On Aug 1, 2013, at 8:09 AM, Jan Hubicka wrote:
> Now when we have abstract origins tracked, this patch makes DECL_ARGUMENTS and
> DECL_RESULT to be removed from FUNCTION_DECLs that are never passed to symbol
> table. This reduces LTO streaming effort (by about 1/3rd of PARM_DECls)
So, I was trac
Change vector::at() call to vector::operator[]().
Booted and tested with -m32, -m64 and -m64 debug-mode under x86_64
GNU/Linux and committed(r201914).
--
Tim Shen
This patch corrects the powerpc64le-linux multiarch directory, adds
opposite-endian multilibs, and chooses non-multiarch os dirs for the
new multilibs.
For multiarch, powerpc64le-linux now will use powerpc64le-linux-gnu.
Given a typical big-endian native toolchain with os dirs /lib and
/lib64, we'
Hello,
> The patch is ok to commit.
Thanks a lot! Checked in to main trunk:
http://gcc.gnu.org/ml/gcc-cvs/2013-08/msg00524.html
--
K
> So, I was tracking down an lto failure in the C++ test suite,
> g++.dg/ipa/pr46984.C, and it appears to be caused by
> 4df870fdeec85907db3dcabf1992cf8b63e1d562 aka
> svn+ssh://gcc.gnu.org/svn/gcc/trunk@201468. I was trying to find the
> gcc-patches email for this work, but could not. :-( A
63 matches
Mail list logo
