Pinging the nios2 port.

On 13/5/15 1:04 AM, Chung-Lin Tang wrote:
> On 2013/4/26 04:35 AM, Joseph S. Myers wrote:
>> I should ask the following general standard new-port questions:
>>
>> * Does the port build cleanly when configured with --enable-werror-always 
>> and built using a native compiler from current GCC trunk - for both 32-bit 
>> host, and 64-bit host?  It should.  This is the standard way of ensuring 
>> the same level of warning-cleanness in a cross build as native bootstrap 
>> automatically enforces (and the build compiler needs to be from current 
>> trunk because warning-cleanness is only expected when the build compiler 
>> is the same version as the compiler being built).
>>
>> The new targets should be added to contrib/config-list.mk, which helps 
>> test all targets with --enable-werror-always.  This is mentioned in "Back 
>> End" in sourcebuild.texi - check there for any other pieces that should be 
>> included in the port submission.
> 
> Currently, nios2 seems to be another affected target by PR 55035, when
> building with a recent trunk with --enable-werror-always:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55035
> 
> I would like to ask this --enable-werror-always requirement be relaxed
> for the nios2 port submission, as it is not alone in the above PR, and
> we are early in the release cycle; there should be plenty of time to fix
> any problems afterwards.
> 
> Though not included in the submitted patches, I will add the target
> entries in contrib/config-list.mk when committing.
> 
>> * What are test results like for the port?  Again, both 32-bit and 64-bit 
>> hosts, to detect any dependencies on whether the host is 32-bit or 64-bit.
> 
> Tests of i686 and x86_64 Linux hosts show same test results. FAILs that
> still exist include g++.dg/debug/dwarf2/non-virtual-thunk.C, due to the
> lack of target specific MI-thunk hooks right now, and a few tree-ssa
> optimization FAILs, that might be worked around by augmenting the
> testcase. The port in whole should be fairly stable.
> 
> Thanks,
> Chung-Lin
> 
> 

Reply via email to