On 03/27/2015 03:43 AM, Kyrill Tkachov wrote:
On 27/03/15 03:29, Bin.Cheng wrote:
[much snippage]
As for tree ivopts, address cost is used in both ways. For any
address computation that's invalid, it tries to legitimize it into two
parts, the first part results in alu instructions, the second
On 27/03/15 03:29, Bin.Cheng wrote:
On Thu, Mar 26, 2015 at 11:40 PM, Kyrill Tkachov wrote:
Hi all,
I'd like to attempt to make GCC's usage of costs in the backends consistent.
We have a lot of different types: rtx costs, address costs, regmove costs,
vector costs etc. Some of them are use in
> I believe this should be another symptom of bug fixed by r221718.
> The earlier revision exposed a problem that the edge may be moved from
> indirect edges to direct edges and the outer walk will end up confused.
https://gcc.gnu.org/ml/gcc-testresults/2015-03/msg03059.html reports success
with
> As is shown here:
>
> https://gcc.gnu.org/ml/gcc-testresults/2015-03/msg03014.html.
Hello,
I believe this should be another symptom of bug fixed by r221718.
The earlier revision exposed a problem that the edge may be moved from
indirect edges to direct edges and the outer walk will end up confu
As is shown here:
https://gcc.gnu.org/ml/gcc-testresults/2015-03/msg03014.html.
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http
On 26 March 2015 at 23:15, Andrew Morton wrote:
> On Thu, 26 Mar 2015 14:58:40 -0700 Joe Perches wrote:
>
>> > I'd have thought that a function-wide
>> > __attribute__((__string_section__(foo))
>> > wouldn't be a ton of work to implement.
>>
>> Maybe not.
>>
>> Could some future version of gc
