LAST_UPDATED: Sun Dec 17 13:48:04 UTC 2006 (revision 119985)
=== acats tests ===
FAIL: cdd2a02
FAIL: cxa5a08
FAIL: cxh1001
=== acats Summary ===
# of expected passes2312
# of unexpected failures3
Native configuration is i486-pc-linux-gnu
sorry, I did check in changes on the sid branch, which are not target
for etch. If we do want to make modifications for the etch target, we
should work on branches/etch instead.
Ludovic Brenta writes:
> I've got gcc-4.1-source (= 4.1.1-19) installed, and dpkg-buildpackage
> aborts when debian/patc
Processing commands for [EMAIL PROTECTED]:
> reassign 403596 gcc-snapshot
Bug#403596: FTBFS with GCC 4.2: ... discards qualifiers from pointer target type
Bug reassigned from package `colo' to `gcc-snapshot'.
> retitle 403596 optmization generates warning for casts
Bug#403596: FTBFS with GCC 4.2:
#
# bts-link upstream status pull for source package gcc-snapshot
# see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
#
user [EMAIL PROTECTED]
# remote status report for #381480
# * http://gcc.gnu.org/PR28624
# * remote status changed: UNCONFIRMED -> ASSIGNED
usertags 3814
I've got gcc-4.1-source (= 4.1.1-19) installed, and dpkg-buildpackage
aborts when debian/patches/gcc-long-double.dpatch fails to apply with:
patching file gcc/config/rs6000/linux.h
patching file gcc/config/rs6000/linux64.h
patching file gcc/configure.ac
Hunk #1 succeeded at 3130 (offset -5 lines).
--- Comment #10 from whaley at cs dot utsa dot edu 2006-12-19 17:18 ---
Guys,
In the interests of full disclosure, I did some quick timings on the Core2Duo,
and as I kind of suspected, scalar SSE crushed x87 there. I was pretty sure
scalar SSE could achieve 2 flop/cycle, while Intel ke
--- Comment #9 from whaley at cs dot utsa dot edu 2006-12-19 16:04 ---
Ian,
Thanks for the info. I see I failed to consider the cross-register moves you
mentioned. However, can't those be moved through memory, where something
destined for a 64-bit register is first written from the 80
--- Comment #8 from ian at airs dot com 2006-12-19 14:57 ---
I think I agree that if we spill an 80387 register to the stack, and then load
the value back into an 80387 register, that we should spill all 80 bits, rather
than implicitly converting to DFmode or SFmode.
This would unfortun
I figure out a few things about this bug. Either cstdlib is wrong or
the /usr/include/pthread.h from pthread-dev is wrong.
Both /usr/include/c++/4.1.2/cstdlib (line 99) and
/usr/include/c++/3.4/cstdlib (line 80) have the following macro:
#undef system
Whereas the header /usr/include/pthread.h t
9 matches
Mail list logo
