On Sun, Aug 12, 2012 at 11:49 PM, Steven Bosscher wrote:
> Hello,
>
> This patch tried to use non-clearing memory allocation where possible.
> This is especially important for very large functions, when arrays of
> size in the order of n_basic_blocks or num_ssa_names are allocated to
> hold sparse
This fixes one issue with copyrename, that it "leaks" names backward
through a PHI node because it treats a PHI node
_1 = PHI <_2, _3, _4>
as
_1 = _2;
_1 = _3;
_1 = _4;
at the point of the PHI node which is certainly not what it is
(the assigns exist, one each, on the incoming edges only).
Denis Chertykov wrote:
> 2012/8/11 Georg-Johann Lay :
>> Weddington, Eric schrieb:
From: Georg-Johann Lay
The first step would be to bisect and find the patch that lead to
PR53923. It was not a change in the avr BE, so the question goes
to the authors of the respectiv
Hello,
To get the prefetchw cpuid flag, cpuid
function 0x8001 needs to be called.
Previous to patch, function 0x7 is called.
Bootstrapping and "make -k check" passes without failures.
Ok for trunk?
Regards
Ganesh
2012-08-13 Ganesh Gopalasubramanian
PR driver/54210
On 12-08-13 02:51 , Steven Bosscher wrote:
On Mon, Aug 13, 2012 at 2:34 AM, Diego Novillo wrote:
On 12-08-12 16:16 , Steven Bosscher wrote:
On Sun, Aug 12, 2012 at 10:09 PM, Diego Novillo
wrote:
This patch implements the configuration changes needed to
bootstrap with a C++ compiler by defa
On Sun, Aug 12, 2012 at 10:04 PM, Diego Novillo wrote:
> I will be sending 6 patches that implement all the changes we
> have been making on the cxx-conversion branch. As described in
> http://gcc.gnu.org/ml/gcc/2012-08/msg00015.html, these patches
> change the default bootstrap process so that s
On Sun, Aug 12, 2012 at 11:30 PM, Marc Glisse wrote:
> On Sun, 12 Aug 2012, Diego Novillo wrote:
>
>> This implements the double_int rewrite.
>>
>> See http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00711.html for
>> details.
>>
>> Diego.
>
>
> I am taking it as a chance to ask a couple questions ab
On Sun, Aug 12, 2012 at 11:30:59PM +0200, Marc Glisse wrote:
> >+inline double_int &
> >+double_int::operator ++ ()
> >+{
> >+ *this + double_int_one;
>
> *this += double_int_one;
> would be less confusing.
Do you mean that *this + double_int_one; alone also works, just is
confusing? That would
On Mon, Aug 13, 2012 at 09:29:45AM +, Gopalasubramanian, Ganesh wrote:
> To get the prefetchw cpuid flag, cpuid
> function 0x8001 needs to be called.
> Previous to patch, function 0x7 is called.
>
> Bootstrapping and "make -k check" passes without failures.
> Ok for trunk?
IMHO you move i
Hi!
I've bootstrapped/regtested on x86_64-linux and i686-linux and committed the
following backport to 4.7 branch.
2012-08-13 Jakub Jelinek
Backported from trunk
2012-07-19 Jakub Jelinek
PR rtl-optimization/53942
* function.c (assign_parm_setup_reg): Avoid
Hi,
For thumb1, arm-gcc rewrites move insn into subtract of ZERO in peephole2
pass intentionally, then executes
pass_if_after_reload/pass_regrename/pass_cprop_hardreg sequentially.
In this scenario, copy propagation opportunities are missed because:
1. the move insns are re-written.
2. pass_cp
Ping.
> -Original Message-
> From: Richard Earnshaw
> Sent: Thursday, July 26, 2012 9:19 PM
> To: Andrew Pinski
> Cc: Bin Cheng; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH]Remove duplicate check on BRANCH_COST in fold-const.c
>
> On 26/07/12 11:27, Andrew Pinski wrote:
> > On Thu, Jul
On Mon, 13 Aug 2012, Jakub Jelinek wrote:
On Sun, Aug 12, 2012 at 11:30:59PM +0200, Marc Glisse wrote:
+inline double_int &
+double_int::operator ++ ()
+{
+ *this + double_int_one;
*this += double_int_one;
would be less confusing.
Do you mean that *this + double_int_one; alone also works,
This is a small patch for sched-rgn that attempts to save DFA state at
the end of a basic block and re-use it in successor blocks. This was a
customer-requested optimization; I've not seen it make much of a
difference in any macro benchmarks.
Bootstrapped and tested on x86_64-linux and also tested
Yes! Thanks Jakub.
-Original Message-
From: Jakub Jelinek [mailto:ja...@redhat.com]
Sent: Monday, August 13, 2012 3:16 PM
To: Gopalasubramanian, Ganesh
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH,i386] cpuid function for prefetchw
On Mon, Aug 13, 2012 at 09:29:45AM +, Gopalasubra
On Fri, Aug 10, 2012 at 7:00 PM, Jonathan Wakely wrote:
> Let's CC Gaby, who likes to keep an eye on patches involving
Thanks Jonathan.
The patch is OK -- though I suspect we should have a documentation note
about the extension of allowing other C99 complex functions in .
-- Gaby
>
>
> On 10
On Mon, Aug 13, 2012 at 5:32 AM, Marc Glisse wrote:
> On Mon, 13 Aug 2012, Jakub Jelinek wrote:
>
>> On Sun, Aug 12, 2012 at 11:30:59PM +0200, Marc Glisse wrote:
+inline double_int &
+double_int::operator ++ ()
+{
+ *this + double_int_one;
>>>
>>>
>>> *this += double_int_
On Mon, 13 Aug 2012, Gabriel Dos Reis wrote:
On Fri, Aug 10, 2012 at 7:00 PM, Jonathan Wakely wrote:
Let's CC Gaby, who likes to keep an eye on patches involving
Thanks Jonathan.
The patch is OK -- though I suspect we should have a documentation note
about the extension of allowing other C
On Mon, Aug 13, 2012 at 6:17 AM, Marc Glisse wrote:
> On Mon, 13 Aug 2012, Gabriel Dos Reis wrote:
>
>> On Fri, Aug 10, 2012 at 7:00 PM, Jonathan Wakely
>> wrote:
>>>
>>> Let's CC Gaby, who likes to keep an eye on patches involving
>>
>>
>> Thanks Jonathan.
>>
>> The patch is OK -- though I susp
On 12-08-13 05:37 , Richard Guenther wrote:
On Sun, Aug 12, 2012 at 10:04 PM, Diego Novillo wrote:
I will be sending 6 patches that implement all the changes we
have been making on the cxx-conversion branch. As described in
http://gcc.gnu.org/ml/gcc/2012-08/msg00015.html, these patches
change
On 12-08-13 05:39 , Richard Guenther wrote:
It's an odd thing that you need to touch code replacing -> with . (yes, it's
due to the use of references) but not at the same time convert those places
to the new VEC interface.
Yes. I hated this aspect of the initial conversion. It caused many
m
On Mon, 13 Aug 2012, Gabriel Dos Reis wrote:
On Mon, Aug 13, 2012 at 6:17 AM, Marc Glisse wrote:
On Mon, 13 Aug 2012, Gabriel Dos Reis wrote:
On Fri, Aug 10, 2012 at 7:00 PM, Jonathan Wakely
wrote:
Let's CC Gaby, who likes to keep an eye on patches involving
Thanks Jonathan.
The patc
Hi!
John Regehr discovered a couple of spots in GCC sources that invoke
undefined behavior during bootstrap/regtest, the following patch fixes most
of them. I couldn't reproduce the diagnostic.c failure and would like to
leave the ipa hunk to Honza, I think the probability/frequency code often
mi
On 08/12/2012 10:00 PM, François Dumont wrote:
On 08/11/2012 03:47 PM, Marc Glisse wrote:
On Sat, 11 Aug 2012, François Dumont wrote:
Your remark on using std::move rather than std::forward Marc made
sens but didn't work. I don't understand why but the new test is
showing that std::forward
On Mon, Aug 13, 2012 at 11:45:36AM +0200, Jakub Jelinek wrote:
> On Mon, Aug 13, 2012 at 09:29:45AM +, Gopalasubramanian, Ganesh wrote:
> > To get the prefetchw cpuid flag, cpuid
> > function 0x8001 needs to be called.
> > Previous to patch, function 0x7 is called.
> >
> > Bootstrapping an
On Sat, Aug 11, 2012 at 2:25 PM, Marc Glisse wrote:
> On Fri, 10 Aug 2012, Marc Glisse wrote:
>
>> this patch detects permutations of permutations and merges them. It also
>> canonicalizes permutations a bit more.
>>
>> There are several issues with this patch:
>>
>> 1) I am not sure we always wan
On Mon, Aug 13, 2012 at 2:01 PM, Jakub Jelinek wrote:
> Hi!
>
> John Regehr discovered a couple of spots in GCC sources that invoke
> undefined behavior during bootstrap/regtest, the following patch fixes most
> of them. I couldn't reproduce the diagnostic.c failure and would like to
> leave the
Paolo Carlini writes:
> Marc Glisse ha scritto:
>
>>To be honest, I only checked the patch on linux/glibc, so there is a
>>real
>>risk on other platforms (which I don't have access to). I also did a
>>quick
>>sanity check on freebsd (not a true test).
>
> Ok, conditioning the small change on g
On 13.08.2012 14:32, Bernd Schmidt wrote:
This is a small patch for sched-rgn that attempts to save DFA state at
the end of a basic block and re-use it in successor blocks. This was a
customer-requested optimization; I've not seen it make much of a
difference in any macro benchmarks.
FWIW, this
Hi,
I've just merged upstream trunk on the aarch64-branch up to r190335.
Thanks
Sofiane
On Mon, Aug 13, 2012 at 2:10 PM, Jakub Jelinek wrote:
>> > To get the prefetchw cpuid flag, cpuid
>> > function 0x8001 needs to be called.
>> > Previous to patch, function 0x7 is called.
>> >
>> > Bootstrapping and "make -k check" passes without failures.
>> > Ok for trunk?
>>
>> IMHO you mov
Accessing loop_depth (bb->loop_father) isn't very expensive. The
following removes the duplicate info in basic-blocks which is not
properly kept up-to-date at the moment.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2012-08-13 Richard Guenther
* basic-blo
Bootstrapped on x86_64-unknown-linux-gnu, committed.
Richard.
2012-08-13 Richard Guenther
* tree-cfg.c (print_loop): Avoid ICEing for loops marked for
removal and loops with multiple latches.
Index: gcc/tree-cfg.c
=
On Mon, 13 Aug 2012, Richard Guenther wrote:
On Sat, Aug 11, 2012 at 2:25 PM, Marc Glisse wrote:
On Fri, 10 Aug 2012, Marc Glisse wrote:
1) I am not sure we always want to combine permutations. Indeed, someone
(user? vectorizer?) may have written 2 permutations to help the backend
generate o
On Mon, 13 Aug 2012, Rainer Orth wrote:
Paolo Carlini writes:
Marc Glisse ha scritto:
To be honest, I only checked the patch on linux/glibc, so there is a
real
risk on other platforms (which I don't have access to). I also did a
quick
sanity check on freebsd (not a true test).
Ok, condit
On Mon, Aug 13, 2012 at 5:59 AM, Uros Bizjak wrote:
> On Mon, Aug 13, 2012 at 2:10 PM, Jakub Jelinek wrote:
>
>>> > To get the prefetchw cpuid flag, cpuid
>>> > function 0x8001 needs to be called.
>>> > Previous to patch, function 0x7 is called.
>>> >
>>> > Bootstrapping and "make -k check" p
On Mon, Aug 13, 2012 at 3:03 PM, Marc Glisse wrote:
> On Mon, 13 Aug 2012, Richard Guenther wrote:
>
>> On Sat, Aug 11, 2012 at 2:25 PM, Marc Glisse wrote:
>>>
>>> On Fri, 10 Aug 2012, Marc Glisse wrote:
>>>
1) I am not sure we always want to combine permutations. Indeed, someone
(user?
>
> I guess people will complain soon enough if this causes horrible performance
> regressions in vectorized code.
Not having looked at your patch in great detail,. surely what we don't
want is a situation where 2 constant permutations are converted into
one generic permute. Based on a quick read
On Mon, Aug 13, 2012 at 3:12 PM, Ramana Radhakrishnan
wrote:
>>
>> I guess people will complain soon enough if this causes horrible performance
>> regressions in vectorized code.
>
> Not having looked at your patch in great detail,. surely what we don't
> want is a situation where 2 constant permu
On Mon, 13 Aug 2012, Richard Guenther wrote:
On Mon, Aug 13, 2012 at 3:12 PM, Ramana Radhakrishnan
wrote:
I guess people will complain soon enough if this causes horrible performance
regressions in vectorized code.
Not having looked at your patch in great detail,. surely what we don't
want
On Mon, Aug 13, 2012 at 03:13:26PM +0200, Richard Guenther wrote:
> On Mon, Aug 13, 2012 at 3:12 PM, Ramana Radhakrishnan
> wrote:
> >>
> >> I guess people will complain soon enough if this causes horrible
> >> performance
> >> regressions in vectorized code.
> >
> > Not having looked at your pat
On Mon, 13 Aug 2012, Richard Guenther wrote:
+ /* Check that it is only used here. We cannot use has_single_use
+ since the expression is using it twice itself... */
Ah ... so then
|| num_imm_uses (op0) != 2
Ah, ok, that's simpler indeed, but there were such dire warnings to
> "Jonathan" == Jonathan Wakely writes:
>> $11 = std::unique_ptr containing (datum *) 0x6067d0
Jonathan> It's inconsistent with the other printers in that it prints
Jonathan> the stored type, unlike e.g. std::vector which just says
Jonathan> "std::vector of length ..." but I think that's an
Dear All,
Please find attached a patch and testcase for the above PR. The
comment before generate_component_assignments explains the need for
the patch, which itself is fairly self explanatory.
Bootstrapped and regtested on Fc9/x86_64 - OK for trunk?
Best regards
Paul and Alessandro.
2012-08-
On Sun, Aug 12, 2012 at 11:28 PM, Laurynas Biveinis
wrote:
> I'm referring to the very first part of gty.texi, section 22 before
> the subsection table of contents:
> http://gcc.gnu.org/onlinedocs/gccint/Type-Information.html#Type-Information.
> It talks about C, structs and unions and it will ne
On Mon, 13 Aug 2012, Jakub Jelinek wrote:
On Mon, Aug 13, 2012 at 03:13:26PM +0200, Richard Guenther wrote:
The patch does not do that. It merely assumes that the target knows
how to perform an optimal constant permute and that two constant
permutes never generate better code than a single one
On Mon, Aug 13, 2012 at 03:45:00PM +0200, Marc Glisse wrote:
> On Mon, 13 Aug 2012, Jakub Jelinek wrote:
>
> >On Mon, Aug 13, 2012 at 03:13:26PM +0200, Richard Guenther wrote:
> >>The patch does not do that. It merely assumes that the target knows
> >>how to perform an optimal constant permute an
On 13 August 2012 14:21, Marc Glisse wrote:
> On Mon, 13 Aug 2012, Richard Guenther wrote:
>
>> On Mon, Aug 13, 2012 at 3:12 PM, Ramana Radhakrishnan
>> wrote:
I guess people will complain soon enough if this causes horrible
performance
regressions in vectorized code.
>>>
On 13 August 2012 14:54, Jakub Jelinek wrote:
> On Mon, Aug 13, 2012 at 03:45:00PM +0200, Marc Glisse wrote:
>> On Mon, 13 Aug 2012, Jakub Jelinek wrote:
>>
>> >On Mon, Aug 13, 2012 at 03:13:26PM +0200, Richard Guenther wrote:
>> >>The patch does not do that. It merely assumes that the target kno
On Mon, 13 Aug 2012, Ramana Radhakrishnan wrote:
On 13 August 2012 14:21, Marc Glisse wrote:
On Mon, 13 Aug 2012, Richard Guenther wrote:
On Mon, Aug 13, 2012 at 3:12 PM, Ramana Radhakrishnan
wrote:
I guess people will complain soon enough if this causes horrible
performance
regressions
Hello,
here is a fix for PR47586: missing deep copy for the case:
dt_w_alloc = ptr_func(arg)
where dt_w_alloc is of derived type with allocatable components, and
ptr_func returns a data pointer.
The fix tweaks expr_is_variable so that gfc_trans_scalar_assign is
called with the flag enabling deep
On Mon, Aug 13, 2012 at 4:12 PM, Ramana Radhakrishnan
wrote:
> On 13 August 2012 14:54, Jakub Jelinek wrote:
>> On Mon, Aug 13, 2012 at 03:45:00PM +0200, Marc Glisse wrote:
>>> On Mon, 13 Aug 2012, Jakub Jelinek wrote:
>>>
>>> >On Mon, Aug 13, 2012 at 03:13:26PM +0200, Richard Guenther wrote:
>>>
Hi all,
It is known that LEA splitting is one of the most critical problems
for Atom processors and changes try to improve it through:
1. More aggressive Lea splitting – do not perform splitting if
only split cost exceeds AGU stall .
2. Reordering splitting instructions to get better s
On 08/13/2012 06:32 AM, Bernd Schmidt wrote:
This is a small patch for sched-rgn that attempts to save DFA state at
the end of a basic block and re-use it in successor blocks. This was a
customer-requested optimization; I've not seen it make much of a
difference in any macro benchmarks.
Bootstrap
On Mon, 13 Aug 2012, Marc Glisse wrote:
On Mon, 13 Aug 2012, Richard Guenther wrote:
If your new predicate would match more places (can you do a quick search?)
You mean: if there are more optimizations that either already check for
double use in the same statement, or could benefit from doi
On Sun, Aug 12, 2012 at 08:02:30PM +0100, Jonathan Wakely wrote:
> This improves the fairly uninformative "Operation not supported"
> message given when std::thread is used without linking to libpthread.
>
> Now you get:
>
> terminate called after throwing an instance of 'std::system_error'
> w
On Sun, Aug 12, 2012 at 12:46 PM, Jack Howarth wrote:
> This patch introduces the regressions...
>
> FAIL: g++.dg/debug/dwarf2/pubnames-2.C scan-assembler
> .section\t.debug_pubnames
> FAIL: g++.dg/debug/dwarf2/pubnames-2.C scan-assembler
> "_GLOBAL__sub_I__ZN3one3c1vE0"+[ \t]+[#;]+[ \t]+exte
Hello!
This patch rewrites ix86_conditional_register_usage to improve following things:
- Do not mark REX registers in FIXED_REGISTERS. We know that no 32bit
target supports them, so we can disable REX registers at
ix86_conditional_register_usage as well.
- Use bitmaps in CALL_USED_REGISTERS to c
Richard Henderson wrote:
> Only "tested" visually, by examining assembly diffs of the
> runtime libraries between successive patches. All told it
> would appear to be some remarkable code size improvements.
Thanks for having a look at this!
> Please test.
Unfortunately GCC crashes during bootst
On 08/13/2012 10:07 AM, Ulrich Weigand wrote:
>> +/* Check whether a rotate of ROTL followed by an AND of CONTIG is equivalent
>> + to a shift followed by the AND. In particular, CONTIG should not overlap
>> + the (rotated) bit 0/bit 63 gap. */
>> +
>> +bool
>> +s390_extzv_shift_ok (int bitsi
On 13 August 2012 16:47, Joe Buck wrote:
> On Sun, Aug 12, 2012 at 08:02:30PM +0100, Jonathan Wakely wrote:
>> This improves the fairly uninformative "Operation not supported"
>> message given when std::thread is used without linking to libpthread.
>>
>> Now you get:
>>
>> terminate called after t
On 13 August 2012 14:31, Tom Tromey wrote:
>> "Jonathan" == Jonathan Wakely writes:
>
>>> $11 = std::unique_ptr containing (datum *) 0x6067d0
>
> Jonathan> It's inconsistent with the other printers in that it prints
> Jonathan> the stored type, unlike e.g. std::vector which just says
> Jonatha
Hi, the google/gcc-4_7 fails to linking anything (on x86-generic), by
looking into specs file, it seems that 'link_emulation' section is
missing in specs.
The problem is in config/i386/linux.h, SUBTARGET_EXTRA_SPECS (which is
not empty for chrome x86-generic) is overridden by
"LINUX_GRTE_EXTRA_SPE
On 13 August 2012 12:57, Marc Glisse wrote:
> I only modified the xml version. I expect the html version will be updated
> the next time someone who knows what they are doing touches the doc...
That's no problem, I tend to regenerate the html fairly frequently.
Thanks.
I noticed recently that while the validator was accepting the
'expire=MMDD' attribute, it was not actually doing anything with
it.
This patch fixes the oversight. Simon, I will be backporting the
patch to google/gcc-4_7.
Committed to trunk.
2012-08-13 Diego Novillo
* testsuite-m
On 13 August 2012 18:49, Jonathan Wakely wrote:
> I suppose EOPNOTSUPP might be better, if it's supported everywhere.
> EPERM has the advantage of being a documented error for
> pthread_create.
We do define std::errc::operation_not_supported unconditionally on
most platforms, but not mingw or djgp
Hello Paul,
I think there are a couple of bugs not triggered by the single component
types in the test. See below.
On 13/08/2012 15:37, Paul Richard Thomas wrote:
> +
> + /* Go through the code chain eliminating all but calls to
> + typebound procedures. Since we have been through
> +
Hello Dehao,
I have mostly cosmetic comments to make about the libcpp parts.
Dehao Chen writes:
> Index: libcpp/include/line-map.h
> ===
> *** libcpp/include/line-map.h (revision 189835)
> --- libcpp/include/line-map.h (working cop
Hi!
move_unallocated_pseudos apparently relies on no insns being deleted
in between find_moveable_pseudos and itself, which can happen when
delete_trivially_dead_insns removes dead insns and insns that feed them.
This can be fixed either by moving the delete_trivially_dead_insns
call earlier in i
On 08/10/2012 03:24 PM, Uros Bizjak wrote:
> + (eq_attr "isa" "fma") (symbol_ref "TARGET_FMA")
> + (eq_attr "isa" "fma4")
> +(symbol_ref "TARGET_FMA4 && !TARGET_FMA")
Why the !TARGET_FMA for fma4?
If both ISAs are enabled, I don't see why we couldn't choose from either.
If they
On Mon, Aug 13, 2012 at 9:03 PM, Richard Henderson wrote:
>> + (eq_attr "isa" "fma") (symbol_ref "TARGET_FMA")
>> + (eq_attr "isa" "fma4")
>> +(symbol_ref "TARGET_FMA4 && !TARGET_FMA")
>
> Why the !TARGET_FMA for fma4?
>
> If both ISAs are enabled, I don't see why we couldn't ch
Hi all!
Patch aims to fix instability introduced by first scheduler on x86. In
particular it targets following list:
[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46843
[2] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46829
[3] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36680
[4] http://gcc.gnu
Jakub Jelinek writes:
> --- gcc/simplify-rtx.c.jj 2012-08-10 15:49:20.0 +0200
> +++ gcc/simplify-rtx.c2012-08-13 09:51:43.628508537 +0200
> @@ -66,7 +66,7 @@ static rtx simplify_binary_operation_1 (
> static rtx
> neg_const_int (enum machine_mode mode, const_rtx i)
> {
> -
On 08/13/2012 02:10 PM, Paolo Carlini wrote:
On 08/12/2012 10:00 PM, François Dumont wrote:
Ok for trunk ?
Ok, thanks!
Paolo.
PS: you may want to remove the trailing blank line of
testsuite_counter_type.h
Attached patch applied.
2012-08-13 François Dumont
Ollie Wild
*
On 08/13/2012 12:33 PM, Uros Bizjak wrote:
> AFAIU fma3 is better than fma4 for bdver2 (the only CPU that
> implements both FMA sets). Current description of bdver2 doesn't even
> enable fma4 in processor_alias_table due to this fact.
>
> The change you are referring to adds preference for fma3 in
This fixes an error I inadvertently introduced a few months ago.
2012-08-13 David Adler
PR libstdc++/54185
* src/c++11/condition_variable.cc (condition_variable): Always
destroy native type in destructor.
* testsuite/30_threads/condition_variable/54185.cc: New.
Dear all,
Attached is the first part of a patch which will implement finalization
support and polymorphic freeing in gfortran.
It addresses two needs:
a) For polymorphic ("CLASS") variables, allocatable components have to
be freed; however, at compile time only the allocatable components of
Hello,
This patch adds basic support for utilizing the SH div0s instruction to
simplify some integer sign comparisons such as '(a < 0) == (b < 0)'.
Tested on rev 190332 with
make -k check RUNTESTFLAGS="--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
and no new
> 2012-08-07 Cary Coutant
>
> gcc/
> * dwarf2out.c (clone_as_declaration): Copy DW_AT_abstract_origin
> attribute.
> (generate_skeleton_bottom_up): Remove DW_AT_object_pointer attribute
> from original DIE.
> (clone_tree_hash): Rename to ...
> (cl
On 8/13/12, Gabriel Dos Reis wrote:
> On Aug 13, 2012 Marc Glisse wrote:
> > On Mon, 13 Aug 2012, Jakub Jelinek wrote:
> > > On Sun, Aug 12, 2012 at 11:30:59PM +0200, Marc Glisse wrote:
> > > > > +inline double_int &
> > > > > +double_int::operator ++ ()
> > > > > +{
> > > > > + *this + double_i
On 8/12/12, Marc Glisse wrote:
> On Sun, 12 Aug 2012, Diego Novillo wrote:
> > This implements the double_int rewrite.
> >
> > See http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00711.html for
> > details.
>
> I am taking it as a chance to ask a couple questions about the coding
> conventions.
>
> >
On 8/13/12, Richard Guenther wrote:
> Increment/decrement operations did not exist, please do not add
> them at this point.
Note that I have also added +=, -= and *= operations. Having them
has three advantages. First, it matches expectations on what
numeric types allow. Second, it results in
This patch fixes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54197.
Certain constructs (see bug for examples) cause C++ references to be
initialized with COMPOUND_EXPR's. The old logic was ignoring these,
causing those temporaries to be prematurely destroyed.
Tested on trunk via full x86_64 boot
Hi,
Here, we were setting the LOOKUP_NONVIRTUAL flag wrongly. Actually, we
need to check if the function context is the same than the instance
type -- yes that might happen that they be different in presence of
using-declarations.
It happens that it was working if the call was invoked through a
p
On Mon, Aug 13, 2012 at 03:47:43PM -0500, Ollie Wild wrote:
> diff --git a/gcc/cp/call.c b/gcc/cp/call.c
> index 5345f2b..b2fac16 100644
> --- a/gcc/cp/call.c
> +++ b/gcc/cp/call.c
> @@ -8924,6 +8924,12 @@ extend_ref_init_temps_1 (tree decl, tree init,
> VEC(tree,gc) **cleanups)
>tree sub = in
On Mon, Aug 13, 2012 at 3:50 PM, Jakub Jelinek wrote:
>
> The formatting doesn't match GCC coding conventions in several ways.
> You don't have spaces before (, and ( shouldn't be at the end of line if
> possible.
Updated patch attached.
Ollie
commit d023097c555a6f7cb84685fd7befedb550889d2c
Auth
On Mon, Aug 13, 2012 at 5:41 AM, Richard Guenther
wrote:
>> *this += double_int_one;
>> would be less confusing.
>
> Increment/decrement operations did not exist, please do not add them
> at this point.
But they are going to be used when the call-sites are converted.
There is no point in leaving
On 08/13/2012 01:22 PM, Lawrence Crowl wrote:
>> > yes, it is just as confusing and a bug as
>> >
>> > 2.3 + 1;
>> >
>> > is in plain C.
> Yes, it is a bug. It's a bit disturbing that it wasn't caught
> in bootstrap.
>
You'll recall that I pointed it out last time around as well.
r~
On 8/13/12, Richard Henderson wrote:
> On 08/13/2012 01:22 PM, Lawrence Crowl wrote:
>>> > yes, it is just as confusing and a bug as
>>> >
>>> > 2.3 + 1;
>>> >
>>> > is in plain C.
>> Yes, it is a bug. It's a bit disturbing that it wasn't caught
>> in bootstrap.
>
> You'll recall that I pointed i
On Mon, Apr 25, 2011 at 2:53 PM, Jason Merrill wrote:
> In C++0x we can have an initializer that is potentially constant and yet
> still type-dependent if it involves a call, so we need to handle that.
>
> For 4.7 I'm explicitly testing for type-dependency; for 4.6 I've made a
> smaller change to
Hello!
> It is known that LEA splitting is one of the most critical problems
> for Atom processors and changes try to improve it through:
> 1. More aggressive Lea splitting – do not perform splitting if
> only split cost exceeds AGU stall .
> 2. Reordering splitting instructions to get
Hello,
This adds support for the SH2A instructions movu.b and movu.w for
zero-extending mem loads with displacement addressing.
Tested on rev 190332 with
make -k check RUNTESTFLAGS="--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
and no new failures.
OK?
Chee
On 08/03/2012 11:28:57 +0200 Paolo Carlini wrote:
> No problem ;) Patch is Ok, thanks!
Hi Paolo,
I see you committed the patch for me. Thanks!! I literally posted
that last patch just minutes before heading out on vacation and didn't
want to commit it just before I left in case it caused any fa
Hi Carrot, could you take a look at this patch? Thanks!
The modification is in upstream trunk patch revision - 186859.
The same patch has been back ported to google/gcc-4_6
(http://codereview.appspot.com/6206055/), this is to apply on
google/gcc-4_7
Regards,
-Han
2012-08-13 Han Shen
On Sun, Aug 12, 2012 at 12:46 PM, Jack Howarth wrote:
> On Sun, Jul 01, 2012 at 09:33:06AM -0500, Gabriel Dos Reis wrote:
>> On Thu, Jun 28, 2012 at 12:50 PM, Sterling Augustine
>> wrote:
>> > The enclosed patch adds a fix for the pubnames anonymous namespaces
>> > contained
>> > within named na
On 9/08/2012, at 7:10 AM, Richard Sandiford wrote:
> Hmm, yeah, it does look like they should be using mips_linked_madd_p
> instead, except that mips_linked_madd_p isn't yet wired up to handle
> DSP macs. Rather than pattern-match them all, the easiest thing would
> probably be to define a new at
On 08/13/2012 02:44 PM, Jakub Jelinek wrote:
Hi!
move_unallocated_pseudos apparently relies on no insns being deleted
in between find_moveable_pseudos and itself, which can happen when
delete_trivially_dead_insns removes dead insns and insns that feed them.
This can be fixed either by moving th
On 07/23/12 02:34, Steven Bosscher wrote:
Hello,
While reading up on how gcov/profiling works, I noticed that there are
a lot of places where the notes file is still referred to as the
"basic block graph" file. Also, the gcov manual has not been updated
for -fprofile-dir. The attached patch addr
Hi Tobias,
Thanks for your work on this. This is a big step. I would add to your
list the following:
(4) If the entity is of extended type and the parent type has a component
that is finalizable, the parent component's component is finalized.
In ForTrilnos, we need for this to happen even when
On Aug 13, 2012, at 4:56 PM, Sterling Augustine wrote:
> The enclosed patch adjusts the test so it will pass on darwin. The
> issue was that it looked for some elf-specific assembly directives,
> which it shouldn't.
>
> OK for mainline?
Ok.
1 - 100 of 109 matches
Mail list logo
