Bug#792204: Setting default CPU to ultrasparc for -m32 on sparc64 does not work

[Matthias Klose <doko@debian.org>]

On 07/20/2015 01:37 AM, Michael Karcher wrote:
> Hello,
> 
> the problem (ATOMIC_INT_LOCK_FREE == 1) applies for the 32-bit build of
> libstdc++,
> and is caused by gcc assuming a too old 32-bit sparc processor, as can
> be seen by:
> 
>> (unstable-sparc64-sbuild)mkarcher@ravirin:~$ COLUMNS=140 dpkg -l gcc-4.9
>> Desired=Unknown/Install/Remove/Purge/Hold
>> |
> Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
>> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
>> ||/ Name                          Version            
> Architecture        Description
>>
> +++-=============================-===================-===================-===============================================================
>> ii  gcc-4.9                       4.9.2-21+sparc64   
> sparc64             GNU C compiler
> 
> (this is a custom build of the official debian gcc source with the
> symbol verification
> quieted by using fudged expected symbols lists)
> 
>> (unstable-sparc64-sbuild)mkarcher@ravirin:~$ g++-4.9 -std=c++11 -dM -E
> -m32 -x c++ /dev/null | grep INT_LOCK      
>> #define __GCC_ATOMIC_INT_LOCK_FREE 1
>> (unstable-sparc64-sbuild)mkarcher@ravirin:~$ g++-4.9 -std=c++11 -dM -E
> -m32 -mcpu=ultrasparc -x c++ /dev/null | grep INT_LOCK
>> #define __GCC_ATOMIC_INT_LOCK_FREE 2
> 
> The changelog messages for gcc seem to indicate that the default CPU for
> -m32 is
> intended to be ultrasparc:
> 
>> gcc-4.9 (4.9.0-10) unstable; urgency=medium
>>
>>   * Update to SVN 20140704 (r212295) from the gcc-4_9-branch.
>>
>>   * Explicitly set cpu_32 to ultrasparc for sparc64 builds.
> [...]
>> gcc-4.9 (4.9.0-9) unstable; urgency=medium
>>
>>   * Update to SVN 20140701 (r212192) from the gcc-4_9-branch.
>>   * Update libstdc++ symbols files for ARM.
>>   * Configure --with-cpu-32=ultrasparc on sparc64.
> 
> This seems to not have the intended effect of defaulting to require the
> ultrasparc
> architecture providing lock-free atomics.
> 
> Regards,
>   Michael Karcher

see sparc-force-cpu.diff, which currently disables this for sparc64 biarch. So
maybe somebody should just enable it and see if it works as intended, or make it
working.