From: Joshua Kinard <kumba@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] What happened to gcc-12.3.0?
Date: Thu, 15 Jun 2023 12:29:19 -0400 [thread overview]
Message-ID: <631d9f97-4c96-daae-d2a9-c56cf881791a@gentoo.org> (raw)
In-Reply-To: <87bkhhhs3i.fsf@gentoo.org>
On 6/15/2023 07:37, Sam James wrote:
>
> Joshua Kinard <kumba@gentoo.org> writes:
>
>> Noticing that the ebuild for gcc-12.3.0 got dropped with little
>> explanation. It is the upstream stable release. I am eyeballing
>> #906310 as what may have triggered the drop, but I find it a bit of a
>> stretch that an upstream stable release got dropped over a single,
>> optional package that has a history of quirky behavior (FWIW, I never
>> had luck with ccache, especially on MIPS).
>
> Please see https://bugs.gentoo.org/908258. There were miscompilations
> even fixed after 12.3.0 was tagged.
>
> (Also, ccache really isn't a "package with quirky behaviour" in terms of
> whether or not it causes gcc to ICE. It has nothing to do with what
> ccache itself does at runtime.)
True, I've just never had solid luck with it in the cases where I've tried using it. Same goes for distcc.
Something always broke, and it took more time to dig into the break and find a fix than to just build things
the regular way. Shouldn't be lumping a compiler ICE into that, but I wrote my inquiry late at night when I
probably should've slept on it some more :)
>>>
>> Under qemu, it takes about 4 hours to build the single-ABI variant of
>> gcc and 7 hours for the multilib variant. So I avoid rebuilding the
>> compiler as much as possible, as with six chroots, that's virtually an
>> entire day across all six just for gcc, minus distractions (seriously,
>> the build times on gcc are getting waaaaaaay out of hand, regardless
>> of arch).
>
> It should get a bit better as of recent 13 as we backported a change
> to help parallel builds at least (and reduce resource consumption).
This is good to know, thanks. I'll look at what qlop reports for build-times on the host itself as well as
inside a qemu-mips chroot and see if there are noticeable differences. I've been wondering if gcc upstream
would ever look into dealing with C++'s slower compilation time in some form, so if they are starting to
address things (beginning w/ better parallelization), that's a hopeful sign.
--
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943
"The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by
moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
next prev parent reply other threads:[~2023-06-15 16:29 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-15 4:02 [gentoo-dev] What happened to gcc-12.3.0? Joshua Kinard
2023-06-15 5:04 ` Matt Turner
2023-06-15 15:47 ` Joshua Kinard
2023-06-15 11:37 ` Sam James
2023-06-15 16:29 ` Joshua Kinard [this message]
2023-06-15 15:09 ` Andreas K. Huettel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=631d9f97-4c96-daae-d2a9-c56cf881791a@gentoo.org \
--to=kumba@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox