On Wed, Jul 13, 2011 at 3:15 PM, Paolo Bonzini wrote:
> On 07/13/2011 12:54 PM, Richard Guenther wrote:
>>
>> > Yes, PROP_gimple_lcx needs to be added to PROP_trees. I cannot approve
>> > the
>> > patch, unfortunately.
>>
>> Hm, why? complex operations are lowered after a complex lowering pass
On Wed, Jul 13, 2011 at 5:16 PM, Ian Lance Taylor wrote:
> Tobias Burnus writes:
>
>> In that sense, I do not seem to need a new flags for
>> asynchronous/coarrays - which are handled by TYPE_QUAL_RESTRICT, but I
>> need a new flag for normal (noncoarray, nonasychronous) variables,
>> which are p
On 07/14/2011 11:11 AM, Richard Guenther wrote:
>> Hm, why? complex operations are lowered after a complex lowering pass
>> has executed. they are still lowered on RTL, so I don't see why we need
>> to destroy them technically.
>
> Because it's PROP_*gimple*_lcx.:)
Shouldn't it then be PR
Hi,
I'm wondering why for Ada boolean_true_node has a value that is
not in the range of the Ada type but is, for the specific case,
255 instead of 1. Is there a specific reason for that?
Does the following patch make sense (untested)?
Btw, I wonder if Ada cannot simply use its own boolean_type
On 07/14/2011 11:21 AM, Richard Guenther wrote:
That Fortran passes everything by reference is really really not helping
optimizers.
I think it also does not harm optimizers. The problem is just that
optimizers are not tuned for it - but for C with later (C99?) attached
qualifiers.
Whether
On Thu, Jul 14, 2011 at 12:29 PM, Tobias Burnus wrote:
> On 07/14/2011 11:21 AM, Richard Guenther wrote:
>>
>> That Fortran passes everything by reference is really really not helping
>> optimizers.
>
> I think it also does not harm optimizers. The problem is just that
> optimizers are not tuned f
Le 13 juil. 2011 à 18:35, Pierre Vittet a écrit :
> Hello,
>
> sorry to answer that late (I didn't saw your mail in my mailbox + I was
> preparing me for RMLL/Libre software meeting).
Yeah i know, i wanted to be there for your RMLL session, but i had to work on
tuesday !
>
> Your solution
Le 14 juil. 2011 à 12:42, Romain Geissler a écrit :
> const char *fullname = lang_hooks.decl_printable_name (my_dec, 2l);
Of course there is no 'l' at the end of the line.
Just read:
const char *fullname = lang_hooks.decl_printable_name (my_decl, 2);
> I'm wondering why for Ada boolean_true_node has a value that is
> not in the range of the Ada type but is, for the specific case,
> 255 instead of 1. Is there a specific reason for that?
None, boolean_true_node must be 1, that's why we (re)set it in gnat_init.
> Does the following patch make s
On Thu, 14 Jul 2011, Eric Botcazou wrote:
> > I'm wondering why for Ada boolean_true_node has a value that is
> > not in the range of the Ada type but is, for the specific case,
> > 255 instead of 1. Is there a specific reason for that?
>
> None, boolean_true_node must be 1, that's why we (re)se
> and from looking at SET_TYPE_RM_VALUEs definition it doesn't
> touch TYPE_MAX_VALUE. So TYPE_MAX_VALUE is as set from
> make_unsigned_type (8) which should set it to 255, not 1.
>
> So ... how can it be a no-op?
Look a few lines below. :-) In gigi we manipulate both full-fledged Ada types
wit
On Thu, 14 Jul 2011, Eric Botcazou wrote:
> > and from looking at SET_TYPE_RM_VALUEs definition it doesn't
> > touch TYPE_MAX_VALUE. So TYPE_MAX_VALUE is as set from
> > make_unsigned_type (8) which should set it to 255, not 1.
> >
> > So ... how can it be a no-op?
>
> Look a few lines below. :-
On 14/07/2011 12:42, Romain Geissler wrote:
At that time i didn't know you were working on Melt, and for now the few things
i know about it is that it's mainly abut hooking the pass manager (or am i
wrong ?) So all those useful events like PLUGIN_PRE_GENERICIZE or
PLUGIN_FINISH_TYPE don't se
Hi,
On Thu, 14 Jul 2011, Paolo Bonzini wrote:
> On 07/14/2011 11:11 AM, Richard Guenther wrote:
> > > > > > Hm, why? complex operations are lowered after a complex lowering
> > > > > > pass
> > > > > > has executed. they are still lowered on RTL, so I don't see why we
> > > > > > need
> > >
Hi,
On Thu, 14 Jul 2011, Richard Guenther wrote:
> Sure ;) What the middle-end currently lacks is explicit tracking of
> what escapes through a function return as opposed to what escapes
> somewhere else. Once that is implemented a flag on the PARM_DECL that
> tells it to use Fortran dummy a
Le 14 juil. 2011 à 16:08, Pierre Vittet a écrit :
> I have seen you were correcting things in the MELT build system, that is not
> easy I think Is it working ? Take me (and Basile) informed. From my
> system, it looks melt-sources directory is not correctly installed, moreover,
> I am not s
Hello,
On Wednesday 13 July 2011 15:46:37 Tobias Burnus wrote:
>
> void some_function(void);
>
> void
> sub (int *restrict non_aliasing_var)
> {
>*non_aliasing_var = 5;
>some_function ();
>if (*non_aliasing_var != 5)
> foobar_();
> }
>
Couldn't we simulate the desired behaviou
Snapshot gcc-4.5-20110714 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20110714/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
18 matches
Mail list logo
