On Fri, Jul 10, 2015 at 03:35:57PM -0400, Trevor Saunders wrote:
> You can also explicitly pick the specialization you want with e.g.
> std::max (x, y); its kind of long, but I can see an argument
> for the explicitness so I'm not sure how ugly I think it is.
Thanks for pointing this out. Yea, th
On Sat, 9 May 2015, Jason Merrill wrote:
> On 05/09/2015 05:37 AM, Richard Biener wrote:
> > Hmm, I wonder if we want to bootstrap with explicit -std=gnu04, our host
> > compiler requirement. Otherwise we'll silently sneak in C++11 features when
> > that becomes the default?
>
> I think just for s
Hi,
>"On completion of execution of the function, the value returned
> is that of its function result. ... If the function result is
> not a pointer, its value shall be defined by the function."
Now we can argue whether the "shall be defined" is to be interpreted as "has to
be" or as
Le 10/07/2015 20:57, Steve Kargl a écrit :
> On Fri, Jul 10, 2015 at 06:20:47PM +0200, Mikael Morin wrote:
>>
>> I'm not completely convinced by the standard excerpts that have been
>> quoted about this topic, as they don't have any explicit mention of
>> allocatable variables/expressions.
>
> I d
Hi,
> > module foo
> >contains
> >function bar(i)
> > integer, allocatable :: bar
> > integer, intent(in) :: i
> > if (i > 0) bar = i
> >end function bar
> > end module foo
> >
> > program test
> >use foo
> >integer j
> >j = bar( 3); print *, j
> >j =
Le 11/07/2015 12:36, Andre Vehreschild a écrit :
> Hi,
>
>
>>"On completion of execution of the function, the value returned
>> is that of its function result. ... If the function result is
>> not a pointer, its value shall be defined by the function."
>
> Now we can argue whether th
On 11 July 2015 at 06:46, Jeff Law wrote:
> On 07/10/2015 06:34 PM, John Marino wrote:
>>
>> After posting the first testsuite results for DragonFly, it was clear
>> that the -fcilkplus functionality was broken:
>> https://gcc.gnu.org/ml/gcc-testresults/2015-07/msg01046.html
>>
>> The problem was r
Hi,
> On Jul 11, 2015, at 04:36 , Andre Vehreschild wrote:
>
>>
>> "On completion of execution of the function, the value returned
>>is that of its function result. ... If the function result is
>>not a pointer, its value shall be defined by the function."
>
> Now we can argue whethe
Hi Mikael,
> > @@ -7030,7 +7053,8 @@ gfc_trans_subcomponent_assign (tree dest,
> > gfc_component * cm, gfc_expr * expr, gfc_add_expr_to_block (&block, tmp);
> > }
> >else if (init && (cm->attr.allocatable
> > - || (cm->ts.type == BT_CLASS && CLASS_DATA
> > (cm)->attr.allocatable)))
>
On 7/11/2015 1:45 PM, Jonathan Wakely wrote:
> On 11 July 2015 at 06:46, Jeff Law wrote:
>> On 07/10/2015 06:34 PM, John Marino wrote:
>>>
>>> After posting the first testsuite results for DragonFly, it was clear
>>> that the -fcilkplus functionality was broken:
>>> https://gcc.gnu.org/ml/gcc-testr
On Sat, Jul 11, 2015 at 12:54:33PM +0200, Mikael Morin wrote:
> Le 10/07/2015 20:57, Steve Kargl a ?crit :
> > On Fri, Jul 10, 2015 at 06:20:47PM +0200, Mikael Morin wrote:
> >>
> >> I'm not completely convinced by the standard excerpts that have been
> >> quoted about this topic, as they don't hav
It looks like the C++ bits are quite similar to the C ones. AFAICT,
only numbers are allowed for the sink offsets, so no C++ iterators,
which would likely complicate matters. If they are eventually allowed,
we can implement them as a follow up.
The attached patch addresses all your concerns
+ c->iter_vars.safe_push(0);
+ c->iter_vars.pop();
Whoops. Consider this removed. This was left over from some tests I
was doing with the vector.
Aldy
On Thu, Jul 09, 2015 at 01:58:22PM -0700, H.J. Lu wrote:
> On Thu, Jul 09, 2015 at 12:13:38PM -0700, H.J. Lu wrote:
> > ix86_split_long_move can optimize floating point constant move, which
> > can be used to optimize SFmode move for IA MCU.
> >
> > OK for trunk if there is no regression?
> >
> >
Hi!
On Fri, 10 Jul 2015 18:04:36 -0400, Nathan Sidwell wrote:
> I've committed this patch to fix a df verify crash Thomas pointed me at.
Thanks!
> Thomas, I think this means you can revert the workaround you just committed?
Right. Committed in r225714:
commit 687f194e535317024ca67c32b26bb2
Hi,
I'm going to ping this on behalf of Andrea: the patch seems almost
obvious to me and so small to not immediately require a copyright
assignment (not sure whether Andrea already has it on file?!?). I also
double checked that it still applies cleanly and passes testing.
Thanks,
Paolo.
On
Hi,
I'm going to ping this one too: a tad less trivial than the other one -
a little explanation here or in a comment would definitely help - but
certainly it looks much simpler than my own tries a while ago...
Regression testing information is also missing.
Thanks,
Paolo.
On 02/21/2015 01:
Hi!
On Thu, 09 Jul 2015 20:25:22 -0400, Nathan Sidwell wrote:
> This is the patch I committed.
> --- internal-fn.c (revision 225323)
> +++ internal-fn.c (working copy)
> +static void
> +expand_GOACC_FORK (gcall *stmt)
> +{
> + rtx mode = expand_normal (gimple_call_arg (stmt, 0));
> +
On 7/7/15 06:09, Chen Gang wrote:
> On 7/6/15 20:51, Bernd Schmidt wrote:
>> On 07/03/2015 04:13 AM, Chen Gang wrote:
>>>
>>> I shall continue to analyse why 2nd lsetup optimiation has not happened.
>>> Hope I can finish within next week (2015-07-12).
>>
>> I've committed my patch after testing bfi
In C++11 or later a bound template template parm should be considered a
valid nontype parm type because it could later be instantiated with an
alias template to have a non-aggregate type such as int.
OK to commit after bootstrap + regtest?
gcc/cp/ChangeLog:
PR c++/65186
* pt.c (i
20 matches
Mail list logo
