This patch is the beginning stages of my revamp of the builtin function
handling in the rs6000 port. When I added target attribute support in GCC 4.6,
I ran out of time in tackling enabling builtin functions if the user says a
function is to be compiled for a different target machine. These patch
On Mon, Jul 11, 2011 at 5:12 AM, Richard Guenther wrote:
> On Fri, 8 Jul 2011, Richard Guenther wrote:
>
>> On Fri, 8 Jul 2011, Michael Matz wrote:
>>
>> > Hi,
>> >
>> > On Fri, 8 Jul 2011, Richard Guenther wrote:
>> >
>> > > It should be indeed safe with the current handling of conversions, but
>
On 08/12/2011 07:05 PM, Richard Henderson wrote:
On 08/11/2011 02:42 PM, Andrew MacLeod wrote:
The names for the previous set implies the fetch is done before the
operation, so the new ones simply drop the fetch and simply use the
operation name. I found sync_mem_op_fetch slightly less clear.
R
Hi,
as I am not working anymore at AMD, I will commit the following patch.
Sebastian
---
MAINTAINERS |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 3c7e8a9..ec0579d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -225,9 +225,9 @@ tree-
On 08/11/2011 02:42 PM, Andrew MacLeod wrote:
> The names for the previous set implies the fetch is done before the
> operation, so the new ones simply drop the fetch and simply use the
> operation name. I found sync_mem_op_fetch slightly less clear.
Really? I guess I'm pretty used to that, and i
On Thu, 11 Aug 2011, Georg-Johann Lay wrote:
> This is an optimization in machine dependent reorg to
> remove redundant comparisons like in
>
>cc0 = compare (Reg, Num)
>if (cc0 == 0)
> goto L1
>
>cc0 = compare (Reg, Num)
>if (cc0 > 0)
> goto L2
>
> The second comparison
Andrew Pinski writes:
> This is wrong as -iquote takes an operand. So it is eating up -I. for
> the -iquote. You have to replace all of the -I after -I- with
> -iquote.
OK, here is an amended patch. I don't dare call it "trivial" anymore :)
(Note that even the "wrong" patch solved the problem r
G++ was complaining about performing the lvalue-rvalue conversion on an
lvalue of abstract type, which is correct when the conversion is
potentially evaluated, but as it turns out, not in unevaluated context.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 28e405968ae794fcb73d2946a6c83bde
On 08/11/2011 05:19 AM, Nick Clifton wrote:
> Hi Guys,
>
> I am applying the patch below on behalf of Renesas. It adds support
> to the RX backend for conditional register moves.
>
> Tested without any regressions on an rx-elf toolchain.
>
> Cheers
> Nick
>
> gcc/ChangeLog
> 2011-08-11
Extra dependencies are needed to avoid creating incorrect unwind info.
See the patch and the PR for more details.
Tested on x86_64-linux. Committed.
r~
diff --git a/gcc/sched-deps.c b/gcc/sched-deps.c
index 2961cca..ed592c8 100644
--- a/gcc/sched-deps.c
+++ b/gcc/sched-deps.c
@@ -2696,6 +2696,1
Steven Bosscher writes:
> On Thu, Aug 11, 2011 at 1:56 PM, Richard Sandiford
> wrote:
>
>> gcc/
>> * config/arm/arm.c (get_label_padding): New function.
>> (create_fix_barrier, md_reorg): Likewise.
>
> The ChangeLog doesn't match the patch:
> * create_fix_barrier is not a new functi
On Fri, Aug 12, 2011 at 6:04 PM, Michael Matz wrote:
> Hi,
>
> On Tue, 9 Aug 2011, Michael Matz wrote:
>
>> > Are there any updates on the libada problem or other reasons why the
>> > patch cannot go in?
>>
>> Nope, I've solved that one. Letme update it.
>
> Like so. Regstrapped on x86_64-linux
On Fri, Aug 12, 2011 at 03:30:25PM -0400, Jack Howarth wrote:
> Skimo,
>Currently we don't have any checks for the minimal isl version required.
I assume they will be added at some point.
AFAIU, Sebastian just started working on this.
It will take some time for him to finish the transition.
A
On 08/11/2011 08:06 PM, Xinliang David Li wrote:
A new patch with lightly modified the test case.
if (lost)
BV_LOST_PRIMARY (*virtuals) = true;
+ else
+BV_LOST_PRIMARY (*virtuals) = false;
Might as well just do
BV_LOST_PRIMARY (*virtuals) = lost;
OK for trunk and 4.6 with that
On Fri, Aug 12, 2011 at 07:28:52PM +, Joseph S. Myers wrote:
> On Fri, 12 Aug 2011, Sven Verdoolaege wrote:
>
> > On Fri, Aug 12, 2011 at 07:16:55PM +, Joseph S. Myers wrote:
> > > Do you mean there is not only a requirement to build both libraries, but
> > > there is a requirement to bui
On Fri, Aug 12, 2011 at 09:22:04PM +0200, Sven Verdoolaege wrote:
> On Fri, Aug 12, 2011 at 07:16:55PM +, Joseph S. Myers wrote:
> > Do you mean there is not only a requirement to build both libraries, but
> > there is a requirement to build CLooG *first*, then ISL, so that ISL's
> > libisl.a
On Fri, 12 Aug 2011, Sven Verdoolaege wrote:
> On Fri, Aug 12, 2011 at 07:16:55PM +, Joseph S. Myers wrote:
> > Do you mean there is not only a requirement to build both libraries, but
> > there is a requirement to build CLooG *first*, then ISL, so that ISL's
> > libisl.a overwrites CLooG's
On Fri, Aug 12, 2011 at 12:50, Jack Howarth wrote:
> On Fri, Aug 12, 2011 at 07:35:24PM +0200, Sven Verdoolaege wrote:
>> On Fri, Aug 12, 2011 at 05:02:18PM +, Joseph S. Myers wrote:
>> > On Fri, 12 Aug 2011, Sebastian Pop wrote:
>> > > +@item Integer Set Library (ISL) version 0.08
>> > > +
>>
On Thu, Aug 11, 2011 at 1:56 PM, Richard Sandiford
wrote:
> gcc/
> * config/arm/arm.c (get_label_padding): New function.
> (create_fix_barrier, md_reorg): Likewise.
The ChangeLog doesn't match the patch:
* create_fix_barrier is not a new function.
* md_reorg should be arm_reorg
Ci
On Fri, Aug 12, 2011 at 07:16:55PM +, Joseph S. Myers wrote:
> Do you mean there is not only a requirement to build both libraries, but
> there is a requirement to build CLooG *first*, then ISL, so that ISL's
> libisl.a overwrites CLooG's rather than the other way round (supposing
> that the
Hi,
When the location for throw() exception specification is not the same
as the function it is written against, it leads gcov to give incorrect
results. See bug 50055 for details of the the same. The following
patch makes sure that the exception specification block (nothrow or
otherwise) is alway
On Fri, 12 Aug 2011, Sven Verdoolaege wrote:
> On Fri, Aug 12, 2011 at 06:56:38PM +, Joseph S. Myers wrote:
> > I don't see why that should make any difference to the build requirements.
> > If CLooG-ISL builds and installs a library libisl.a as well as
> > libcloog-isl.a (as config/cloog.m
On Fri, Aug 12, 2011 at 06:56:38PM +, Joseph S. Myers wrote:
> I don't see why that should make any difference to the build requirements.
> If CLooG-ISL builds and installs a library libisl.a as well as
> libcloog-isl.a (as config/cloog.m4 thinks it does at present), why should
> someone ne
On Fri, 12 Aug 2011, Sven Verdoolaege wrote:
> On Fri, Aug 12, 2011 at 05:02:18PM +, Joseph S. Myers wrote:
> > On Fri, 12 Aug 2011, Sebastian Pop wrote:
> > > +@item Integer Set Library (ISL) version 0.08
> > > +
> > > +Necessary to build GCC with the Graphite loop optimizations.
> > > +It ca
> "Gabriel" == Gabriel Charette writes:
Gabriel> Removed LINEMAP_POSITION_FOR_COLUMN, it did the EXACT same
Gabriel> thing as linemap_position_for_column, so maintaining both in
Gabriel> parallel seems like overkill to me. The only thing I can think
Gabriel> of is that it's more optimal as it
On Fri, Aug 12, 2011 at 07:35:24PM +0200, Sven Verdoolaege wrote:
> On Fri, Aug 12, 2011 at 05:02:18PM +, Joseph S. Myers wrote:
> > On Fri, 12 Aug 2011, Sebastian Pop wrote:
> > > +@item Integer Set Library (ISL) version 0.08
> > > +
> > > +Necessary to build GCC with the Graphite loop optimiz
On Fri, Aug 12, 2011 at 05:02:18PM +, Joseph S. Myers wrote:
> On Fri, 12 Aug 2011, Sebastian Pop wrote:
> > +@item Integer Set Library (ISL) version 0.08
> > +
> > +Necessary to build GCC with the Graphite loop optimizations.
> > +It can be downloaded from @uref{http://www.kotnet.org/~skimo/is
On 08/05/2011 10:33 AM, Torvald Riegel wrote:
> Use per-transaction reader flags for the serial lock (gtm_rwlock).
>
> * config/posix/rwlock.cc (gtm_rwlock::read_lock): Changed locking
> implementation.
> (gtm_rwlock::read_unlock): Same.
> (gtm_rwlock::write_lock_ge
On 08/09/2011 05:01 AM, Torvald Riegel wrote:
> Maintain a list of all threads' transactions.
>
> * libitm_i.h (next_tx): Add list of all threads' transaction.
> * beginend.cc (GTM::gtm_transaction::begin_transaction): Register
> transaction with list of transactions and
Now that we do not depend on the LTO streamer anymore, these calls are
unnecessary. There are still some remnants that will be necessary
until I factor the pickling buffers out of lto-streamer.h.
Tested on x86_64. Committed to branch.
Diego.
* pph-streamer-in.c (pph_init_read): Do no
On 08/12/2011 06:25 PM, H.J. Lu wrote:
>
> I prefer to wait for testing results to commit it, the breakage is minor.
It bootstraps successfully with "make -j12" on a 24 core machine.
Thanks.
Committed.
Paolo
> "Jie" == Jie Liu writes:
Jie> In my debug, there appears no check for 'this' at start of String.length():
Yeah, I looked for uses of flag_check_references and didn't see one when
building a method's body. So I guess I mis-remembered this.
In any case, the spot you found is just the tip o
On Fri, 12 Aug 2011, Sebastian Pop wrote:
> ---
> gcc/doc/install.texi |8 +++-
> 1 files changed, 7 insertions(+), 1 deletions(-)
>
> diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
> index 368221f..f2b2fd9 100644
> --- a/gcc/doc/install.texi
> +++ b/gcc/doc/install.texi
> @@ -
On 08/05/2011 04:24 PM, Torvald Riegel wrote:
> Note that I did have code ready to have a single statically allocated
> __thread gtm_thread object. However, I then saw that unlike discussed
> off-list, the compiler does indeed complain about using non-trivial
> objects with __thread (which makes se
This patch adds an option for enabling/disabling the warning for
attempting to free nonheap objects (PR/38509). The warning is
imprecise and can issue false positives.
Bootstrapped on x86-64. Ok for trunk?
Mark
2011-08-11 Mark Heffernan
PR middle-end/38509
* common.opt (Wfr
Hi Jeff,
The point of the patch is that the cmpstrnsi machine pattern should
not be used to implement the memcmp builtin function. This is
because a string comparison will terminate if two zero bytes are read
whereas a memory comparison should continue.
OK. Kindof surprised this wasn't deal
On Fri, Aug 12, 2011 at 8:57 AM, Paolo Bonzini wrote:
> On 08/12/2011 05:50 PM, H.J. Lu wrote:
>>
>> > Thanks, you are correct.
>>
>> It should work.
>>
>> Thanks.
>
> I prefer to wait for testing results to commit it, the breakage is minor.
It bootstraps successfully with "make -j12" on a 24 co
> If you did, then I don't know, you'll have to debug it, sorry.
>
> I vaguely recollect that -fcheck-references adds a check for 'this' at
> the start of final methods. If I'm misremembering, then that is
> probably the problem.
In my debug, there appears no check for 'this' at start of String.l
On Friday 12 August 2011 16:40:33, Paolo Bonzini wrote:
> install-unwind_h:
> - rm -f $(gcc_objdir)/include/unwind.h
> - cp unwind.h $(gcc_objdir)/include/unwind.h
> - chmod a+r $(gcc_objdir)/include/unwind.h
> + dest=$(gcc_objdir)/include/tmp-unwind.h; \
> + cp u
Hi,
On Tue, 9 Aug 2011, Michael Matz wrote:
> > Are there any updates on the libada problem or other reasons why the
> > patch cannot go in?
>
> Nope, I've solved that one. Letme update it.
Like so. Regstrapped on x86_64-linux (all languages + Ada). Okay for
trunk?
Ciao,
Michael.
--
On 08/12/2011 05:50 PM, H.J. Lu wrote:
> Thanks, you are correct.
It should work.
Thanks.
I prefer to wait for testing results to commit it, the breakage is minor.
Paolo
On Fri, Aug 12, 2011 at 8:40 AM, Paolo Bonzini wrote:
>>> Can't this sequence happen?
>>>
>>> proc1: cp unwind.h $(gcc_objdir)/include/tmp-unwind.h
>>> proc2: cp unwind.h $(gcc_objdir)/include/tmp-unwind.h
>>> proc1: sh $(srcdir)/../move-if-change \
>>> $(gcc_objdir
Hi,
tested x86_64-linux, committed to mainline.
Paolo.
PS: will add separately tests for the C++11 facilities.
//
2011-08-12 Paolo Carlini
* include/c_global/cmath (fmod(_Tp, _Up)): Add.
* include/c_std/cmath: Likewise.
Index: include/c_std/cmath
==
Can't this sequence happen?
proc1: cp unwind.h $(gcc_objdir)/include/tmp-unwind.h
proc2: cp unwind.h $(gcc_objdir)/include/tmp-unwind.h
proc1: sh $(srcdir)/../move-if-change \
$(gcc_objdir)/include/tmp-unwind.h \
$(gcc_objdir)/include/unwind.h
proc2
On Fri, Aug 12, 2011 at 10:16:05AM -0500, Sebastian Pop wrote:
> ---
> gcc/doc/install.texi |8 +++-
> 1 files changed, 7 insertions(+), 1 deletions(-)
>
> diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
> index 368221f..f2b2fd9 100644
> --- a/gcc/doc/install.texi
> +++ b/gcc/doc
On Fri, Aug 12, 2011 at 11:16, Michael Matz wrote:
> I see downthread that this is changed to hwi/uhwi already. I even would
> have suggested int/uint directly, as we never stream other numbers than
> host_wide_ints or chars.
For now, that's true. Over in PPH we do stream out ints/uints, and
t
---
gcc/doc/install.texi |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 368221f..f2b2fd9 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -368,6 +368,11 @@ It can be downloaded from
@uref{http://www.
---
gcc/graphite.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/gcc/graphite.c b/gcc/graphite.c
index b2cf7c6..7d124c7 100644
--- a/gcc/graphite.c
+++ b/gcc/graphite.c
@@ -41,6 +41,7 @@ along with GCC; see the file COPYING3. If not see
#include
#include
Hi,
On Fri, 12 Aug 2011, Diego Novillo wrote:
> 3- Replaces dwarf terminology for numbers with C-like terminology:
> sleb128 -> wide_int
> uleb128 -> wide_uint
I see downthread that this is changed to hwi/uhwi already. I even would
have suggested int/uint directly, as we never stre
---
gcc/graphite-poly.c |6
gcc/graphite-sese-to-poly.c | 54 --
2 files changed, 57 insertions(+), 3 deletions(-)
diff --git a/gcc/graphite-poly.c b/gcc/graphite-poly.c
index 1828727..2835311 100644
--- a/gcc/graphite-poly.c
+++ b/gcc/gr
On Fri, Aug 12, 2011 at 02:22, Sven Verdoolaege wrote:
> On Thu, Aug 11, 2011 at 05:44:37PM -0500, Sebastian Pop wrote:
>> + ctx = isl_ctx_alloc ();
>
> I can't find the call to cloog_isl_state_malloc in this patch
> that Tobi correctly requested.
Yes, sorry, I forgot about this one after I merg
Hello,
This fixes an ICE triggered by resolve.c's gfc_expr_to_initialize reseting a
range array ref into a full array ref, updating the rank, but leaving the
shape as is, which eventually leads to an out of bound error.
The right fix would probably be to avoid this kind of tricks. But I don't
On Thu, Aug 11, 2011 at 1:57 AM, Richard Guenther wrote:
> On Wed, 10 Aug 2011, Richard Guenther wrote:
>
>> On Wed, 10 Aug 2011, Richard Guenther wrote:
>>
>> > On Wed, 10 Aug 2011, Jason Merrill wrote:
>> >
>> > > On 08/10/2011 08:35 AM, Richard Guenther wrote:
>> > > > * call.c (build_o
Hi,
The Thumb2 tbh instruction can take half word values that are
multiplied by 2 which implies the maximum offset is 0x1 when you
add it to the pc ,
rather than 0xFFF which is what the current range check of 0x2000 for
HImode values indicates. Checked that a pre-compiled insn-recog.i that
I h
Hello,
-fbranch-probabilities fails to find the gcda information, because they
are initialized only if flag_profile_use.
The problem is easily observable by recompiling with
-fbranch-probabilities instead of -fprofile-use (after profile
information generation)
This fails with "xxx.gcda not
On Fri, Aug 12, 2011 at 09:50, Richard Guenther wrote:
> Oh, how even more confusing ;) So maybe hwi and uhwi instead then?
> That's what we use elsewhere.
Sounds good. Done.
Diego.
On Fri, 12 Aug 2011, Diego Novillo wrote:
> On Fri, Aug 12, 2011 at 09:45, Richard Guenther wrote:
> > On Fri, 12 Aug 2011, Diego Novillo wrote:
> >
> >>
> >> This is mind numbing but mechanical. This rename does two things:
> >>
> >> 1- Replaces the 'lto_' prefix with 'streamer_' in all the pub
On Fri, Aug 12, 2011 at 09:45, Richard Guenther wrote:
> On Fri, 12 Aug 2011, Diego Novillo wrote:
>
>>
>> This is mind numbing but mechanical. This rename does two things:
>>
>> 1- Replaces the 'lto_' prefix with 'streamer_' in all the public functions
>> that deal with generic streaming func
On Fri, Aug 12, 2011 at 5:38 AM, Pedro Alves wrote:
> On Friday 12 August 2011 13:17:21, Paolo Bonzini wrote:
>> 2011-08-12 Paolo Bonzini
>>
>> * Makefile.in (install-unwind_h): Create
>> $(gcc_objdir)/include/unwind.h
>> atomically.
>>
>> Index: Makefile.in
>> ==
Ramana Radhakrishnan writes:
> While the ARM backend doesn't support hot cold partitioning of basic blocks
> because of issues with the mini-pool placements, I suspect
> this by itself is a good cleanup. The bits of the use that I'm not
> convinced about
> yet are the changes of optimize_size in t
On Friday 12 August 2011 13:17:21, Paolo Bonzini wrote:
> 2011-08-12 Paolo Bonzini
>
> * Makefile.in (install-unwind_h): Create
> $(gcc_objdir)/include/unwind.h
> atomically.
>
> Index: Makefile.in
> ===
> --- M
On Fri, Aug 12, 2011 at 2:18 PM, Richard Guenther wrote:
>> Attached patch adds testcases for all conversion builtins. The gcc.dg
>> one tests that we are always able to link executable correctly, no
>> matter if target implements convresion optabs or not, the
>> gcc.target/i386 test exercises x8
Hi,
Quite some time back someone had pointed out that the ARM backend
used optimize_size in quite a few areas and that backends shouldn't
use this directly in patterns any more. I had written this patch up a few weeks
back and it was in one of my trees and had gone through some degree of
testing.
On Fri, 12 Aug 2011, Uros Bizjak wrote:
> On Thu, Aug 11, 2011 at 2:50 PM, Richard Guenther wrote:
>
> >> Currently, conversion from floating point to integer on 64bit targets
> >> goes through DImode temporary, due to missing BUILT_IN_ICEIL (and
> >> other) builtins that can convert directly fr
On 08/12/2011 02:13 PM, H.J. Lu wrote:
We may have a race condition here.
I opened:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50047
Does the attached patch work?
Can you provide a patch instead of the whole Makefile.in?
Sorry, that was not intended.
Paolo
2011-08-12 Paolo Bonzini
On Thu, Aug 11, 2011 at 2:50 PM, Richard Guenther wrote:
>> Currently, conversion from floating point to integer on 64bit targets
>> goes through DImode temporary, due to missing BUILT_IN_ICEIL (and
>> other) builtins that can convert directly from FP to integer.
> Please document those in doc/e
On Fri, Aug 12, 2011 at 12:04 AM, Paolo Bonzini wrote:
> On 08/11/2011 08:24 PM, H.J. Lu wrote:
>>
>> On Thu, Aug 11, 2011 at 11:19 AM, H.J. Lu wrote:
>>>
>>> On Thu, Aug 11, 2011 at 8:23 AM, Rainer Orth
>>> wrote:
Paolo Bonzini writes:
> On 08/10/2011 06:05 PM, Rainer Orth
This implements NEGATE_EXPR as 0 - X, re-using code we have for
MINUS_EXPR.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2011-08-12 Richard Guenther
* tree-vrp.c (extract_range_from_unary_expr_1): Implement
-X as 0 - X.
Index: gcc/tree-vrp
On Fri, 12 Aug 2011, Uros Bizjak wrote:
> On Thu, Aug 11, 2011 at 2:50 PM, Richard Guenther wrote:
>
> >> Currently, conversion from floating point to integer on 64bit targets
> >> goes through DImode temporary, due to missing BUILT_IN_ICEIL (and
> >> other) builtins that can convert directly fr
On Thu, Aug 11, 2011 at 2:50 PM, Richard Guenther wrote:
>> Currently, conversion from floating point to integer on 64bit targets
>> goes through DImode temporary, due to missing BUILT_IN_ICEIL (and
>> other) builtins that can convert directly from FP to integer.
> Please document those in doc/e
Jason Merrill writes:
> On 08/11/2011 10:49 AM, Rainer Orth wrote:
>> There might be an alternative implementation that is less invasive to
>> the C++ frontend, though: add
>>
>> && TARGET_DECL_NAMESPACE_STD_P (decl)
>>
>> in write_unscoped_name, defaulting to true, override it in sol2.h (w
On 12/08/11 10:28, Ramana Radhakrishnan wrote:
> On 12 August 2011 10:19, Ramana Radhakrishnan
> wrote:
>> Hi,
>>
>> The attached patch fixes up PR50022 which exposed a problem in my reworking
>
> And with the patch even :( ...
>
> Ramana
>
> 2011-08-12 Ramana Radhakrishnan
>
>PR ta
On Fri, 12 Aug 2011, James Greenhalgh wrote:
> > 2011-08-10 Richard Guenther
> >
> > * tree.h (can_trust_pointer_alignment): Remove.
> > * builtins.c (can_trust_pointer_alignment): Remove.
> >
> > cp/
> > * call.c (build_over_call): Call memcpy unconditionally.
> >
>
> Hi,
>
On 12 August 2011 10:19, Ramana Radhakrishnan
wrote:
> Hi,
>
> The attached patch fixes up PR50022 which exposed a problem in my reworking
And with the patch even :( ...
Ramana
2011-08-12 Ramana Radhakrishnan
PR target/50022
* config/arm/arm.c (output_move_double): Add 2 param
Hi,
The attached patch fixes up PR50022 which exposed a problem in my reworking
the movdi_vfp_cortex_a8 patterns. The problem was the ce_count attribute
wasn't being set at all for alternatives that would have more than
one assembler instruction that could be generated as a result of
predication.
> 2011-08-10 Richard Guenther
>
> * tree.h (can_trust_pointer_alignment): Remove.
> * builtins.c (can_trust_pointer_alignment): Remove.
>
> cp/
> * call.c (build_over_call): Call memcpy unconditionally.
>
Hi,
This appears to have caused a regression on arm-unknown-ea
On 3 August 2011 01:44, Joey Ye wrote:
>
> This patch fixes PR49437 with a single line change in ARM backend
> and a regression test case for ARM target
>
> ChangeLog:
> 2011-08-02 Matthew Gretton-Dann
> PR target/49437
> * config/arm/arm.c (arm_output_epilogue): Properly handle e
On Fri, Aug 12, 2011 at 8:27 AM, Jie Liu wrote:
> The method length() is not a final method, as java/lang/String.java line 447:
>
> public int length()
> {
> return count;
> }
>
> Is this the problem?
As String is a final class, all its methods are implicitly final.
Bryce
> Jie> But it does not work as we want, is there something wrong?
>
> Did you rebuild all of libgcj?
Yes. :)
>
> If you did, then I don't know, you'll have to debug it, sorry.
>
> I vaguely recollect that -fcheck-references adds a check for 'this' at
> the start of final methods. If I'm misrememb
On Thu, Aug 11, 2011 at 05:44:37PM -0500, Sebastian Pop wrote:
> + ctx = isl_ctx_alloc ();
I can't find the call to cloog_isl_state_malloc in this patch
that Tobi correctly requested.
skimo
diff --git a/gcc/graphite.c b/gcc/graphite.c
index 8f6d8a1..b2cf7c6 100644
--- a/gcc/graphite.c
+++ b/gcc/graphite.c
@@ -260,10 +260,12 @@ graphite_transform_loops (void)
bool need_cfg_cleanup_p = false;
VEC (scop_p, heap) *scops = NULL;
htab_t bb_pbb_mapping;
+ isl_ctx *ctx;
if
Shouldn't you document that you need isl now?
skimo
On 08/11/2011 08:24 PM, H.J. Lu wrote:
On Thu, Aug 11, 2011 at 11:19 AM, H.J. Lu wrote:
On Thu, Aug 11, 2011 at 8:23 AM, Rainer Orth
wrote:
Paolo Bonzini writes:
On 08/10/2011 06:05 PM, Rainer Orth wrote:
True: it is called once per multilib.
Just to doublecheck, are we sure that u
83 matches
Mail list logo
