Mike Stump writes:
>> Constructors are allowed, but PODs are often passed more efficiently.
>> That property seemed particularly important for double_int.
>
> Show us the difference in timing. Show us the generated code. I
> can't imagine that it could ever matter.
I'm also curious about that s
On Tue, 7 Aug 2012, Richard Smith wrote:
I've attached a patch for unordered_map which solves the rvalue
reference problem. For efficiency, I've created a new
_M_emplace_bucket method rather than call emplace directly.
I've verified all libstdc++ tests pass (sorry for the previous
oversight) a
On Wed, Aug 8, 2012 at 9:09 AM, Miles Bader wrote:
> Mike Stump writes:
>>> Constructors are allowed, but PODs are often passed more efficiently.
>>> That property seemed particularly important for double_int.
>>
>> Show us the difference in timing. Show us the generated code. I
>> can't imagin
On Tue, Aug 7, 2012 at 8:38 PM, Lawrence Crowl wrote:
> On 8/7/12, Richard Guenther wrote:
>> On Tue, Aug 7, 2012 at 2:35 AM, Lawrence Crowl wrote:
>> > Convert double_int from a struct with function into a class with
>> > operators and methods.
>> >
>> > This patch adds the methods and operator
Hi all!
I'd like to ask whether stack-protector changes for Android could go to 4.7?
Pathes are:
http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01089.html
http://gcc.gnu.org/ml/gcc-patches/2012-07/msg01157.html
Thanks,
Igor
On Wed, Jul 25, 2012 at 2:08 AM, Maxim Kuvyrkov wrote:
> On 24/07/2012,
"H.J. Lu" writes:
> diff --git a/gcc/combine.c b/gcc/combine.c
> index a07c046..b9a3589 100644
> --- a/gcc/combine.c
> +++ b/gcc/combine.c
> @@ -10784,12 +10784,30 @@ gen_lowpart_for_combine (enum machine_mode omode,
> rtx
> x)
>if (omode == imode)
> return x;
>
> - /* Return identity i
Richard Guenther writes:
Constructors are allowed, but PODs are often passed more efficiently.
That property seemed particularly important for double_int.
>>>
>>> Show us the difference in timing. Show us the generated code. I
>>> can't imagine that it could ever matter.
>>
>> I'm also
On Wed, 8 Aug 2012, Richard Guenther wrote:
+ static double_int make (unsigned HOST_WIDE_INT cst);
+ static double_int make (HOST_WIDE_INT cst);
+ static double_int make (unsigned int cst);
+ static double_int make (int cst);
[...]
Btw, if HOST_WIDE_INT == int the above won't even compile.
Hi DJ,
I am applying the following patch to the gcc mainline as an obvious
fix for the following problem building the RL78 backend:
gcc/config/rl78/rl78.c:151:3: error: 'PASS_POS_INSERT_BEFORE' undeclared
here (not in a function)
Cheers
Nick
gcc/ChangeLog
2012-08-08 Nick Clifton
On Wed, Aug 8, 2012 at 10:33 AM, Marc Glisse wrote:
> On Wed, 8 Aug 2012, Richard Guenther wrote:
>
> + static double_int make (unsigned HOST_WIDE_INT cst);
> + static double_int make (HOST_WIDE_INT cst);
> + static double_int make (unsigned int cst);
> + static double_int make
On Wed, Aug 8, 2012 at 10:28 AM, Nick Clifton wrote:
> Hi DJ,
>
> I am applying the following patch to the gcc mainline as an obvious
> fix for the following problem building the RL78 backend:
>
> gcc/config/rl78/rl78.c:151:3: error: 'PASS_POS_INSERT_BEFORE' undeclared
> here (not in a fu
Sandra Loosemore writes:
> Index: gcc/config/mips/mips.c
> ===
> --- gcc/config/mips/mips.c(revision 190188)
> +++ gcc/config/mips/mips.c(working copy)
> @@ -1530,6 +1530,8 @@ mips16_local_function_p (const_rtx x)
>return
Hi Richard,
Err - you are inside the compiler and should not use plugin stuff to
register your machine dependent pass.
Umm, OK, what is the correct method for registering target specific
passes ? (Ones that need to run at times other than
TARGET_MACHINE_DEPENDENT_REORG).
Cheers
Nick
On Wed, Aug 8, 2012 at 11:02 AM, nick clifton wrote:
> Hi Richard,
>
>
>> Err - you are inside the compiler and should not use plugin stuff to
>> register your machine dependent pass.
>
>
> Umm, OK, what is the correct method for registering target specific passes ?
> (Ones that need to run at tim
On Wed, Aug 8, 2012 at 3:29 AM, Miles Bader wrote:
> Richard Guenther writes:
> Constructors are allowed, but PODs are often passed more efficiently.
> That property seemed particularly important for double_int.
Show us the difference in timing. Show us the generated code. I
>
On Wed, Aug 8, 2012 at 9:54 AM, Igor Zamyatin wrote:
> I'd like to ask whether stack-protector changes for Android could go to 4.7?
>
> Pathes are:
>
> http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01089.html
> http://gcc.gnu.org/ml/gcc-patches/2012-07/msg01157.html
OK, as far as x86 is concerned
8 Joseph Myers
* simplify-rtx.c (simplify_binary_operation_1): Do not simplify
IOR to a constant if one operand has side effects.
testsuite:
2012-08-08 Joseph Myers
* gcc.c-torture/execute/20120808-1.c: New test.
Index: testsuite/gcc.c-torture/execu
Hi,
I've just reverted my recent merge from upstream trunk on the aarch64-branch
(r190119).
A cleaner and broader merge will follow.
Thanks
Sofiane
On 8/08/2012, at 9:46 PM, Uros Bizjak wrote:
> On Wed, Aug 8, 2012 at 9:54 AM, Igor Zamyatin wrote:
>
>> I'd like to ask whether stack-protector changes for Android could go to 4.7?
>>
>> Pathes are:
>>
>> http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01089.html
>> http://gcc.gnu.org/ml/gcc-pat
"Joseph S. Myers" writes:
> 2012-08-08 Joseph Myers
>
> * simplify-rtx.c (simplify_binary_operation_1): Do not simplify
> IOR to a constant if one operand has side effects.
OK, thanks.
Richard
* Arnaud Charlet, 2012-06-18 :
> > > > -#if defined (__linux__) && !defined (_XOPEN_SOURCE)
> > > > +#if (defined (__linux__) || defined (__GNU__)) && !defined
> > > > (_XOPEN_SOURCE)
> > > > /** For Linux _XOPEN_SOURCE must be defined, otherwise IOV_MAX is not
> > > > defined
> > > > **/
> >
Hello,
Bdver2 cpu supports both fma and fma4 instructions.
Previous to patch, option "-mno-xop" removes "-mfma4".
Similarly, option "-mno-fma4" removes "-mxop".
So, the patch conditionally disables "-mfma" or "-mfma4".
Enabling "-mxop" is done by also checking "-mfma".
Ok for trunk?
Regards
Gan
On Wed, Aug 8, 2012 at 1:31 PM, wrote:
> Hello,
>
> Bdver2 cpu supports both fma and fma4 instructions.
> Previous to patch, option "-mno-xop" removes "-mfma4".
> Similarly, option "-mno-fma4" removes "-mxop".
Eh? Why's that? I think we should disentangle -mxop and -mfma4
instead. Otherwise,
.. I'm coming to the conclusion that the tests which are not fixed by a
patch along the lines of my draft don't have much to do with SFINAE vs
inaccessible bases per se (with the possible exception of the
conditional operator case). Consider:
struct A
{};
struct B
{};
template
T &&declval();
On 08/08/2012 01:57 PM, Paolo Carlini wrote:
this also triggers the static_assert. Really, in
'decltype(B{declval()})' almost *everything* is Ok between the
curly brackets. Maybe we should have a separate PR for this.
And I think this issue is addressed by the ongoing work on instantiation
depe
Hi,
while running check for Android NDK compiler (I've used
contrib/test_installed for it) I've noticed that gcov name is
hardcoded in g++.dg/gcov/gcov.exp.
All NDK x86 tools have prefix like i686-linux-android-, so testing
will fail to spawn gcov.
The patch attached introduces --with-gcov flag o
On 08/08/2012 02:47 PM, Paolo Carlini wrote:
On 08/08/2012 01:57 PM, Paolo Carlini wrote:
this also triggers the static_assert. Really, in
'decltype(B{declval()})' almost *everything* is Ok between the
curly brackets. Maybe we should have a separate PR for this.
And I think this issue is addres
On 08/08/2012 09:34 AM, Marc Glisse wrote:
On Tue, 7 Aug 2012, Richard Smith wrote:
I've attached a patch for unordered_map which solves the rvalue
reference problem. For efficiency, I've created a new
_M_emplace_bucket method rather than call emplace directly.
I've verified all libstdc++ tes
> Here is the patch with some obvious fixes. If there are no objections,
> could anyone please check it in?
Done:
http://gcc.gnu.org/ml/gcc-cvs/2012-08/msg00203.html
Thanks, K
On Wed, Aug 8, 2012 at 1:45 AM, Richard Guenther
wrote:
> On Wed, Aug 8, 2012 at 10:28 AM, Nick Clifton wrote:
>> Hi DJ,
>>
>> I am applying the following patch to the gcc mainline as an obvious
>> fix for the following problem building the RL78 backend:
>>
>> gcc/config/rl78/rl78.c:151:3
On 08/08/2012 03:15 PM, François Dumont wrote:
I have also introduce a special std::pair constructor for container
usage so that we do not have to include the whole tuple stuff just for
associative container implementations.
To be clear: sorry, this is not an option.
Paolo.
On Wed, Aug 8, 2012 at 1:08 AM, Richard Sandiford
wrote:
> "H.J. Lu" writes:
>> diff --git a/gcc/combine.c b/gcc/combine.c
>> index a07c046..b9a3589 100644
>> --- a/gcc/combine.c
>> +++ b/gcc/combine.c
>> @@ -10784,12 +10784,30 @@ gen_lowpart_for_combine (enum machine_mode omode,
>> rtx
>> x)
>>
On Wed, Aug 8, 2012 at 3:40 PM, H.J. Lu wrote:
> wrote:
>> "H.J. Lu" writes:
>>> diff --git a/gcc/combine.c b/gcc/combine.c
>>> index a07c046..b9a3589 100644
>>> --- a/gcc/combine.c
>>> +++ b/gcc/combine.c
>>> @@ -10784,12 +10784,30 @@ gen_lowpart_for_combine (enum machine_mode omode,
>>> rtx
On Wed, 8 Aug 2012, François Dumont wrote:
On 08/08/2012 09:34 AM, Marc Glisse wrote:
On Tue, 7 Aug 2012, Richard Smith wrote:
I've attached a patch for unordered_map which solves the rvalue
reference problem. For efficiency, I've created a new
_M_emplace_bucket method rather than call empla
On Wed, Aug 8, 2012 at 6:43 AM, Uros Bizjak wrote:
> On Wed, Aug 8, 2012 at 3:40 PM, H.J. Lu wrote:
>
>> wrote:
>>> "H.J. Lu" writes:
diff --git a/gcc/combine.c b/gcc/combine.c
index a07c046..b9a3589 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -10784,12 +10784,30
This splits out more cleanups from the main patch to make that smaller.
The only bigger part of the patch is making tree-stdarg track
escapes/varargs for SSA names more precise by not globbing on
SSA_NAME_VAR but instead using the bits [0..num_ssa_names-1] for
SSA names and [num_ssa_names,max_decl
This adds a virual_operand_p predicate and uses it where we currently
use the bit on the decl (VAR_DECL_IS_VIRTUAL_OPERAND) directly.
I suspect most of the is_gimple_reg users in SSA optimizers can
be replaced by this predicate eventually making is_gimple_reg a
private predicate to the gimplifier
On Wed, Aug 8, 2012 at 3:35 PM, Ian Lance Taylor wrote:
> On Wed, Aug 8, 2012 at 1:45 AM, Richard Guenther
> wrote:
>> On Wed, Aug 8, 2012 at 10:28 AM, Nick Clifton wrote:
>>> Hi DJ,
>>>
>>> I am applying the following patch to the gcc mainline as an obvious
>>> fix for the following problem
On Wed, Aug 8, 2012 at 7:03 AM, Richard Guenther
wrote:
> I don't think we really want that (machine dependent passes). It seems
> we cannot get away with it (so we have mdreorg). Allowing (some) flexibility
> where to put mdreorg is ok, using two different mechanisms (mdreorg and
> a "plugin")
On Wed, Aug 8, 2012 at 4:06 PM, Ian Lance Taylor wrote:
> On Wed, Aug 8, 2012 at 7:03 AM, Richard Guenther
> wrote:
>
>> I don't think we really want that (machine dependent passes). It seems
>> we cannot get away with it (so we have mdreorg). Allowing (some) flexibility
>> where to put mdreorg
The following patch fixes a ppc64 gcc testsuite failure.
The patch was successfully bootstrapped on x86/x86-64.
Committed as rev. 190207.
2012-08-07 Vladimir Makarov
* lra-int.h (lra_constraint_iter_after_spill): New.
* lra.c (lra): Initialize lra_constraint_iter_after_spil
On 3 August 2012 16:00, Richard Earnshaw wrote:
> On 30/07/12 12:43, Ramana Radhakrishnan wrote:
>>> Patch 1 fixes up the vaba and vabal patterns to use a canonical RTL
>>> form with the first operand to the plus being the more complex one.
>>
>> This patch canonicalizes the instruction patterns f
On Wed, Aug 8, 2012 at 7:11 AM, Richard Guenther
wrote:
> On Wed, Aug 8, 2012 at 4:06 PM, Ian Lance Taylor wrote:
>> On Wed, Aug 8, 2012 at 7:03 AM, Richard Guenther
>> wrote:
>>
>>> I don't think we really want that (machine dependent passes). It seems
>>> we cannot get away with it (so we hav
"H.J. Lu" writes:
> On Wed, Aug 8, 2012 at 6:43 AM, Uros Bizjak wrote:
>> Probably we need to backport this patch to 4.7, where x32 is
>> -maddress-mode=long by default.
>>
>
> It doesn't fail on 4.7 branch since checking mode on PLUS CONST
> is new on trunk. However, I think it is a correctness
On 08/08/2012 07:19 AM, Ian Lance Taylor wrote:
>> > I was suggesting to for example register a 2nd mdreorg-like pass and
>> > add a 2nd target hook. regstack should get the same treatment.
> If the mechanism is a proliferation of mdreorg passes in every place
> we want a target-specific pass, tha
> But we should definitely have a way to register machine dependent
> passes, and what's wrong with the plugin interface?
IIRC I asked about how to schedule that pass when I wrote it, and "use
the plugin API" was the recommendation.
Some background...
The RL78 devirtualization pass is *not* a r
Omit another TARGET_LIB_PATH from RPATH_ENVVAR set on bootstrap builds.
A second occurrence of adding TARGET_LIB_PATH to LD_LIBRARY_PATH on gcc
bootstrap builds. This one also needs removing to enable full test coverage.
Discussion and rationale at: http://gcc.gnu.org/ml/gcc/2012-06/msg00314.htm
On 08/07/2012 06:25 AM, Richard Guenther wrote:
> (is re-setting _every_ stmt location really ok in all cases?)
I'm certain that it's not, though you can't tell that from C++.
Examine instead a Java test case using try-finally. In Java the
contents of the finally would be incorrectly relocated f
On 12-08-08 11:49 , Simon Baldwin wrote:
Omit another TARGET_LIB_PATH from RPATH_ENVVAR set on bootstrap builds.
A second occurrence of adding TARGET_LIB_PATH to LD_LIBRARY_PATH on gcc
bootstrap builds. This one also needs removing to enable full test coverage.
Discussion and rationale at: htt
On Wed, Aug 8, 2012 at 8:56 AM, Richard Henderson wrote:
> On 08/07/2012 06:25 AM, Richard Guenther wrote:
>> (is re-setting _every_ stmt location really ok in all cases?)
>
> I'm certain that it's not, though you can't tell that from C++.
>
> Examine instead a Java test case using try-finally. I
On 08/08/2012 09:27 AM, Dehao Chen wrote:
> On Wed, Aug 8, 2012 at 8:56 AM, Richard Henderson wrote:
>> On 08/07/2012 06:25 AM, Richard Guenther wrote:
>>> (is re-setting _every_ stmt location really ok in all cases?)
>>
>> I'm certain that it's not, though you can't tell that from C++.
>>
>> Exam
On 08/08/2012 02:47 PM, Paolo Carlini wrote:
AFAICS, the most uncertain case is the conditional operator test,
otherwise we could split the PR.
Turned out to be really trivial: a missing check for error_mark_node in
build_conditional_expr_1.
I'll send in a separate message a complete regtested
This patch implements a warning for the following Fortran 95 (and later)
obsolescent features (cf. F2008, "B.2 Obsolescent features"):
"(2) Shared DO termination and termination on a statement other than END
DO or CONTINUE -- use
an END DO or a CONTINUE statement for each DO statement."
"(6) D
On Aug 8, 2012, at 8:38 AM, DJ Delorie wrote:
> The RL78 devirtualization pass is *not* a reorg pass, it has to happen
> after reload but before debug info is set up. The RL78 does not have
> a consistent register set or addressing scheme, GCC cannot practically
> support it.
Gosh, we got one of
Richard Henderson wrote:
> On 08/07/2012 10:02 AM, Ulrich Weigand wrote:
> > The following patch changes the builtin expander to pass a MEM oldval
> > as-is to the back-end expander, so that the back-end can move the
> > store to before the CC operation. With that patch I'm also seeing
> > all the
> Gosh, we got one of those too, though, I don't know how much worse
> your machine is than mine, in at all.
In the RL78 case, it's basically a modern Z80 clone. It has eight
8-bit registers (er, four banks of those, one active at a time) which
can be combined into four 16-bit registers, but for
On Wed, Aug 08, 2012 at 10:52:28AM -0700, Mike Stump wrote:
> As we move to C++, I'd love for port maintainers to be able to get together
> and hoist _up_ code from the port so other ports can use it and thus, have
> more sharing. We make heavily stylized uses, which could be wrapped into a
> p
> Index: gcc/cp/parser.c
> ===
> --- gcc/cp/parser.c (revision 190195)
> +++ gcc/cp/parser.c (working copy)
> @@ -28351,6 +28351,13 @@
>FOR_EXPR (statement) = decl;
>CILK_FOR_GRAIN (statement) = grain;
>
> + /* If an
Hello Aldy,
The only time we will get into this function (cp_parser_cilk_for) is
when the fcilkplus is turned on.
Here is the original call for this function (line #9983) :
if (!flag_enable_cilk)
fatal_error ("-fcilkplus must be enabled to use %");
else
statemen
On 08/08/12 13:27, Iyer, Balaji V wrote:
Hello Aldy,
The only time we will get into this function (cp_parser_cilk_for) is
when the fcilkplus is turned on.
Here is the original call for this function (line #9983) :
if (!flag_enable_cilk)
fatal_error ("-fcilkplus must be en
> Index: gcc/testsuite/g++.dg/debug/dwarf2/dwarf4-nested.C
> ===
> --- gcc/testsuite/g++.dg/debug/dwarf2/dwarf4-nested.C (revision 0)
> +++ gcc/testsuite/g++.dg/debug/dwarf2/dwarf4-nested.C (revision 0)
> @@ -0,0 +1,55 @@
> +// { d
In the same vein as your CAS boolean output patch, if we rearrange the
copies here we can get the combined compare-and-branch insn for the z10.
I see that the z196 prefers not to use those, but the number of insns
in that case remains the same, merely in a different order.
Can you please test with
Its ok. I am glad you are catching all these, it makes me rethink and recheck.
Thanks,
Balaji V. Iyer.
-Original Message-
From: Aldy Hernandez [mailto:al...@redhat.com]
Sent: Wednesday, August 08, 2012 2:29 PM
To: Iyer, Balaji V
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH][Cilkplus
Sandra Loosemore writes:
>> +;; Before reload, all multiplier is registered as imul3 (which has a long
>> +;; latency). We temporary jig the latency such that the macc groups
>> +;; are scheduled closely together during the first scheduler pass.
>> +(define_bypass 1 "r74k_int_mul3" "r74k_dsp_ma
hi Diego,
just a word on style in the documentation:
> +template
> +void gt_pch_nx (TP *tp)
> +@{
> + extern void gt_pch_nx (T&);
> +
> + /* This marks field 'fld' of type 'T'. */
> + gt_pch_nx (tp->fld);
> +@}
'extern' declaration at local scope if considered an extremely
poor style in C++
On 12-08-08 16:12 , Gabriel Dos Reis wrote:
hi Diego,
just a word on style in the documentation:
+template
+void gt_pch_nx (TP *tp)
+@{
+ extern void gt_pch_nx (T&);
+
+ /* This marks field 'fld' of type 'T'. */
+ gt_pch_nx (tp->fld);
+@}
'extern' declaration at local scope if considere
Hi,
this is a booted and tested patch which handles all the tests submitted
as part of the PR besides the first 4, which require
finish_decltype_type to use an instantiation_dependent_p along the lines
of the work done as part of c++/51222. As I mentioned, I already
verified that the latter w
On 08/08/2012 03:39 PM, Paolo Carlini wrote:
On 08/08/2012 03:15 PM, François Dumont wrote:
I have also introduce a special std::pair constructor for container
usage so that we do not have to include the whole tuple stuff just
for associative container implementations.
To be clear: sorry, this
On Wed, Aug 8, 2012 at 3:37 PM, Diego Novillo wrote:
> On 12-08-08 16:12 , Gabriel Dos Reis wrote:
>>
>> hi Diego,
>>
>> just a word on style in the documentation:
>>
>>> +template
>>> +void gt_pch_nx (TP *tp)
>>> +@{
>>> + extern void gt_pch_nx (T&);
>>> +
>>> + /* This marks field 'fld' of typ
On Wed, Aug 8, 2012 at 4:47 PM, Gabriel Dos Reis
wrote:
> So, if the issue that the function does not exist at the point of the template
> definition, but will definitely exist at the point where it is instantiated
> because of inclusion of a header file (later or in a different
> translation uni
Hello,
This patch fixes a minor issue related to the displacement addressing
patterns, which leads to useless movt exts.* sequences and one of the
predicates wrongly accepting non-mem ops.
Tested on rev 190151 with
make -k check RUNTESTFLAGS="--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/
On Wed, Aug 8, 2012 at 3:58 PM, Diego Novillo wrote:
> On Wed, Aug 8, 2012 at 4:47 PM, Gabriel Dos Reis
> wrote:
>
>> So, if the issue that the function does not exist at the point of the
>> template
>> definition, but will definitely exist at the point where it is instantiated
>> because of inc
On 12-08-08 17:25 , Gabriel Dos Reis wrote:
Aha, so it is an ordering issue, e.g. declarations being generated
after they have been seen used in an instantiation.
We might want to consider including the header file (that contains
only the declarations of the marking functions) in the header
f
On Wed, Aug 8, 2012 at 4:27 PM, Diego Novillo wrote:
> On 12-08-08 17:25 , Gabriel Dos Reis wrote:
>
>> Aha, so it is an ordering issue, e.g. declarations being generated
>> after they have been seen used in an instantiation.
>>
>> We might want to consider including the header file (that contain
Hello,
This patch mainly improves stores of negated/inverted floating point
comparison results in regs and removes a useless zero-extension after
storing the negated T bit in a reg.
One thing that is annoying is the fact that the '-1' constant is emitted
during combine and thus won't get any chan
As previously discussed, this patch XFAIL's the new libstdc++ failure
caused by http://gcc.gnu.org/viewcvs?revision=190129&view=revision.
It will be reverted once the issues discussed at
http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00141.html have been
resolved.
Okay to submit to google/gcc-4_7?
On 12-08-08 17:52 , Ollie Wild wrote:
As previously discussed, this patch XFAIL's the new libstdc++ failure
caused by http://gcc.gnu.org/viewcvs?revision=190129&view=revision.
It will be reverted once the issues discussed at
http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00141.html have been
resolv
On Aug 8, 2012, at 11:16 AM, Nathan Froyd wrote:
> On Wed, Aug 08, 2012 at 10:52:28AM -0700, Mike Stump wrote:
>> As we move to C++, I'd love for port maintainers to be able to get together
>> and hoist _up_ code from the port so other ports can use it and thus, have
>> more sharing. We make hea
Hello,
This is a fix to prepare the xmlj_io.c file of gnu classpath to a coming
API change in libxml2.
Basically, we were previously accessing fields inside the
xmlOutputBuffer struct of libxml2. In a coming version of libxml2,
that won't be possible anymore. Client code will have to use access
On Mon, 2012-07-30 at 08:28 -0700, Richard Henderson wrote:
> On 2012-07-29 15:56, Oleg Endo wrote:
> > + "&& can_create_pseudo_p ()"
> > + [(set (match_dup 5) (ashift:SI (match_dup 1) (match_dup 2)))
> > + (set (match_dup 6) (plus:SI (match_dup 5) (match_dup 3)))
> > + (set (match_dup 0) (me
On 8/7/12, Mike Stump wrote:
> On Aug 7, 2012, at 11:42 AM, Lawrence Crowl wrote:
> > On 8/7/12, Mike Stump wrote:
> > > On Aug 6, 2012, at 5:35 PM, Lawrence Crowl wrote:
> > > > Convert double_int from a struct with function into a class
> > > > with operators and methods.
> > >
> > > We have a
On 8/7/12, Richard Henderson wrote:
> On 08/06/2012 05:35 PM, Lawrence Crowl wrote:
> > +inline double_int &
> > +double_int::operator ++ ()
> > +{
> > + *this + double_int_one;
> > + return *this;
> > +}
> > +
> > +inline double_int &
> > +double_int::operator -- ()
> > +{
> > + *this - double
On 8/7/12, Mike Stump wrote:
> On Aug 7, 2012, at 11:38 AM, Lawrence Crowl wrote:
> > Hm. There seems to be significant opinion that there should not be any
> > implicit conversions. I am okay with operations as above, but would like
> > to hear the opinions of others.
>
> If there is an agreed
On Wed, Aug 1, 2012 at 10:36 AM, William J. Schmidt
wrote:
> Greetings,
>
> Thanks for the review of part 2! Here's another chunk of the SLSR code
> (I feel I owe you a few beers at this point). This performs analysis
> and replacement on groups of related candidates having an SSA name
> (rather
On 8/8/12, Richard Guenther wrote:
> On Aug 7, 2012 Lawrence Crowl wrote:
> > We should probably think about naming conventions for mutating
> > operations, as I expect we will want them eventually.
>
> Right. In the end I would prefer explicit constructors.
I don't think we're thinking about t
On Wed, Aug 8, 2012 at 3:25 PM, H.J. Lu wrote:
> On Wed, Aug 1, 2012 at 10:36 AM, William J. Schmidt
> wrote:
>> Greetings,
>>
>> Thanks for the review of part 2! Here's another chunk of the SLSR code
>> (I feel I owe you a few beers at this point). This performs analysis
>> and replacement on
On Aug 8, 2012, at 11:14 AM, DJ Delorie wrote:
> It's the weird addressing modes that confuse gcc.
Ah, yes... That problem. Sigh, my port is nice and orthogonal and doesn't
suffer in this area, so... no solution from me.
On Aug 8, 2012, at 3:25 PM, H.J. Lu wrote:
> This doesn't work on x32 nor Linux/ia32 since -m32
> may not be needed for ILP32. This patch works for
> me. OK to install?
Ok.
On 8/8/12, Richard Guenther wrote:
> On Aug 7, 2012 Lawrence Crowl wrote:
> > On 8/7/12, Richard Guenther wrote:
> > > For most parts overloads that take an (unsigned) HOST_WIDE_INT
> > > argument would be nice, as well as the ability to say dbl + 1.
> >
> > Hm. There seems to be significant op
On 08/08/2012 03:27 PM, Andrew Pinski wrote:
> On Wed, Aug 8, 2012 at 3:25 PM, H.J. Lu wrote:
>> On Wed, Aug 1, 2012 at 10:36 AM, William J. Schmidt
>> wrote:
>>> Greetings,
>>>
>>> Thanks for the review of part 2! Here's another chunk of the SLSR code
>>> (I feel I owe you a few beers at this p
Richard Henderson wrote:
> In the same vein as your CAS boolean output patch, if we rearrange the
> copies here we can get the combined compare-and-branch insn for the z10.
> I see that the z196 prefers not to use those, but the number of insns
> in that case remains the same, merely in a differen
On 8/8/12, Richard Guenther wrote:
> On Aug 8, 2012 Marc Glisse wrote:
> > On Wed, 8 Aug 2012, Richard Guenther wrote:
> > > > > > + static double_int make (unsigned HOST_WIDE_INT cst);
> > > > > > + static double_int make (HOST_WIDE_INT cst);
> > > > > > + static double_int make (unsigned int
This patch is for the google/gcc-4_7 branch. It's a backport of an
upstream patch at:
http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00398.html
If approved for trunk, is this OK for google/gcc-4_7?
Google ref b/6705530.
Original description:
With --std=c++11, a template parameter can refer to
On 8/8/12, Gabriel Dos Reis wrote:
> On Aug 8, 2012 Miles Bader wrote:
> > Richard Guenther writes:
> > > > > > Constructors are allowed, but PODs are often passed
> > > > > > more efficiently. That property seemed particularly
> > > > > > important for double_int.
> > > > >
> > > > > Show us t
On 08/08/2012 03:12 PM, Oleg Endo wrote:
> How about the attached patch?
> Is that way of dealing with the mems OK?
> What could be a possible test case for the alias info issue?
That looks like the right sort of thing.
A test case would have to be for a missed-optimization,
where we failed to sc
On Thu, Aug 09, 2012 at 12:08:20AM +0200, Dodji Seketeli wrote:
> Hello,
>
> This is a fix to prepare the xmlj_io.c file of gnu classpath to a coming
> API change in libxml2.
>
> Basically, we were previously accessing fields inside the
> xmlOutputBuffer struct of libxml2. In a coming version of
On 8/8/12, Miles Bader wrote:
> Mike Stump writes:
> > > Constructors are allowed, but PODs are often passed more
> > > efficiently. That property seemed particularly important
> > > for double_int.
> >
> > Show us the difference in timing. Show us the generated code.
> > I can't imagine that i
On Wed, 2012-08-08 at 15:35 -0700, Janis Johnson wrote:
> On 08/08/2012 03:27 PM, Andrew Pinski wrote:
> > On Wed, Aug 8, 2012 at 3:25 PM, H.J. Lu wrote:
> >> On Wed, Aug 1, 2012 at 10:36 AM, William J. Schmidt
> >> wrote:
> >>> Greetings,
> >>>
> >>> Thanks for the review of part 2! Here's anot
On 08/08/2012 06:41 PM, William J. Schmidt wrote:
> On Wed, 2012-08-08 at 15:35 -0700, Janis Johnson wrote:
>> On 08/08/2012 03:27 PM, Andrew Pinski wrote:
>>> On Wed, Aug 8, 2012 at 3:25 PM, H.J. Lu wrote:
On Wed, Aug 1, 2012 at 10:36 AM, William J. Schmidt
wrote:
> +/* { dg-do co
I have committed this to google/main for Chris (approved by Rong).
Chris, please prepare a patch to backport this to google/4_7.
Teresa
On Tue, Aug 7, 2012 at 3:55 PM, Chris Manghane wrote:
> Removes references in libgcov.c to functions and structs removed from
> pmu-profile.c
>
> For google/mai
1 - 100 of 101 matches
Mail list logo
