https://bugs.llvm.org/show_bug.cgi?id=32020 YunQiang Su <[email protected]> 于2018年9月28日周五 上午11:05写道： > > Ximin Luo <[email protected]> 于2018年9月27日周四 下午12:06写道： > > > > Ximin Luo: > > > Do you have a link to a more detailed description of the problem, so that > > > the rest of us can understand it? > > > > > > For example James in message 29 gave a very detailed summary of other > > > previous problems: > > > > > > [29] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881845#29 > > > > > > Nobody in this thread has stated what the supposed problem actually is > > > with these Cavium/Octeon machines. FYI the builds failed recently on > > > eberlin and manda-03, and has failed in the past on aql-01. These are all > > > octeon, and the other mips64el buildd sil-01 is also octeon. So it seems > > > all our buildds are affected by the bug. So the blacklist approach won't > > > even work. > > > > > > > Oh I take that back, it seems aql-01 and manda-01,02 are not octeon, I had > > previously assumed all the x-{01..03} machines would be the same. > > > > Still, please give us a link to the description of the problem. > > I cannot remember clear. > It seems that no branch instruction can be in ll/sc pair on Octeon, > while llvm does generate code like this. > > Loongson has no this problem. anyway, we should patch llvm. > > > > > > X > > > > > Also unless I can understand the problem, I don't feel happy using the > > > blacklist as a temporary solution, even if it was going to work. > > > > > > X > > > > > > YunQiang Su: > > >> It is still about llvm+octeon problem. > > >> > > >> Maybe we can ask pin rustc on Loongson machines. > > >> Ximin Luo <[email protected]> 于2018年9月24日周一 上午2:21写道： > > >>> > > >>> Aron Xu: > > >>>> [..] > > >>>>> > > >>>>> Aron, the next version 1.27.1 is already in binary-NEW so the same > > >>>>> issue will block testing migration again, when that gets accepted. > > >>>>> > > >>>>> Earlier you said "Binary only upload from porter is allowed [..]" but > > >>>>> I am not sure the other porters have access to a loongson-3a box. > > >>>>> Will you continue to run builds of new rustc versions on your box? I > > >>>>> think that is the key point here. > > >>>>> > > >>>> > > >>>> Will do that and see if we can get the issue either fixed or have a > > >>>> blacklist placed at the same time. > > >>>> > > >>> > > >>> I have just uploaded 1.29.0 to unstable. It will need manual building > > >>> with a non-buggy mips machine, to unblock us for Debian Testing. The > > >>> previous build 1.29.0+dfsg1-1~exp1 failed due to hanging atomic tests: > > >>> > > >>> https://buildd.debian.org/status/fetch.php?pkg=rustc&arch=mips64el&ver=1.29.0%2Bdfsg1-1%7Eexp1&stamp=1537686627&raw=0 > > >>> > > >>> test sync.rs - sync::Arc (line 124) ... test sync.rs - sync::Arc (line > > >>> 124) has been running for over 60 seconds > > >>> test sync.rs - sync::Arc<T>::downgrade (line 418) ... test sync.rs - > > >>> sync::Arc<T>::downgrade (line 418) has been running for over 60 seconds > > >>> test sync.rs - sync::Arc<T>::get_mut (line 856) ... test sync.rs - > > >>> sync::Arc<T>::get_mut (line 856) has been running for over 60 seconds > > >>> test sync.rs - sync::Arc<T>::make_mut (line 769) ... test sync.rs - > > >>> sync::Arc<T>::make_mut (line 769) has been running for over 60 seconds > > >>> E: Build killed with signal TERM after 150 minutes of inactivity > > >>> > > >>> I still think we should just RM rustc on mips64el. > > >>> > > >>> X > > >>> > > >>> -- > > >>> GPG: ed25519/56034877E1F87C35 > > >>> GPG: rsa4096/1318EFAC5FBBDBCE > > >>> https://github.com/infinity0/pubkeys.git > > >>> > > >> > > >> > > > > > > > > > > > > -- > > GPG: ed25519/56034877E1F87C35 > > GPG: rsa4096/1318EFAC5FBBDBCE > > https://github.com/infinity0/pubkeys.git > > > > -- > YunQiang Su
-- YunQiang Su
