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 illustra
> -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 addre
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 gengtype
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: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la
Mike Stump 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 want t
On Fri, Aug 30, 2013 at 6:27 PM, Xinliang David Li 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
> use the same
On Fri, Aug 30, 2013 at 9:51 PM, Teresa Johnson wrote:
> On Fri, Aug 30, 2013 at 9:27 AM, Xinliang David Li 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 both a fairly large source file th
On Fri, Aug 30, 2013 at 11:23 PM, Teresa Johnson wrote:
> On Fri, Aug 30, 2013 at 1:30 PM, Xinliang David Li wrote:
>> On Fri, Aug 30, 2013 at 12:51 PM, Teresa Johnson
>> wrote:
>>> On Fri, Aug 30, 2013 at 9:27 AM, Xinliang David Li
>>> wrote:
Except that in this form, the dump will be e
Kenneth Zadeck 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 should keep double_int arou
On Sun, Sep 1, 2013 at 3:10 PM, Bernd Edlinger
wrote:
> On Fri, 30 Aug 2013 11:47:21, Richard Biener wrote:
>> On Tue, Jul 2, 2013 at 7:33 PM, DJ Delorie wrote:
>>>
The choice appears to be to continue to have broken volatile bitfields
on ARM with no way for users to make them conform t
On Mon, Sep 2, 2013 at 8:56 AM, bin.cheng 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 efficient
> addressin
On Mon, Sep 2, 2013 at 9:03 AM, bin.cheng 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
> candidate's inc
> 2013-08-27 Martin Jambor
>
> 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/
> * gcc.dg/ipa
On Fri, Aug 30, 2013 at 5:21 PM, Kenneth Zadeck
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 canonization). So if the
On Fri, Aug 30, 2013 at 5:13 PM, Meador Inge 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 and
> in some cases
On Fri, Aug 30, 2013 at 6:13 PM, Easwaran Raman wrote:
> On Fri, Aug 30, 2013 at 1:25 AM, Richard Biener
> wrote:
>> On Fri, Aug 30, 2013 at 2:30 AM, Easwaran Raman wrote:
>>> Richard,
>>> Do you want me to commit everything but the insert_stmt_after hunk
>>> now?
>>
>> Yes.
>>
>>> There are mo
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 a
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 rev
On Mon, 2 Sep 2013, Richard Sandiford wrote:
> Kenneth Zadeck 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.
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 las
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 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 now.
>
> As we conv
On Fri, 30 Aug 2013, Richard Biener wrote:
On Sat, Jul 6, 2013 at 9:42 PM, Marc Glisse 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, op1);
and then checks
> On Aug 21, 2013, at 11:47 PM, Jan Hubicka 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 o
On Mon, Sep 2, 2013 at 12:52 PM, Jan Hubicka wrote:
>> On Aug 21, 2013, at 11:47 PM, Jan Hubicka 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.
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 gcc.dg/tree-ssa/reassoc-19
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 l
> > + 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 func
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, co
On Mon, Sep 2, 2013 at 1:43 PM, Jan Hubicka 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 Andre
On 09/02/2013 05:35 AM, Richard Biener wrote:
On Mon, 2 Sep 2013, Richard Sandiford wrote:
Kenneth Zadeck 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
On Wed, Jul 3, 2013 at 2:25 PM, Kugan 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 return
>> + false. */
>> +
>
> 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, instea
On Fri, Aug 30, 2013 at 11:34 PM, Xinliang David Li wrote:
> On Fri, Aug 30, 2013 at 1:23 AM, Richard Biener
> wrote:
>> On Fri, Aug 30, 2013 at 1:28 AM, Xinliang David Li
>> wrote:
>>> I was debugging a runtime failure of SPEC06 xalancbmk built with LIPO.
>>> Using -fdisable- option pinpoints
On Mon, Sep 2, 2013 at 3:02 PM, Jan Hubicka 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;
}
i
>
> 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 handle
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]
b.b=
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 fo
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 Au
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 GN
> 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
PR middle-end/56382
* expr.c (emit_move_complex): Do not move complex FP values as parts if
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" 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 went for "w
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
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) : wide_int_ro (w) {
/* We o
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. Do
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
s
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 sort
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 (s
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
> 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 with the
>> __a
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 Bernd'
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 values
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 declarat
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 issues
On Fri, Aug 30, 2013 at 10:04 PM, Tim Shen 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 togethe
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 passing
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:
../..
On Tue, Sep 03, 2013 at 09:25:31AM +0400, Alexander Ivchenko wrote:
> Several builds are broken after r201838.
What targets actually support bionic? If it is just arm, i?86/x86_64
and perhaps aarch64 and nothing else, I'd like to question the way where
you enforce all the
# Add Android userspac
70 matches
Mail list logo
