The attached patch fixes the regression in gcc.dg/attr-ifunc-4.c (PR 58398).
The problem is that the resolver function just looks like an alias, but it
actually is
something completely different. So inlining the resolver function has to be
avoided.
The patch was bootstrapped and regression-test
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of bin.cheng
> Sent: Thursday, September 12, 2013 2:13 PM
> To: 'Bill Schmidt'; Yufeng Zhang; Yufeng Zhang
> Cc: Richard Biener; GCC Patches
> Subject: RE: [PATCH GCC]Catch more
m32c's PSImode is 24-bits, why does it have "32" in the macro?
/* 24-bit pointers, in 32-bit units */
-PARTIAL_INT_MODE (SI);
+PARTIAL_INT_MODE_NAME (SI, 32, PSI);
> -Original Message-
> From: Richard Earnshaw
> Sent: Thursday, September 12, 2013 11:24 PM
> To: Bin Cheng
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH ARM]Extend thumb1_reorg to save more comparison
> instructions
>
> On 18/04/13 06:34, Bin Cheng wrote:
>
> Sorry for the delay,
On Tue, Jun 11, 2013 at 07:43:05PM -0400, Michael Meissner wrote:
> Ah, you are correct. I misread the code, thinking it was returning a string,
> and not a pointer to the string in memory.
http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00640.html
Patch reverted.
--
Alan Modra
Australia Developme
Hi,
for this kind of code:
template class F, typename T> struct apply
{ typedef F type; };
template using map = const T;
static_assert(std::is_same::type, const int>::value, "");
line #11542 of pt.c, in tsubst is reached:
r = lookup_template_class (arg,
argve
On 16.09.2013 17:54, Eric Botcazou wrote:
Apologies if this was out of context. This was a change suggested
and
reviewed by Jason
(http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01114.html).
Then don't repost it on gcc-patches, it is already available on
gcc-cvs:
http://gcc.gnu.org/ml/gcc-c
On 09/16/2013 07:32 PM, Marc Glisse wrote:
New version that passed testing.
Looks good to me, thanks!
Paolo.
There are two separate root causes for the problem reported in PR
57393. This patch attempts to fix both.
First is due to newly created stmts that have the default UID of 0
which are compared with statements with valid UIDs leading to broken
dependences. As discussed in an earlier thread, I check
On Thu, Sep 12, 2013 at 09:33:05AM +0100, Andrew Haley wrote:
> On 09/12/2013 03:11 AM, Alan Modra wrote:
> > We have precedent for compiling libffi based on gcc preprocessor
> > defines, eg. __NO_FPRS__, so here's a way of making upstream libffi
> > compatible with the various versions of gcc out
Hi,
On Sun, Sep 15, 2013 at 06:55:17PM +0200, Bernd Edlinger wrote:
> Hello Richard,
>
> attached is my second attempt at fixing PR 57748. This time the
> movmisalign path is completely removed and a similar bug in the read
> handling of misaligned structures with a non-BLKmode is fixed
> too. Th
On Sep 16, 2013, at 2:09 AM, Richard Biener wrote:
>> Here is the patch to add precision to partial int modes. I included
>> switching over the rs6000 port to the new scheme so one can get a feel for
>> that it would look like.
> Can you instead of adding PARTIAL_INT_MODE_N change all existing
Nobody has expressed concern for a week, so it may be worth doing an
official review ;-)
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00676.html
On Mon, 9 Sep 2013, Marc Glisse wrote:
I have now tested bootstrap+testsuite and there was no regression.
2013-09-07 Marc Glisse
PR c++
Forgot this bit, committed.
* config/rl78/vregs.h: Add G10 register definitions.
Index: config/rl78/vregs.h
===
--- config/rl78/vregs.h (revision 202637)
+++ config/rl78/vregs.h (working copy)
@@ -8,12 +8,35 @@ r_2 =
Janus Weil wrote:
(The same problem I had yesterday: Three emails didn't make it.)
Any idea what's the reason for this?
No idea. Usually, one gets a bounce message but this time one didn't.
Thus, I have no possibility to debug this from my side. #overseers
didn't see it as their business and
On 09/16/2013 05:28 AM, Richard Biener wrote:
which exhibits exactly the behavior you quote - return x is considered throwing
an exception. The C++ FE doesn't arrange for TREE_THIS_NOTRAP to be
set here (maybe due to this issue you quote?).
I haven't been aware of TREE_THIS_NOTRAP, but we coul
Just for completeness. Installed.
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index f606965..7150063 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2013-09-16 Jeff Law
+
+ * gcc.c-torture/execute/pr58419.c: New test.
+ * gc
This patch adds support for the RL78/G10 variant, which doesn't have
register banks like the other RL78 chips. Committed.
* config/rl78/rl78.c (rl78_asm_file_start): Specify alternate
vregs location for RL78/G10.
(rl78_expand_prologue): Avoid SEL on G10.
(rl78_exp
Ok -- abandon the patch.
On Mon, Sep 16, 2013 at 2:04 AM, Richard Biener
wrote:
> On Sat, Sep 14, 2013 at 8:10 AM, Xinliang David Li wrote:
>> tree if conversion is an enabler pass for vectorization, so by
>> default, it is only turned on when vectorization is on, but may also
>> depend on the o
Paolo> The series looks okay to me with that change.
Two last questions while I'm testing my rebase --
First, do you mind if I resend the whole series? Otherwise I can try to
pick out just the patches that have changed, plus the additional
patches.
Second, should I get a separate ok for the cha
On Mon, Sep 16, 2013 at 4:50 PM, Michael Matz wrote:
>> > Why do you think so? The t-* frags are includes via
>> > ...
>> > tmake_file=...$(srcdir)/config/i386/t-i386
>> > ...
>> > ifneq ($(tmake_file),)
>> > include $(tmake_file)
>> > endif
>> > ...
>> >
>> > It's just that there's no t-alpha f
> Contrary to Janus' second
> patch review of today which didn't went past GCC's mail server.
Huh, indeed. I hadn't noticed ...
> (The same
> problem I had yesterday: Three emails didn't make it.)
Any idea what's the reason for this?
Cheers,
Janus
On Mon, Sep 16, 2013 at 3:13 AM, Richard Biener
wrote:
> On Fri, Sep 13, 2013 at 5:16 PM, Xinliang David Li wrote:
>> On Fri, Sep 13, 2013 at 1:30 AM, Richard Biener
>> wrote:
>>> On Thu, Sep 12, 2013 at 10:31 PM, Xinliang David Li
>>> wrote:
Currently -ftree-vectorize turns on both loop
Yep, looked too quickly every time and thought the newline after "be
zero" was applying. Here is the patch with the fix. Ok for trunk
pending regression testing?
2013-09-16 Teresa Johnson
* coverage.c (get_coverage_counts): Add missing newline.
Index: coverage.c
==
I forgot, again, to attach the patch.
However, to my surprise the email made it through. Contrary to Janus'
second patch review of today which didn't went past GCC's mail server.
(The same problem I had yesterday: Three emails didn't make it.)
Tobias Burnus wrote:
There were two related issue
There were two related issues with the _vtab of CLASS(*): First, it was
crashing in the generation of the finalization wrapper. Secondly, one
needs to ensure that the _vtab contains a NULL pointer for _final.
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
Tobias
On Sep 16, 2013, at 5:10 AM, Nick Clifton wrote:
> The new MSP430 target has a few limitations which show up as
> unexpected failures in the GCC testsuite. I would like to apply the
> patch below to update target-supports.exp with this information.
> Applying the patch results in a drop of 13
I incorporated all the comments and committed the change (also fixed a
test failure with --help=optimizers).
thanks,
David
On Mon, Sep 16, 2013 at 3:07 AM, Richard Biener
wrote:
> On Fri, Sep 13, 2013 at 6:56 PM, Xinliang David Li wrote:
>> Updated patch implementing the logic that more specif
> "Uros" == Uros Bizjak writes:
Uros> Attached patch decleres dependecies for config/alpha/alpha.o.
Uros> 2013-09-16 Uros Bizjak
Uros> * config/alpha/t-alpha: New.
Uros> * config.gcc (alpha*-*-linux*): Add alpha/t-alpha to tmake_file.
Uros> (alpha*-*-freebsd*): Ditto.
Uros>
> On Sun, Sep 15, 2013 at 09:08:00PM +0200, Jan Hubicka wrote:
> > > 2013-09-13 Jakub Jelinek
> > >
> > > * ipa-prop.c (ipa_compute_jump_functions_for_edge): Return early
> > > for internal calls.
> >
> > That seems resonable. I wonder if we want to consider internal calls to
> > form
>
On Fri, Sep 13, 2013 at 08:01:36PM +0200, Marek Polacek wrote:
> 2013-09-13 Marek Polacek
>
> PR sanitizer/58413
> c-family/
> * c-ubsan.c (ubsan_instrument_shift): Don't instrument
> an expression if we can prove it is correct.
>
> testsuite/
> * c-c++-common/ubsan/shi
Looks like there is one missing spot:
@@ -349,7 +349,7 @@ get_coverage_counts (unsigned counter, u
(flag_guess_branch_prob
? "file %s not found, execution counts
estimated" <
: "file %s not foun
The description of the macro REVERSE_CONDEXEC_PREDICATES_P has been
removed from (gccint)Cond Exec Macros in r188983, but the now
effectively empty node has been left behind.
Tested with make info and installed as obvious.
Andreas.
* doc/tm.texi.in (Cond Exec Macros): Remove node.
New version that passed testing.
2013-09-16 Marc Glisse
PR libstdc++/58338
* include/bits/stl_vector.h (vector::vector(),
vector::vector(const allocator_type&)): Merge.
(_Vector_impl::_Vector_impl(_Tp_alloc_type const&),
_Vector_impl::_Vector_impl(_Tp_a
Il 16/09/2013 19:23, Tom Tromey ha scritto:
> Tom> I can try a test build using a setting for CC that rejects -c -o.
>
> I did this and the build died pretty early on:
>
> /home/tromey/Space/Trunk/Git/bin/my-cc -c -DHAVE_CONFIG_H -g -g -I.
> -I../../gcc/libiberty/../include -W -Wall -Wwrite-s
On Mon, Sep 16, 2013 at 10:57 AM, Xinliang David Li wrote:
> I noticed there are a couple of dump_printf_loc instances in
> coverage.c not ended with newline. They should be fixed.
I committed this change this morning as r202628. I believe I fixed all
the dump_printf_loc calls (just double-checke
>> Just notice another problem here:
>> processor_type only contains PROCESSOR_COREI7, so I cannot
>> differentiate Westmere and Sandybridge in x86-tune.def, which are
>> different for TARGET_FUSE_ALU_AND_BRANCH. So do I have to separate
>> m_SANDYBRIDGE out from m_COREI7?
>
> Yes, please.
>
> Than
I noticed there are a couple of dump_printf_loc instances in
coverage.c not ended with newline. They should be fixed.
David
On Tue, Sep 10, 2013 at 6:32 AM, Teresa Johnson wrote:
> On Mon, Sep 9, 2013 at 9:55 PM, Xinliang David Li wrote:
>> looks fine to me.
>>
>> In the long run, I wonder if t
Hi!
This patch fixes two issues I found on the pr58392.c testcase:
1) we weren't copying decl attributes, so e.g. inside #pragma omp parallel
"omp simd array" temporary arrays lost their attribute and weren't
adjusted because of that
2) DR_ALIGNED_TO wasn't reset after resetting DR_OFFSET on simd
Hello!
Attached patch synchronizes i386.o dependecies with i386.c.
2013-09-16 Uros Bizjak
* config/i386/t-i386 (i386.o): Update dependecies.
Bootstrap on x86_64-pc-linux-gnu is in progress.
Uros.
Index: config/i386/t-i386
=
Tom> I can try a test build using a setting for CC that rejects -c -o.
I did this and the build died pretty early on:
/home/tromey/Space/Trunk/Git/bin/my-cc -c -DHAVE_CONFIG_H -g -g -I.
-I../../gcc/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat
-Wstrict-prototypes -pedantic -fpi
> Apologies if this was out of context. This was a change suggested and
> reviewed by Jason
> (http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01114.html).
Then don't repost it on gcc-patches, it is already available on gcc-cvs:
http://gcc.gnu.org/ml/gcc-cvs/2013-09/msg00473.html
--
Eric Botcazo
Hi Christian,
Christian Bruel writes:
> @@ -6893,11 +6894,14 @@ label:
> ;; reloading MAC subregs otherwise. For that probably special patterns
> ;; would be required.
> (define_insn "*mov_reg_reg"
> - [(set (match_operand:QIHI 0 "arith_reg_dest" "=r")
> - (match_operand:QIHI 1 "register
Il 20/08/2013 15:59, Tom Tromey ha scritto:
> This converts the C front end.
>
> Note that this fixes a latent bug in gcc/Makefile.in's definition of
> C_TREE_H. This is needed to avoid breaking this build with this
> patch.
>
> * Makefile.in (C_TREE_H): Reference c/c-tree.h.
>
> *
On 13-09-16 11:39 AM, H.J. Lu wrote:
On Mon, Sep 16, 2013 at 8:12 AM, Vladimir Makarov wrote:
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58418
The patch also fixes a duplicated bug PR58419.
Shouldn't we also add a testcase from PR58419?
I've checked the test and
On Mon, Sep 16, 2013 at 06:04:23PM +0200, Jakub Jelinek wrote:
> On Mon, Sep 16, 2013 at 05:59:28PM +0200, Marek Polacek wrote:
> > Regtested/ran bootstrap-ubsan on x86_64-linux.
>
> That looks wrong. ubsan_type_descriptor shouldn't change TYPE_PRECISION of
> the type it has been called with, whe
Hello!
Attached patch decleres dependecies for config/alpha/alpha.o.
2013-09-16 Uros Bizjak
* config/alpha/t-alpha: New.
* config.gcc (alpha*-*-linux*): Add alpha/t-alpha to tmake_file.
(alpha*-*-freebsd*): Ditto.
(alpha*-*-netbsd*): Ditto.
(alpha*-*-openbsd*): Ditto.
This patch amends the chunk of code where we are determining the
type name; I haven't consider that IDENTIFIER_NODEs require special
handling, since we need to omit the DECL_NAME. I had something similar
in http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00917.html patch, but
there I had a thinko: I
> "Paolo" == Paolo Bonzini writes:
Paolo> Can you put before patch 4 another that defines OUTPUT_OPTION to "-o $@"
Paolo> unconditionally and removes all traces of NO_MINUS_C_MINUS_O?
Sure thing.
Paolo> The series looks okay to me with that change.
Thanks very much for your reviews.
I'll s
This patch ought to fix the unexpected size of type 'long long unsigned int:40'
issue in PR58413. Since libubsan will fail when the precision of a type
is not 32/64/128, we can't pass the width of a bitfield, instead we should pass
the TYPE_SIZE of the base type, I guess.
What is not very nice is
On Mon, 16 Sep 2013, Marek Polacek wrote:
> On Fri, Sep 13, 2013 at 07:18:24PM +, Joseph S. Myers wrote:
> > On Fri, 13 Sep 2013, Marek Polacek wrote:
> >
> > > This is kind of fugly, but don't have anything better at the moment.
> > > 2013-09-13 Marek Polacek
> > >
> > > PR sanitizer/5
Tom> There is a single reference to TREE_GIMPLE_H in the source tree.
Tom> Since it is not defined anywhere, we might as well remove the use.
Paolo> Could it be for gimple.h?
Good catch, it seems to be.
Rather than fix that, it is simple to just drop all these dependencies
from t-i386. I'll do t
On Mon, Sep 16, 2013 at 8:12 AM, Vladimir Makarov wrote:
> The following patch fixes
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58418
>
> The patch also fixes a duplicated bug PR58419.
Shouldn't we also add a testcase from PR58419?
> The patch was successfully tested and bootstrapped on x86
On Mon, Sep 16, 2013 at 05:59:28PM +0200, Marek Polacek wrote:
> Regtested/ran bootstrap-ubsan on x86_64-linux.
That looks wrong. ubsan_type_descriptor shouldn't change TYPE_PRECISION of
the type it has been called with, whether type is a bitfield or not can
change what typedescriptor is generate
Paolo> You are listed as the author of the "compile" script in Automake, do you
Paolo> remember which compilers need it? I'm too young for that (that's
Paolo> something I can say less and less :))...
I have no idea any more.
I can try a test build using a setting for CC that rejects -c -o.
Tom
Il 26/08/2013 18:09, Tom Tromey ha scritto:
>> "Ian" == Ian Lance Taylor writes:
>
> Ian> I assume that dropping $(OUTPUT_OPTION) is correct--I haven't looked
> Ian> at the new definition of $(COMPILE).
>
> I believe the depcomp script takes care of this.
I think that would be the "compile"
Il 20/08/2013 15:59, Tom Tromey ha scritto:
> I used this perl script to find unused _H macros in the Makefile. I
> deleted the definitions it reported and re-ran the script, until there
> was no more output.
>
> The script also makes note of _H variables which are used but never
> defined. That
Il 20/08/2013 15:59, Tom Tromey ha scritto:
> There is a single definition of CROSS_FLOAT_H in the source.
> As far as I can tell, this is never used anywhere.
> So, this patch removes it.
>
> * config/mcore/t-mcore (CROSS_FLOAT_H): Remove.
> ---
> gcc/config/mcore/t-mcore | 3 ---
> 1 file
Il 20/08/2013 15:59, Tom Tromey ha scritto:
> There is a single reference to TREE_GIMPLE_H in the source tree.
> Since it is not defined anywhere, we might as well remove the use.
>
> * config/i386/t-i386 (i386.o): Don't use TREE_GIMPLE_H.
> ---
> gcc/config/i386/t-i386 | 2 +-
> 1 file cha
Il 20/08/2013 15:59, Tom Tromey ha scritto:
> This is a small change to make out_object_file use automatic
> dependencies.
>
> * Makefile.in ($(out_object_file)): Use COMPILE and POSTCOMPILE.
> ---
> gcc/Makefile.in | 12 +++-
> 1 file changed, 3 insertions(+), 9 deletions(-)
>
> d
Il 20/08/2013 15:59, Tom Tromey ha scritto:
> This removes most of the explicit dependencies for host objects.
> It also fixes a few rules to use $(COMPILE) in the process.
>
> build objects are not affected, and are one reason that the various _H
> macros are not yet removed.
>
> * Makefil
Hi,
On Mon, 16 Sep 2013, Uros Bizjak wrote:
> > Why do you think so? The t-* frags are includes via
> > ...
> > tmake_file=...$(srcdir)/config/i386/t-i386
> > ...
> > ifneq ($(tmake_file),)
> > include $(tmake_file)
> > endif
> > ...
> >
> > It's just that there's no t-alpha frag yet.
>
> No, t
Il 20/08/2013 15:59, Tom Tromey ha scritto:
> This converts LTO.
>
> This also fixes a latent buglet in lto/Make-lang.in. lto_OBJS should
> hold all the objects for a language, but LTO never defined this.
>
> * Make-lang.in (LTO_H, LINKER_PLUGIN_API_H, LTO_TREE_H)
> (lto/lto-lang.o,
Il 20/08/2013 15:59, Tom Tromey ha scritto:
> This removes manual dependencies for the c-family .o files.
>
> * Makefile.in (c-family/cppspec.o, c-family/c-common.o)
> (c-family/c-cppbuiltin.o, c-family/c-dump.o, c-family/c-format.o)
> (c-family/c-gimplify.o, c-family/c-lex.o, c-
Il 20/08/2013 15:59, Tom Tromey ha scritto:
> This adds the configury needed for automatic dependency tracking. It
> also adds some bits to the Makefile so we can begin converting
> (removing) explicit dependencies.
>
> * Makefile.in (CCDEPMODE, DEPDIR, depcomp, COMPILE.base)
> (COMPI
On 09/14/2013 06:41 AM, Jan-Benedict Glaw wrote:
Hi!
I suggest this patch, which fixes an alpha-linux build for me:
2013-09-13 Jan-Benedict Glaw
* config/alpha.c: Include tree-ssa.h.
diff --git a/gcc/config/alpha/alpha.c b/gcc/config/alpha/alpha.c
index a8fb929..3759205 100644
---
Il 20/08/2013 15:59, Tom Tromey ha scritto:
> There is an order-only dependency in gcc/Makefile.in that tries to
> build the generated files before compiling regular objects. However,
> this appears too early, and so at the time it is seen by make,
> GCOV_OBJS and GCOV_DUMP_OBJS have not yet been
Il 16/09/2013 16:39, Tom Tromey ha scritto:
> Richard> Where's that automatic dependency patch blocked ...
>
> No build machinery maintainer has reviewed it.
/me gets out of coma...
Someone said "automatic dependency" and "build machinery maintainer" in
the same sentence???
Paolo
Il 20/08/2013 15:59, Tom Tromey ha scritto:
> A few generated files were not mentioned in the generated_files
> variable. This fixes the problem.
>
> * Makefile.in (generated_files): Add options.h,
> target-hooks-def.h, insn-opinit.h,
> common/common-target-hooks-def.h, pass-ins
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58418
The patch also fixes a duplicated bug PR58419.
The patch was successfully tested and bootstrapped on x86/x86-64.
Committed as rev. 202630.
2013-09-16 Vladimir Makarov
PR middle-end/58418
* lra-cons
Il 20/08/2013 15:58, Tom Tromey ha scritto:
> This changes the handling of SHLIB so that it is inlined into
> DRIVER_DEFINES. This is ok because SHLIB is defined in a Makefile
> fragment that is included by the generated Makefile.
>
> The rationale for this is that it simplifies some .o targets,
On 09/16/2013 04:55 AM, Richard Biener wrote:
On Fri, Sep 13, 2013 at 9:15 PM, Andrew MacLeod wrote:
OK, a slightly different take..
I realized that I should be adding tree-outof-ssa.h to handle the 3 exports
from tree-outof-ssa.c that are in ssaexpand.h... In fact, by far the most
sensible
Richard> Where's that automatic dependency patch blocked ...
No build machinery maintainer has reviewed it.
Tom
On Mon, Sep 16, 2013 at 4:26 PM, Yuri Rumyantsev wrote:
> Thanks for your review.
>
> I attached modified patch - is it OK for you now?
I can't understand the comment, so perhaps a native English speaking
person could help here.
The patch with a fixed comment is OK otherwise.
Thanks,
Uros.
On Mon, Sep 16, 2013 at 4:20 PM, Michael Matz wrote:
>> >> Where? I don't see config/alpha.c listed anywhere.
>> >
>> > Must be in one of the fragments in config/ or config/alpha. For
>> > i386 it's config/i386/t-i386
>>
>> Well, we have a problem here. The dependencies from t-* files are
>> ign
On 09/16/2013 05:05 AM, Richard Biener wrote:
On Sat, Sep 14, 2013 at 12:41 PM, Jan-Benedict Glaw wrote:
Hi!
My Build Robot[1] found this recent commit to break Alpha:
* tree-flow.h (FREE_SSANAMES): Move to tree-ssanames.c
(SSANAMES, MODIFIED_NORETURN_CALLS, DEFAULT_DEFS, pt
Uros,
Thanks for your review.
I attached modified patch - is it OK for you now?
2013/9/16 Uros Bizjak :
> On Mon, Sep 16, 2013 at 2:50 PM, Yuri Rumyantsev wrote:
>> Hi All,
>>
>> Here is 1-line fix which improves Atom performance by better distance
>> estimation. We got ~20% speedup on one of b
Hi,
On Mon, 16 Sep 2013, Uros Bizjak wrote:
> >> Where? I don't see config/alpha.c listed anywhere.
> >
> > Must be in one of the fragments in config/ or config/alpha. For
> > i386 it's config/i386/t-i386
>
> Well, we have a problem here. The dependencies from t-* files are
> ignored
Why do yo
On Mon, 16 Sep 2013, Kugan wrote:
> Hi,
>
> Updated the patch to the latest changes in trunk that splits tree.h. I also
> noticed an error in printing double_int and fixed it.
>
> Is this OK?
print_gimple_stmt (dump_file, stmt, 0,
-TDF_SLIM | (dump_flags & TDF_LIN
On Mon, Sep 16, 2013 at 2:50 PM, Yuri Rumyantsev wrote:
> Hi All,
>
> Here is 1-line fix which improves Atom performance by better distance
> estimation. We got ~20% speedup on one of bench from eembc2.0 with
> this fix.
>
> Bootstrapping and regression testing were successful for x86-64.
>
> Is i
On Mon, Sep 16, 2013 at 09:39:27AM -0400, Diego Novillo wrote:
> On Fri, Sep 13, 2013 at 11:25 AM, Diego Novillo wrote:
> > On Fri, Sep 13, 2013 at 11:07 AM, Jakub Jelinek wrote:
> >
> >> E.g. today I've noticed you've lost OMP_CLAUSE_LINEAR_NO_COPYIN
> >> comment that has been added to tree.h re
On Fri, Sep 13, 2013 at 11:25 AM, Diego Novillo wrote:
> On Fri, Sep 13, 2013 at 11:07 AM, Jakub Jelinek wrote:
>
>> E.g. today I've noticed you've lost OMP_CLAUSE_LINEAR_NO_COPYIN
>> comment that has been added to tree.h recently, but you haven't
>> actually moved it into tree-core.h.
>
> Sorry
On Mon, Sep 16, 2013 at 1:57 PM, Richard Biener wrote:
>> >> > > My Build Robot[1] found this recent commit to break Alpha:
>> >>
>> >> I think you can remove the tree-flow.h include and you need to update the
>> >> dependencies in gcc/Makefile.in.
>> >>
>> >> However, we still need tree-flow.h,
The following fixes PR58432 - I forgot to seed partitions from
PHI nodes that have uses on the exit edge.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
Richard.
2013-09-16 Richard Biener
PR tree-optimization/58432
* tree-loop-distribution.c (tree_loop_distributi
On 09/12/2013 06:05 PM, Joseph S. Myers wrote:
On Thu, 12 Sep 2013, Joseph S. Myers wrote:
(Actually, I believe sizes (in bytes) greater than target PTRDIFF_MAX, not
just SIZE_MAX, should be caught, because pointer subtraction cannot work
reliably with larger objects. So it's not just when the
Hi All,
Here is 1-line fix which improves Atom performance by better distance
estimation. We got ~20% speedup on one of bench from eembc2.0 with
this fix.
Bootstrapping and regression testing were successful for x86-64.
Is it OK for trunk?
ChangeLog:
2013-09-16 Yuri Rumyantsev
* config/i38
> A rather obvious patch.
>
> Build and regtested on x86-64-gnu-linux.
> OK for the trunk?
Looks good to me!
Thanks,
Janus
On Mon, 16 Sep 2013, Jonathan Wakely wrote:
Are you sure the noexcept on the destructors is useless?
Ok, I am putting it back in.
--
Marc Glisse
On 15 September 2013 10:12, Marc Glisse wrote:
>
> PR libstdc++/58338
> * include/bits/stl_vector.h
> (_Vector_impl::_Vector_impl(_Tp_alloc_type const&),
> _Vector_impl::_Vector_impl(_Tp_alloc_type&&),
> _Vector_impl::_M_swap_data,
> _Vector_base::_Ve
Hi Guys,
The new MSP430 target has a few limitations which show up as
unexpected failures in the GCC testsuite. I would like to apply the
patch below to update target-supports.exp with this information.
Applying the patch results in a drop of 133 unexpected failures (per
multilib).
O
On Mon, 16 Sep 2013, Uros Bizjak wrote:
> On Mon, Sep 16, 2013 at 1:36 PM, Jan-Benedict Glaw wrote:
> > On Mon, 2013-09-16 13:01:40 +0200, Uros Bizjak wrote:
> >> On Mon, Sep 16, 2013 at 11:06 AM, Uros Bizjak wrote:
> >> > > My Build Robot[1] found this recent commit to break Alpha:
> >>
> >> I
Hi,
this patch solves problem with can_refer_decl_in_current_unit_p always
returning true for static functions. The devirtualization code can look
up a method in anonymous namespace that has been optimized out due to
lack of references to any of vtables mentioning it. In this case we need
to make
On Mon, Sep 16, 2013 at 1:36 PM, Jan-Benedict Glaw wrote:
> On Mon, 2013-09-16 13:01:40 +0200, Uros Bizjak wrote:
>> On Mon, Sep 16, 2013 at 11:06 AM, Uros Bizjak wrote:
>> > > My Build Robot[1] found this recent commit to break Alpha:
>>
>> I think you can remove the tree-flow.h include and you
On Mon, 16 Sep 2013, Uros Bizjak wrote:
> On Mon, Sep 16, 2013 at 11:06 AM, Uros Bizjak wrote:
>
> >> My Build Robot[1] found this recent commit to break Alpha:
> >>
> >> * tree-flow.h (FREE_SSANAMES): Move to tree-ssanames.c
> >> (SSANAMES, MODIFIED_NORETURN_CALLS, DEFAULT_DEFS, ptr_info_def,
>
On Mon, 2013-09-16 13:01:40 +0200, Uros Bizjak wrote:
> On Mon, Sep 16, 2013 at 11:06 AM, Uros Bizjak wrote:
> > > My Build Robot[1] found this recent commit to break Alpha:
>
> I think you can remove the tree-flow.h include and you need to update the
> dependencies in gcc/Makefile.in.
>
> Howe
On Mon, 16 Sep 2013, Paolo Carlini wrote:
On 09/15/2013 11:12 AM, Marc Glisse wrote:
I had to separate the constructor that takes an allocator from the default
constructor in debug/profile, since in release the noexcept only applies to
one of them (and the testsuite asserts that release and de
Ping.
On 09/09/13 10:56, Kyrylo Tkachov wrote:
[Resending, since I was away and not pinging it]
Hi all,
In PR58088 the constant folder goes into an infinite recursion and runs out of
stack space because of two conflicting optimisations:
(X * C1) & C2 plays dirty when nested inside an IOR expr
On Mon, Sep 16, 2013 at 11:06 AM, Uros Bizjak wrote:
>> My Build Robot[1] found this recent commit to break Alpha:
>>
>> * tree-flow.h (FREE_SSANAMES): Move to tree-ssanames.c
>> (SSANAMES, MODIFIED_NORETURN_CALLS, DEFAULT_DEFS, ptr_info_def,
>> num_ssa_names, ssa_name): Move to tree-ssanames.h +
On Thu, Sep 12, 2013 at 04:05:48PM +, Joseph S. Myers wrote:
> On Thu, 12 Sep 2013, Joseph S. Myers wrote:
>
> > (Actually, I believe sizes (in bytes) greater than target PTRDIFF_MAX, not
> > just SIZE_MAX, should be caught, because pointer subtraction cannot work
> > reliably with larger ob
On Mon, Sep 16, 2013 at 12:07:37PM +0200, Richard Biener wrote:
> On Fri, Sep 13, 2013 at 6:56 PM, Xinliang David Li wrote:
> > Updated patch implementing the logic that more specific option wins.
> >
> > Ok for trunk?
>
> @@ -2305,8 +2305,8 @@ omp_max_vf (void)
> {
>if (!optimize
>|
1 - 100 of 140 matches
Mail list logo
