OK.
Jason
Hi,
The gimple-ssa-strength-reduction pass handles CAND_REFs in order to find
different MEM_REFs sharing common part in addressing expression. If such
MEM_REFs are found, the pass rewrites MEM_REFs, and produces more efficient
addressing expression during the RTL passes.
The pass analyzes
Hi,
For now set_autoinc_for_original_candidates only searches auto-inc uses
before candidate's increment, causing pre-increment opportunities missed for
original candidates. This is a straightforward fix by searching after
candidate's increment too.
The patch also includes a test case to
-Original Message-
From: Richard Earnshaw
Sent: Thursday, August 29, 2013 9:06 PM
To: Bin Cheng
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH ARM]Refine scaled address expression on ARM
On 28/08/13 08:00, bin.cheng wrote:
Hi,
This patch refines scaled address expression
Hello All,
The attached patch (for trunk svn rev 202160)
to gcc/gengtype.c permits files named *.cc (by adding another rule)
to be passed to gengtype and gives a slightly meaningful fatal
error message whan an unrecogized file name (e.g. *.cpp or something
even more wild) is passed to
Hello
I'm pinging my last month's patch
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00382.html
of August 07th 2013 to accept the = inside plugin arguments
Cheers
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue
Mike Stump mikest...@comcast.net writes:
* A static assert also prevents fixed_wide_ints from being initialised
from wide_ints. I think combinations like that would always be a
mistake.
I don't see why. In C, this:
int i;
long l = i;
is not an error, and while a user might not
On Fri, Aug 30, 2013 at 6:27 PM, Xinliang David Li davi...@google.com wrote:
Except that in this form, the dump will be extremely large and not
suitable for very large applications.
So? You asked for it and you can easily grep the output before storing it
away.
Besides, we might also want to
On Fri, Aug 30, 2013 at 9:51 PM, Teresa Johnson tejohn...@google.com wrote:
On Fri, Aug 30, 2013 at 9:27 AM, Xinliang David Li davi...@google.com wrote:
Except that in this form, the dump will be extremely large and not
suitable for very large applications.
Yes. I did some measurements for
On Fri, Aug 30, 2013 at 11:23 PM, Teresa Johnson tejohn...@google.com wrote:
On Fri, Aug 30, 2013 at 1:30 PM, Xinliang David Li davi...@google.com wrote:
On Fri, Aug 30, 2013 at 12:51 PM, Teresa Johnson tejohn...@google.com
wrote:
On Fri, Aug 30, 2013 at 9:27 AM, Xinliang David Li
Kenneth Zadeck zad...@naturalbridge.com writes:
There is no place for exactly two HWIs in the machine independent parts
of the compiler,
I totally agree. In fact I was taking that so much for granted that
I didn't even think to add a rider about it, sorry. I didn't mean
to imply that we
On Sun, Sep 1, 2013 at 3:10 PM, Bernd Edlinger
bernd.edlin...@hotmail.de wrote:
On Fri, 30 Aug 2013 11:47:21, Richard Biener wrote:
On Tue, Jul 2, 2013 at 7:33 PM, DJ Delorie d...@redhat.com wrote:
The choice appears to be to continue to have broken volatile bitfields
on ARM with no way for
On Mon, Sep 2, 2013 at 8:56 AM, bin.cheng bin.ch...@arm.com wrote:
Hi,
The gimple-ssa-strength-reduction pass handles CAND_REFs in order to find
different MEM_REFs sharing common part in addressing expression. If such
MEM_REFs are found, the pass rewrites MEM_REFs, and produces more
On Mon, Sep 2, 2013 at 9:03 AM, bin.cheng bin.ch...@arm.com wrote:
Hi,
For now set_autoinc_for_original_candidates only searches auto-inc uses
before candidate's increment, causing pre-increment opportunities missed for
original candidates. This is a straightforward fix by searching after
2013-08-27 Martin Jambor mjam...@suse.cz
PR ipa/58106
* ipa-prop.c (ipa_edge_duplication_hook): Always put new rdesc to the
linked list. When finding the correct duplicate, also consider also
the caller in additon to its inlined_to node.
testsuite/
*
On Fri, Aug 30, 2013 at 5:21 PM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
richi,
on further thought, this is going to be a huge task. The problem is at the
edges. right now we share the rep of the array with the tree-csts and rtl
(though the rtl sharing may go away to support
On Fri, Aug 30, 2013 at 5:13 PM, Meador Inge mead...@codesourcery.com wrote:
Hi All,
This patch fixes a minor issue that can occur when issuing array bounds
warnings. In GNU C mode we allow empty lists and their upper bound is
initialized to -1. This confuses the array bound analysis in VRP
On Fri, Aug 30, 2013 at 6:13 PM, Easwaran Raman era...@google.com wrote:
On Fri, Aug 30, 2013 at 1:25 AM, Richard Biener
richard.guent...@gmail.com wrote:
On Fri, Aug 30, 2013 at 2:30 AM, Easwaran Raman era...@google.com wrote:
Richard,
Do you want me to commit everything but the
I'd like to ping this patch 1 of 2 that removes redundant zero/sign
extension using value range information.
Bootstrapped and no new regression for x86_64-unknown-linux-gnu and
arm-none-linux-gnueabi.
Thanks you for your time.
Kugan
n 14/08/13 16:49, Kugan wrote:
Hi Richard,
Here is an
I'd like to ping this patch 2 of 2 that removes redundant zero/sign
extension using value range information.
Bootstrapped and no new regression for x86_64-unknown-linux-gnu and
arm-none-linux-gnueabi.
Thanks you for your time.
Kugan
On 14/08/13 16:59, Kugan wrote:
Hi Eric,
Thanks for
On Mon, 2 Sep 2013, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
There is no place for exactly two HWIs in the machine independent parts
of the compiler,
I totally agree. In fact I was taking that so much for granted that
I didn't even think to add a rider
Ping.
On 13/8/20 10:57 AM, Chung-Lin Tang wrote:
Ping.
BTW, the SC has approved the Nios II port already:
http://gcc.gnu.org/ml/gcc/2013-07/msg00434.html
The port is still awaiting technical review.
Thanks,
Chung-Lin
On 13/7/14 下午3:54, Chung-Lin Tang wrote:
Hi, the last ping of
On 01/09/13 14:10, Bernd Edlinger wrote:
IMHO the AAPCS forbids packed structures. Therefore we need not
interfere with the C++ memory model if we have unaligned data.
The AAPCS neither forbids nor requires packed structures. They're a GNU
extension and as such not part of standard C++. Thus
On Sat, Aug 31, 2013 at 1:22 AM, Diego Novillo dnovi...@google.com wrote:
Thanks for the suggestions. I've incorporated them into the patch.
It now adds tree-core.h with all the structures, enums, typedefs and
some fundamental declarations from tree.h. Everything else stays in
tree.h for
On Fri, 30 Aug 2013, Richard Biener wrote:
On Sat, Jul 6, 2013 at 9:42 PM, Marc Glisse marc.gli...@inria.fr wrote:
First, the fold-const bit causes an assertion failure (building libjava) in
combine_cond_expr_cond, which calls:
t = fold_binary_loc (gimple_location (stmt), code, type, op0,
On Aug 21, 2013, at 11:47 PM, Jan Hubicka hubi...@ucw.cz wrote:
The problem is that DECL_ARGUMENTS of the thunk (aka _ZThn528_N1D3fooEv)
is used during thunk code-generation, and thunk code-generation happens
during the output of D::foo.
I see, I will try to modify i386 backend to not
On Mon, Sep 2, 2013 at 12:52 PM, Jan Hubicka hubi...@ucw.cz wrote:
On Aug 21, 2013, at 11:47 PM, Jan Hubicka hubi...@ucw.cz wrote:
The problem is that DECL_ARGUMENTS of the thunk (aka _ZThn528_N1D3fooEv)
is used during thunk code-generation, and thunk code-generation happens
during the
tree-affine is a bit overzealous when converting elements of
pointer-typed combinations to sizetype. From IVOPTs we often
get a combination that doesn't start with a pointer element in
which case the result was a pure sizetype compute. This shows
when fixing PR57511 in
The fix for PR5/40281 was too broad which results in unhandled
IVs in some loops and thus missed optimizations. The PR specifically
talks about missed final value replacement but I've seem IVOPTs
failing to detect BIVs like for gcc.dg/tree-ssa/reassoc-19.c.
The following again allows SCEVs
+ tree a;
+
+ if (in_lto_p)
+cgraph_get_body (node);
That looks gross. It cannot possibly be the correct fix for this.
DECL_ARGUMENTS/DECL_RESULT are now part of function body. cgraph_get_body is
there to load it for you when you need it. We are going to expand the function
so
Hi,
On Fri, 30 Aug 2013, David Malcolm wrote:
Here's the result of a pair of builds of r202029 without and with the
patches, configured with --enable-checking=release, running make, then
stripping debuginfo [1]
So the overall sizes of such binaries are essentially unchanged.
Yep, cool.
On Mon, Sep 2, 2013 at 1:43 PM, Jan Hubicka hubi...@ucw.cz wrote:
+ tree a;
+
+ if (in_lto_p)
+cgraph_get_body (node);
That looks gross. It cannot possibly be the correct fix for this.
DECL_ARGUMENTS/DECL_RESULT are now part of function body.
Well, there is still fallout from
Hello,
what is the blocking point for GCC integration? It was accepted by the SC and
all issues of the last review have been addressed (at least this is my
impression). Is it that none of the persons with global write permission seems
to be responsible? The Binutils port is available since
Hi,
On Fri, Aug 30, 2013 at 03:21:22PM -0400, David Malcolm wrote:
Apart from the GTY aspect, how do people feel about the patch series?
FWIW I have vague thoughts about doing something similar for tree -
doing so *might* give an easier route to the type vs expression
separation that Andrew
On 09/02/2013 05:35 AM, Richard Biener wrote:
On Mon, 2 Sep 2013, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
There is no place for exactly two HWIs in the machine independent parts
of the compiler,
I totally agree. In fact I was taking that so much for granted
On Wed, Jul 3, 2013 at 2:25 PM, Kugan kugan.vivekanandara...@linaro.org wrote:
On 17/06/13 18:33, Richard Biener wrote:
On Mon, 17 Jun 2013, Kugan wrote:
+/* Extract the value range of assigned exprassion for GIMPLE_ASSIGN stmt.
+ If the extracted value range is valid, return true else
Well, there is still fallout from this change so I'm not convinced
this will stay
this way. Also we stream the function-decl that refers to these fields in
As far as I know there are two problems
1) problem with the thunk expansion not getting DECL_ARGUMENTS/DECL_RESULT
addressed by
Well, there is still fallout from this change so I'm not convinced
this will stay
this way. Also we stream the function-decl that refers to these fields in
As far as I know there are two problems
1) problem with the thunk expansion not getting DECL_ARGUMENTS/DECL_RESULT
+ case CILK_SYNC_STMT: +{ + if (!cfun-cilk_frame_decl) +
{ + error_at (input_location, expected %_Cilk_spawn% before
+ %_Cilk_sync%); + ret = GS_ERROR; +
}
First, surely you have a location you can use, instead of the
On Fri, Aug 30, 2013 at 11:34 PM, Xinliang David Li davi...@google.com wrote:
On Fri, Aug 30, 2013 at 1:23 AM, Richard Biener
richard.guent...@gmail.com wrote:
On Fri, Aug 30, 2013 at 1:28 AM, Xinliang David Li davi...@google.com
wrote:
I was debugging a runtime failure of SPEC06 xalancbmk
On Mon, Sep 2, 2013 at 3:02 PM, Jan Hubicka hubi...@ucw.cz wrote:
Well, there is still fallout from this change so I'm not convinced
this will stay
this way. Also we stream the function-decl that refers to these fields in
As far as I know there are two problems
1) problem with the
Hi,
unfortunately this patch ICEs on the following testcase
/* This used to fail on SPARC with an unaligned memory access. */
void foo(int n)
{
struct S {
int i[n];
unsigned int b:1;
int i2;
} __attribute__ ((packed)) __attribute__ ((aligned (4)));
struct S s;
s.i2 = 0;
}
But we still refer to the local entity from TREE_TYPE of the function decl,
no?
depending on definition of local entity. I tought we was discussing if
PARM_DECL
is local or not.
I spent some time thining about the whole streaming scheme and I think we do
have
important side cases handled
Hi,
the following testcase illustrate problem with the offset. Sadly it ICEs even
w/o
LTO:
evans:/abuild/jh/trunk-3/build-inst12/gcc/:[1]# ./xgcc -B ./ -O2 ~/tt.c
/root/tt.c: In function 'main':
/root/tt.c:24:11: warning: overflow in implicit constant conversion [-Woverflow]
On Sun, 1 Sep 2013, Richard Sandiford wrote:
like to get rid of them and just keep the genuine operators. The problem
is that I'd have liked the AND routine to be wi::and, but of course that
isn't possible with and being a keyword, so I went for wi::bit_and
instead. Same for not and
Hi,
also to avoid the ICE in the original testcase, we do not really need the
DECL_ARGUMENTS/RESULT_DECL lists. All we need is RESULT_DECL in the global
stream. The following one liner fixes the testcase and all variants of my
ulitimate death testcase that did not ICE in tree from beggining of
On Mon, 2 Sep 2013, Richard Earnshaw wrote:
On 01/09/13 14:10, Bernd Edlinger wrote:
IMHO the AAPCS forbids packed structures. Therefore we need not
interfere with the C++ memory model if we have unaligned data.
The AAPCS neither forbids nor requires packed structures. They're a GNU
Eric, your patch works for me. Tested on hppa2.0w-hp-hpux11.11 and
hppa64-hp-hpux11.11.
Thanks, also tested on x86-64/Linux and applied on the mainline.
2013-09-02 Eric Botcazou ebotca...@adacore.com
PR middle-end/56382
* expr.c (emit_move_complex): Do not move complex FP
Hi,
We have just committed backports of the following revisions from trunk
to linaro/gcc-4_8-branch:
r201636 (as 202175)
r201501 (as 202176) (should have picked it up by 4.8 branch merge)
r201341 (as 202181)
Thanks,
Christophe.
Joseph S. Myers jos...@codesourcery.com writes:
On Sun, 1 Sep 2013, Richard Sandiford wrote:
like to get rid of them and just keep the genuine operators. The problem
is that I'd have liked the AND routine to be wi::and, but of course that
isn't possible with and being a keyword, so I
Hi,
gcc.dg/lto/20090218-1.c contains cross module call into always_inline function.
At -O0 -flto we used to report nothing since optimize_inline_calls was not
called. With
my change we report it as error.
I am not sure what is desired behaviour, but for now I am restoring the previous
situation
On Sep 2, 2013, at 1:22 AM, Richard Sandiford rdsandif...@googlemail.com
wrote:
What I'm saying is that the assert stops plain:
max_wide_int x = wide_int_var;
Sorry for being slow. I see the point, indeed, from the preexisting code, we
did:
fixed_wide_int (const wide_int_ro w) :
On 01.09.2013 21:05, Jason Merrill wrote:
On 08/27/2013 03:42 PM, Adam Butcher wrote:
I don't know if it's the correct thing to do but the implementation
currently omits the conversion to function pointer operator if the
argument list contains a parameter pack.
I would expect that to work.
On 01.09.2013 21:22, Jason Merrill wrote:
On 08/27/2013 03:42 PM, Adam Butcher wrote:
+ vec_safe_push (argvec, arg);
I bet we want convert_from_reference in the non-generic lambda case,
too.
OK with that change.
I think I had made that change originally to keep the two impls the
On 09/02/2013 02:30 PM, Adam Butcher wrote:
I think I had made that change originally to keep the two impls the same
and I hit issues with non-generic lambdas. But I can't remember the
details. I'll try again. If it works with convert_from_reference in
both cases should I push or should I
Ping**0.5714 ?
the attached patch rejects impure subroutines, such as RANDOM_NUMBER,
within DO CONCURRENT.
Regression-tested. OK for trunk?
On 01.09.2013 22:20, Jason Merrill wrote:
On 08/27/2013 03:42 PM, Adam Butcher wrote:
+ else // extend current template parameter list
+ // pop the innermost template parms into tparms
Most comments should start with a capital letter and end with a
period.
Will change.
+ for
On 09/02/2013 02:27 PM, Adam Butcher wrote:
Bug 41933 is specifically about lambda capture; I think you're
running into something else.
The problem is in expanding the 'ts' capture from the 5.1.2.5. It
looks like this:
1 auto vglambda = [](auto printer) {
2 return [=](auto ... ts) {
On Fri, 30 Aug 2013 12:34:51 Richard Biener wrote:
On Tue, Aug 20, 2013 at 1:01 PM, Bernd Edlinger
bernd.edlin...@hotmail.de wrote:
This patch fixes a bug in the vectorized pointer arithmetic in the forwprop
optimization pass.
Although it seems to be impossible to create a vector of pointers
On 09/02/2013 03:10 AM, Richard Biener wrote:
Can someone, in a new thread, ping the patches that are still in
flight? ISTR having approved bits of some patches before my leave.
Here's the current state of the patch set I put together. I've lost
track of where the canonical version of
Thomas Koenig wrote:
the attached patch rejects impure subroutines, such as RANDOM_NUMBER,
within DO CONCURRENT.
Regression-tested. OK for trunk?
Okay - and thanks for the patch. Unrelated to changes in your patch, I
am a bit unhappy about:
* Proliferation of global variables
* Magic
Thomas Koenig wrote:
+Unformatted sequential files are stored using record markers. Each
+full record consists of a leading record marker, the data written
+by the user program, and a trailing record marker. The record markers
+are four-byte integers by default, and eight-byte integers if the
Am 27.08.2013 15:09, schrieb Janus Weil:
here is a patch for PR 55603, which plugs a memory leak with scalar
allocatable function results.
To accomplish this, several things are done:
1) Allocatable scalar function results are passed as argument now and
returned by reference (just like array or
Hi,
this patch fixes gcc.dg/lto/pr56297 failure. Here we have two modules defining
global variable assigned to hard registers. Those variables do not go into
assembler name hash because they have no real assembler name and consequentely
they are not merged.
We however may end up with two
On 02.09.2013 19:34, Jason Merrill wrote:
On 09/02/2013 02:30 PM, Adam Butcher wrote:
On 01.09.2013 21:22, Jason Merrill wrote:
I bet we want convert_from_reference in the non-generic lambda
case, too.
I think I had made that change originally to keep the two impls the
same
and I hit
On Fri, Aug 30, 2013 at 10:04 PM, Tim Shen timshe...@gmail.com wrote:
I didn't use any tool to check that, but adjust it by hand. It
shouldn't break anything, but I'll test it again before committing.
Tested under -m32, -m64 and debug mode and committed.
--
Tim Shen
Hi,
reading profile/instrumenting breaks basic blocks and introduces fake edges.
The broken basic blocks are not re-merged until after LTO streaming that is
wasteful. Fixed thus.
Profiledbotostrapped/regtsted ppc64-linux, comitted.
Index: tree-profile.c
This is a follow-up patch for Sandra Loosemore's patch in this
thread: reimplement -fstrict-volatile-bitfields, v3.
It was already posted a few weeks ago, but in the wrong thread.
Therefore I re-post it herewith.
It was initially suggested by Hans-Peter Nilsson, and I had much
help from him in
On Mon, 2 Sep 2013 12:56:22 Sandra Loosemore wrote:
On 09/02/2013 03:10 AM, Richard Biener wrote:
Can someone, in a new thread, ping the patches that are still in
flight? ISTR having approved bits of some patches before my leave.
Here's the current state of the patch set I put together. I've
On 09/02/2013 05:18 PM, Adam Butcher wrote:
Will assume, for now, that the convert_from_reference call is not wanted
in the non-generic case (maybe something to do with using 'build_call_a'
instead of 'build_nt_call_vec' or the convert_from_reference on the call
itself?)
Ah, yes; we are
Hi,
Several builds are broken after r201838.
Here is the fix, awaiting review:
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01245.html
The targets that are broken now:
1) *linux* targets that do not include config/linux.h in their tm.h
(e.g alpha-linux, ppc64-linux etc). For them we have:
71 matches
Mail list logo
