Bug#898323: g++-8 -m32 do not find bits/c++config.h

2018-05-11 Thread James Cowgill 
Hi,

On 11/05/18 00:55, Matthias Klose wrote:
> On 10.05.2018 11:24, Bill Allombert wrote:
>> Package: g++-8
>> Version: 8.1.0-1
>> Severity: normal
>>
>> Hello GCC maintainers,
>>
>> trying to the attached dummy file with g++-8 fails:
>>
>> g++-8 -m32 hello.c
>> In file included from /usr/include/c++/8/stdlib.h:36,
>>  from hello.c:1:
>> /usr/include/c++/8/cstdlib:41:10: fatal error: bits/c++config.h: No such 
>> file or directory
>>  #include 
>>   ^~
>> compilation terminated.
>>
>> g++-8-multilib is installed.
>> This work with g++-7 and g++-6
>> Maybe this is related to
>>  "* Stop providing the 8.x.y symlinks in gcc_lib_dir and incluce/c++.  "
> 
> works for me.

I get the same error in a clean sid chroot. I've attached the whole log
which may be useful.

Neither of these directories are in the include path:
 /usr/include/x86_64-linux-gnu/c++/8/
 /usr/include/x86_64-linux-gnu/c++/8/x32/
But this one (which doesn't exist) is:
 /usr/include/i386-linux-gnu/c++/8

James
root@LDT-J-COWGILL:~# schroot -c sid-amd64-sbuild
(sid-amd64-sbuild)root@LDT-J-COWGILL:~# apt-get install g++-8-multilib
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following additional packages will be installed:
  cpp-8 g++-8 gcc-7-multilib gcc-8 gcc-8-multilib gcc-multilib lib32asan4 lib32asan5 lib32atomic1 lib32cilkrts5 lib32gcc-7-dev lib32gcc-8-dev lib32gcc1 lib32gomp1 lib32itm1 lib32mpx2 lib32quadmath0
  lib32stdc++-8-dev lib32stdc++6 lib32ubsan0 lib32ubsan1 libasan5 libc6-dev-i386 libc6-dev-x32 libc6-i386 libc6-x32 libgcc-8-dev libstdc++-8-dev libubsan1 libx32asan4 libx32asan5 libx32atomic1 libx32cilkrts5
  libx32gcc-7-dev libx32gcc-8-dev libx32gcc1 libx32gomp1 libx32itm1 libx32quadmath0 libx32stdc++-8-dev libx32stdc++6 libx32ubsan0 libx32ubsan1
Suggested packages:
  gcc-8-locales gcc-8-doc libstdc++6-8-dbg lib32stdc++6-8-dbg libx32stdc++6-8-dbg libgcc1-dbg libgomp1-dbg libitm1-dbg libatomic1-dbg libasan5-dbg liblsan0-dbg libtsan0-dbg libubsan1-dbg libmpx2-dbg
  libquadmath0-dbg libstdc++-8-doc
The following NEW packages will be installed:
  cpp-8 g++-8 g++-8-multilib gcc-7-multilib gcc-8 gcc-8-multilib gcc-multilib lib32asan4 lib32asan5 lib32atomic1 lib32cilkrts5 lib32gcc-7-dev lib32gcc-8-dev lib32gcc1 lib32gomp1 lib32itm1 lib32mpx2
  lib32quadmath0 lib32stdc++-8-dev lib32stdc++6 lib32ubsan0 lib32ubsan1 libasan5 libc6-dev-i386 libc6-dev-x32 libc6-i386 libc6-x32 libgcc-8-dev libstdc++-8-dev libubsan1 libx32asan4 libx32asan5 libx32atomic1
  libx32cilkrts5 libx32gcc-7-dev libx32gcc-8-dev libx32gcc1 libx32gomp1 libx32itm1 libx32quadmath0 libx32stdc++-8-dev libx32stdc++6 libx32ubsan0 libx32ubsan1
0 upgraded, 44 newly installed, 0 to remove and 0 not upgraded.
Need to get 149 MB of archives.
After this operation, 691 MB of additional disk space will be used.
Do you want to continue? [Y/n] 
Get:1 http://deb.debian.org/debian sid/main amd64 cpp-8 amd64 8.1.0-1 [39.9 MB]
Get:2 http://deb.debian.org/debian sid/main amd64 libasan5 amd64 8.1.0-1 [360 kB]
Get:3 http://deb.debian.org/debian sid/main amd64 libubsan1 amd64 8.1.0-1 [119 kB]
Get:4 http://deb.debian.org/debian sid/main amd64 libgcc-8-dev amd64 8.1.0-1 [2295 kB]
Get:5 http://deb.debian.org/debian sid/main amd64 gcc-8 amd64 8.1.0-1 [39.3 MB]
Get:6 http://deb.debian.org/debian sid/main amd64 libstdc++-8-dev amd64 8.1.0-1 [1525 kB]
Get:7 http://deb.debian.org/debian sid/main amd64 g++-8 amd64 8.1.0-1 [42.5 MB]
Get:8 http://deb.debian.org/debian sid/main amd64 libc6-i386 amd64 2.27-3 [2855 kB]
Get:9 http://deb.debian.org/debian sid/main amd64 libc6-dev-i386 amd64 2.27-3 [2020 kB]
Get:10 http://deb.debian.org/debian sid/main amd64 libc6-x32 amd64 2.27-3 [3053 kB]
Get:11 http://deb.debian.org/debian sid/main amd64 libc6-dev-x32 amd64 2.27-3 [ kB]
Get:12 http://deb.debian.org/debian sid/main amd64 lib32gcc1 amd64 1:8.1.0-1 [47.8 kB]
Get:13 http://deb.debian.org/debian sid/main amd64 libx32gcc1 amd64 1:8.1.0-1 [40.5 kB]
Get:14 http://deb.debian.org/debian sid/main amd64 lib32gomp1 amd64 8.1.0-1 [82.1 kB]
Get:15 http://deb.debian.org/debian sid/main amd64 libx32gomp1 amd64 8.1.0-1 [77.2 kB]
Get:16 http://deb.debian.org/debian sid/main amd64 lib32itm1 amd64 8.1.0-1 [29.7 kB]
Get:17 http://deb.debian.org/debian sid/main amd64 libx32itm1 amd64 8.1.0-1 [27.9 kB]
Get:18 http://deb.debian.org/debian sid/main amd64 lib32atomic1 amd64 8.1.0-1 [8356 B]
Get:19 http://deb.debian.org/debian sid/main amd64 libx32atomic1 amd64 8.1.0-1 [ B]
Get:20 http://deb.debian.org/debian sid/main amd64 lib32stdc++6 amd64 8.1.0-1 [407 kB]
Get:21 http://deb.debian.org/debian sid/main amd64 lib32asan5 amd64 8.1.0-1 [368 kB]
Get:22 http://deb.debian.org/debian sid/main amd64 libx32stdc++6 amd64 8.1.0-1 [381 kB]
Get:23 http://deb.debian.org/debian sid/main amd64 libx32asan5 amd64 8.1.0-1 [353 kB]
Get:24 http://deb.debian.org/debian sid/main amd64 lib32ubsan1 amd64 8.1.0-1 [134 kB]
Get:25 http://deb.debian.org/debian

Bug#886316: gcc-7: fix typo for N32 conditions in debian/rules2

2018-01-04 Thread James Cowgill 
Hi,

On 04/01/18 11:00, YunQiang Su wrote:
> Package: src:gcc-7
> Version: 7.2.0-18
> 
> when detect mipsn32 triarch,
> we use ifeq ($(biarchn32)-$(biarch32),yes-yes), but we should use
>   ifeq ($(biarch64)-$(biarch32),yes-yes)
> 

I guess you attached the wrong patch?

James



signature.asc
Description: OpenPGP digital signature

Re: mips/mipsel: enforce --param ggc-min-expand=10 always

2017-11-23 Thread James Cowgill 
On 23/11/17 11:42, Mathieu Malaterre wrote:
> YunQiang,
> 
> Do you know of any drawbacks ?

This has been raised before:
https://lists.debian.org/debian-mips/2016/10/msg00049.html

I think it's generally a good idea. You wouldn't want to "enforce" this
- you would set it as an overridable default setting.

I think the disadvantages are: compilation speed, I think there is no
official way to do this so you would have to hack the gcc source a bit,
and deviation from upstream / other distros.

James

> On Thu, Nov 23, 2017 at 11:29 AM, YunQiang Su  wrote:
>> I guess we should set this param for mips/mipsel by default?
>>
>> On Thu, Nov 23, 2017 at 5:20 AM, Mathieu Malaterre  wrote:
>>> On Wed, Nov 22, 2017 at 2:24 PM, Mathieu Malaterre  wrote:
 Dear mips gurus,

 Could someone please suggest a fix for the following FTBFS issue for
 OpenVDB package:

 https://buildd.debian.org/status/fetch.php?pkg=openvdb=mipsel=4.0.2-1=1508213166=0

 Thanks much
>>>
>>> Turns out that --param ggc-min-expand=10 worked just fine on eller.d.o.
>>>
>>> Sorry for the noise,
>>>
>>
>>
>>
>> --
>> YunQiang Su
> 




signature.asc
Description: OpenPGP digital signature

Bug#880962: mips*: "gcc --help=target --help=optimizers" busyloops forever

2017-11-14 Thread James Cowgill 
Control: tags -1 patch

Hi,

On 07/11/17 13:45, James Cowgill wrote:
> Control: forwarded -1 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82880
> 
> Hi,
> 
> On 06/11/17 18:07, James Cowgill wrote:
>> On 06/11/17 12:11, Adrian Bunk wrote:
>>> Package: gcc-7
>>> Version: 7.2.0-12
>>> Severity: serious
>>> Control: affects -1 src:amanda
>>>
>>> https://buildd.debian.org/status/package.php?p=amanda=sid
>>>
>>> ...
>>> checking for gcc flag -fstrict-aliasing... 
>>> E: Build killed with signal TERM after 360 minutes of inactivity
>>>
>>>
>>> Testcase:
>>>
>>> (sid_mips-dchroot)bunk@minkus:~$ gcc --help=target --help=optimizers  
>>
>> Bisected to this commit, but I don't know how far that helps us.
>> Probably some mips specific option blows up.
> 
> I've filed a bug upstream with some more details. Indeed a mips
> optimization pass being registered twice caused the infinite loop, but I
> currently think the mips specific code is being called incorrectly and
> there needs to be a generic fix.
> 
> I posted a workaround patch in the upstream bug report.

I was about to post the patch upstream, but I have just been reminded
that the FSF paperwork for the new MIPS company hasn't gone through yet
(since I don't work for Imagination anymore - it's all very fun), so I'm
not allowed to post it yet.

Here's what I was about to send.

James
From dcbbf8b94831616203731ee8be9b40817aa6695f Mon Sep 17 00:00:00 2001
From: James Cowgill <james.cowg...@mips.com>
Date: Tue, 14 Nov 2017 12:18:37 +
Subject: [PATCH] MIPS: remove static specifier from register_pass_info struct

This fixes PR 82880 (where gcc --help --help hangs) by ensuring that if
mips_register_frame_header_opt is called twice, the second call to
register_pass gets a different instance of register_pass_info.

2017-11-14  James Cowgill <james.cowg...@mips.com>

	PR target/82880
	* config/mips/frame-header-opt.c (mips_register_frame_header_opt):
	Remove static specifier from f.
---
 gcc/config/mips/frame-header-opt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/mips/frame-header-opt.c b/gcc/config/mips/frame-header-opt.c
index 76930792e92..0ebf377d046 100644
--- a/gcc/config/mips/frame-header-opt.c
+++ b/gcc/config/mips/frame-header-opt.c
@@ -99,7 +99,7 @@ void
 mips_register_frame_header_opt (void)
 {
   opt_pass *p = make_pass_ipa_frame_header_opt (g);
-  static struct register_pass_info f =
+  struct register_pass_info f =
 {p, "comdats", 1, PASS_POS_INSERT_AFTER };
   register_pass ();
 }
-- 
2.15.0



signature.asc
Description: OpenPGP digital signature

Bug#880962: mips*: "gcc --help=target --help=optimizers" busyloops forever

2017-11-07 Thread James Cowgill 
Control: forwarded -1 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82880

Hi,

On 06/11/17 18:07, James Cowgill wrote:
> On 06/11/17 12:11, Adrian Bunk wrote:
>> Package: gcc-7
>> Version: 7.2.0-12
>> Severity: serious
>> Control: affects -1 src:amanda
>>
>> https://buildd.debian.org/status/package.php?p=amanda=sid
>>
>> ...
>> checking for gcc flag -fstrict-aliasing... 
>> E: Build killed with signal TERM after 360 minutes of inactivity
>>
>>
>> Testcase:
>>
>> (sid_mips-dchroot)bunk@minkus:~$ gcc --help=target --help=optimizers  
> 
> Bisected to this commit, but I don't know how far that helps us.
> Probably some mips specific option blows up.

I've filed a bug upstream with some more details. Indeed a mips
optimization pass being registered twice caused the infinite loop, but I
currently think the mips specific code is being called incorrectly and
there needs to be a generic fix.

I posted a workaround patch in the upstream bug report.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#880962: mips*: "gcc --help=target --help=optimizers" busyloops forever

2017-11-06 Thread James Cowgill 
Hi,

On 06/11/17 12:11, Adrian Bunk wrote:
> Package: gcc-7
> Version: 7.2.0-12
> Severity: serious
> Control: affects -1 src:amanda
> 
> https://buildd.debian.org/status/package.php?p=amanda=sid
> 
> ...
> checking for gcc flag -fstrict-aliasing... 
> E: Build killed with signal TERM after 360 minutes of inactivity
> 
> 
> Testcase:
> 
> (sid_mips-dchroot)bunk@minkus:~$ gcc --help=target --help=optimizers  

Bisected to this commit, but I don't know how far that helps us.
Probably some mips specific option blows up.

> 4972d77dcbe0c4186dabc67a0edb7f3f2df4e646 is the first bad commit
> commit 4972d77dcbe0c4186dabc67a0edb7f3f2df4e646
> Author: marxin 
> Date:   Fri Sep 15 08:18:34 2017 +
> 
> Subject: Backport r251400
> 
> 2017-09-15  Martin Liska  
> 
> Backport from mainline
> 2017-08-29  Martin Liska  
> 
> PR other/39851
> * gcc.c (driver_handle_option): Add new argument.
> * opts-common.c (handle_option): Pass
> target_option_override_hook.
> * opts-global.c (lang_handle_option): Add new option.
> (set_default_handlers):  Add new argument.
> (decode_options): Likewise.
> * opts.c (target_handle_option): Likewise.
> (common_handle_option): Call target_option_override_hook.
> * opts.h (struct cl_option_handler_func): Add hook for
> target option override.
> (struct cl_option_handlers): Likewise.
> (set_default_handlers): Add new argument.
> (decode_options): Likewise.
> (common_handle_option): Likewise.
> (target_handle_option): Likewise.
> * toplev.c (toplev::main): Pass targetm.target_option.override
> hook.
> 2017-09-15  Martin Liska  
> 
> Backport from mainline
> 2017-08-29  Martin Liska  
> 
> PR other/39851
> * c-common.c (parse_optimize_options): Add argument to function
> call.
> * c-pragma.c (handle_pragma_diagnostic): Likewise.
> 
> 
> git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-7-branch@252787 
> 138bc75d-0d04-0410-961f-82ee72b054a4
> 
> :04 04 435ac2ed3f121183790fa89d3120400725e3c6a0 
> 424643290a7f6c41e0abe05fb6c596113ed6e611 Mgcc

James



signature.asc
Description: OpenPGP digital signature

Bug#876639: libgo11: Please consider backport "libgo: use gc's arch names as the default GOARCHs on MIPS"

2017-09-27 Thread James Cowgill 
Hi,

On 24/09/17 10:36, Shengjing Zhu wrote:
> Package: libgo11
> Version: 7.2.0-5
> Severity: wishlist
> Tags: upstream
> X-Debbugs-CC: pkg-go-maintain...@lists.alioth.debian.org
> 
> Dear Maintainer,
> 
> Currently the pkg-go team uses gccgo to build Go packages on MIPS*
> archs. However currently version of gccgo has different GOARCH name for
> MIPS*.
> 
> Bug is reported at https://github.com/golang/go/issues/18031
> And the fix is applied in trunk,
> https://github.com/gcc-mirror/gcc/commit/074bbd7b6a221b0446c73b3f4c2e1bf6cc7b2634
> 
> We currently need tricky way to build Go packages on MIPS*(as described
> in https://github.com/golang/go/issues/18031#issuecomment-318574018 )
> 
> So I think backport this fix in gccgo can be really helpful.

I just want to note that you need all 6 of the patches from the original
patch series I submitted. If you only apply the commit above, the build
will fail.

These are commits 648dc544240~6..648dc544240 in the gcc git mirror. I
can collect all the patches together if that would be easier.

See this for the original series:
https://go-review.googlesource.com/c/gofrontend/+/46150

This should be enough to get golang to build with gccgo on mips64el. For
the two 32-bit architectures, we need the waitid bug to be fixed in the
kernel and pushed to the buildds as well - #867358

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#871514: gcc-7: miscompiles stack spills on mips64el

2017-09-01 Thread James Cowgill 
Control: tags -1 patch

Hi,

On 23/08/17 17:42, James Cowgill wrote:
> This bug is very closely related to an earlier GCC bootstrap failure on
> mips64el: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660
> In comment 17 Matthew sent a patch and applying it also fixes this bug.
> However, he tells me it has some other issues and isn't suitable to be
> applied (which is presumably why it was reverted).

Matthew has now had a better look at the bug and has posted a patch to
fix it which is a tweaked version of the patch above:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81803#c9

I've done some testing, and it seems to solve all the known package
failures (at least the ones on my list) caused by this bug and I haven't
noticed any failures with it. I also tested it on armhf and it causes no
regressions there (this was one of the issues with the earlier patch).

So I think the attached debdiff should be applied to gcc-7. Currently
the patch is applied everywhere, but if you want you could limit it to
mips64el.

Thanks,
James
diff -u gcc-7-7.2.0/debian/rules.patch gcc-7-7.2.0/debian/rules.patch
--- gcc-7-7.2.0/debian/rules.patch
+++ gcc-7-7.2.0/debian/rules.patch
@@ -72,6 +72,7 @@
gcc-fuse-ld-lld \
libgo-s390x-default-isa \
pr81829 \
+   gcc-mips64-stack-spilling \
 
 
 #  $(if $(filter yes, $(DEB_CROSS)),,gcc-print-file-name) \
only in patch2:
unchanged:
--- gcc-7-7.2.0.orig/debian/patches/gcc-mips64-stack-spilling.diff
+++ gcc-7-7.2.0/debian/patches/gcc-mips64-stack-spilling.diff
@@ -0,0 +1,16 @@
+--- a/src/gcc/lra-constraints.c
 b/src/gcc/lra-constraints.c
+@@ -4235,7 +4235,12 @@ curr_insn_transform (bool check_only_p)
+ && (goal_alt[i] == NO_REGS
+ || (simplify_subreg_regno
+ (ira_class_hard_regs[goal_alt[i]][0],
+- GET_MODE (reg), byte, mode) >= 0)
++ GET_MODE (reg), byte, mode) >= 0
++|| (type != OP_IN
++&& GET_MODE_PRECISION (mode)
++< GET_MODE_PRECISION (GET_MODE (reg))
++&& GET_MODE_SIZE (GET_MODE (reg)) <= UNITS_PER_WORD
++&& WORD_REGISTER_OPERATIONS))
+   {
+ /* An OP_INOUT is required when reloading a subreg of a
+mode wider than a word to ensure that data beyond the


signature.asc
Description: OpenPGP digital signature

Bug#873584: gcc-7: compiles in ARM mode instead of Thumb on armhf

2017-08-29 Thread James Cowgill 
Package: gcc-7
Severity: important
X-Debbugs-CC: debian-...@lists.debian.org

Hi,

It appears that gcc-7 no longer compiles in Thumb mode by default on
armhf.

My guess is that it was caused by this change which was intended to
remove all the java / gcj code:
https://anonscm.debian.org/viewvc/gcccvs/branches/sid/gcc-7/debian/rules.defs?r1=9038=9039

The part at the top with the "with_arm_thumb" assignments should be
reverted. Maybe there should be a mass-rebuild after this, but I'll
let the ARM porters deal with that :)

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#871514: clamav: FTBFS on mips64el

2017-08-23 Thread James Cowgill 
Control: forcemerge -1 872438

Hi,

Just a brief update on this bug. Unfortunately there is still no "good" fix.

As I have written in a few places now, the bug occurs on mips64el where
a "small" variable gets spilled to the stack. It is possible that GCC
writes the variable to the stack using a small instruction (like sw for
a 32-bit store) and then reloads it as a 64-bit integer (using ld). This
means that the upper bits of the loaded value will contain garbage
causing chaos later when the value is used.

The bug is almost certainly in the LRA part of the compiler which
handles spilling values to the stack. One possible temporary workaround
(originally suggested by Adrian Bunk) would be to disable LRA on
mips64el. I have tested the attached patch which does seem to work. The
disadvantage of this is that non-LRA hasn't really been tested on MIPS
for ages so it might introduce some other bugs. Given the scale of this
issue it might be worth it?

This bug is very closely related to an earlier GCC bootstrap failure on
mips64el: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660
In comment 17 Matthew sent a patch and applying it also fixes this bug.
However, he tells me it has some other issues and isn't suitable to be
applied (which is presumably why it was reverted).

James
commit 21398b7c319ed013741a9b249cb2315a098b6753
Author: James Cowgill <james...@cowgill.org.uk>
Date:   Tue Aug 22 11:33:47 2017 +0100

Disable LRA on mips as a workaround

diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index 563f74b74f0..c89067cf89c 100644
--- a/gcc/config/mips/mips.c
+++ b/gcc/config/mips/mips.c
@@ -19738,7 +19738,7 @@ mips_option_override (void)
   else if (ISA_MIPS1 && !TARGET_FLOAT32)
 error ("%<-march=%s%> requires %<-mfp32%>", mips_arch_info->name);
   else if (TARGET_FLOATXX && !mips_lra_flag)
-error ("%<-mfpxx%> requires %<-mlra%>");
+mips_lra_flag = 1;
 
   /* End of code shared with GAS.  */
 
diff --git a/gcc/config/mips/mips.opt b/gcc/config/mips/mips.opt
index ced243218e3..cf7795c63e4 100644
--- a/gcc/config/mips/mips.opt
+++ b/gcc/config/mips/mips.opt
@@ -385,7 +385,7 @@ Target Report Mask(SYNCI)
 Use synci instruction to invalidate i-cache.
 
 mlra
-Target Report Var(mips_lra_flag) Init(1) Save
+Target Report Var(mips_lra_flag) Init(0) Save
 Use LRA instead of reload.
 
 mlxc1-sxc1


signature.asc
Description: OpenPGP digital signature

Re: Bug#871565: gcc-7: ppc64el: miscompiles ffmpeg's scalarproduct_int16_vsx at -O1

2017-08-12 Thread James Cowgill 
Control: reassign -1 gcc-7 7.1.0-13
Control: severity -1 important
Control: retitle -1 gcc-7: ppc64el: miscompiles ffmpeg's 
scalarproduct_int16_vsx at -O1
Control: forwarded -1 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81833
Control: affects -1 src:ffmpeg

Hi,

On 09/08/17 06:47, Adrian Bunk wrote:
> Source: ffmpeg
> Version: 7:3.3.3-2
> Severity: serious
> 
> https://buildd.debian.org/status/fetch.php?pkg=ffmpeg=ppc64el=7%3A3.3.3-2=1502249633=0
[...]
> TESTcheckasm-audiodsp
> /<>/tests/fate-run.sh fate-checkasm-audiodsp "" "" 
> "/<>/debian/standard" 'run tests/checkasm/checkasm 
> --test=audiodsp' '' '/dev/null' '' '1' '' '' '' '' '' '' '' ''
>  /<>/debian/standard/ffmpeg -nostdin -nostats -cpuflags all 
> -threads 1 -idct simple -flags +bitexact -sws_flags +accurate_rnd+bitexact 
> -fflags +bitexact -f image2 -vcodec pgmyuv -hwaccel none -threads 1 
> -thread_type frame+slice -i 
> /<>/debian/standard/tests/vsynth1/%02d.pgm -flags +bitexact 
> -sws_flags +accurate_rnd+bitexact -fflags +bitexact -threads 1 -idct simple 
> -dct fastint -vf format=gbrp14be,vflip= -vcodec rawvideo -frames:v 5 -pix_fmt 
> gbrp14be -frames:v 1 -f nut md5:
>  /<>/debian/standard/tests/checkasm/checkasm --test=audiodsp
> Test checkasm-audiodsp failed. Look at tests/data/fate/checkasm-audiodsp.err 
> for details.
> checkasm: using random seed 3484844225
> ALTIVEC:
>audiodsp.scalarproduct_int16_altivec (audiodsp.c:81)
>  - audiodsp.audiodsp [FAILED]
> VSX:
>audiodsp.scalarproduct_int16_vsx (audiodsp.c:81)
>  - audiodsp.audiodsp [FAILED]
> checkasm: 2 of 2 tests have failed
> /<>/tests/Makefile:219: recipe for target 
> 'fate-checkasm-audiodsp' failed
> make[2]: *** [fate-checkasm-audiodsp] Error 1

I've debugged this a bit and it definitely looks like GCC 7 has
miscompiled some of the VSX routines in FFmpeg. I've filed an upstream
bug againt GCC, but I'll probably just disable these optimizations on
ppc64el until it's fixed.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#798710: jit-playback changes brake package pygccjit build on mips and mipsel

2017-02-16 Thread James Cowgill 
Control: reassign -1 gcc-6 6.3.0-6
Control: tags -1 - sid
Control: forwarded -1 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79560
Control: retitle -1 gcc-6: libgccjit is broken on mips*

Hi,

I've checked recent versions of GCC and this bug is still present in
gcc-6 and gcc-7 and I've submitted it to the upstream bug tracker. It
seems to me that the value of MULTILIB_DEFAULTS is incorrect in the MIPS
backend but I don't really know much about it so we'll see what upstream
GCC says!

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Re: Bug#848285: jackd2: spits verbose output and exits immediately when the client stops sending audio

2016-12-21 Thread James Cowgill 
Control: clone -1 -2
Control: reassign -2 gcc-6 6.2.0-13
Control: found -2 6.2.1-7
Control: severity -2 normal
Control: retitle -2 gcc-6: wrong code generation with -O1 if union is written 
to twice
Control: forwarded -2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78895
Control: affects -2 src:jackd2

Hi all,

On 19/12/16 23:39, Francesco Poli wrote:
> On Sun, 18 Dec 2016 22:56:00 +0000 James Cowgill wrote:
> [...]
>> On 15/12/16 23:18, Francesco Poli (wintermute) wrote:
> [...]
>>> I experienced a grave bug: as soon as the client (audacious, firefox through
>>> ALSA redirection in ~/.asoundrc, ...) stops sending audio to the jackd
>>> sound server, the latter spits a bunch of output messages and exits
>>> immediately (as if the --temporary option were passed, no!, even worse!).
>>
>> Firstly, apologies for not testing this fully before uploading the most
>> recent version :/
> 
> It may happen.
> It's weird that nobody noticed in unstable, before the package managed
> to migrate to testing, but anyway...
> 
>> This appears this is a toolchain bug. Simply recompiling the latest
>> version of jackd2 with gcc-6_6.2.0-6 (the version the -3 revision was
>> compiled with) makes it work again. The toolchain bug will probably need
>> reducing before anyone can look at it however.
> 
> Good that you are able to reproduce the bug and managed to pinpoint the
> cause.
> I hope this can be fixed soon.

I got a reduced testcase and submitted the bug upstream. I'm cloning
this bug into gcc-6 to keep track of the fix there.

Since the bug only happens with optimization turned on, it could
probably be worked around by disabling some optimization options (I
haven't checked which), but I think that should be a last resort.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#781457: ada bootstrap failure on mips and mipsel

2016-12-16 Thread James Cowgill 
Control: found -1 6.2.1-6
Control: severity -1 serious
Control: tags -1 patch

Hi,

On Sun, 29 Mar 2015 17:17:03 +0200 Matthias Klose  wrote:
> Package: src:gcc-5
> Version: 5-20150327-1
> Severity: important
> Tags: sid stretch
> Forwarded: https://gcc.gnu.org/PR65618
> 
> seen building trunk 20150328. I'm not entirely sure if this is a regression.
> Apparently all distro builds for mips and mipsel set STAGE3_CFLAGS += -gtoggle
> (same as in stage2) in the past, and maybe were papering over the problem.
> 
> If this workaround is really needed, we should limit the comparision failure 
> to
> exactly the one failing file.
> 
> Comparing stages 2 and 3
> warning: gcc/cc1-checksum.o differs
> warning: gcc/cc1objplus-checksum.o differs
> warning: gcc/cc1obj-checksum.o differs
> warning: gcc/cc1plus-checksum.o differs
> Bootstrap comparison failure!
> gcc/ada/a-except.o differs
> Makefile:22697: recipe for target 'compare' failed
> make[4]: *** [compare] Error 1

Given that you reverted the workaround for this, I assume that you
consider this bug RC for stretch? I note that this isn't a recent issue
- the workaround was shipped in both wheezy and jessie.

I attach the patch I posted to the upstream bug report. I am going to
submit it properly once I do a few extra tests (I'm fairly confident
about it, but it won't be done until next week). I'm also planning on
upstreaming ada-mips.diff with a few tweaks simplify it a bit.

Thanks,
James
--- a/gcc/emit-rtl.c	
+++ a/gcc/emit-rtl.c	
@@ -3742,6 +3742,11 @@ try_split (rtx pat, rtx_insn *trial, int last)
 		   next = NEXT_INSN (next))
 		if (NOTE_KIND (next) == NOTE_INSN_CALL_ARG_LOCATION)
 		  {
+		/* Advance after to the next instruction if it is about to
+		   be removed */
+		if (after == next)
+		  after = NEXT_INSN(after);
+
 		remove_insn (next);
 		add_insn_after (next, insn, NULL);
 		break;


signature.asc
Description: OpenPGP digital signature

Bug#841316: gcc: the last 6.2.0-7 broke the virtualbox build

2016-10-19 Thread James Cowgill 
Hi,

On Wed, 19 Oct 2016 14:47:48 + (UTC) Gianfranco Costamagna
 wrote:
> Source: gcc
> Version: 6.2.0-7
> Severity: serious
> 
> As said, I built virtualbox correctly with 6.2.0-6 and then uploaded on 
> unstable.
> The new gcc 6.2.0-7 broke the build with the following error:
[...]
> /usr/include/x86_64-linux-gnu/sys/inotify.h:34:13: error: flexible array 
> member 'inotify_event::name' not at end of 'struct InotifyEventWithName'

Relevant parts:

cdefs.h
---
# define __flexarr  []

inotify.h

/* Structure describing an inotify event.  */
struct inotify_event
{
  int wd;   /* Watch descriptor.  */
  uint32_t mask;/* Watch mask.  */
  uint32_t cookie;  /* Cookie to synchronize two events.  */
  uint32_t len; /* Length (including NULs) of name.  */
  char name __flexarr;  /* Name.  */
};

HostDnsServiceLinux.cpp:

struct InotifyEventWithName
{
struct inotify_event e;
char name[NAME_MAX];
};

While I do not know if this is a GCC bug or not, doing the above is a
bit dodgy (and prohibited by C99). What is the offset of
InotifyEventWithName::name supposed to be (given sizeof(inotify_event)
is undefined)?

This report has some info about GCC 6 changes in this regard:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69550

Since it's closed as WONTFIX, I expect this will not be changed in gcc.

Thanks,
James




signature.asc
Description: OpenPGP digital signature

Bug#839132: libgo9: libgo built without FFI in mips*

2016-09-29 Thread James Cowgill 
Hi,

On 29/09/16 18:17, Matthias Klose wrote:
> Control: tags -1 + help
> 
> Please find out why libgo isn't configured to use libffi.

It looks like the necessary support for go closures on mips isn't
implemented in the version of libffi in gcc 6.

There appears to be a PR here which fixes it:
https://github.com/libffi/libffi/pull/197

It's not in GCC's copy of libffi though.

James

> On 29.09.2016 12:30, Martín Ferrari wrote:
>> Package: libgo9
>> Version: 6.2.0-4
>> Severity: normal
>>
>> Hi,
>>
>> Recently, I modified golang-goprotobuf to use gccgo in non-native go arches,
>> and found that it FTBFS in mips/mipsel/mps64el due to this error:
>>
>>   fatal error: libgo built without FFI does not support reflect.Call or 
>> runtime.SetFinalizer
>>
>> Here is one of the build logs:
>>
>> https://buildd.debian.org/status/fetch.php?pkg=golang-goprotobuf=mips=0.0~git20160815.0.7390af9-2=1474830436
>>
>> I don't know if this is a mistake, or if there is a reason for this FFI 
>> support
>> not being included in these arches, but without it, a big number of packages
>> are BD-Uninstallable as they depend transitively on protobuf support.
>>
>> -- System Information:
>> Debian Release: stretch/sid
>>   APT prefers unstable
>>   APT policy: (500, 'unstable'), (500, 'testing')
>> Architecture: amd64 (x86_64)
>>
>> Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
>> Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8)
>> Shell: /bin/sh linked to /bin/dash
>> Init: sysvinit (via /sbin/init)
>>
>> Versions of packages libgo9 depends on:
>> ii  gcc-6-base  6.2.0-4
>> ii  libc6   2.24-3
>> ii  libgcc1 1:6.2.0-4
>>
>> libgo9 recommends no packages.
>>
>> libgo9 suggests no packages.
>>
>> -- no debconf information
>>
> 




signature.asc
Description: OpenPGP digital signature

Bug#788210: Package x42-plugins doesn't build on mipsel arch

2015-06-10 Thread James Cowgill 
Control: reassign -1 g++-4.9 4.9.2-1
Control: retitle -1 g++-4.9: generates invalid assembly building x42-plugins on 
mipsel
Control: affects -1 src:x42-plugins
Control: tags -1 unreproducible

On Tue, 09 Jun 2015 14:55:49 +0200 (CEST) Jaromír Mikeš mira.mi...@seznam.cz 
wrote:
 Package: gcc
 Version: 4.9_4.9.2-19
 
 Hello,
 
 Package x42-plugins doesn't build on mipsel with gcc 4.9_4.9.2-19
 https://buildd.debian.org/status/fetch.php?pkg=x42-pluginsarch=mipselver=20150530-1stamp=1433113512
 As x42-plugins doesn't contain any assembler code it might be gcc bug.
 It looks like gcc generates invalid code for that platform 

I can't reproduce this bug. I tried building x42-plugins on a few
different mipsel machines in sid chroots and it worked every time.

James

signature.asc
Description: This is a digitally signed message part

Bug#781892: (Hardware?) problem with denormal values on mipsel

2015-05-27 Thread James Cowgill 
Control: reassign -1 src:linux 3.16.7-ckt9-2
Control: retitle -1 linux: mips sqrt.s instruction not emulated on Loongson 
processors
Control: tags -1 fixed-upstream
# Will be fixed in 4.1

On Tue, 2015-05-26 at 20:21 +0300, Aaro Koskinen wrote:
 On Tue, May 26, 2015 at 10:13:35AM +0100, James Cowgill wrote:
  On Sun, 2015-05-24 at 22:32 +0300, Aaro Koskinen wrote:
   On Fri, May 22, 2015 at 11:00:18PM +0100, James Cowgill wrote:
On Sat, 2015-05-23 at 00:04 +0300, Aaro Koskinen wrote:
 On Fri, May 22, 2015 at 05:27:14PM +0100, James Cowgill wrote:
  Yep it's a hardware problem. The following assembly dies (raises 
  SIGILL)
  at 'sqrt.s' on the Loongsons and works everywhere else:
  
  ===
  .set mips2
  .text
  .global main
  .type main, @function
  main:
  lui $t0, %hi(value)
  lwc1 $f0, %lo(value)($t0)
  nop
  sqrt.s $f0, $f0
  jr $ra
  
  .data
  value:
  .float 1.1342362e-39
  ===
 
 Is this a standalone reproducer program for the problem? Because
 I tried it on on my Loongson box and didn't get any SIGILL...

It should be. I tried it on some 3A machines at work and it crashed
there (and then some other machines which didn't crash). There's a 2F I
can try on Tuesday.
   
   My Loongson is 2F...
  
  I tried it on my 2F (it's a Lemote Fuloong) and it crashed there as well
  (both the gfortran and my testcase). It's running up to date jessie.
  
  What compiler versions do you have?
  What does the 'cpu model' line say in /proc/cpuinfo?
 
 I'm using binutils 2.25, GCC 5.1, Linux 4.1-rc5. The cpu model is:
 
 cpu model   : ICT Loongson-2 V0.3  FPU V0.1

Thanks! The kernel was the important part which was different to my
setup.

There's probably still a hardware bug in here somewhere, but before 3.16
the kernel was fixing it with the math emulator.

From what I can see:
Commit 08a07904e182 in 3.16 ('MIPS: math-emu: Remove most ifdefery.')
incorrectly disabled emulation of the sqrt.s instruction on processors
only supporting the mips2/mips3 ISA.

Commit 7352c8b13dd9 in 3.18 ('MIPS: Loongson: Set Loongson-3's ISA level
to MIPS64R1') worked around this in the Loongson 3s because their ISA
level was bumped to mips64r1.

Commit 2d83fea786d7 in 4.1-rc1 ('MIPS: Correct FP ISA requirements')
fixed the underlying sqrt.s emulation bug.

It would be good if the 4.1-rc1 patch or at least the 'case fsqrt_op'
part (which is the fix for this bug) can be applied to a jessie stable
kernel and then installed on the buildds. This should fix the original
problem of eso-midas failing to build on mipsel.

Thanks,
James


signature.asc
Description: This is a digitally signed message part

Bug#781892: (Hardware?) problem with denormal values on mipsel

2015-05-26 Thread James Cowgill 
On Sun, 2015-05-24 at 22:32 +0300, Aaro Koskinen wrote:
 On Fri, May 22, 2015 at 11:00:18PM +0100, James Cowgill wrote:
  On Sat, 2015-05-23 at 00:04 +0300, Aaro Koskinen wrote:
   On Fri, May 22, 2015 at 05:27:14PM +0100, James Cowgill wrote:
Yep it's a hardware problem. The following assembly dies (raises SIGILL)
at 'sqrt.s' on the Loongsons and works everywhere else:

===
.set mips2
.text
.global main
.type main, @function
main:
lui $t0, %hi(value)
lwc1 $f0, %lo(value)($t0)
nop
sqrt.s $f0, $f0
jr $ra

.data
value:
.float 1.1342362e-39
===
   
   Is this a standalone reproducer program for the problem? Because
   I tried it on on my Loongson box and didn't get any SIGILL...
  
  It should be. I tried it on some 3A machines at work and it crashed
  there (and then some other machines which didn't crash). There's a 2F I
  can try on Tuesday.
 
 My Loongson is 2F...

I tried it on my 2F (it's a Lemote Fuloong) and it crashed there as well
(both the gfortran and my testcase). It's running up to date jessie.

What compiler versions do you have?
What does the 'cpu model' line say in /proc/cpuinfo?

  Does the original gfortran code crash for you?
 
 I don't have gfortran available on my system.

Don't you run Debian?

Thanks,
James


signature.asc
Description: This is a digitally signed message part

Bug#781892: (Hardware?) problem with denormal values on mipsel

2015-05-22 Thread James Cowgill 
On Sat, 2015-05-23 at 00:04 +0300, Aaro Koskinen wrote:
 Hi,
 
 On Fri, May 22, 2015 at 05:27:14PM +0100, James Cowgill wrote:
  Yep it's a hardware problem. The following assembly dies (raises SIGILL)
  at 'sqrt.s' on the Loongsons and works everywhere else:
  
  ===
  .set mips2
  .text
  .global main
  .type main, @function
  main:
  lui $t0, %hi(value)
  lwc1 $f0, %lo(value)($t0)
  nop
  sqrt.s $f0, $f0
  jr $ra
  
  .data
  value:
  .float 1.1342362e-39
  ===
 
 Is this a standalone reproducer program for the problem? Because
 I tried it on on my Loongson box and didn't get any SIGILL...

It should be. I tried it on some 3A machines at work and it crashed
there (and then some other machines which didn't crash). There's a 2F I
can try on Tuesday. Does the original gfortran code crash for you?

Thanks,
James


signature.asc
Description: This is a digitally signed message part

Bug#781892: (Hardware?) problem with denormal values on mipsel

2015-05-22 Thread James Cowgill 
On Fri, 2015-05-22 at 16:41 +0200, Ole Streicher wrote:
 Dear Mailing list,
 
 a few weeks ago, I found a problem that I thought is related to gfortran;
 however I am unsure whether this is really the case.
 
 http://bugs.debian.org/781892
 
 Basically it burns down to the following minimal code on eder.debian.org:
 
 (sid_mipsel-dchroot)olebole@eder:~$ cat aini.f
   PROGRAM AINI
   R=1.1342362e-39
   R=SQRT(R)
   STOP
   END
 (sid_mipsel-dchroot)olebole@eder:~$ gfortran -Wall -o aini aini.f
 (sid_mipsel-dchroot)olebole@eder:~$ ./aini
 
 Program received signal SIGILL: Illegal instruction.

eder and all the other machines eso-midas has failed on are Loongson
machines. I'll have a further investigate but I wouldn't be too
surprised if this was yet another Loongson FPU bug...

Thanks,
James


signature.asc
Description: This is a digitally signed message part

Bug#781892: (Hardware?) problem with denormal values on mipsel

2015-05-22 Thread James Cowgill 
On Fri, 2015-05-22 at 16:12 +0100, James Cowgill wrote:
 On Fri, 2015-05-22 at 16:41 +0200, Ole Streicher wrote:
  Program received signal SIGILL: Illegal instruction.
 
 eder and all the other machines eso-midas has failed on are Loongson
 machines. I'll have a further investigate but I wouldn't be too
 surprised if this was yet another Loongson FPU bug...

Yep it's a hardware problem. The following assembly dies (raises SIGILL)
at 'sqrt.s' on the Loongsons and works everywhere else:

===
.set mips2
.text
.global main
.type main, @function
main:
lui $t0, %hi(value)
lwc1 $f0, %lo(value)($t0)
nop
sqrt.s $f0, $f0
jr $ra

.data
value:
.float 1.1342362e-39
===

There is now only one non-loongson build machine (mayer) so it doesn't
look good. All the solutions I can think of for this sound really
horrible (stuff like disabling the FPUs) :(

Thanks,
James


signature.asc
Description: This is a digitally signed message part

Bug#779191: gnat-4.9: fix build on mips64el

2015-02-25 Thread James Cowgill 
Source: gnat-4.9
Version: 4.9.2-1
Severity: important
Tags: patch

Hi,

I managed to successfully bootstrap gnat on mips64el, but it required a
small patch to the build system for it to build on Debian. It's similar
to patches used on other 64-bit arches and is due to Debian not putting
the 64-bit libs in lib64.

Thanks,
James
--- a/src/gcc/ada/gcc-interface/Makefile.in
+++ b/src/gcc/ada/gcc-interface/Makefile.in
@@ -1893,7 +1893,7 @@ ifeq ($(strip $(filter-out mips64el linu
   LIBGNAT_TARGET_PAIRS_64 = \
   system.adssystem-linux-mips64el.ads
 
-  ifeq ($(strip $(shell $(GCC_FOR_TARGET) $(GNATLIBCFLAGS) -print-multi-os-directory)),../lib64)
+  ifneq ($(strip $(MULTISUBDIR)),/32)
 LIBGNAT_TARGET_PAIRS = \
 $(LIBGNAT_TARGET_PAIRS_COMMON) $(LIBGNAT_TARGET_PAIRS_64)
   else

Bug#773177: gcc-defaults: enable multilib on mips64*

2014-12-15 Thread James Cowgill 
Source: gcc-defaults
Version: 1.135
Severity: important
Tags: patch

Hi,

This patch enables multilib on mips64 and mips64el. Currently gcc-4.9
build-depends on g++-multilib on mips64el, but that package isn't built
by gcc-defaults.

While I was doing the modifications, I also enabled gccgo on mips64
since it's built by gcc-4.9 as well. I didn't enable gcj in the
gcj_archs field because gcj seems to be broken on mips64el (I haven't
investigated why).

Thanks,
James
From 55efad3ed9530dbfddce85bfce8cc272f162363e Mon Sep 17 00:00:00 2001
From: James Cowgill james...@cowgill.org.uk
Date: Mon, 15 Dec 2014 10:39:41 +
Subject: [PATCH] Add mips64 and mips64el to gcc-defaults

---
 debian/control | 12 ++--
 debian/rules   |  6 +++---
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/debian/control b/debian/control
index 07beb43..bef210f 100644
--- a/debian/control
+++ b/debian/control
@@ -44,7 +44,7 @@ Description: GNU C++ compiler
 
 Package: g++-multilib
 Priority: optional
-Architecture: amd64 i386 kfreebsd-amd64 mips mipsel powerpc ppc64 s390 s390x sparc sparc64 x32
+Architecture: amd64 i386 kfreebsd-amd64 mips mips64 mips64el mipsel powerpc ppc64 s390 s390x sparc sparc64 x32
 Depends: cpp (= ${version:cpp}), gcc-multilib (= ${version:cpp}), g++ (= ${version:cpp}), g++-${pv:gpp}-multilib ${reqv:gpp}, ${misc:Depends}
 Description: GNU C++ compiler (multilib files)
  This is the GNU C++ compiler, a fairly portable optimizing compiler for C++.
@@ -67,7 +67,7 @@ Description: GNU Objective-C compiler
 
 Package: gobjc-multilib
 Priority: optional
-Architecture: amd64 i386 kfreebsd-amd64 mips mipsel powerpc ppc64 s390 s390x sparc sparc64 x32
+Architecture: amd64 i386 kfreebsd-amd64 mips mips64 mips64el mipsel powerpc ppc64 s390 s390x sparc sparc64 x32
 Depends: cpp (= ${version:cpp}), gcc-multilib (= ${version:cpp}), gobjc (= ${version:gcc}), gobjc-${pv:gobjc}-multilib ${reqv:gobjc}, ${misc:Depends}
 Description: GNU Objective-C compiler (multilib files)
  This is the GNU Objective-C compiler, which compiles Objective-C on
@@ -92,7 +92,7 @@ Description: GNU Objective-C++ compiler
 
 Package: gobjc++-multilib
 Priority: optional
-Architecture: amd64 i386 kfreebsd-amd64 mips mipsel powerpc ppc64 s390 s390x sparc sparc64 x32
+Architecture: amd64 i386 kfreebsd-amd64 mips mipsel mips64 mips64el powerpc ppc64 s390 s390x sparc sparc64 x32
 Depends: cpp (= ${version:cpp}), gobjc-multilib (= ${version:cpp}), gobjc++ (= ${version:gcc}), gobjc++-${pv:gobjcxx}-multilib ${reqv:gobjcxx}, ${misc:Depends}
 Description: GNU Objective-C++ compiler (multilib files)
  This is the GNU Objective-C++ compiler, which compiles Objective-C++ on
@@ -116,7 +116,7 @@ Description: GNU Fortran 95 compiler
 
 Package: gfortran-multilib
 Priority: optional
-Architecture: amd64 i386 kfreebsd-amd64 mips mipsel powerpc ppc64 s390 s390x sparc sparc64 x32
+Architecture: amd64 i386 kfreebsd-amd64 mips mips64 mips64el mipsel powerpc ppc64 s390 s390x sparc sparc64 x32
 Depends: cpp (= ${version:cpp}), gcc-multilib (= ${version:cpp}), gfortran (= ${version:gcc}), gfortran-${pv:gfort}-multilib ${reqv:gfort}, ${misc:Depends}
 Description: GNU Fortran 95 compiler (multilib files)
  This is the GNU Fortran compiler, which compiles Fortran 95 on platforms
@@ -139,7 +139,7 @@ Description: Go compiler, based on the GCC backend
 
 Package: gccgo-multilib
 Priority: optional
-Architecture: amd64 i386 mips mipsel powerpc ppc64 s390 s390x x32
+Architecture: amd64 i386 mips mips64 mips64el mipsel powerpc ppc64 s390 s390x x32
 Depends: cpp (= ${version:cpp}), gcc-multilib (= ${version:cpp}), gccgo (= ${version:ggo}), gccgo-${pv:ggo}-multilib ${reqv:ggo}, ${misc:Depends}
 Description: Go compiler, based on the GCC backend (multilib files)
  This is the GNU Go compiler, which compiles Go on platforms supported by
@@ -239,7 +239,7 @@ Description: GNU C compiler
 
 Package: gcc-multilib
 Priority: optional
-Architecture: amd64 i386 kfreebsd-amd64 mips mipsel powerpc ppc64 s390 s390x s390x sparc sparc64 x32
+Architecture: amd64 i386 kfreebsd-amd64 mips mips64 mips64el mipsel powerpc ppc64 s390 s390x s390x sparc sparc64 x32
 Depends: cpp (= ${version:cpp}), gcc (= ${version:gcc}), gcc-${pv:gcc}-multilib ${reqv:gcc}, ${misc:Depends}, linux-libc-dev (= 3.0.0-2) [linux-any]
 Breaks: gcc-4.9-arm-linux-gnueabihf, gcc-4.9-arm-linux-gnueabi, gcc-4.9-powerpc-linux-gnu, gcc-4.9-powerpc64el-linux-gnu, gcc-4.9-mipsel-linux-gnu
 Description: GNU C compiler (multilib files)
diff --git a/debian/rules b/debian/rules
index 59bf438..b1b689a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -259,10 +259,10 @@ gcj_native_archs = alpha amd64 armel armhf arm64 hppa i386 ia64 mips mipsel \
 	powerpc powerpcspe ppc64 ppc64el s390 s390x sh4 sparc sparc64 x32 \
 	kfreebsd-amd64 kfreebsd-i386 hurd-i386
 
-multilib_archs = amd64 i386 kfreebsd-amd64 mips mipsel powerpc ppc64 \
-	s390 s390x sparc sparc64 x32
+multilib_archs = amd64 i386 kfreebsd-amd64 mips mips64 mips64el mipsel

Re: gcc-defaults_1.135+nmu1_source.changes REJECTED

2014-12-12 Thread James Cowgill 
On Fri, 2014-12-12 at 15:36 +, Debian FTP Masters wrote:
 
 ACL dm: not allowed to upload source package 'gcc-defaults'

Sorry, I uploaded it to the wrong queue (it should have been sent to a
private repo). God help me if I ever become a DD.

James


-- 
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1418398686.15123.157.ca...@cowgill.org.uk