You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
1
(1) |
2
(13) |
3
(1) |
|
4
(1) |
5
(11) |
6
|
7
|
8
(3) |
9
(18) |
10
(7) |
|
11
(21) |
12
(26) |
13
(16) |
14
(17) |
15
(14) |
16
(6) |
17
(6) |
|
18
(17) |
19
(1) |
20
(16) |
21
(1) |
22
(2) |
23
(14) |
24
(7) |
|
25
(6) |
26
(3) |
27
(11) |
28
(9) |
29
(2) |
30
(7) |
31
(3) |
|
From: Florian K. <br...@ac...> - 2011-12-29 16:15:38
|
Here are my comments. Everything I say for s390 is based on chapter 20 of this document: http://publibfi.boulder.ibm.com/epubs/pdf/dz9zr008.pdf > Notation Description > > ------------------------------------------------------------------ > DFP: Decimal Floating Point number possibly 32-bit, 64-bit, or > 128-bit format > > D32: 32-bit decimal floating point format These values use F64 > registers. The D32 term is used to distinguish the value > from the standard 32-bit floating point value. > > D64: 64-bit decimal floating point format. These values use F64 > registers. The D64 term is used to distinguish the value > from the standard 64-bit floating point value. > > D128: 128-bit decimal floating point format. These values use a pair > of two 64 bit floating point registers (F64). The instruction > only references the first register of the register pair. The > second register is implied. > So we need three new IRTypes Ity_D32 Ity_D64 Ity_D128 as Julian suggested in his reply. > IRRoundingMode(I32): Indicates the I32 argument is used to hold the > bits that specify the rounding mode to be used > by the instruction. > IEEE Std 754-2008 says (4.3.3) that A decimal format implementation of this standard shall provide roundTiesToAway as a user-selectable rounding-direction attribute. with: roundTiesToAway, the floating-point number nearest to the infinitely precise result shall be delivered; if the two nearest floating-point numbers bracketing an unrepresentable infinitely precise result are equally near, the one with larger magnitude shall be delivered. We probably should extend IRRoundingMode accordingly. s930 DFP actually has 9 rounding modes According to FPC setting Round toward 0 Round away from 0 Round toward +inf Round toward -inf Round to nearest with ties away from 0 Round to nearest with ties to even Round to nearest with ties toward 0 Round to prepare for shorter precision We can handle the unsupported ones as we do for binary floating point and map them to Irrm_NEAREST until problems arise. > IRRoundingExceptionModes(I32): Indicates the I32 argument is used to hold the > bits that specify the rounding mode and the bits > that specify the exception mode to be used by > the instruction. The s390 instructions specify > both modes whereas POWER does not specify either > mode. > If we keep support for floating point exceptions at the current level, then these exception modes do not need to be modelled in the IR. I.e. in the following IRRoundingExceptionModes can be replaced with IRRoundingMode. > IRRoundingModeAndEponent(I32): Indicates the I32 argument will contain bits to > specify the rounding mode. POWER also has bits > to specify the desired exponent. The s390 > instructions only specify the rounding mode. > > This is similar to IRRoundingExceptionModes, i.e. replace with IRRoundingMode. > > ARITHMETIC INSTRUCTIONS > ----------------------- > IRRoundingMode(I32) X D64 X D64 -> D64 > Iop_AddD64, Iop_SubD64, Iop_MulD64, Iop_DivD64 > > IRRoundingMode(I32) X D128 X D128 -> D128 > Iop_AddD128, Iop_SubD128, Iop_MulD128, Iop_DivD128 > OK > > FORMAT CONVERSION INSTRUCTIONS > ------------------------------ > InvOperationModes(I32) x D32 -> D64 > Iop_D32toD64 > You did not describe InvOperationModes. But looking at insn LDETR (which is D32 -> D64 conversion) I gather that InvOperationModes controls whether or not the IEEE-invalid-operation-exception is delivered. It's essentially a Boolean value. I propose to ignore it and deliver the exception unconditionally (which is what we do for binary floating point). > IRRoundingExceptionModes(I32) x D64 -> D32 > Iop_RoundD64toD32 > > IRRoundingExceptionModes(I32) x D128 -> D64 > Iop_RoundD128toD64 > These two should be renamed to Iop_D64toD32 and Iop_D128toD64 for symmetry in naming with binary floating point ops. > IRRoundingExceptionModes(I32) x I64 -> D64 > Iop_I64StoD64 > OK. For s390 we also need: IROp description s390 insn Iop_I64StoD128 IRRoundingMode(I32) x signed I64 -> D128 CXGTR Iop_I32StoD64 signed I32 -> D64 CDFTR Iop_I32StoD128 signed I32 -> D128 CXFTR Iop_I64UtoD64 IRRoundingMode(I32) x unsigned I64 -> D64 CDLGTR Iop_I64UtoD128 IRRoundingMode(I32) x unsigned I64 -> D128 CXLGTR Iop_I32UtoD64 unsigned I32 -> D64 CDLFTR Iop_I32UtoD128 unsigned I32 -> D128 CXLFTR > IRRoundingExceptionModes(I32) x D64 -> I64 > Iop_D64toI64 > We need both: conversion to signed and unsigned int IROp description s390 insn Iop_D64toI64S IRRoundingMode(I32) x D64 -> signed I64 CGDTR(A) Iop_D128toI64S IRRoundingMode(I32) x D128 -> signed I64 CGXTR(A) Iop_D64toI32S IRRoundingMode(I32) x D64 -> signed I32 CFDTR Iop_D128toI32S IRRoundingMode(I32) x D128 -> signed I32 CFXTR Iop_D64toI64U IRRoundingMode(I32) x D64 -> unsigned I64 CLGDTR Iop_D128toI64U IRRoundingMode(I32) x D128 -> unsigned I64 CLGXTR Iop_D64toI32U IRRoundingMode(I32) x D64 -> unsigned I32 CLFDTR Iop_D128toI32U IRRoundingMode(I32) x D128 -> unsigned I32 CLFXTR Note, the new IRops for conversion to 32-bit wide results and from D128. > > ROUNDING INSTRUCTIONS > ----------------------- > IRRoundingMode(I32) x D64 -> D64 > Iop_RoundD64 > > IRRoundingMode(I32) x D128 -> D128 > Iop_RoundD128 > These should be named Iop_RoundD64toInt and Iop_RoundD128toInt for symmetry in naming with binary floating point ops. > > COMPARE INSTRUCTIONS > ----------------------- > D64 x D64 -> IRCmpF64Result(I32) > Iop_CmpD64 > > D128 x D128 -> IRCmpF64Result(I32) > Iop_CmpD128 > OK. I would use IRCmpD64Result and IRCmpD128Result. That allows us to use a different encoding, which may be desirable. > D64 x D64 -> 1 if the condition is TRUE, 0 otherwise > Iop_CmpEQD64, Iop_CmpLTD64, Iop_CmpGTD64 > These ops appear unused. > D128 x D128 -> 1 if the condition is TRUE; 0 otherwise; > Iop_CmpEQD128, Iop_CmpLTD128, Iop_CmpGTD128 > These are unused, too. > > QUANTIZE AND ROUND INSTRUCTIONS > ------------------------------- > EXTRACT AND INSERT INSTRUCTIONS > ------------------------------- Do we need to support these at all? In other words, does GCC issue these or do they show up in hand crafted assembler shipped with GCC/GLIBC? I don't know but will find out (for s390). > > FORMAT CONVERSION INSTRUCTIONS > Iop s390 Power Description of instruction, implementation > opcode opcode details > > --------------------------------------------------------------------- > TBD > PFPO > The PFPO instruction operation is [snip] To be done.... > COMPARE INSTRUCTIONS > > -------------------------------------------------------------------- > > Iop_CmpD64 D64 x D64 -> IRCmpF64Result(I32) > dcmpo > dcmpu > > Iop_CmpD128 D128 x D128 -> IRCmpF64Result(I32) > dcmpoq > dcmpuq > The s390 insns are CDTR and CXTR, respectively. The possible condition codes are: 0 Operands equal 1 First operand low 2 First operand high 3 Operands unordered which is what IRCmpF64Result provides. So we could reuse it: typedef IRCmpF64Result IRCmpD64Result; typedef IRCmpF128Result IRCmpD128Result; or choose a different encoding. > > QUANTIZE AND ROUND INSTRUCTIONS > ----------------------------------------------------------- > > Iop_QuantizeID64 IRRoundingModeAndEponent(I32) x D64 -> D64 > QADTR dquai > The D64 source operand is converted and rounded > to the form with the immediate exponent > specified by the rounding and exponent > parameter. > > Iop_QuantizeID128 IRRoundingModeAndExponent(I32) x D128-> D128 > QAXTR dquaiq > The D128 source operand is converted and > rounded to the form with the immediate exponent > specified by the rounding and exponent > parameter. > QADTR (QAXTR) have two D64 (D128) operands, a rounding mode and a D64 (D128) result (ignoring the quantum exception control): IRRoundingMode(I32) x D64 x D64 -> D64 Did you mix this up perhaps with Iop_QuantizeD64/D128? But as I said earlier, perhaps we don't need to support these. Cheers, Florian |
|
From: <sv...@va...> - 2011-12-29 08:29:35
|
Author: dirk
Date: 2011-12-29 08:24:55 +0000 (Thu, 29 Dec 2011)
New Revision: 12323
Log:
add support for glibc 2.15
Modified:
trunk/configure.in
Modified: trunk/configure.in
===================================================================
--- trunk/configure.in 2011-12-27 18:43:32 UTC (rev 12322)
+++ trunk/configure.in 2011-12-29 08:24:55 UTC (rev 12323)
@@ -778,6 +778,13 @@
DEFAULT_SUPP="glibc-2.34567-NPTL-helgrind.supp ${DEFAULT_SUPP}"
DEFAULT_SUPP="glibc-2.X-drd.supp ${DEFAULT_SUPP}"
;;
+ 2.15)
+ AC_MSG_RESULT(2.15 family)
+ AC_DEFINE([GLIBC_2_15], 1, [Define to 1 if you're using glibc 2.15.x])
+ DEFAULT_SUPP="glibc-2.X.supp ${DEFAULT_SUPP}"
+ DEFAULT_SUPP="glibc-2.34567-NPTL-helgrind.supp ${DEFAULT_SUPP}"
+ DEFAULT_SUPP="glibc-2.X-drd.supp ${DEFAULT_SUPP}"
+ ;;
darwin)
AC_MSG_RESULT(Darwin)
AC_DEFINE([DARWIN_LIBC], 1, [Define to 1 if you're using Darwin])
@@ -791,7 +798,7 @@
*)
AC_MSG_RESULT([unsupported version ${GLIBC_VERSION}])
- AC_MSG_ERROR([Valgrind requires glibc version 2.2 - 2.14])
+ AC_MSG_ERROR([Valgrind requires glibc version 2.2 - 2.15])
AC_MSG_ERROR([or Darwin libc])
;;
esac
|