| 1 |
On Sat, Apr 26, 2014 at 6:23 AM, Michał Górny <mgorny@g.o> wrote: |
| 2 |
> |
| 3 |
> As far as I understand, the LTO concept is suited well for most |
| 4 |
> programs, though the results can vary. I agree that in the early stage |
| 5 |
> many packages may be unhappy about it but as far as I understand, once |
| 6 |
> it is more widespread only a few corner cases would be unsuited for LTO |
| 7 |
> (+ the usual limitations like memory). |
| 8 |
|
| 9 |
I tend to agree. I've been using stable gcc with -flto in my CFLAGS |
| 10 |
for a while now with only isolated problems. When I run into a |
| 11 |
problem, I disable it for that package alone. So far I've only done |
| 12 |
it for 26 packages. I wouldn't be surprised if some of them now work. |
| 13 |
|
| 14 |
I wouldn't really put LTO in the same category as fast-math. |
| 15 |
|
| 16 |
Anybody who is using it should be prepared to run into the odd |
| 17 |
breakage. It does make sense to filter the flag when it is known to |
| 18 |
not work. |
| 19 |
|
| 20 |
Rich |
Archives