Hi!
On Mon, Sep 23, 2013 at 05:26:13PM -0700, Cong Hou wrote:
Missing ChangeLog entry.
> --- gcc/testsuite/gcc.dg/alias-14.c (revision 0)
> +++ gcc/testsuite/gcc.dg/alias-14.c (revision 0)
Vectorizer tests should go into gcc.dg/vect/ instead, or, if they are
for a single target (but there is no
> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Monday, September 23, 2013 8:08 PM
> To: Bin Cheng
> Cc: GCC Patches
> Subject: Re: [PATCH]Construct canonical scaled address expression in IVOPT
>
> On Fri, Sep 20, 2013 at 12:00 PM, bin.cheng wrote
Hi Honza,
I am finally getting back to working on this after a few weeks of
working on some other priorities.
On Sat, Aug 31, 2013 at 2:46 PM, Jan Hubicka wrote:
> Hi,
> I run my script on execute testsuite and looked into few testcases. The
> problem I found
> was roundoff errors - i.e. when e
On Mon, Sep 23, 2013 at 4:06 PM, Michael Meissner
wrote:
> 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).
Hi,
with the attached patch the read-side of the out of bounds accesses are fixed.
There is a single new test case pr57748-3.c that is derived from Martin's test
case.
The test case does only test the read access and does not depend on part 1 of
the
patch.
This patch was boot-strapped and regre
On Sun, Sep 22, 2013 at 4:20 PM, Paolo Carlini wrote:
> If testing goes well patch is Ok to commit.
Tested under -m32 and -m64 and committed :)
I'll learn how locale in glibc works.
Thank you all!
--
Tim Shen
Greetings,
I've committed the patch below to google/integration (r202856) and
gcc-4_8 (r202857) branches. Google ref: b/10872448.
This cought approximately 10 bugs in our code.
See also r195357 (similar checks for std::vector) and PR 56109.
Thanks,
2013-09-23 Paul Pluzhnikov
* lib
Basically GCC reports that the loop is vectorized, but the vectorized
loop is never executed because of the bogus alias check ' a + 16 < a'
generated. In trunk, the vectorized version is eliminated, but it
remains as a dead code with gcc 48.
David
On Mon, Sep 23, 2013 at 5:26 PM, Cong Hou wrote:
(I have also created this issue in bug reports:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58513)
First look at the code below:
int op(const int* a, const int* b)
{ return *a+*b; }
void foo(int*a, int b)
{
int i;
for (i = 0; i < 10; ++i)
a[i] = op(a+i, &b);
}
GCC will generate t
Err...I hit the send button too quickly, thus making a stupid grammatical
error.. it should say "Did anyone get a chance to look into this patch?" Sorry
about this.
-Balaji V. Iyer.
> -Original Message-
> From: Iyer, Balaji V
> Sent: Monday, September 23, 2013 7:14 PM
> To: 'r...@redha
Hello,
Has anyone got a chance to look into this patch?
Thanks,
Balaji V. Iyer.
> -Original Message-
> From: Iyer, Balaji V
> Sent: Tuesday, September 17, 2013 10:51 AM
> To: r...@redhat.com; Jason Merrill (ja...@redhat.com); 'Jeff Law'; Aldy
> Hernandez (al...@redhat.com)
> Cc:
Mike started a merge from trunk to the wide-int branch because the
previous merge had happened when bootstrap was broken for ppc.
This patch fixes mike's partial merge and has been bootstrapped and
tested on ppc. I will pull the patch down and test it on x86-64 tonight.
kenny
Index: gcc/post
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
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.
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 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 Sep 23, 2013, at 7:11 AM, Tom Tromey wrote:
> This converts the ObjC++ front end.
Ok.
(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 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
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: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
On Sep 23, 2013, at 7:11 AM, Tom Tromey wrote:
> This converts the ObjC front end.
Ok.
> 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 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
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
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
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 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
I have merged the trunk into the branch; committed as Rev. 202840
Tobias
> 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
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
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
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 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 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
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 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
>
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
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 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
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
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
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
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
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
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 ..
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,.
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
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 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
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 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
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-
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
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 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
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 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
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 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 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.
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 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
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 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.
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
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 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
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
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
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 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
> -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, 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
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
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_
> -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
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
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?
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
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
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
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/
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
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
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
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
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 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
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 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:
>>>
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 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 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
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
1 - 100 of 112 matches
Mail list logo
