On 07.07.18 17:24, YunQiang Su wrote:
> Niels Thykier 于2018年6月28日周四 上午4:06写道：
>> List of concerns for architectures
>> ==
>>
>> The following is a summary from the current architecture qualification
>> table.
>>
>> * Concern for ppc64el and s390x: we are dependent on sponsors for
>>hardware.
>>(Raised by DSA; carried over from stretch)
>>
>> * Concern for armel and armhf: only secondary upstream support in GCC
>>(Raised by the GCC maintainer; carried over from stretch)
I don't think anybody objected about the status for armhf. I didn't follow
armel issues too closely.
>> * Concern for mips, mips64el, mipsel and ppc64el: no upstream support
>>in GCC
>>(Raised by the GCC maintainer; carried over from stretch)
>>
>
> This is a misunderstanding as MIPS company had some unrest in recent half
> year.
> Currently we are stable now, and the shape of gcc upstream is also good.
This is an optimistic view. While currently not having any RC issues, we still
see mips* specific issues popping up more often than on other release
architectures.
According to https://gcc.gnu.org/gcc-8/criteria.html there is no mips*-linux*
target listed as either primary or secondary platform. As far as I understand
the mips porters argue that this is covered by mipsisa64-elf, a bare metal
target. I don't agree with this view, because
- testing is missing on mips*-linux-* targets. If you look at
the gcc-testresults ML, you see only test reports submitted for
the Debian GCC packages, nothing else.
- A bare metal target is usually only built/used for C and C++. I
doubt that other frontends are tested.
- Configurations like libgcjit are not tested/used upstream, and not
addressed. See #798710.
The Debian bug tracking for the MIPS port could be better, I usually need some
pings to the MIPS porters to get things forwarded or addressed.
To me it looks sometimes that Debian is used for testing by upstream, and for
that the mips architectures don't need to be release architectures.
Matthias
