On Tue, Dec 11, 2012 at 10:12 AM, Eric Botcazou wrote:
>> ... so if would really be a pessimization doing that. Of course handling
>> CONST_DECL in for_each_index is indeed obvious - I just was curios if
>> it was a missed-optimization opportunity as well.
>
> It turns out that, for the same test
> ... so if would really be a pessimization doing that. Of course handling
> CONST_DECL in for_each_index is indeed obvious - I just was curios if
> it was a missed-optimization opportunity as well.
It turns out that, for the same testcase, &CONST_DECL is generated on the MIPS
and prepare_decl_r
On Mon, Dec 10, 2012 at 10:55 AM, Eric Botcazou wrote:
>> Well ... I would have expected that we'd have folded the CONST_DECL to
>> its DECL_INITIAL. At least that is what we do for all other CONST_DECLs.
>> The only way CONST_DECLs should appear in the IL (after some optimization
>> of course) i
> Well ... I would have expected that we'd have folded the CONST_DECL to
> its DECL_INITIAL. At least that is what we do for all other CONST_DECLs.
> The only way CONST_DECLs should appear in the IL (after some optimization
> of course) is when you take their address.
That's what (essentially) ha
On Sat, Dec 8, 2012 at 12:42 PM, Eric Botcazou wrote:
> This is an internal error in for_each_index at -O:
>
> +===GNAT BUG DETECTED==+
> | 4.8.0 20121208 (experimental) [trunk revision 194319] (x86_64-suse-linux)
> GCC error:|
> | in for_each_in
This is an internal error in for_each_index at -O:
+===GNAT BUG DETECTED==+
| 4.8.0 20121208 (experimental) [trunk revision 194319] (x86_64-suse-linux)
GCC error:|
| in for_each_index, at tree-ssa-loop-im.c:324 |
| Er
