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 parameter
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
wrote:
> REG_BR_PROB notes are stored as:
>
> (expr_list:REG_BR_PROB (const_int ) )
>
> 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 )
>
> instead.
>
> I did
On Fri, Sep 20, 2013 at 5:39 PM, Paulo Matos 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.
Ok.
Thanks,
Ric
> -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 wr
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, R
On 09/20/2013 01:07 AM, Kaz Kojima wrote:
> Christian Bruel 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 impacted ins
Paul Pluzhnikov 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 +1,152 @@
> +// Debugg
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
patch
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 i
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 wrote:
> Forgot to add the test case. Patch updated.
>
> Sri
>
> On Fri, Sep 20, 2013 at 7:06 PM, Sriraman Tallam wrote:
>> On Wed, Aug 14, 2013 at 3:38 AM, Richard Biener
>> wrote:
>>> On Wed, Aug 14, 2013 at 2:02 AM, Sriraman Tallam
>>> wrote:
On Fri, Sep 20, 2013 at 4:05 PM, David Malcolm 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 field-traversal.
>
>
On Thu, Sep 19, 2013 at 7:07 AM, Kugan
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 wrote:
>>>
Hi,
thanks Andreas.
On 9/23/13 3:53 AM, Andreas Schwab wrote:
Paul Pluzhnikov 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/snp
On Wed, Sep 18, 2013 at 10:21 PM, Xinliang David Li wrote:
> On Tue, Sep 17, 2013 at 1:20 AM, Richard Biener
> wrote:
>> On Mon, Sep 16, 2013 at 10:24 PM, Xinliang David Li
>> wrote:
>>> On Mon, Sep 16, 2013 at 3:13 AM, Richard Biener
>>> wrote:
On Fri, Sep 13, 2013 at 5:16 PM, Xinliang D
On Wed, Sep 18, 2013 at 1:21 PM, Eric Botcazou 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:
>
> eric@polaris:~/gnat/bugs/M823-029> ~/build/gc
On Mon, Sep 23, 2013 at 1:26 PM, Paolo Carlini wrote:
> Hi,
>
> thanks Andreas.
>
>
> On 9/23/13 3:53 AM, Andreas Schwab wrote:
>>
>> Paul Pluzhnikov writes:
>>
>>> Index: libstdc++-v3/src/c++11/snprintf_lite.cc
>>> ===
>>> --- libst
Paolo Carlini 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 long as second template
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
PR tree-optimization/58464
* tree-ssa-pre.c (phi_trans_lookup
On Fri, Sep 20, 2013 at 12:00 PM, bin.cheng 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 ARM. Th
On Fri, Sep 20, 2013 at 5:08 PM, Brooks Moses 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 it merges from g/
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 i
Hi
Andreas Schwab 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, either you or Paul
Paolo Carlini writes:
> Hi
>
> Andreas Schwab 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.
--
Andreas Schwab, SUSE Labs, sch...@
Hi,
I've rebased my patch.
Is it ok for gomp4
2013/9/13 Ilya Tocar :
> 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 attached patch?
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.h
> -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
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 (GET_
2013-09-20 Paulo Matos
* 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
>
> * 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
PR middle-en
> -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
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
> obv
On 9/23/13 8:22 AM, Andreas Schwab wrote:
Paolo Carlini writes:
Hi
Andreas Schwab 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?
I would say *a
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 Pa
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.
* Makefile.in
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,
c-family/c-target-hooks-def.h.
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 (g++spec.o
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.
(CFLAGS-c/gccs
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, c-fa
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 973cc46.
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.
---
gcc/config/i386/t-i3
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
--- a
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
(java/jvspec.
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 .c.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 (START_
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.
(GF
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 AM_PRO
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.
* Make-la
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)
(lto/lto-objec
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 a/gcc/config/mcore/t-
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 tar
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 p
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_char(char*, unsigned int,
char const*, std::_Ios_Fmtflags, bool)'
Reproduced on i686.
Sorry about the trouble ...
I would say, either make sure to use only tho
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
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-r
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_char(char*, unsigned int,
char const*, std::_Ios_Fmtflags, bool)'
Reproduced on i686.
Sorry about the trouble ..
On 4 June 2013 20:49, Steve Ellcey 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 needed linker
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
* src/c++11/snprintf_lite.cc (__concat_size_t): Use only
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
PR libstdc++/58338
Ping.
On Mon, Sep 16, 2013 at 4:42 PM, Easwaran Raman 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 valid UIDs l
On 09/20/2013 04:08 AM, Richard Biener wrote:
On Thu, Sep 19, 2013 at 6:56 PM, Andrew MacLeod 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 it in tree-ssa.c
(r
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 expl
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 controlle
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.
Patc
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 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
>
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 removi
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 is
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
* src/c++11/snprintf_lite.cc (__concat_size_t): Use
unsigned long long conditiona
On Mon, 2013-09-23 at 16:26 +0100, Marcus Shawcroft wrote:
> On 4 June 2013 20:49, Steve Ellcey 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/li
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 iteratio
> 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
PSImo
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
constructo
On Sep 23, 2013, at 8:24 AM, nick clifton 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
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
* con
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 turning
> 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
>
> * gimple-pretty-print.c (dump_ssaname_info): New function.
> (dump_gimple_phi): Call it.
> (pp_gimple_stm
On Sep 23, 2013, at 7:11 AM, Tom Tromey 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 non-me
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
wrote:
> On Wed, Sep 18, 2013 at 10:21 PM, Xinliang David Li
> wrote:
>> On Tue, Sep 17, 2013 at 1:20 AM
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
gene
(Putting into plain test for gcc-patches list).
On Mon, Sep 23, 2013 at 11:42 AM, Caroline Tice wrote:
>
> Ping?
>
>
> On Thu, Sep 12, 2013 at 10:44 AM, Caroline Tice wrote:
>>
>> On Wed, Sep 11, 2013 at 12:35 PM, H.J. Lu wrote:
>> > On Wed, Sep 11, 2013 at 12:27 PM, Caroline Tice
>> > wrote:
On Fri, Sep 20, 2013 at 7:32 PM, Michael Meissner
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 2.06 for DFmode, ISA 2.
On Sep 23, 2013, at 7:11 AM, Tom Tromey 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 con
On 09/23/2013 01:05 PM, David Malcolm wrote:
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 wrote:
On 09/19/2013 09:24 AM, Andrew MacLeod wrote:
I think this is of most use to ssa passes t
On 9/23/13 3:44 PM, Marc Glisse wrote:
Sorry.
You are welcome. Thanks for the time you are spending on these details!
Paolo.
This patch updates the powerpc64le xfails file on the google/gcc-4_8
branch to reflect two new failures caused by the addition of a new
vectorization testcase. Committed as obvious.
- Brooks
2013-09-23_powerpc64le-xfails.diff
Description: Binary data
1 - 100 of 112 matches
Mail list logo
