Bug#810055: gcc bug

2016-01-05 Thread 张永肃
Package: gcc Version : gcc (Debian 4.9.2-10) 4.9.2 or gcc (Debian 4.7.4-3) 4.7.4 The problem: the libtcmalloc_minimal.so complied by gcc 4.7.4 got higher latency than complied by gcc 4.9.2 tcmalloc version: gperftools 2.1 system: debian jessie 8.2 ps:Maybe I didn't describe the issue so clear.

Bug#810009: gcc-5 misscompiles ARM thumb code

2016-01-05 Thread Sebastian Andrzej Siewior
Package: gcc-5 Version: 5.2.1-13 Severity: important Tags: upstream Forwarded: https://gcc.gnu.org/PR69124 Clamav (and now tomsfastmath) miscompiles on armhf since the switch to gcc-5. I forwarded a testcase to gcc bugzilla. We have a workaround where we use -O1 in the affected file so it is not

Bug#809509: Processed: retitle 809509 to gcc-6: Please build with -mcpu=ultrasparc on sparc64 when building 32-bit binaries

2016-01-05 Thread Matthias Klose
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 prob

Bug#809509: Processed: retitle 809509 to gcc-6: Please build with -mcpu=ultrasparc on sparc64 when building 32-bit binaries

2016-01-05 Thread Jose E. Marchesi
> 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 we

Bug#809509: Processed: retitle 809509 to gcc-6: Please build with -mcpu=ultrasparc on sparc64 when building 32-bit binaries

2016-01-05 Thread Matthias Klose
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 im

Bug#809509: Processed: retitle 809509 to gcc-6: Please build with -mcpu=ultrasparc on sparc64 when building 32-bit binaries

2016-01-05 Thread Jose E. Marchesi
> 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

Bug#809509: Processed: retitle 809509 to gcc-6: Please build with -mcpu=ultrasparc on sparc64 when building 32-bit binaries

2016-01-05 Thread Matthias Klose
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 build

Bug#809509: Processed: retitle 809509 to gcc-6: Please build with -mcpu=ultrasparc on sparc64 when building 32-bit binaries

2016-01-05 Thread Jose E. Marchesi
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

Bug#809509: Processed: retitle 809509 to gcc-6: Please build with -mcpu=ultrasparc on sparc64 when building 32-bit binaries

2016-01-05 Thread Jose E. Marchesi
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

Bug#809509: Processed: retitle 809509 to gcc-6: Please build with -mcpu=ultrasparc on sparc64 when building 32-bit binaries

2016-01-05 Thread Jose E. Marchesi
> 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.

Bug#809509: Processed: retitle 809509 to gcc-6: Please build with -mcpu=ultrasparc on sparc64 when building 32-bit binaries

2016-01-05 Thread John Paul Adrian Glaubitz
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

Bug#809509: Processed: retitle 809509 to gcc-6: Please build with -mcpu=ultrasparc on sparc64 when building 32-bit binaries

2016-01-05 Thread John Paul Adrian Glaubitz
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 -