Is this still an issue? I was able to only reproduce it on groovy, now
EoL.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1890435
Title:
gcc-10 breaks on armhf (flaky): internal compiler error:
** Changed in: gcc
Status: Confirmed => In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1890435
Title:
gcc-10 breaks on armhf (flaky): internal compiler error: Segmentation
fault
Just FYI - as we were afraid of - this now starts to break SRUs and other
service actions to qemu in Groovy.
https://launchpad.net/ubuntu/+source/qemu/1:5.0-5ubuntu9.7/+build/21361775 just
failed.
And without a better solution I'll need to trigger retry with fingers crossed.
--
You received
On BareMetal now also triggered with -j1 (but there were multiple LXD
containers each running -j1 to increase the chance to find it).
/root/qemu-5.0/memory.c: In function ‘memory_region_write_accessor’:
/root/qemu-5.0/memory.c:485:1: internal compiler error: Segmentation fault
485 | }
| ^
So far 2/4 failed of r11-5879 on X-Gene BareMetal.
Doko asked me to try if I could get these to fail with -j1 as well (in
the past I was unable to do so, but it is worth a try).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
The canonistack machines I used to crash it (and likely the LP builders) are
X-Gene as well.
So we might have a chance to lock this in on specific HW if there are other
chip types I could use.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
I was unable to trigger the issue on my rpi4 yet, but as you'd imagine it is
rather slow.
But (thanks Dannf) I got access to an X-gene - and carrying my known bad setup
there (LXD container export FTW) I was able to recreate this on bare-metal as
well.
(Host) Kernel: 5.4.0-58-generic
Model:
Fails with -O1 as well, although I have to admit that different -O
levels are deeply integrated in qemus build system. So it is hard to
overwrite "all of them". Therefore - while I set -O1 and that affected
some builds, it isn't implying that all compiler calls were -O1.
I know dannf has made
I left r11-5879 running over the weekend and it concluded with 37 of 75 runs
failing
That is ~50%
I'll look at -O1 next
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1890435
Title:
gcc-10 breaks
r11-5879 - bad 8 of 10
So we know:
a) the bug has not been fixed yet
b) as we've seen with later GCC-10 runs, the chances to trigger further
increased
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Indeed, gcc-10.2.1 with qemu 5.2 no more breaks 100%.
Here a good build log
https://launchpadlibrarian.net/510811599/buildlog_ubuntu-hirsute-armhf.qemu_1%3A5.2+dfsg-2ubuntu1~ppa2_BUILDING.txt.gz
I'll need a few more builds anyway and will let you know.
As mentioned before that does lower
In the test env (not LP build infra, but canonistack) I've got 30 good
runs on 10.2.1 which gives me some hope ...
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1890435
Title:
gcc-10 breaks on
I'll give things a try in current Hirsute (gcc on 10.2.1, qemu on 5.2) building
with gcc-10.
If we are back at a level where retries work I'm ok to lower severity.
I'll let you know about these results in a few days.
But since we have had the case of it reaching 100% breakage (and then
would be
On Thu, Dec 10, 2020 at 5:31 PM Dimitri John Ledkov
<1890...@bugs.launchpad.net> wrote:
>
> "just retry the build" is our solution to this issue.
It is not - in hirsute the builds of the actual package on LP hit 100%
fail-rate.
Unfortunately not in the repro, but due to the above the workaround
> "just retry the build" is our solution to this issue.
It is not - in hirsute the builds of the actual package on LP hit 100%
fail-rate.
Unfortunately not in the repro, but due to the above the workaround currently
is to build with gcc-9 on armhf.
But that is not a long term solution.
"just retry the build" is our solution to this issue. It's a bit a waste
of time hunting this all down at this point, unfortunately.
maybe we can try reproducing this on some publicly available hardware,
i.e. graviton2 on aws. But also not sure how much value there is in
doing this.
** Tags
As mentioned before - I didn't trust this result.
And with "likeliness" of this being so low we all know that results are
unreliable.
Due to that now r10-6822 is
r10-6822 - bad 2 of 67
The signature was the same "add_regs_to_insn_regno_info (lra)" as before
on (again) different places
r10-6823 bad 1 of 28
during RTL pass: reload
/root/qemu-5.0/migration/ram.c: In function ‘ram_load_postcopy’:
/root/qemu-5.0/migration/ram.c:3298:1: internal compiler error: Segmentation
fault
3298 | }
| ^
0x524cf3 crash_signal
../../gcc/gcc/toplev.c:328
0x411e07
Updated Result Overview:
20190425 good 0 of 13
r10-2027 good 0 of 4
r10-3040 good 0 of 4
r10-3400 good 0 of 4
r10-3657 good 0 of 5
r10-3727 good 0 of 3
r10-4054 other kind of bad 1 of 18 (signature different)
r10-6080 good 0 of 10
r10-6586 good 0 of 27
r10-6760 good 0 of 20
r10-6799 good 0 of 20
r10-6822 seems good.
Updated Result Overview:
20190425 good 0 of 13
r10-2027 good 0 of 4
r10-3040 good 0 of 4
r10-3400 good 0 of 4
r10-3657 good 0 of 5
r10-3727 good 0 of 3
r10-4054 other kind of bad 1 of 18 (signature different)
r10-6080 good 0 of 10
r10-6586 good 0 of 27
r10-6760 good 0 of 20
r10-6822 so far has 0 of 20, but I'll let it run another ~24h
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1890435
Title:
gcc-10 breaks on armhf (flaky): internal compiler error: Segmentation
Updated Result Overview:
20190425 good 0 of 13
r10-2027 good 0 of 4
r10-3040 good 0 of 4
r10-3400 good 0 of 4
r10-3657 good 0 of 5
r10-3727 good 0 of 3
r10-4054 other kind of bad 1 of 18 (signature different)
r10-6080 good 0 of 10
r10-6586 good 0 of 27
r10-6760 good 0 of 20
r10-6799 good 0 of 20
r10-6824 bad 1 of 24, signature matches
We have only a few steps to go and need to increase the number of runs to be
sure, so I'll let it run for a while longer.
Also - eventually - I'll re-run what we consider to be the last good, quite a
few times to be sure.
Most likely I'll later today
r10-6829 has 2 fails in 35 runs
Signature matches, both are: add_regs_to_insn_regno_info (lra)
r10-6824 = next
Updated Result Overview:
20190425 good 0 of 13
r10-2027 good 0 of 4
r10-3040 good 0 of 4
r10-3400 good 0 of 4
r10-3657 good 0 of 5
r10-3727 good 0 of 3
r10-4054 other kind of bad 1 of 18
r10-6819 had 22 good runs.
r10-6829 will be the next to try.
Updated Result Overview:
20190425 good 0 of 13
r10-2027 good 0 of 4
r10-3040 good 0 of 4
r10-3400 good 0 of 4
r10-3657 good 0 of 5
r10-3727 good 0 of 3
r10-4054 other kind of bad 1 of 18 (signature different)
r10-6080 good 0 of 10
Completed 20 good runs on r10-6799, continuing with r10-6819 as
planned.
Updated Result Overview:
20190425 good 0 of 13
r10-2027 good 0 of 4
r10-3040 good 0 of 4
r10-3400 good 0 of 4
r10-3657 good 0 of 5
r10-3727 good 0 of 3
r10-4054 other kind of bad 1 of 18 (signature different)
r10-6080 good
FYI: r10-6799 had 14 good runs so far, I'll let it run for a bit longer to be
sure.
Then - later today - if nothing changes r10-6819 will be next.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Ok, r10-6760 reached 20 good runs and is considered good.
Doko was so kind to build 6779 6799 6819 for me - of which 6799 will be next.
Note: I've aligned the comments to all have the same style and dropped
the untested revisions.
Updated Result Overview:
20190425 good 0 of 13
r10-2027 good 0 of
We'll need more runs to be sure, but so far r10-6760 seems good.
In preparation - could I requests builds between r10-6760 - r10-6839 please ?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1890435
Updated Result Overview:
20190425 good
r10-1014
r10-2027 good?4
r10-2533
r10-3040 good?4
r10-3220
r10-3400 good?4
r10-3450
r10-3475
r10-3478
r10-3593
r10-3622
r10-3657 good?5
r10-3727 good?3
r10-4054 other kind of bad - signature different, and rare?
r10-6080 good?10
r10-6586 good?27
r10-6760 next
2/7 runs of r10-6839 failed with
r10-6839 add_regs_to_insn_regno_info (lra)
Next will be r10-6760
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1890435
Title:
gcc-10 breaks on armhf (flaky):
Add another 1/3 fails to r10-7093
Now I am on the next two
- r10-6760
- r10-6839
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1890435
Title:
gcc-10 breaks on armhf (flaky): internal compiler
r10-6586 - passed 27 good runs, no fails
Updated Result Overview:
20190425 good
r10-1014
r10-2027 good?4
r10-2533
r10-3040 good?4
r10-3220
r10-3400 good?4
r10-3450
r10-3475
r10-3478
r10-3593
r10-3622
r10-3657 good?5
r10-3727 good?3
r10-4054 other kind of bad - signature different, and rare?
Since this seems to become a reproducibility-fest I've spawned and
prepared two more workers using the same setup as the one we used
before. That should allow for some more runs/days to increase the rate
at we can process it - given the new insight to its unreliability.
--
You received this bug
FYI - another 8 runs without a crash on r10-7093.
My current working theory is that the root cause of the crash might have been
added as early as r10-4054 but one or many later changes have increased the
chance (think increase the race window or such) for the issue to trigger.
If that assumption
I'm not yet sure what we should learn from that - do we need 30 runs of
each step to be somewhat sure? That makes an already slow bisect even
slower ...
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Failed on #17
during RTL pass: reload
/root/qemu-5.0/fpu/softfloat.c: In function ‘soft_f64_muladd’:
/root/qemu-5.0/fpu/softfloat.c:1535:1: internal compiler error: Segmentation
fault
1535 | }
| ^
cc -iquote /root/qemu-5.0/b/qemu/target/mips -iquote target/mips -iquote
14 runs and going ...
It was never "so rare" when we were at the gcc that is in hirsute or 20200507.
I'll let it continue to run for now
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1890435
Title:
To be sure i was running r10-7093 again and so far got 8 good runs in a row :-/
If only we could have a better trigger :-/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1890435
Title:
gcc-10 breaks
3 full runs good with r10-7093 but then I got:
/root/qemu-5.0/disas/nanomips.cpp: In member function ‘std::string
NMD::JALRC_HB(uint64)’:
/root/qemu-5.0/disas/nanomips.cpp:7969:1: internal compiler error: Segmentation
fault
7969 | }
| ^
0x602fa7 crash_signal
We again need to ask, is this the one we are hunting for - or might it be
another issue in between.
Doko ?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1890435
Title:
gcc-10 breaks on armhf
Doko is so kind and builds r10-7093 got me.
20190425 good
r10-1014
r10-2027 good
r10-2533
r10-3040 good
r10-3220
r10-3400 good
r10-3450
r10-3475
r10-3478
r10-3593
r10-3622
r10-3657 good
r10-3727 good
r10-4054 other kind of bad?
r10-6080 good
r10-7093 next
20200507 bad bad bad
--
You received
Another crash with 20200507 at first try:
/root/qemu-5.0/fpu/softfloat.c: In function ‘float128_div’:
/root/qemu-5.0/fpu/softfloat.c:7504:1: internal compiler error: Segmentation
fault
7504 | }
| ^
0x5518cb crash_signal
../../gcc/gcc/toplev.c:328
0x43e363
Ok, 20200507 almost immediately triggered the ICE
/root/qemu-5.0/linux-user/syscall.c: In function ‘do_syscall1’:
/root/qemu-5.0/linux-user/syscall.c:12479:1: internal compiler error:
Segmentation fault
12479 | }
| ^
0x5518cb crash_signal
../../gcc/gcc/toplev.c:328
0x542673
FYI - inquiry for the underlying HW/SW is in RT 128805 - I set Doko and
Rick to CC on that.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1890435
Title:
gcc-10 breaks on armhf (flaky): internal
r10-6080 now had 10 good runs.
I'm going back to test 20200507 next - we had bad states with that
version so often this MUST trigger IMHO,
Reminder this runs on in armhf LXD containers on arm64 VMs (like our builds do).
I'm slowly getting the feeling it could be an issue with the underlying
On this re-check r10-4054 had 7 complete runs without a fail.
So as I was afraid of in comment 71 already, it might have been another much
more rare ICE hidden in there as well. Or OTOH we are cursed by some very bad
statistical chances :-/.
I'll check r10-6080 next to see if it
a) reproduces
r10-3727 had another 2.5 good runs, overall it LGTM now.
I'll re-run r10-4054 just to be sure not to hunt a ghost.
20190425 good
r10-1014
r10-2027 good
r10-2533
r10-3040 good
r10-3220
r10-3400 good
r10-3450
r10-3475
r10-3478
r10-3593
r10-3622
r10-3657 good
r10-3727 good
r10-4054 bad next
r10-6080
FYI: Systems are back up, restarted tests on r10-3727
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1890435
Title:
gcc-10 breaks on armhf (flaky): internal compiler error: Segmentation
fault
To
1.5 builds good on r10-3727, but that is not enough to make a decision.
Right now there is some machine downtime due to a datacenter move. Back
on Monday I guess.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
r10-3657 had 5 good runs
Status:
20190425 good
r10-1014
r10-2027 good
r10-2533
r10-3040 good
r10-3220
r10-3400 good
r10-3450
r10-3475
r10-3478
r10-3593
r10-3622
r10-3657 good
r10-3727 next
r10-4054 bad
r10-6080
20200507 bad
I might want to do a re-run of r10-4054 if r10-3727 is also good. Just
r10-3400 is good
I need to switch to a different overview to make sure I can track this
:-)
20190425 good
r10-1014
r10-2027 good
r10-2533
r10-3040 good
r10-3220
r10-3400 good
r10-3450
r10-3475
r10-3478
r10-3593
r10-3622
r10-3657 next
r10-3727
r10-4054 bad
r10-6080
20200507 bad
--
You received
r10-3040 got 4.5 good passes before I aborted it - it seems to be good
as well.
That means next is r10-3400
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1890435
Title:
gcc-10 breaks on armhf
r10-2027 seems to be good passing 4 runs without a fail.
Continuing with r10-3040 next.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1890435
Title:
gcc-10 breaks on armhf (flaky): internal
r10-4054 failed with
during RTL pass: reload
/root/qemu-5.0/fpu/softfloat.c: In function ‘sf_canonicalize’:
/root/qemu-5.0/fpu/softfloat.c:670:1: internal compiler error: Segmentation
fault
670 | }
| ^
0x4b7443 crash_signal
../../gcc/gcc/toplev.c:326
0x66b7c7
20190425 can be considered good it completed 4.5 times before I scheduled the
next run.
Next is r10-4054 which has -v of:
gcc version 10.0.0 20191022 (experimental) (GCC)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
FYI currently on 20190425.
First build passed, but we need a few more to be sure.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1890435
Title:
gcc-10 breaks on armhf (flaky): internal compiler
Bisect step #1 - Expected to ICE and indeed does so.
gcc-20200507.tar.xz
/root/qemu-5.0/linux-user/syscall.c: In function ‘do_syscall1.constprop’:
/root/qemu-5.0/linux-user/syscall.c:12479:1: internal compiler error:
Segmentation fault
12479 | }
| ^
0x5518cb crash_signal
For the sake of a potential upstream change I was trying qemu from git up to
current master, but it still fails with the same error: ‘TYPE_CANONICAL’ is not
compatible.
Due to that - as long as the checking is enabled - qemu is unbuildable in
Hirsute.
At the same time Doko and I began with
Failed on the second run with:
during RTL pass: reload
/root/qemu-5.0/fpu/softfloat.c: In function ‘soft_f64_muladd’:
/root/qemu-5.0/fpu/softfloat.c:1535:1: internal compiler error: Segmentation
fault
1535 | }
| ^
...
0x532aeb crash_signal
../../src/gcc/toplev.c:328
0x41ccd7
FYI - Started a build run with 10.2.0-16ubuntu1.2
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1890435
Title:
gcc-10 breaks on armhf (flaky): internal compiler error: Segmentation
fault
To
I've learned that the gcc in hirsute has the checking enabled atm.
That explains why any qemu 5.1 build I do (merging) or Doko's rebuild on [1]
fail atm.
New GCC build is coming in [2] that has the fix applied but the checking no
more enabled.
Once built I'll re-test that one as well.
[1]:
Over night it made 5 complete runs and all worked.
@Doko - I think we can call this fix you have a good one at least from my
current tests POV.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1890435
And FYI the test build with the new compiler by Doko still runs, but we
know that not failing on the first rounds isn't a 100% win. I'll let it
continue some hours and ping back later once it passed e.g. 5 rounds or
so which we never achieved before.
--
You received this bug notification because
FYI as one would expect this continues to affect Hirsute just as much, I
just had a broken qemu-5.1 build on armhf.
/<>/qemu-5.1+dfsg/linux-user/m68k/signal.c:44:1: error:
‘TYPE_MODE’ of ‘TYPE_CANONICAL’ is not compatible
P.S. I'm still unsure if that "TYPE_CANONICAL" issue IS the formerly
seen
I got a ping by Doko (thanks) to try
https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/test/+build/20227507
ii cpp-10 10.2.0-16ubuntu1.1
armhfGNU C preprocessor
ii g++-10 10.2.0-16ubuntu1.1
** Bug watch added: Debian Bug tracker #972789
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972789
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1890435
Title:
gcc-10 breaks on armhf
** Changed in: groovy
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1890435
Title:
gcc-10 breaks on armhf (flaky): internal compiler error: Segmentation
fault
To
I've been able to reproduce reliably on X-Gene gear when running in a
KVM instance. I have not been able to reproduce outside of KVM, nor on
an alternate SoC (Hi1616). I *can* reproduce on a xenial kvm guest
running on a xenial X-Gene host - which suggests that correlation with
the LP builder
I was talking to Matthias and he mentioned that this seems to be correlated
with the LP builder upgrade to bionic:
https://lists.ubuntu.com/archives/ubuntu-devel/2020-September/041158.html
I'm running some tests to see if there might be a lower level issue:
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: gcc-10 (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1890435
Title:
Launchpad has imported 1 comments from the remote bug at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97323.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
** Bug watch added: GCC Bugzilla #97323
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97323
** Also affects: groovy via
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97323
Importance: Unknown
Status: Unknown
--
You received this bug notification because you are a member of Ubuntu
** Attachment added: "list of installed packages"
https://bugs.launchpad.net/ubuntu/+source/gcc-10/+bug/1890435/+attachment/5418899/+files/dpkg-l.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
The last one now is reproducible (not sure if that is what the segfault
was), but still useful.
$ cd /root/qemu-5.0/b/qemu/m68k-linux-user
$ cc -iquote /root/qemu-5.0/b/qemu/linux-user/m68k -iquote linux-user/m68k
-iquote /root/qemu-5.0/tcg/arm -isystem /root/qemu-5.0/linux-headers -isystem
** Attachment added: ".i file after preprocessor"
https://bugs.launchpad.net/ubuntu/+source/gcc-10/+bug/1890435/+attachment/5418898/+files/signal.i
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
The extra checks that are enabled trigger the same issues I was seeing
with gcc-snapshot (maybe they have it enabled as well?).
/root/qemu-5.0/linux-user/syscall.c: In function ‘do_setsockopt’:
/root/qemu-5.0/linux-user/syscall.c:1935:17: note: non-delegitimized UNSPEC
UNSPEC_PIC_SYM (1) found
Does the following help anything, do you want source and preprocessed
source of it?
cc -iquote /root/qemu-5.0/b/qemu/linux-user/m68k -iquote linux-user/m68k
-iquote /root/qemu-5.0/tcg/arm -isystem /root/qemu-5.0/linux-headers -isystem
/root/qemu-5.0/b/qemu/linux-headers -iquote . -iquote
FYI now Testing 10.2.0-14ubuntu0.2 from https://launchpad.net/~ubuntu-
toolchain-r/+archive/ubuntu/test/+sourcepub/11647665/+listing-archive-
extra
I've stopped setting -marm to trigger the issue "faster", please let me
know if you want me to continue to use -marm for those tests.
--
You
I spoke too soon after ~7.5 runs I got the following with -marm:
cc -iquote /root/qemu-5.0/b/user-static/target/arm -iquote target/arm -iquote
/root/qemu-5.0/tcg/arm -isystem /root/qemu-5.0/linux-headers -isystem
/root/qemu-5.0/b/user-static/linux-headers -iquote . -iquote /root/qemu-5.0
@Doko - I can confirm that with -marm the issue is gone.
I have had 6 full runs yesterday and overnight.
We can conclude, -mthumb is a requirement to trigger the issue.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Defaults:
# gcc -Q --help=target | grep -e '-marm' -e '-mthumb'
-marm [disabled]
-mthumb [enabled]
-mthumb-interwork [enabled]
Doko suggested to change that by using -marm.
This is running since a while, but
gcc-snapshot still has various issues - but not the crash
/root/qemu-5.0/linux-user/m68k/signal.c:44:1: error: 'TYPE_CANONICAL' is not
compatible
44 | };
| ^
...
/root/qemu-5.0/linux-user/m68k/signal.c:44:1: internal compiler error:
'verify_type' failed
Can't continue with
cc -iquote /root/qemu-5.0/b/qemu/accel/stubs -iquote accel/stubs -iquote
/root/qemu-5.0/tcg/arm -isystem /root/qemu-5.0/linux-headers -isystem
/root/qemu-5.0/b/qemu/linux-headers -iquote . -iquote /root/qemu-5.0 -iquote
/root/qemu-5.0/accel/tcg -iquote /root/qemu-5.0/include -iquote
I'll re-run and dump a few of them just to help you to get to the root
cause:
cc -iquote /root/qemu-5.0/b/qemu/block -iquote block -iquote
/root/qemu-5.0/tcg/arm -isystem /root/qemu-5.0/linux-headers -isystem
/root/qemu-5.0/b/qemu/linux-headers -iquote . -iquote /root/qemu-5.0 -iquote
With this build the crash does still not leave a .crash file, but it is
more verbose
cc -iquote /root/qemu-5.0/b/user-static/linux-user -iquote linux-user -iquote
/root/qemu-5.0/tcg/arm -isystem /root/qemu-5.0/linux-headers -isystem
/root/qemu-5.0/b/user-static/linux-headers -iquote . -iquote
As expected the non-strip removed the dbgsym:
The following packages will be REMOVED:
gcc-10-dbgsym
The following packages will be upgraded:
cpp-10 g++-10 gcc-10 gcc-10-base gcc-10-multilib libasan6 libatomic1 libcc1-0
libgcc-10-dev libgcc-s1 libgomp1 libsfasan6 libsfatomic1 libsfgcc-10-dev
Doko passed me gcc-10 - 10.2.0-14ubuntu0.1 from
https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/test/+packages.
Still building on armhf, but I'll give those a try once complete.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
gcc-snapshot 1:20200917-1ubuntu1 fails in other places.
/root/qemu-5.0/linux-user/m68k/signal.c:44:1: internal compiler error:
'verify_type' failed
0xf0afc3 internal_error(char const*, ...)
???:0
0x8fa705 verify_type(tree_node const*)
???:0
0x5f644b
Trying gcc-snapshot 1:20200917-1ubuntu1 now
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1890435
Title:
gcc-10 breaks on armhf (flaky): internal compiler error: Segmentation
fault
To manage
https://launchpad.net/ubuntu/+source/gcc-9/9.3.0-18ubuntu1 ran 6
complete runs over night and can be considered good.
So the breakage was between 9.3.0-18ubuntu1 and 10-20200425-1ubuntu2
How to continue from here, will you throw me PPA builds and/or do you
still have debs anywhere I should try?
So all 10.x that I could get fail:
https://launchpad.net/ubuntu/+source/gcc-10/10-20200425-1ubuntu2 - fail
https://launchpad.net/ubuntu/+source/gcc-10/10.1.0-6ubuntu1 - fail
https://launchpad.net/ubuntu/+source/gcc-10/10.2.0-9ubuntu2 - fail
https://launchpad.net/ubuntu/+source/gcc-10/10.1.0-6ubuntu1 survived 2.5
runs but then crashed as well.
Now on https://launchpad.net/ubuntu/+source/gcc-10/10-20200425-1ubuntu2
... failing as well
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
FYI: This passed two runs good by now, but that isn't enough. I need to
have it running over night to be sure about 10.1
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1890435
Title:
gcc-10 breaks
Downloaded the other two as well and running on
https://launchpad.net/ubuntu/+source/gcc-10/10.1.0-6ubuntu1 now
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1890435
Title:
gcc-10 breaks on armhf
https://launchpad.net/ubuntu/+source/gcc-10/10.2.0-11ubuntu1 - Fails
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1890435
Title:
gcc-10 breaks on armhf (flaky): internal compiler error:
There is a new gcc-10 version from two days ago in groovy now.
I was talking with doko and we wanted to try different gcc-10 versions in
general trying to corner the issue to when it started to appear.
https://launchpad.net/ubuntu/+source/gcc-10/10-20200425-1ubuntu2 - WIP
It was brought up with foundations last week in our sync and mentioned
that someone will look into it for further guidance on the case. Since
nothing happened I'll add the rls-gg-incoming tag to make sure it is re-
visited in your bug meetings.
I beg you pardon, i know it is your tag and please
I tried to isolate what was running concurrently and found 7 gcc calls.
I have set them up to run concurrently in endless loops each.
That way they reached a lot of iterations without triggering the issue :-/
I don't know how to continue :-/
But I can share a login to this system and show how to
Interim Summary:
- hits armhf compiles of various large source projects, chances are it it
completely random
and just hits those more likely by compiling more
- build system auto-retries the compiles and they work on retry eventually
reported as "The bug
is not reproducible, so it is likely
1 - 100 of 119 matches
Mail list logo
