This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [GSoC] generation of Gimple loops with empty bodies


On Tue, Jul 15, 2014 at 5:45 PM, Tobias Grosser <tobias@grosser.es> wrote:
> This is not a patch review, lets move this to gcc@gcc.gnu.org.
>
>
> On 15/07/2014 17:03, Roman Gareev wrote:
>>
>> I've found out that int128_integer_type_node and
>> long_long_integer_type_node are NULL at the moment of definition of
>> the graphite_expression_size_type. Maybe we should use
>> long_long_integer_type_node, because, as you said before, using of
>> signed 64 has also been proved to be very robust. What do you think
>> about this?
>
>
> I do not fully understand this message. You first say that
> long_long_integer_type_node is NULL, but then want to use this. This does
> not seem to be a solution. Most likely it is the solution, but the problem
> description makes it hard to understand it. Is the problem
> caused by initialization order issues? Or why are such types NULL?

Because they are not available on all targets or for all languages.

I suggest you use the largest available integer mode via
mode = mode_for_size (MAX_FIXED_MODE_SIZE, MODE_INT, 0);
type = build_nonstandard_integer_type (GET_MODE_PRECISION (mode), [01]);

Richard.

> (I am fine with using 64 bits by default, but I would like to keep the
> possibility to compile with 128 bits to allow the size to be changed
> easily during debugging. So using a specific type directly without
> going through a graphite specific variable is something I would like to
> avoid.
>
> Cheers,
> Tobias
>
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]