Mailing List Archive

Am 2015-05-20 um 20:55 schrieb Frank Peters:
> What is going on with the new gcc-5.1.0?
>
> I've read some reports that others are already using gcc-5.1.0,
> yet when I try to install gcc-5.1.0 it pulled in isl-0.14 which
> completely broke my current gcc-4.9.2. As a result I could compile
> nothing. I had to temporarily install the Fedora isl-0.12.2
> libraries so I could downgrade to the Gentoo version and get things
> working again.
>
> I notice that gcc-5.1.0 has a keyword mask and isl-0.14 and
> cloog-0.18.3, both of which are needed for gcc-5.1.0, are hard masked.
>
> My plan is to leave things alone until everything becomes unmasked
> but how are others able to use gcc-5.1.0?
>
> The only way to do so would be to install isl-0.14 in a different
> slot but I don't think portage will allow this.

isl is only pulled in by USE="graphite" for gcc ...
as I don't have that set I have gcc-5.1.0 compiled and working.
maybe remove that flag for now?

On Fri, 22 May 2015 20:35:23 +0200
"Stefan G. Weichinger" <lists@xunil.at> wrote:

>
> isl is only pulled in by USE="graphite" for gcc ...
> as I don't have that set I have gcc-5.1.0 compiled and working.
> maybe remove that flag for now?
>

Yes, that is correct. Isl is needed only for the graphite loop
optimization features of gcc.

But then that leads to a new question: How important and/or useful
is the gcc-graphite optimization? AFAIK it does improve performance
in many cases.

Also, as opposed to link-time optimization (LTO), gcc-graphite is
stable.

Since gcc-5.1.0 is not that urgent, I'll wait until the isl problem
is sorted out.

Frank Peters

Frank Peters <frank.peters@comcast.net> wrote:
>
> Also, as opposed to link-time optimization (LTO), gcc-graphite is
> stable.

My experience is quite the opposite: With graphite, I had
many random crashes (and seldom also unexplainable compiler
errors which vanish without graphite). The situation did not
improve or got even worse with 4.8 to 4.9.
OTOH, with LTO there are sometimes link errors (unsurprisingly),
but usually it works smoothly.

On Sat, 23 May 2015 15:47:04 +0000 (UTC)
Martin Vaeth <martin@mvath.de> wrote:

>
> My experience is quite the opposite: With graphite, I had
> many random crashes (and seldom also unexplainable compiler
> errors which vanish without graphite).
>

My whole system has been compiled with graphite since its introduction
and I've never seen any problems.

What gcc flags are you using to enable graphite?

Usually, -floop-interchange, -floop-strip-mine, and -floop-block are
enough.

One can go further with -ftree-loop-distribution and -ftree-vectorize
and maybe even others. AFAIK these extra graphite options may cause
problems.

Regarding LTO, I experienced a severe problem with ghostscipt due to
what I later traced to LTO:

http://bugs.ghostscript.com/show_bug.cgi?id=691768

Ever since that time I disabled LTO completely.

Frank Peters

Frank Peters <frank.peters@comcast.net> skribis:
> On Sat, 23 May 2015 15:47:04 +0000 (UTC)
> Martin Vaeth <martin@mvath.de> wrote:
>
> >
> > My experience is quite the opposite: With graphite, I had
> > many random crashes (and seldom also unexplainable compiler
> > errors which vanish without graphite).
> >
>
> My whole system has been compiled with graphite since its introduction
> and I've never seen any problems.

Well, to my mind, the biggest problem with graphite is how it is
dependent on libraries with funny names. Thus one should always, I
think, at least keep a compiler of _some_ reliable version around
compiled without it, and capable of building other gcc versions.

I tend to keep quite a few gcc versions around, but then I like to
program and occasionally to test on different versions. Also, being
conservative, I generally use a newer version for development than for
building my system. I do not move my system compiler to a new version
just because I installed that version. One can always set the compiler
per-package via /etc/portage files.

Frank Peters <frank.peters@comcast.net> wrote:
> Martin Vaeth <martin@mvath.de> wrote:
>>
>> My experience is quite the opposite: With graphite, I had
>> many random crashes (and seldom also unexplainable compiler
>> errors which vanish without graphite).
>
> My whole system has been compiled with graphite since its introduction
> and I've never seen any problems.

I think it can depend on the processor you compile for.
For instance, with an athlon, graphite caused much more trouble
than with an i3.

> What gcc flags are you using to enable graphite?
>
> Usually, -floop-interchange, -floop-strip-mine, and -floop-block are
> enough.

By "graphite", I mean these 3 flags plus -fgraphite-identity
(the latter should be rather harmless, I suppose).

> Regarding LTO, I experienced a severe problem with ghostscipt due to
> what I later traced to LTO:
>
> http://bugs.ghostscript.com/show_bug.cgi?id=691768

Are you sure that the problem remained with LTO and *without*
graphite in *all* of the libraries which are used? Namely, such
kind of bugs is what I traced back to graphite in several cases
(which I meanwhile forgot, since I didn't report bugs for which
I found that graphite was the only cause; after finding 5 or 6
times that the cause of runtime problems was graphite, I simply
got tired of it, especially since the benefits are tiny; sometimes,
I even had slight slowdowns.)