) unstable; urgency=medium
.
* Update to SVN 20131203 (r205647) from the gcc-4_8-branch.
* Fix PR libgcc/57363, taken from the trunk.
Checksums-Sha1:
4dac999dea8cee1d0e83234149138485ffd99fc0 11218 gcc-4.8_4.8.2-8.dsc
68f39c3d58de114bc0bd1809551ec07f1c469ae6 1221914 gcc-4.8_4.8.2-8.diff.gz
gcc-4.8_4.8.2-8_amd64.changes uploaded successfully to localhost
along with the files:
gcc-4.8_4.8.2-8.dsc
gcc-4.8_4.8.2-8.diff.gz
gcc-4.8-source_4.8.2-8_all.deb
gcj-4.8-jre-lib_4.8.2-8_all.deb
gcj-4.8-source_4.8.2-8_all.deb
libgcj-doc_4.8.2-8_all.deb
libstdc++-4.8-doc_4.8.2-8_all.deb
Hi,
(2013/12/04 9:52), Matthias Klose wrote:
> Am 02.12.2013 23:20, schrieb Hiroyuki Yamamoto:
>> Hi,
>>
>> I don't know whether it is appropriate that I remark,
>> I have no objection to moving to gcc-4.8 on ppc64, too.
>
> this is not a question about any objections, but about a call to the ppc6
Am 02.12.2013 23:20, schrieb Hiroyuki Yamamoto:
> Hi,
>
> I don't know whether it is appropriate that I remark,
> I have no objection to moving to gcc-4.8 on ppc64, too.
this is not a question about any objections, but about a call to the ppc64
porters if they are able to maintain such a port in
LAST_UPDATED: Fri Nov 29 16:58:54 UTC 2013 (revision 205535)
Target: mipsel-linux-gnu
gcc version 4.8.2 (Debian 4.8.2-7)
Native configuration is mipsel-unknown-linux-gnu
=== g++ tests ===
Running target unix
=== g++ Summary for unix ===
# of expected passes
Package: gcc-4.8
Version: 4.8.2-7
Severity: normal
--- Please enter the report below this line. ---
Compiling a 64bit kernel on my 32 bit host results on a kernel that does
not boot and hangs while decompressing. Kernels compiled with gcc-4.7
works perfectly fine.
I've uploaded both kernels
According to this bugzilla entry, the issue is how
ATOMIC_INT_LOCK_FREE is computed, which is not the same as the for
the __atomic_always_lock_free builtin (I checked on armv5 the builtin
is true for int whereas the macro value is 1). There is a proposed
patch, but it still has some issues... ha
On 3 December 2013 01:19, Nicolas Pitre wrote:
> On Mon, 2 Dec 2013, Riku Voipio wrote:
>
>> Hi,
>>
>> According the debian bug report [1], it is not possible to use std::future
>> on armv5 targetting toolchains. This is because libstdc++ will only enable
>> std::future if ATOMIC_INT_LOCK_FREE > 1
On Sun, 2013-12-01 at 18:24 +0200, Eugene V. Lyubimkin wrote:
> 2013-11-16 15:05, Eugene V. Lyubimkin:
> > For some reason, on armel architecture exclusively [1], g++ has problems
> > compiling seemingly any program which uses std::future [2].
>
> std::future is actually defined in libstdc++'s hea
On Mon, Dec 02, 2013 at 01:14:17PM +0100, Matthias Klose wrote:
> Afaics, the situation didn't change. There is nobody committing to work on the
> toolchain for these architectures. At least for release architectures the
> alternative is to drop the port unless somebody wants to maintain the
> to
10 matches
Mail list logo
