On Tue, Sep 6, 2011 at 12:44 PM, Jonathan Wakely wrote:
> On 6 September 2011 20:23, Jonathan Wakely wrote:
>>
>> What's a dangling vector anyway? One that has been moved from?
>
> Apparently not, since a moved-from vector would pass __valid() (as
> indeed it should)
>
> So I'm quite curious what
Jason Merrill a écrit:
> A followup: non-literal argument types shouldn't change the constexpr
> flag either, and we shouldn't crash when a constructor initializes
> bases as well as members (50296). I'm not sure how my testing missed
> that bug...
>
> Tested x86_64-pc-linux-gnu, applying to tru
On 6 Sep 2011, at 21:19, Paul Pluzhnikov wrote:
> On Tue, Sep 6, 2011 at 12:44 PM, Jonathan Wakely
> wrote:
>> On 6 September 2011 20:23, Jonathan Wakely wrote:
>>>
>>> What's a dangling vector anyway? One that has been moved from?
>>
>> Apparently not, since a moved-from vector would pass _
On 6 September 2011 21:19, Paul Pluzhnikov wrote:
> On Tue, Sep 6, 2011 at 12:44 PM, Jonathan Wakely
> wrote:
>> On 6 September 2011 20:23, Jonathan Wakely wrote:
>>>
>>> What's a dangling vector anyway? One that has been moved from?
>>
>> Apparently not, since a moved-from vector would pass __v
On Tue, Sep 6, 2011 at 1:33 PM, Jonathan Wakely wrote:
>> for (it = v->begin(); it != v->end(); ++it) // Oops!
>
> Eurgh, the occurrence of "delete" in anything except a destructor is a
> code smell that should have led someone to find those bugs anyway!
> Obviously the code above is a trivial
Hello!
x32 follows x86_64 ABI, so no MMX regs are saved/restored in
__builtin_apply_args/__builtin_return, even with -mmmx. The patch also
includes some cleanups in this area.
2011-09-06 Uros Bizjak
* config/i386/i386.c (ix86_function_value_regno_p): Use AX_REG.
(function_valu
On Tue, Sep 6, 2011 at 8:00 PM, Maxim Kuvyrkov wrote:
>
> On 7/09/2011, at 3:13 AM, Steven Bosscher wrote:
>
>> On Tue, Sep 6, 2011 at 11:14 AM, Tom de Vries wrote:
>>> Hi,
>>>
>>> During testing the approved-for-commit middle-end patch for bug 43864 on
>>> ARM, I
>>> ran into a gcc.dg/torture/p
On 09/06/2011 04:21 PM, Dodji Seketeli wrote:
Jason Merrill a écrit:
A followup: non-literal argument types shouldn't change the constexpr
flag either, and we shouldn't crash when a constructor initializes
bases as well as members (50296). I'm not sure how my testing missed
that bug...
Teste
On Tue, Sep 6, 2011 at 11:31 PM, Steven Bosscher wrote:
> Index: haifa-sched.c
> ===
> --- haifa-sched.c (revision 178601)
> +++ haifa-sched.c (working copy)
> @@ -6071,7 +6071,10 @@ check_cfg (rtx head, rtx tail)
>
On 6 September 2011 21:52, Paul Pluzhnikov wrote:
> On Tue, Sep 6, 2011 at 1:33 PM, Jonathan Wakely wrote:
>
>>> for (it = v->begin(); it != v->end(); ++it) // Oops!
>>
>> Eurgh, the occurrence of "delete" in anything except a destructor is a
>> code smell that should have led someone to find th
> Hi,
>
> somehow I lost two hunks in the patch allowing IPA-CP to process
> functions with variable number of arguments and one of these omissions
> caused PR 50301 (416.gamess LTO miscompilation). The two hunks check
> the number of actual arguments in two places of IPA-CP which are not
> execu
On 7/09/2011, at 9:32 AM, Steven Bosscher wrote:
> On Tue, Sep 6, 2011 at 11:31 PM, Steven Bosscher
> wrote:
>> Index: haifa-sched.c
>> ===
>> --- haifa-sched.c (revision 178601)
>> +++ haifa-sched.c (working copy)
>> @@
On Tue, Sep 6, 2011 at 2:51 PM, Jonathan Wakely wrote:
> I don't mean for vector::begin and the other functions in that patch,
> I mean in general for member functions of any type. There are plenty
> of functions that wouldn't crash when called through a null pointer.
> But even std:vector has me
I committed the following patch as obvious to make the dg-error test match the
current compiler's error message (the current compiler now lists the type which
broke the regexp).
2011-09-06 Michael Meissner
* g++.dg/ext/altivec-17.C: Fix dg-error to match current compiler.
Index: gcc/t
On 6 September 2011 22:58, Paul Pluzhnikov wrote:
> On Tue, Sep 6, 2011 at 2:51 PM, Jonathan Wakely wrote:
>
>> I don't mean for vector::begin and the other functions in that patch,
>> I mean in general for member functions of any type. There are plenty
>> of functions that wouldn't crash when cal
I checked in the following patch to update the documentation for tm_p.h. I
noticed the FIXME comment in the texi source when I was working on my previous
patch for combining the standard and machine dependent builtin indexes. While
that patch did not go in, I figured I could improve the documenta
Here's the tuple additions for constexpr now that it's ok to return
this.
I'm not quite sure what to do with the get, tie, tuple_cat functions
given the current signatures. Is tuple_cat now considered conforming?
If so, certain signatures can be constexpr.
tested x86/linux
benjamin2011-09-06
This showed up with a coldfire-linux toolchain. get_condition can return
NULL in some cases when the condition is reversed and there are float
modes involved; in that case we will move instructions in between a cc0
user and setter.
This patch fixes it. Tested on cris-elf, since I currently have no
This patches fixes bugs that caused the multi-version tests to fail.
* mversn-dispatch.c (specialize_call): Rebuild cgraph edges after
specialization.
(clone_and_dispatch_function): Rebuild cgraph edges to compute
inline parameters.
(do_convert_builtin_dispa
2011/9/7 Benjamin Kosnik :
>
> Here's the tuple additions for constexpr now that it's ok to return
> this.
Btw.: I would have expected that you can make
__tuple_compare<>::__eq/__less also constexpr.
These are static functions, thus __tuple_compare
itself need not to be a literal type (Disclaimer
101 - 120 of 120 matches
Mail list logo
