3:32 a.m.
Hi,
I'm getting some strange errors from some packages built for f32 with
gcc 10.0 [0].
Building with g++ 10.1 ardourd5 seems fine...
It seems GCC 10.0 had some bugs that could be discovered only at
runtime. Did you have any similar problems?
Ciao
Guido
FAS: tartina
[0]: https://bugzilla.redhat.com/show_bug.cgi?id=1837089
3:55 a.m.
On Tue, May 19, 2020 at 10:33 AM Guido Aulisi <guido.aulisi(a)gmail.com> wrote:
Hi,
I'm getting some strange errors from some packages built for f32 with
gcc 10.0 [0].
Building with g++ 10.1 ardourd5 seems fine...
It seems GCC 10.0 had some bugs that could be discovered only at
runtime. Did you have any similar problems?
Hi,
This was even brought up at - I think - last week's FESCo meeting
because it also affected erlang and some other packages.
But basically, since we can't do a mass rebuild on a released fedora,
we can only deal with problems when someone becomes aware of them,
instead of throwing the baby out with the bathwater (or whichever way
that idiom is supposed to work).
Fabio
> Ciao
> Guido
> FAS: tartina
>
> [0]: https://bugzilla.redhat.com/show_bug.cgi?id=1837089
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
4:25 a.m.
On 19.05.2020 10:32, Guido Aulisi wrote:
It seems GCC 10.0 had some bugs that could be discovered only at
runtime. Did you have any similar problems?
GCC 10.0.1 was broken. Maintainers of gcc just used SVN trunk in
production without any real tests.
I experienced lots of ICEs and multiple crashes with my packages (the
affected packages are Telegram Desktop, kiwix-lib, zimlib,
kiwix-desktop, tdlib, and some libpurple plugins).
Next time FESCo should forbid gcc updates to unreleased versions in
branched Fedora releases.
Now we need a new mass rebuild in Fedora 32 with fixed gcc 10.1.1 version.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
4:40 a.m.
On Tue, May 19, 2020 at 11:28 AM Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org> wrote:
Next time FESCo should forbid gcc updates to unreleased versions in
branched Fedora releases.
Now we need a new mass rebuild in Fedora 32 with fixed gcc 10.1.1 version.
As I wrote in my direct response to Guido, doing a mass rebuild for
fedora just isn't possible in released branches. So, the best we can
do is to deal with issues as people become aware of them and report
them, and then rebuild those few broken packages with the "fixed" GCC
version, instead of "just rebuild everything because".
We also briefly talked about not including pre-release GCC versions in
rawhide, but since new GCC versions get almost all their testing only
in rawhide, this would inevitably only lead to lower-quality final GCC
releases that would then end up in released fedora versions anyway. We
(FESCo) were not able to think of a better way to do this.
Fabio
4:58 a.m.
On 19.05.2020 11:40, Fabio Valentini wrote:
As I wrote in my direct response to Guido, doing a mass rebuild for
fedora just isn't possible in released branches. So, the best we can
do is to deal with issues as people become aware of them and report
them, and then rebuild those few broken packages with the "fixed" GCC
version, instead of "just rebuild everything because".
Yes, I understand. But most of package maintainers even don't know about
such major problems with GCC compiler.
I already rebuilt all my affected packages with 10.1.1.
We also briefly talked about not including pre-release GCC versions
in
rawhide, but since new GCC versions get almost all their testing only
in rawhide, this would inevitably only lead to lower-quality final GCC
releases that would then end up in released fedora versions anyway. We
(FESCo) were not able to think of a better way to do this.
Non-released GCC versions is okay for Rawhide, but not for branched
releases. Now lots of end-users suffer from different side effects of
such testing like random crashes and this is a strong reputation blow on
the whole Fedora distribution.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
5:11 a.m.
* Guido Aulisi:
I'm getting some strange errors from some packages built for f32
with
gcc 10.0 [0].
Building with g++ 10.1 ardourd5 seems fine...
It seems GCC 10.0 had some bugs that could be discovered only at
runtime. Did you have any similar problems?
Ciao
Guido
FAS: tartina
[0]: https://bugzilla.redhat.com/show_bug.cgi?id=1837089
Comment 12 on that bug suggests that it's the known underlinking issue
in Ardour (“it seems related to a missing symbol (__atan2_finite) in
libvampplugins”). If true, this is not related to GCC 10 at all.
Thanks,
Florian
5:52 a.m.
On Tue, May 19, 2020 at 11:58:47AM +0200, Vitaly Zaitsev via devel wrote:
On 19.05.2020 11:40, Fabio Valentini wrote:
> As I wrote in my direct response to Guido, doing a mass rebuild for
> fedora just isn't possible in released branches. So, the best we can
> do is to deal with issues as people become aware of them and report
> them, and then rebuild those few broken packages with the "fixed" GCC
> version, instead of "just rebuild everything because".
Yes, I understand. But most of package maintainers even don't know about
such major problems with GCC compiler.
I already rebuilt all my affected packages with 10.1.1.
> We also briefly talked about not including pre-release GCC versions in
> rawhide, but since new GCC versions get almost all their testing only
> in rawhide, this would inevitably only lead to lower-quality final GCC
> releases that would then end up in released fedora versions anyway. We
> (FESCo) were not able to think of a better way to do this.
Non-released GCC versions is okay for Rawhide, but not for branched
releases. Now lots of end-users suffer from different side effects of
such testing like random crashes and this is a strong reputation blow on
the whole Fedora distribution.
There is nothing magic about released vs. unreleased versions of GCC,
10.0.1 is a version used for any development snapshot from mid January
until the release that happened on May 7th, this whole period is restricted
to regression and documentation bugfixes.
A test mass rebuild is performed on GCC before it is added into rawhide in
January, though for a single arch only (x86_64), other distros perform
sometimes scratch testing on other architectures too.
Every GCC build performs a few hundred thousands tests itself, and due to
slooow arm and s390x build boxes in Fedora that build already takes
sometimes more than a day. It is not feasible to test mass rebuild the
whole distribution afterwards just to see if it doesn't regress anything,
not to mention that many packages have their issues, so what we usually need
to do is try to rebuild what failed with older gcc and only if it built fine
before try to analyze.
Like all non-trivial software, the compiler can and does have bugs
(I'm sorry if you happen or happened to be affected by some particular one),
and while during the period when it is present in rawhide and in the
branched distros GCC is in the above mentioned regression bugfixing only
mode, it is possible a regression is introduced, that possibility is the
same for released compilers.
All we need is get those issues reported and fixed, having just officially
released compiler doesn't change anything on that.
Jakub
10:42 a.m.
Il giorno mar, 19/05/2020 alle 12.11 +0200, Florian Weimer ha scritto:
* Guido Aulisi:
> I'm getting some strange errors from some packages built for f32
> with
> gcc 10.0 [0].
> Building with g++ 10.1 ardourd5 seems fine...
>
> It seems GCC 10.0 had some bugs that could be discovered only at
> runtime. Did you have any similar problems?
>
> Ciao
> Guido
> FAS: tartina
>
> [0]: https://bugzilla.redhat.com/show_bug.cgi?id=1837089
Comment 12 on that bug suggests that it's the known underlinking
issue
in Ardour (“it seems related to a missing symbol (__atan2_finite) in
libvampplugins”). If true, this is not related to GCC 10 at all.
Yes, that really seems a link and/or symbol versioning problem, but it
wasn't the only one.
I had some other crashes in packages, usually not x86 arches.
As an example sord [0] was crashing on power64 when compiled with -O2,
an exit condition in a for loop was optimized out until it crashed the
loop. I had to use -O1 [1], and I have not tried with gcc 10.1 yet.
Thanks,
Florian
Ciao
Guido
[0]: https://src.fedoraproject.org/rpms/sord/
[1]:
https://src.fedoraproject.org/rpms/sord/c/0a9adfc498d2e3cfcb3c8e67e53463b...
11:43 a.m.
On Tue, 19 May 2020 17:42:29 +0200
Guido Aulisi <guido.aulisi(a)gmail.com> wrote:
Il giorno mar, 19/05/2020 alle 12.11 +0200, Florian Weimer ha
scritto:
> * Guido Aulisi:
>
> > I'm getting some strange errors from some packages built for f32
> > with
> > gcc 10.0 [0].
> > Building with g++ 10.1 ardourd5 seems fine...
> >
> > It seems GCC 10.0 had some bugs that could be discovered only at
> > runtime. Did you have any similar problems?
> >
> > Ciao
> > Guido
> > FAS: tartina
> >
> > [0]: https://bugzilla.redhat.com/show_bug.cgi?id=1837089
>
> Comment 12 on that bug suggests that it's the known underlinking
> issue
> in Ardour (“it seems related to a missing symbol (__atan2_finite) in
> libvampplugins”). If true, this is not related to GCC 10 at all.
Yes, that really seems a link and/or symbol versioning problem, but it
wasn't the only one.
I had some other crashes in packages, usually not x86 arches.
As an example sord [0] was crashing on power64 when compiled with -O2,
an exit condition in a for loop was optimized out until it crashed the
loop. I had to use -O1 [1], and I have not tried with gcc 10.1 yet.
usually it's useful to report a bug against gcc if such things happen.
Also there is https://gcc.gnu.org/wiki/FAQ#misoptimization the should
help to localize the root cause. My blog
(https://gcc.gnu.org/wiki/FAQ#misoptimization) has also some pointers.
Dan
>
> > Thanks,
> > Florian
>
> Ciao
> Guido
>
> [0]: https://src.fedoraproject.org/rpms/sord/
> [1]:
>
https://src.fedoraproject.org/rpms/sord/c/0a9adfc498d2e3cfcb3c8e67e53463b...
1:07 p.m.
On Tue, May 19, 2020 at 11:40:50AM +0200, Fabio Valentini wrote:
On Tue, May 19, 2020 at 11:28 AM Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org> wrote:
> Next time FESCo should forbid gcc updates to unreleased versions in
> branched Fedora releases.
>
> Now we need a new mass rebuild in Fedora 32 with fixed gcc 10.1.1 version.
As I wrote in my direct response to Guido, doing a mass rebuild for
fedora just isn't possible in released branches. So, the best we can
do is to deal with issues as people become aware of them and report
them, and then rebuild those few broken packages with the "fixed" GCC
version, instead of "just rebuild everything because".
We also briefly talked about not including pre-release GCC versions in
rawhide, but since new GCC versions get almost all their testing only
in rawhide, this would inevitably only lead to lower-quality final GCC
releases that would then end up in released fedora versions anyway. We
(FESCo) were not able to think of a better way to do this.
Well that's one way to look at it. Another is that I spent half a day
chasing a bug for one of our users in Fedora 32, and it turned out to
be caused by GCC. I *would* have spotted this in Rawhide if it had
been there for any length of time first.
https://bugzilla.redhat.com/show_bug.cgi?id=1835649
You just cannot allow random preproduction GCC into released Fedora.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
2:28 p.m.
Il giorno mar, 19/05/2020 alle 18.43 +0200, Dan Horák ha scritto:
On Tue, 19 May 2020 17:42:29 +0200
Guido Aulisi <guido.aulisi(a)gmail.com> wrote:
> Il giorno mar, 19/05/2020 alle 12.11 +0200, Florian Weimer ha
> scritto:
> > * Guido Aulisi:
> >
> > > I'm getting some strange errors from some packages built for
> > > f32
> > > with
> > > gcc 10.0 [0].
> > > Building with g++ 10.1 ardourd5 seems fine...
> > >
> > > It seems GCC 10.0 had some bugs that could be discovered only
> > > at
> > > runtime. Did you have any similar problems?
> > >
> > > Ciao
> > > Guido
> > > FAS: tartina
> > >
> > > [0]: https://bugzilla.redhat.com/show_bug.cgi?id=1837089
> >
> > Comment 12 on that bug suggests that it's the known underlinking
> > issue
> > in Ardour (“it seems related to a missing symbol (__atan2_finite)
> > in
> > libvampplugins”). If true, this is not related to GCC 10 at all.
>
> Yes, that really seems a link and/or symbol versioning problem, but
> it
> wasn't the only one.
> I had some other crashes in packages, usually not x86 arches.
> As an example sord [0] was crashing on power64 when compiled with
> -O2,
> an exit condition in a for loop was optimized out until it crashed
> the
> loop. I had to use -O1 [1], and I have not tried with gcc 10.1 yet.
usually it's useful to report a bug against gcc if such things
happen.
Also there is https://gcc.gnu.org/wiki/FAQ#misoptimization the should
help to localize the root cause. My blog
(https://gcc.gnu.org/wiki/FAQ#misoptimization) has also some
pointers.
Dan
Yes, I was trying to report a bug, but it was really hard to repeat all
the steps I made to get it; at that time I thought it was a program
bug, not some compiler optimization.
Next time (I hope never!) I will try to file a bug...
Ciao
Guido
7:20 a.m.
On Tue, May 19, 2020 at 8:08 PM Richard W.M. Jones <rjones(a)redhat.com> wrote:
On Tue, May 19, 2020 at 11:40:50AM +0200, Fabio Valentini wrote:
> On Tue, May 19, 2020 at 11:28 AM Vitaly Zaitsev via devel
> <devel(a)lists.fedoraproject.org> wrote:
> > Next time FESCo should forbid gcc updates to unreleased versions in
> > branched Fedora releases.
> >
> > Now we need a new mass rebuild in Fedora 32 with fixed gcc 10.1.1 version.
>
> As I wrote in my direct response to Guido, doing a mass rebuild for
> fedora just isn't possible in released branches. So, the best we can
> do is to deal with issues as people become aware of them and report
> them, and then rebuild those few broken packages with the "fixed" GCC
> version, instead of "just rebuild everything because".
>
> We also briefly talked about not including pre-release GCC versions in
> rawhide, but since new GCC versions get almost all their testing only
> in rawhide, this would inevitably only lead to lower-quality final GCC
> releases that would then end up in released fedora versions anyway. We
> (FESCo) were not able to think of a better way to do this.
Well that's one way to look at it. Another is that I spent half a day
chasing a bug for one of our users in Fedora 32, and it turned out to
be caused by GCC. I *would* have spotted this in Rawhide if it had
been there for any length of time first.
https://bugzilla.redhat.com/show_bug.cgi?id=1835649
You just cannot allow random preproduction GCC into released Fedora.
Well, that's not exactly what happened.
The branch for what would eventually become fedora 32 just inherited a
pre-release GCC version, because that's what was on the master branch
/ in rawhide at the time.
I think we just jad a bit of "bad luck" this time round - the exact
build that was used a period of time (including the mass rebuild, I
think) seems to have produced buggy code in some circumstances. If
those issues had been compile time errors instead of runtime errors,
they would've been caught pretty quickly, but alas ...
Fabio
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> Fedora Windows cross-compiler. Compile Windows programs, test, and
> build Windows installers. Over 100 libraries supported.
> http://fedoraproject.org/wiki/MinGW
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
1436
days inactive
1437
days old
11 comments
7 participants
participants (7)
-
Dan Horák -
Fabio Valentini -
Florian Weimer -
Guido Aulisi -
Jakub Jelinek -
Richard W.M. Jones -
Vitaly Zaitsev