Hi Jose!
On 01/05/2016 11:21 AM, Jose E. Marchesi wrote:
> Right. cpu_32, cpu_64, tune_32 and tune_64 are not supported in sparc*
> targets yet.
>
> I will prepare a patch for that and send it upstream.
Any news on this issue?
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian
On 01/05/2016 11:21 AM, Jose E. Marchesi wrote:
> Right. cpu_32, cpu_64, tune_32 and tune_64 are not supported in sparc*
> targets yet.
>
> I will prepare a patch for that and send it upstream.
Any news on this issue?
Didn't happen yet.
On 01/05/2016 11:21 AM, Jose E. Marchesi wrote:
> Right. cpu_32, cpu_64, tune_32 and tune_64 are not supported in sparc*
> targets yet.
>
> I will prepare a patch for that and send it upstream.
Great, thanks a lot!
Could you also attach it to this bug report as well once you have it?
Adrian
> Right. cpu_32, cpu_64, tune_32 and tune_64 are not supported in sparc*
> targets yet.
>
> I will prepare a patch for that and send it upstream.
Great, thanks a lot!
Could you also attach it to this bug report as well once you have it?
Sure.
On 01/05/2016 11:31 AM, Jose E. Marchesi wrote:
> The default cpu option for -m32 in sparc is very very conservative: a v7
> cpu. It may be worth it to consider bumping it to ultrasparc/v9a or, at
> least v9, when GCC is built for sparcv9-* targets...
Yeah, we actually want to force -multrasparc
On 01/04/2016 02:48 PM, John Paul Adrian Glaubitz wrote:
> On 01/01/2016 02:36 PM, Matthias Klose wrote:
>> how was this tested? The last time I checked that option was ignored.
>
> Argh, you are right, I actually mentioned that earlier [1].
So, looking at the code
Not building -mcpu=ultrasparc results in ATOMIC_INT_LOCK_FREE == 1
which is responsible for the missing symbols on sparc64 multilib [2].
Maybe Jose (CC) can give some hints regarding the proper buildflags
which will make gcc build with -mcpu=ultrasparc when -mcpu32 is
On 05.01.2016 11:31, Jose E. Marchesi wrote:
Not building -mcpu=ultrasparc results in ATOMIC_INT_LOCK_FREE == 1
which is responsible for the missing symbols on sparc64 multilib [2].
Maybe Jose (CC) can give some hints regarding the proper buildflags
which will make gcc
> The default cpu option for -m32 in sparc is very very conservative: a v7
> cpu. It may be worth it to consider bumping it to ultrasparc/v9a or, at
> least v9, when GCC is built for sparcv9-* targets...
right, but v9 seems to imply 64bit/sparc64. used this patch to work
> Your patch above uses -mcpu=ultrasparc, and that is not right for
> sparc-* triplets targetting 32-bit processors.
ohh ... ok, but 32bit sparc is gone in Debian anyway. If somebody
wants to revive this architecture, then we probably would have to
change the triplet as
On 05.01.2016 13:23, Jose E. Marchesi wrote:
> Your patch above uses -mcpu=ultrasparc, and that is not right for
> sparc-* triplets targetting 32-bit processors.
ohh ... ok, but 32bit sparc is gone in Debian anyway. If somebody
wants to revive this architecture, then we
On 05.01.2016 13:06, Jose E. Marchesi wrote:
> The default cpu option for -m32 in sparc is very very conservative: a v7
> cpu. It may be worth it to consider bumping it to ultrasparc/v9a or, at
> least v9, when GCC is built for sparcv9-* targets...
right, but v9 seems to
On 01/04/2016 02:48 PM, John Paul Adrian Glaubitz wrote:
> On 01/01/2016 02:36 PM, Matthias Klose wrote:
>> how was this tested? The last time I checked that option was ignored.
>
> Argh, you are right, I actually mentioned that earlier [1].
So, looking at the code [1] it seems the reason is
On 01/01/2016 02:36 PM, Matthias Klose wrote:
> how was this tested? The last time I checked that option was ignored.
Argh, you are right, I actually mentioned that earlier [1].
Not building -mcpu=ultrasparc results in ATOMIC_INT_LOCK_FREE == 1
which is responsible for the missing symbols on
how was this tested? The last time I checked that option was ignored.
15 matches
Mail list logo
