-Original Message-
From: Richard Earnshaw
Sent: Thursday, September 19, 2013 5:13 PM
To: Zhenqiang Chen
Cc: 'Richard Biener'; GCC Patches
Subject: Re: [PATCH 1/n] Add conditional compare support
On 18/09/13 10:45, Zhenqiang Chen wrote:
-Original Message-
From:
Hi Jason,
I noticed that, although implicit function template declarations were
accepted. They weren't setup correctly and didn't instantiate properly.
The following patch fixes this by moving finish_fully_implicit_template
to the end of cp_parser_init_declarator. OK to go with the others?
Hi,
The patch fixes PR target/58423.
Bootstrap and no make check regression on Chromebook with ARM mode.
Is it OK for trunk?
Thanks!
-Zhenqiang
ChangeLog:
2013-09-23 Zhenqiang Chen zhenqiang.c...@linaro.org
PR target/58423
* config/arm/arm.c (arm_emit_ldrd_pop): Attach
Hi,
This fixes using 'auto' in the return type of a function pointer to
introduce an implicit function template parameter.
Note that this doesn't mean that 'auto' parameters in a function ptr
will be treated the same; I think we need a special case for this in the
implicit template
On 09/18/13 02:26, bin.cheng wrote:
-Original Message-
From: Dominique Dhumieres [mailto:domi...@lps.ens.fr]
Sent: Wednesday, September 18, 2013 1:47 AM
To: gcc-patches@gcc.gnu.org
Cc: hjl.to...@gmail.com; Bin Cheng
Subject: Re: [PATCH GCC]Catch more MEM_REFs sharing common
addressing
On 22.09.2013 18:57, Adam Butcher wrote:
The following solves the canonical type issue in the general case
(pointers and refs) and makes it equivalent to the explicit template
case -- in terms of canonical type at least.
for (tree t = TREE_TYPE (TREE_VALUE (p)); t; t = TREE_CHAIN
(t))
On 09/23/13 07:58, Zhenqiang Chen wrote:
--- clean-trunk/gcc/config/arm/arm.c2013-09-17 14:29:45.632457018 +0800
+++ pr58423/gcc/config/arm/arm.c2013-09-18 14:34:24.708892318 +0800
@@ -17645,8 +17645,8 @@
mem = gen_frame_mem (DImode, stack_pointer_rtx);
tmp
Hi Paul,
This is OK for trunk and, in my opinion, for back-porting in its entirity.
Thanks for the patch
thanks for the review! Committed to trunk as r202823. Will do the
backports soon.
Also: Nice to hear from you! It's been a while ... :)
Cheers,
Janus
On 21 September 2013 16:31,
On Sun, Sep 22, 2013 at 12:54 PM, Richard Sandiford
rdsandif...@googlemail.com wrote:
REG_BR_PROB notes are stored as:
(expr_list:REG_BR_PROB (const_int prob) chain)
but a full const_int rtx seems a bit heavweight when all we want is
a plain int. This patch uses:
(int_list:REG_BR_PROB
On Fri, Sep 20, 2013 at 5:39 PM, Paulo Matos pma...@broadcom.com wrote:
Can we please backport this to 4.8 (it will fix PR58463)?
I attach Richard's patch to master, let me know if instead I should create
one specific for 4.8.1. I tested this against 4.8 branch and everything looks
fine.
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Yufeng Zhang
Sent: Monday, September 23, 2013 3:16 PM
To: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH, ARM] Fix PR target/58423
On 09/23/13 07:58, Zhenqiang Chen wrote:
On Sat, Sep 21, 2013 at 09:34:34AM +0100, James Greenhalgh wrote:
On Fri, Sep 20, 2013 at 03:40:59PM +0100, Renlin Li wrote:
Thank you, can you please commit it for me?
Kind regards,
Renlin Li
On 09/20/13 15:26, Marcus Shawcroft wrote:
On 20 September 2013 15:18, Renlin Li
On 09/20/2013 01:07 AM, Kaz Kojima wrote:
Christian Bruel christian.br...@st.com wrote:
This patch fixes the aforementioned PR by refusing FPUL_REG to be an
acceptable reg for any arithmetic_operand on TARGET_SH4. (This was a
strange SH4 singularity with regards to the SH family).
The only
Paul Pluzhnikov ppluzhni...@google.com writes:
Index: libstdc++-v3/src/c++11/snprintf_lite.cc
===
--- libstdc++-v3/src/c++11/snprintf_lite.cc (revision 0)
+++ libstdc++-v3/src/c++11/snprintf_lite.cc (revision 0)
@@ -0,0
Hi,
here is a status of LRA on ARM, after Vladimir's patch and a rebase of
my branch:
AArch64:
No more issues in the testsuite, the libstdc++ ones weren't LRA
specific, they happened at the pass manager level and due to PCH
inclusion, but were fixed with the trunk update. Thus, I'll post a
Hi!
This patch implements the library side of
#pragma omp cancel{,llation point} {parallel,for,sections}.
The compiler adds GOMP_cancel calls for #pragma omp cancel
and GOMP_cancellation_point calls for #pragma omp cancellation point,
both returning bool whether it has been cancelled or not (and
On Thu, Sep 19, 2013 at 08:09:04PM +0400, Michael V. Zolotukhin wrote:
Hi Jakub,
Updated patch and my answers are below.
Ok for gomp-4_0-branch.
Jakub
On Sat, Sep 21, 2013 at 4:09 AM, Sriraman Tallam tmsri...@google.com wrote:
Forgot to add the test case. Patch updated.
Sri
On Fri, Sep 20, 2013 at 7:06 PM, Sriraman Tallam tmsri...@google.com wrote:
On Wed, Aug 14, 2013 at 3:38 AM, Richard Biener
richard.guent...@gmail.com wrote:
On Wed,
On Fri, Sep 20, 2013 at 4:05 PM, David Malcolm dmalc...@redhat.com wrote:
There have been various discussions about how to handle inheritance
within ggc and PCH: whether to extend gengtype to support C++ syntax
such as templates, or to require people to use GTY((user)) and manually
write
On Thu, Sep 19, 2013 at 7:07 AM, Kugan
kugan.vivekanandara...@linaro.org wrote:
Thanks Richard for the review.
On 18/09/13 18:55, Richard Biener wrote:
On Wed, 18 Sep 2013, Kugan wrote:
Thanks Richard for the review.
On 16/09/13 23:43, Richard Biener wrote:
On Mon, 16 Sep 2013, Kugan
Hi,
thanks Andreas.
On 9/23/13 3:53 AM, Andreas Schwab wrote:
Paul Pluzhnikovppluzhni...@google.com writes:
Index: libstdc++-v3/src/c++11/snprintf_lite.cc
===
--- libstdc++-v3/src/c++11/snprintf_lite.cc (revision 0)
+++
On Wed, Sep 18, 2013 at 10:21 PM, Xinliang David Li davi...@google.com wrote:
On Tue, Sep 17, 2013 at 1:20 AM, Richard Biener
richard.guent...@gmail.com wrote:
On Mon, Sep 16, 2013 at 10:24 PM, Xinliang David Li davi...@google.com
wrote:
On Mon, Sep 16, 2013 at 3:13 AM, Richard Biener
On Wed, Sep 18, 2013 at 1:21 PM, Eric Botcazou ebotca...@adacore.com wrote:
Hi,
this is a regression present on mainline and 4.8 branch (and latent on the 4.7
branch), which is visible with the attached Ada testcase for targets using the
SJLJ exception scheme:
On Mon, Sep 23, 2013 at 1:26 PM, Paolo Carlini paolo.carl...@oracle.com wrote:
Hi,
thanks Andreas.
On 9/23/13 3:53 AM, Andreas Schwab wrote:
Paul Pluzhnikovppluzhni...@google.com writes:
Index: libstdc++-v3/src/c++11/snprintf_lite.cc
Paolo Carlini paolo.carl...@oracle.com writes:
Paul, the *.cc are built with implicit instantiations disabled and we are
missing explicit instantiations of this function template. If I remember
correctly, we normally instantiate it in locale-inst.cc only for unsigned
long and unsigned long
This re-instantiates a generic recursion prevention for PHI translation,
removing the simple one added for PR51042.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2013-09-23 Richard Biener rguent...@suse.de
PR tree-optimization/58464
* tree-ssa-pre.c
On Fri, Sep 20, 2013 at 12:00 PM, bin.cheng bin.ch...@arm.com wrote:
Hi,
For now IVOPT constructs scaled address expression in the form of
scaled*index and checks whether backend supports it. The problem is the
address expression is invalid on ARM, causing scaled expression disabled in
IVOPT
On Fri, Sep 20, 2013 at 5:08 PM, Brooks Moses bmo...@google.com wrote:
Thus, this Google-local patch addresses our immediate need in a simple
way. Ok to commit to google/main and merge to google/gcc-4_8?
OK. This should go in google/integration, actually. google/main can
get it later when
Hi,
this is the last patch of the series.
This patch adds sanity check that all devirtualizations are among ones
predicted by possible_polymorphic_call_targets. This sanity check was
very useful to chase out numberous problems in this area.
The patch check the type based devirtualization to go
Hi
Andreas Schwab sch...@suse.de ha scritto:
What's wrong with always adding the instantiation?
That quite a few targets will not use it and will remain dead in the .so? But I
agree that it's an option, that you can also pursue immediately if you like,
also preapproved (I'm traveling,
Paolo Carlini paolo.carl...@oracle.com writes:
Hi
Andreas Schwab sch...@suse.de ha scritto:
What's wrong with always adding the instantiation?
That quite a few targets will not use it and will remain dead in the .so?
How many uses are there for the unsigned long version?
Andreas.
--
Hi,
I've rebased my patch.
Is it ok for gomp4
2013/9/13 Ilya Tocar tocarip.in...@gmail.com:
Hi,
I'm working on dumping gimple for omp pragma target stuff into
gnu.target_lto_ sections.
I've tried to reuse current lto infrastructure as much as possible.
Could you please take a look at
On 23 Sep 12:26, Jakub Jelinek wrote:
On Thu, Sep 19, 2013 at 08:09:04PM +0400, Michael V. Zolotukhin wrote:
Hi Jakub,
Updated patch and my answers are below.
Ok for gomp-4_0-branch.
Checked into gomp-4_0-branch by Kirill Yukhin:
http://gcc.gnu.org/ml/gcc-cvs/2013-09/msg00692.html
-Original Message-
From: Jakub Jelinek [mailto:ja...@redhat.com]
Sent: 20 September 2013 16:50
To: Paulo Matos
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PR58463] New testcase for pr58463
That is not the right place (and, note the ChangeLog entry refers to a
different path than
Hi Renlin, all,
On 20/09/13 15:30, Renlin Li wrote:
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -7016,10 +7016,10 @@ arm_legitimize_reload_address (rtx *p,
/* Reload the high part into a base reg; leave the low part
in the mem. */
- *p = gen_rtx_PLUS
2013-09-20 Paulo Matos pma...@broadcom.com
* gcc.c-torture/pr58463.c: New testcase for pr58463
Paulo Matos
0001-2013-09-23-Paulo-Matos-pmatos-broadcom.com.patch
Description: 0001-2013-09-23-Paulo-Matos-pmatos-broadcom.com.patch
On Mon, Sep 23, 2013 at 01:43:49PM +, Paulo Matos wrote:
2013-09-20 Paulo Matos pma...@broadcom.com
* gcc.c-torture/pr58463.c: New testcase for pr58463
The testcase looks good, the ChangeLog entry is still wrong. Should
be
2013-09-23 Paulo Matos
-Original Message-
From: Jakub Jelinek [mailto:ja...@redhat.com]
Sent: 23 September 2013 14:49
To: Paulo Matos
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH middle-end/58463] New testcase
The testcase looks good, the ChangeLog entry is still wrong. Should
be
2013-09-23
On Mon, 23 Sep 2013, Paolo Carlini wrote:
There are a lot of targets using unsigned int for size_t, which would
have been uncovered by proper testing.
We can't test all patches on 3-4 different targets... It wasn't obvious
this patch could be that sensitive to the target.
That's true, just
On Mon, Sep 23, 2013 at 03:55:26PM +0200, Marc Glisse wrote:
On Mon, 23 Sep 2013, Paolo Carlini wrote:
There are a lot of targets using unsigned int for size_t, which would
have been uncovered by proper testing.
We can't test all patches on 3-4 different targets... It wasn't
obvious this
On 9/23/13 8:22 AM, Andreas Schwab wrote:
Paolo Carlinipaolo.carl...@oracle.com writes:
Hi
Andreas Schwabsch...@suse.de ha scritto:
What's wrong with always adding the instantiation?
That quite a few targets will not use it and will remain dead in the .so?
How many uses are there for
This is a patch for master, where in number_of_loops, we want to check if the
loops (returned by loops_for_fn) is non-null but instead we are using fn, which
is the function argument. I haven't opened a bug report, please let me know if
I need to do that before submitting patches.
2013-09-23
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, so that
we can share more code.
*
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 set.
This patch fixes the problem and prevents any
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-instances.def,
This converts the C++ front end.
This renames g++spec.o to cp/g++spec.o for uniformity.
This lets us remove an explicit rule.
This patch does not remove various *_H macros from cp/Make-lang.in.
These are still needed by ObjC++. They're removed by a later patch.
* Make-lang.in
This converts the ObjC++ front end.
Now we can finally remove the *_H macros from cp/Make-lang.in.
* Make-lang.in (CXX_TREE_H, CXX_PARSER_H, CXX_PRETTY_PRINT_H):
Remove.
* Make-lang.in (START_HDRS, cc1objplus-checksum.o)
(objcp/objcp-lang.o, objcp/objcp-decl.o
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.
* Make-lang.in (c/gccspec.o): Remove.
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-family/c-omp.o)
(c-family/c-opts.o,
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(-)
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index
While discussing an earlier revision of this patch series, we
discovered that bootstrapping gcc with a compiler that does not
support -c -o has not worked in a long time.
This patch removes the vestiges of this support from gcc itself. This
is preparation for subsequent patches which break the
I haven't made a pass to fix dependencies in all the t-* files, but I
did this one both as an example, and because it was the last user of
the undefined TREE_GIMPLE_H variable.
* config/i386/t-i386 (i386.o): Remove.
(i386-c.o): Use COMPILE and POSTCOMPILE.
---
This fixes t-glibc to use automatic dependency tracking.
* config/t-glibc (glibc-c.o): Use COMPILE and POSTCOMPILE.
---
gcc/config/t-glibc | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/gcc/config/t-glibc b/gcc/config/t-glibc
index 032c68d..ae7bf7a 100644
---
This converts the Java front end.
We also rename jvspec.o to java/jvspec.o, for uniformity; this lets us
remove an explicit rule.
* Make-lang.in (jvspec.o): Remove.
(CFLAGS-java/jvspec.o): New variable.
($(XGCJ)$(exeext), java_OBJS): Use java/jvspec.o
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)
(COMPILE, POSTCOMPILE): New variables.
(.cc.o
This converts the ObjC front end.
Note that there is a latent possible bug in this code -- both ObjC and
ObjC++ define START_HDRS. Whichever is included last, wins; if they
are out of sync, then something could break. This possibility is
eliminated by this series.
* Make-lang.in
This convert fortran.
It renames gfortranspec.o to fortran/gfortranspec.o, for uniformity
and to allow removing an explicit rule.
* Make-lang.in (fortran_OBJS): Use fortran/gfortranspec.o.
(gfortranspec.o): Remove.
(CFLAGS-fortran/gfortranspec.o): New variable.
Here is version 4 of my series to resurrect automatic dependencies for
GCC. Version 3 is here:
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01106.html
This version has a few changes.
First, I believe I've addressed all of the comments in Paolo's review.
This added patch #5, to remove
This converts Go.
It renames gospec.o to go/gospec.o, for uniformity and so we can
remove an explicit rule.
It defines go_OBJS, to conform to the documented Make-lang.in
conventions, and to ensure that Go objects are given the correct
order-only dependencies on generated files.
*
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 is how I found the TREE_GIMPLE_H use, fixed earlier in
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, lto/lto.o, lto/lto-partition.o)
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 changed, 3 deletions(-)
diff --git
On 23/09/13 09:11, Zhenqiang Chen wrote:
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Yufeng Zhang
Sent: Monday, September 23, 2013 3:16 PM
To: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH, ARM] Fix PR target/58423
On 23/09/13 14:42, Kyrill Tkachov wrote:
Hi Renlin, all,
On 20/09/13 15:30, Renlin Li wrote:
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -7016,10 +7016,10 @@ arm_legitimize_reload_address (rtx *p,
/* Reload the high part into a base reg; leave the low part
On 9/23/13 4:26 AM, Paolo Carlini wrote:
m68k-linux/./libstdc++-v3/src/.libs/libstdc++.so: undefined reference
to `int std::__int_to_charchar, unsigned int(char*, unsigned int,
char const*, std::_Ios_Fmtflags, bool)'
Reproduced on i686.
Sorry about the trouble ...
I would say, either make
Kugan,
I have changed all of the above in the attached patch and ChangeLog. If this
is OK, could someone please commit it for me. I don’t have access to commit
it.
Bootstrapped and regtested on x86_64-unknown-linux-gnu and arm-none
linux-gnueabi.
Ok.
Thanks and sorry that it took so
On 23/09/13 13:07, Richard Biener wrote:
What's the problem
with arm supporting reg1 * scale? Why shouldn't it being able to handle
the implicit zero offset?
Something like we don't have an instruction that can do that...
Valid addresses are of the general form
address:=
'[' base-reg
AArch32:
No more issues in libstdc++ as well (same as reasons as AArch64), and
only 3 failures in the testsuite:
- The first one is invalid as the test sans the assembler for
ldaex\tr\[0-9\]+... and it fails because with LRA the chosen
register is r12 and thus the instruction is ldaex ip,...
Hi,
On 9/23/13 9:48 AM, Paul Pluzhnikov wrote:
On 9/23/13 4:26 AM, Paolo Carlini wrote:
m68k-linux/./libstdc++-v3/src/.libs/libstdc++.so: undefined reference
to `int std::__int_to_charchar, unsigned int(char*, unsigned int,
char const*, std::_Ios_Fmtflags, bool)'
Reproduced on i686.
Sorry
On 4 June 2013 20:49, Steve Ellcey sell...@mips.com wrote:
This patch allows me to build libgfortran for a cross-compiling toolchain
using newlib. Currently the checks done by AC_CHECK_FUNCS_ONCE fail with
my toolchain because the compile/link fails due to the configure script not
using the
On 9/23/13 7:48 AM, Paul Pluzhnikov wrote:
Testing this patch:
libstdc++ tests finished with
RUNTESTFLAGS='--target_board=unix\{-m32,-m64\}'
Committed as r202832.
Sorry about the trouble.
--
2013-09-23 Paul Pluzhnikov ppluzhni...@google.com
* src/c++11/snprintf_lite.cc
Hello,
this patch was tested on x86_64 with a bootstrap and a simple make -k
check, without regression. Note that it doesn't completely fix 56166, it
merely admits that we may currently throw and avoids turning that into
std::terminate.
2013-09-24 Marc Glisse marc.gli...@inria.fr
Ping.
On Mon, Sep 16, 2013 at 4:42 PM, Easwaran Raman era...@google.com wrote:
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
On 09/20/2013 04:08 AM, Richard Biener wrote:
On Thu, Sep 19, 2013 at 6:56 PM, Andrew MacLeod amacl...@redhat.com wrote:
On 09/19/2013 09:24 AM, Andrew MacLeod wrote:
I think this is of most use to ssa passes that need to construct code
snippets, so I propose we make this ssa specific and put
On 9/23/13 7:54 AM, Paolo Carlini wrote:
Testing this patch:
In fact, however, that unsigned long long instantiation isn't
*unconditionally* available, see locale-inst.cc.
Thanks,
I think we have to use
unsigned long as a fall back controlled by the same macro. And please
add a comment
Hi,
On 9/23/13 11:02 AM, Paul Pluzhnikov wrote:
On 9/23/13 7:54 AM, Paolo Carlini wrote:
Testing this patch:
In fact, however, that unsigned long long instantiation isn't
*unconditionally* available, see locale-inst.cc.
Thanks,
I think we have to use
unsigned long as a fall back
On 9/23/13 10:55 AM, Marc Glisse wrote:
Hello,
this patch was tested on x86_64 with a bootstrap and a simple make -k
check, without regression. Note that it doesn't completely fix 56166, it
merely admits that we may currently throw and avoids turning that into
std::terminate.
Of course.
On Mon, 2013-09-23 at 12:21 -0400, Andrew MacLeod wrote:
On 09/20/2013 04:08 AM, Richard Biener wrote:
On Thu, Sep 19, 2013 at 6:56 PM, Andrew MacLeod amacl...@redhat.com wrote:
On 09/19/2013 09:24 AM, Andrew MacLeod wrote:
I think this is of most use to ssa passes that need to construct
Tom Tromey wrote:
This convert fortran.
Looks good to me, but I am not really a built-system expert. Hence, I
wouldn't mind if also Paolo glances at the patch …
Thanks for the nice patch series!
Tobias
It renames gfortranspec.o to fortran/gfortranspec.o, for uniformity
and to allow
On 09/23/2013 02:08 AM, Adam Butcher wrote:
Note that this doesn't mean that 'auto' parameters in a function ptr
will be treated the same; I think we need a special case for this in the
implicit template parameter introduction code (or refactor to generate
template parm types on the fly).
It
On 9/23/13 9:24 AM, Paolo Carlini wrote:
Does this look right?
Yes. Nit, in the comment I would also explicitly mention locale-inst.cc.
Done, submitted as r202836.
2013-09-23 Paul Pluzhnikov ppluzhni...@google.com
* src/c++11/snprintf_lite.cc (__concat_size_t): Use
On Mon, 2013-09-23 at 16:26 +0100, Marcus Shawcroft wrote:
On 4 June 2013 20:49, Steve Ellcey sell...@mips.com wrote:
This patch allows me to build libgfortran for a cross-compiling toolchain
using newlib. Currently the checks done by AC_CHECK_FUNCS_ONCE fail with
my toolchain because the
On 09/23/2013 01:53 AM, Adam Butcher wrote:
+ if (member_p)
+decl = finish_fully_implicit_template (parser, decl);
+ else
+finish_fully_implicit_template (parser, /*member_decl_opt=*/0);
Why don't we want to return the template for the non-member case?
Jason
This patch fixes the issue of indirect call promotion while using
AutoFDO optimized binary to collect profile, and use the new profile
to re-optimize the binary. Before the patch, the indirect call is
promoted (and likely inlined) in the profiled binary, and will not be
promoted in the new
If we instead ask, is it sane for gcc to ever want to signed extend
in this case,
IIRC I've seen this due to the fact that pointer math is always
signed, and since gcc has no way of having a PSImode-sized size_t, all
pointer math is done in signed SImode, then the result is truncated to
I have merged the trunk into the branch; committed as Rev. 202840
Tobias
Hi again,
It is funny that with fully dynamic strings, the copy constructor is
better than the move constructor: faster, doesn't throw, etc. I
think we should remove the move constructor in that case, or at least
make it act the same as the copy constructor. I didn't mark the copy
constructor
On Sep 23, 2013, at 8:24 AM, nick clifton ni...@redhat.com wrote:
+(define_insn extendpsisi2
+ [(set (match_operand:SI 0 nonimmediate_operand =r)
+(sign_extend:SI (match_operand:PSI 1 nonimmediate_operand 0)))]
+ TARGET_LARGE
+ # extend psi to si in %0
+)
+
;; Look for cases where
Hi,
On 9/23/13 2:23 PM, Marc Glisse wrote:
On Mon, 23 Sep 2013, Paolo Carlini wrote:
On 9/23/13 10:55 AM, Marc Glisse wrote:
Hello,
this patch was tested on x86_64 with a bootstrap and a simple make
-k check, without regression. Note that it doesn't completely fix
56166, it
merely admits
This patch is an infrastructure patch that combines the 3 reload helper
function arrays into a single array of structures. All machines generate the
same code with this patch (and no regressions were found in bootstrap/make
check). Is it ok to apply?
2013-09-23 Michael Meissner
On Mon, 23 Sep 2013, Paolo Carlini wrote:
On 9/23/13 10:55 AM, Marc Glisse wrote:
Hello,
this patch was tested on x86_64 with a bootstrap and a simple make -k
check, without regression. Note that it doesn't completely fix 56166, it
merely admits that we may currently throw and avoids
I have committed it for you (rev 202831), with a few modifications
(ChangeLog formatting, typos).
Here is what I have committed:
2013-09-23 Kugan Vivekanandarajah kug...@linaro.org
* gimple-pretty-print.c (dump_ssaname_info): New function.
(dump_gimple_phi): Call it.
On Sep 23, 2013, at 7:11 AM, Tom Tromey tro...@redhat.com wrote:
This converts the ObjC front end.
Ok.
On 23.09.2013 19:03, Jason Merrill wrote:
On 09/23/2013 01:53 AM, Adam Butcher wrote:
+ if (member_p)
+decl = finish_fully_implicit_template (parser, decl);
+ else
+finish_fully_implicit_template (parser, /*member_decl_opt=*/0);
Why don't we want to return the template for the
Thanks. I modified the patch so that the max allowed peel iterations
can be specified via a parameter. Testing on going. Ok for trunk ?
David
On Mon, Sep 23, 2013 at 4:31 AM, Richard Biener
richard.guent...@gmail.com wrote:
On Wed, Sep 18, 2013 at 10:21 PM, Xinliang David Li davi...@google.com
On 23.09.2013 19:02, Jason Merrill wrote:
On 09/23/2013 02:08 AM, Adam Butcher wrote:
Note that this doesn't mean that 'auto' parameters in a function ptr
will be treated the same; I think we need a special case for this in
the
implicit template parameter introduction code (or refactor to
(Putting into plain test for gcc-patches list).
On Mon, Sep 23, 2013 at 11:42 AM, Caroline Tice cmt...@google.com wrote:
Ping?
On Thu, Sep 12, 2013 at 10:44 AM, Caroline Tice cmt...@google.com wrote:
On Wed, Sep 11, 2013 at 12:35 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed, Sep 11,
On Fri, Sep 20, 2013 at 7:32 PM, Michael Meissner
meiss...@linux.vnet.ibm.com wrote:
I am now breaking the patches down to be more bite size. Ultimately, I hope
these patches will provide support to allow scalar floating point to occupy
the
Altivec (upper) registers if the ISA allows it (ISA
On Sep 23, 2013, at 7:11 AM, Tom Tromey tro...@redhat.com wrote:
This converts the ObjC++ front end.
Ok.
On Mon, 23 Sep 2013, Paolo Carlini wrote:
Hi again,
It is funny that with fully dynamic strings, the copy constructor is
better than the move constructor: faster, doesn't throw, etc. I think we
should remove the move constructor in that case, or at least make it act
the same as the copy
1 - 100 of 113 matches
Mail list logo
