Updated doc/invoke.texi and submitted.
Thanks,
-Sri.
On Sat, Mar 17, 2012 at 11:58 PM, wrote:
>
> Ok for google branches after updating the doc/invoke.texi file.
>
> David
>
>
> http://codereview.appspot.com/5825054/
I knew I was forgetting something: bootstrapped and tested with no
additional regressions on powerpc64-linux-gnu...
On Sun, 2012-03-18 at 20:38 -0500, William J. Schmidt wrote:
> On Sun, 2012-03-18 at 18:19 -0700, Andrew Pinski wrote:
> > On Sun, Mar 18, 2012 at 6:12 PM, William J. Schmidt
> > w
On Sun, 2012-03-18 at 18:19 -0700, Andrew Pinski wrote:
> On Sun, Mar 18, 2012 at 6:12 PM, William J. Schmidt
> wrote:
> > Greetings,
> >
> > Now that we're into stage 1 again, I'd like to submit the first round of
> > changes for dominator-based strength reduction, which will address
> > issues f
On Sun, Mar 18, 2012 at 6:12 PM, William J. Schmidt
wrote:
> Greetings,
>
> Now that we're into stage 1 again, I'd like to submit the first round of
> changes for dominator-based strength reduction, which will address
> issues from PR22586, PR35308, PR46556, and perhaps others. I'm
> attaching tw
Now that G++ supports it we can use a NSDMI for std::list::_M_size to
avoid needing conditional compilation to set it in the constructors.
I think the attached patch is an improvement so I plan to commit it to
trunk soon unless I hear objections.
* include/bits/stl_list.h (list::_M_size):
On Wed, 14 Mar 2012, H.J. Lu wrote:
>> Apart from the above, at least invoke.texi does not define what an x32
>> environment is. Shouldn't that done somewhere (before this terminology
>> is used)?
> I am not sure where to put it. In any case, here is a patch to update
> GCC 4.7.0 changes with lin
Dear Paul,
thanks for the patch.
Paul Richard Thomas wrote:
+ /* Transfer the selector typespec to the associate name. */
+
+ copy_ts_from_selector_to_associate (gfc_expr *expr1, gfc_expr *expr2)
+ {
I think it is not obvious which type spec is which. Maybe you could
add a "(expr1)" and "(ex
On 03/18/2012 03:00 PM, Gerald Pfeifer wrote:
On Fri, 9 Mar 2012, Sandra Loosemore wrote:
Per the DWARF web site
http://dwarfstd.org/Download.php
the correct names of the various versions of the DWARF standard appear
to be either "DWARF Version N" or "DWARF N", rather than e.g. "DWARF2",
"DWAR
On Fri, 9 Mar 2012, Sandra Loosemore wrote:
> Per the DWARF web site
>
> http://dwarfstd.org/Download.php
>
> the correct names of the various versions of the DWARF standard appear
> to be either "DWARF Version N" or "DWARF N", rather than e.g. "DWARF2",
> "DWARF-2", "dwarf2", or whatever. Thi
On Sun, Mar 18, 2012 at 5:01 PM, Uros Bizjak wrote:
>> I am testing this patch. OK for trunk if it passes all tests?
>
> No, force_reg will generate a pseudo, so this conversion is valid only
> for !can_create_pseudo ().
>
> At least for *tls_initial_exec_x32_store, you will need a temporary to
Dear All,
Please find attached a fix for PR41600 plus some. It is reasonably
straightforward but the following should be noted:
(i) gfc_get_vptr_from_expr exploits that seeming fact that tracing
back any class expression through TREE_OPERAND 0 eventually gets one
back to the class expression. I
On Thu, 15 Mar 2012, Tom G. Christensen wrote:
> Latest results for 4.6.x
>
> -tgc
>
> Testresults for 4.6.2:
> hppa2.0w-hp-hpux11.11
> i386-pc-solaris2.8
> i686-pc-linux-gnu
> powerpc-apple-darwin8.11.0
> sparc-sun-solaris2.8 (2)
> x86_64-apple-darwin10.8.0
> x86_64-apple-darwin11.
On Mar 18, 2012, at 3:16 AM, Richard Sandiford wrote:
> Mike Stump writes:
>>> We currently only support constant integer
>>> widths <= 2*HOST_BITS_PER_WIDE_INT, and the assert is correctly
>>> triggering if we try to build a wider constant.
>>
>> Can you give me a concrete example of what will f
On Sat, Mar 17, 2012 at 10:50 PM, H.J. Lu wrote:
> Since we must use reg64 in %fs:(%reg) memory operand like
>
> movq x@gottpoff(%rip),%reg64;
> mov %fs:(%reg64),%reg
>
> this patch optimizes x32 TLS IE load and store by wrapping
> %reg64 inside of UNSPEC when Pmode ==
Hi,
That won't catch something like
int i;
static_cast(i);
which is also a useless cast, because i is already an int lvalue; not
all lvalues are derived from references. Note that something like
static_cast(42);
is not a useless cast, because it turns a prvalue into an xvalue.
Agreed. In o
On Thu, 8 Mar 2012, Jonathan Wakely wrote:
> The manual claims a future version of G++ will support a hybrid
> instantiation model, which I don't think is still planned, and
> describes extern templates as an extension when they are in C++11.
>
> * doc/extend.texi (Template Instantiation):
Mike Stump writes:
>> We currently only support constant integer
>> widths <= 2*HOST_BITS_PER_WIDE_INT, and the assert is correctly
>> triggering if we try to build a wider constant.
>
> Can you give me a concrete example of what will fail with the constant
> 0 generated by:
>
> return GEN_I
17 matches
Mail list logo
