From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 91289 invoked by alias); 5 Sep 2017 10:24:38 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 81943 invoked by uid 89); 5 Sep 2017 10:24:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-25.0 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,KAM_ASCII_DIVIDERS,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: EUR03-AM5-obe.outbound.protection.outlook.com Received: from mail-eopbgr30068.outbound.protection.outlook.com (HELO EUR03-AM5-obe.outbound.protection.outlook.com) (40.107.3.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 05 Sep 2017 10:24:24 +0000 Received: from DB6PR0802MB2309.eurprd08.prod.outlook.com (10.172.228.13) by DB6PR0802MB2184.eurprd08.prod.outlook.com (10.172.227.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.10; Tue, 5 Sep 2017 10:24:16 +0000 Received: from DB6PR0802MB2309.eurprd08.prod.outlook.com ([fe80::9894:78af:87e4:9ded]) by DB6PR0802MB2309.eurprd08.prod.outlook.com ([fe80::9894:78af:87e4:9ded%17]) with mapi id 15.20.0013.018; Tue, 5 Sep 2017 10:24:16 +0000 From: Tamar Christina To: Richard Biener , Andrew Pinski CC: Andreas Schwab , Jon Beniston , "gcc-patches@gcc.gnu.org" , nd Subject: RE: [RFC, vectorizer] Allow single element vector types for vector reduction operations Date: Tue, 05 Sep 2017 10:24:00 -0000 Message-ID: References: <015b01d31f6b$c3651620$4a2f4260$@beniston.com> <000001d31fd7$b239abb0$16ad0310$@beniston.com> <004501d3217d$119d81c0$34d88540$@beniston.com> <00ba01d321a2$3fd81260$bf883720$@beniston.com> <874lskiwz6.fsf@linux-m68k.org> In-Reply-To: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Tamar.Christina@arm.com; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;DB6PR0802MB2184;6:dlNBuxaY4m9v80d2Q5Ls84JbS+FXCZ4fIKNwmhN8n1qjt6G04EUX0aZSjzXG0gKyQZSv44OGRSjDegnQyI4igl7OMu18gLOsokgOzqKn+yan+pvB48loLXBNYB1f2Skg/f/OPdcew/C3JqtUiIH0wmYIY3xQRFtOQ5lce0y4VdnH9DcgrVFX1+rJCIVoVqUl/0AY6HJnyb6UY50SmLiwAaKpuQGImdxjpb7v3Z7FU1PNdlANEdIv7kKspuDVC2/sIYECXh9N/353OgQNSSw8esfv1ganu3moaSEwFDLE5CLFHDBU8SqjosyIm8PzJdV03k99kBgHLVZpKNGmNQb25w==;5:f4kZOe/mfe5M8KqYYWkGZl3w0gxxc8gMtoMr9ckIMv3zX21hiRTgQSbXB2/bhOFeouwIlzzJcgekdHhqbpc+DcY2X4idSxNUeNidxrEf7zuBzA/o5gB0H1zXGhVBtD80AFXDLnJYIvDs1H5VVUaI9Q==;24:2MgxELxXTXY4h27xFjkA+IzrbUZQZKGg13GuCmLc5O5HOg59bTPeOT17MshYw8Aygqhci8Q9H9Jh6NDjRmRQzcWay5cquxkEjsUWmAiPlDU=;7:kgVoNPkbLFdLd4NY5kwP7thl/PYqmk0gczLWPQBqECzwaAdKbgAMAD0ZNVwkOsidTr30+qa83ttkyMCfFPhIdp5bTA1+eXxW7OXB9fDN9KVngawCqRD8R0FjZ3OZDPoA1AQ2qM+5X9dePx+uc4qQ2bAvC23+BrFFwfHbjG8dWThZeHz9MjxQE6vpPLfGjVFW5xY+CSacAia69PeNfOcpSyMHQ0v+kjv8+i+es5wq3Ms= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ab0602b6-6bc6-40ad-ecd8-08d4f44842b5 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095);SRVR:DB6PR0802MB2184; x-ms-traffictypediagnostic: DB6PR0802MB2184: nodisclaimer: True x-exchange-antispam-report-test: UriScan:(180628864354917)(22074186197030)(183786458502308)(17755550239193); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123560025)(20161123562025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:DB6PR0802MB2184;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:DB6PR0802MB2184; x-forefront-prvs: 0421BF7135 x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(6009001)(39860400002)(199003)(24454002)(377424004)(377454003)(51914003)(189002)(13464003)(2950100002)(7696004)(81166006)(14454004)(105586002)(106356001)(66066001)(8676002)(8936002)(229853002)(305945005)(54356999)(53546010)(76176999)(81156014)(101416001)(50986999)(72206003)(2900100001)(6436002)(68736007)(478600001)(53936002)(5250100002)(6246003)(102836003)(3846002)(6116002)(189998001)(3280700002)(5660300001)(74316002)(25786009)(86362001)(33656002)(55016002)(575784001)(4326008)(54906002)(97736004)(2906002)(3660700001)(7736002)(99286003)(9686003)(39060400002)(93886005)(6506006)(53946003);DIR:OUT;SFP:1101;SCL:1;SRVR:DB6PR0802MB2184;H:DB6PR0802MB2309.eurprd08.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Sep 2017 10:24:15.8874 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0802MB2184 X-IsSubscribed: yes X-SW-Source: 2017-09/txt/msg00238.txt.bz2 Hi Richard, That was an really interesting analysis, thanks for the details! Would you be submitting the patch you proposed at the end as a fix? Thanks, Tamar > -----Original Message----- > From: Richard Biener [mailto:rguenther@suse.de] > Sent: 05 September 2017 10:38 > To: Andrew Pinski > Cc: Tamar Christina; Andreas Schwab; Jon Beniston; gcc- > patches@gcc.gnu.org; nd > Subject: Re: [RFC, vectorizer] Allow single element vector types for vect= or > reduction operations >=20 > On Mon, 4 Sep 2017, Andrew Pinski wrote: >=20 > > On Mon, Sep 4, 2017 at 7:28 AM, Tamar Christina > wrote: > > >> > vect__5.25_58 =3D VIEW_CONVERT_EXPR > >> intD.11>(vect__4.21_65); > > >> > vect__5.25_57 =3D VIEW_CONVERT_EXPR > >> intD.11>(vect__4.22_63); > > >> > vect__5.25_56 =3D VIEW_CONVERT_EXPR > >> intD.11>(vect__4.23_61); > > >> > vect__5.25_55 =3D VIEW_CONVERT_EXPR > >> > intD.11>(vect__4.24_59); > > >> > > > >> > I suspect this patch will be quite bad for us performance wise as > > >> > it thinks it's as cheap to do all our integer operations on the > > >> > vector side with > > >> vectors of 1 element. But I'm still waiting for the perf numbers to > confirm. > > >> > > >> Looks like the backend advertises that it can do POPCOUNT on V1DI. > > >> So SLP vectorization decides it can vectorize this without unrolling. > > > > > > We don't, POPCOUNT is only defined for vector modes V8QI and V16QI, > > > we also don't define support For V1DI anywhere in the backend, we do > > > however say we support V1DF, but removing That doesn't cause the ICE > to go away. > > > > > >> Vectorization with V2DI is rejected: > > >> > > >> /tmp/trunk/gcc/testsuite/gcc.dg/vect/pr68577.c:18:3: note: function > > >> is not vectorizable. > > >> /tmp/trunk/gcc/testsuite/gcc.dg/vect/pr68577.c:18:3: note: not > vectorized: > > >> relevant stmt not supported: _8 =3D __builtin_popcountl (_5); ... > > >> /tmp/trunk/gcc/testsuite/gcc.dg/vect/pr68577.c:18:3: note: ***** > > >> Re-trying analysis with vector size 8 > > >> > > >> and that now succeeds (it probably didn't succeed before the patch). > > > > > > In the .optimized file, I see it vectorised it to > > > > > > vect__5.25_58 =3D VIEW_CONVERT_EXPR intD.11>(vect__4.21_65); > > > vect__5.25_57 =3D VIEW_CONVERT_EXPR intD.11>(vect__4.22_63); > > > vect__5.25_56 =3D VIEW_CONVERT_EXPR intD.11>(vect__4.23_61); > > > vect__5.25_55 =3D VIEW_CONVERT_EXPR intD.11>(vect__4.24_59); > > > _54 =3D POPCOUNT (vect__5.25_58); > > > _53 =3D POPCOUNT (vect__5.25_57); > > > > > > Which is something we just don't have a pattern for. Before this patc= h, it > was rejecting "long unsigned int" > > > With this patch is somehow thinks we support an integer vector of 1 > > > element, even though 1) we don't have an optab Defined for this > operation for POPCOUNT (or at all in aarch64 as far as I can tell), and 2= ) we > don't have it in our supported list of vector modes. > > > > Here are the two popcount optab aarch64 has: > > (define_mode_iterator GPI [SI DI]) > > (define_expand "popcount2" > > [(match_operand:GPI 0 "register_operand") > > (match_operand:GPI 1 "register_operand")] > > > > > > (define_insn "popcount2" > > (define_mode_iterator VB [V8QI V16QI]) > > [(set (match_operand:VB 0 "register_operand" "=3Dw") > > (popcount:VB (match_operand:VB 1 "register_operand" "w")))] > > > > As you can see we only define popcount optab for SI, DI, V8QI and > > V16QI. (note SI and DI uses the V8QI and V16QI during the expansion > > but that is a different story). > > > > Maybe somehow the vectorizer is thinking V1DI and DI are > > interchangeable in some places. >=20 > We ask >=20 > Breakpoint 5, vectorizable_internal_function > (cfn=3DCFN_BUILT_IN_POPCOUNTL, > fndecl=3D, > vectype_out=3D, > vectype_in=3D) > at /tmp/trunk/gcc/tree-vect-stmts.c:1666 > 1666 if (internal_fn_p (cfn)) > (gdb) p debug_generic_expr (vectype_out) > vector(2) int > $10 =3D void > (gdb) p debug_generic_expr (vectype_in) > vector(1) long unsigned int > $11 =3D void > (gdb) fin > Run till exit from #0 vectorizable_internal_function ( > cfn=3DCFN_BUILT_IN_POPCOUNTL, > fndecl=3D, > vectype_out=3D, > vectype_in=3D) > at /tmp/trunk/gcc/tree-vect-stmts.c:1666 > 0x0000000001206afc in vectorizable_call (gs=3D, > gsi=3D0x0, vec_stmt=3D0x0, slp_node=3D0x2451290) > at /tmp/trunk/gcc/tree-vect-stmts.c:2762 > 2762 ifn =3D vectorizable_internal_function (cfn, callee, > vectype_out, > Value returned is $12 =3D IFN_POPCOUNT >=20 > so somehow direct_internal_fn_supported_p says true for a POPCOUNTL > V1DI -> V2SI. I'd argue the question is odd already but the ultimative a= nswer > is cleary wrong ;) >=20 > We have >=20 > (gdb) p info > $22 =3D (const direct_internal_fn_info &) @0x19b8e0c: {type0 =3D 0, type1= =3D 0, > vectorizable =3D 1} >=20 > so require vectype_in as vectype_out which means we ask for V1DI -> V1DI > (and the vectorizer compensates for the demotion). But the mode of V1DI = is > actually DI (because the target doesn't support V1DI). > Thus we end up with asking for popcount with DImode which is available. >=20 > Note that this V1DI vector type having DImode is desirable for Jons case = as > far as I understand. DImode gets used because aarch64 advertises generic > vectorization support with word_mode. >=20 > Things may get tricky later when we look for VEC_PACK_TRUNC of V1DI, > V1DI -> V2SI but the vec_pack_trunc_optab advertises DImode support via > the VDN iterator (maybe expecting this only in case no V2SI support is > available). >=20 > So in the end the vectorizer works as expected ;) >=20 > What we don't seem to handle is a single-element vector typed, DImode > constructor with a single DImode element. >=20 > We call store_bit_field with fieldmode DI but a value with V2SI, I guess = things > go downhill from there. The SSA exp we store was DImode. Ah. >=20 > type size > unit-size > align:64 warn_if_not_align:0 symtab:0 alias-set 3 canonical-type > 0x7ffff68a07e0 precision:64 min max > > pointer_to_this > > visited > def_stmt _62 =3D VEC_PACK_TRUNC_EXPR <_67, _64>; >=20 > I suppose _that_'s already somewhat bogus. vector lowering creates it for > some reason: >=20 > - vect__8.26_52 =3D VEC_PACK_TRUNC_EXPR <_54, _53>; > + _67 =3D BIT_FIELD_REF <_54, 64, 0>; > + _64 =3D BIT_FIELD_REF <_53, 64, 0>; > + _62 =3D VEC_PACK_TRUNC_EXPR <_67, _64>; > + _60 =3D {_62}; > + _48 =3D VIEW_CONVERT_EXPR(_60); > + vect__8.26_52 =3D _48; >=20 > which happens because >=20 > static tree > get_compute_type (enum tree_code code, optab op, tree type) { > /* For very wide vectors, try using a smaller vector mode. */ > tree compute_type =3D type; > if (op > && (!VECTOR_MODE_P (TYPE_MODE (type)) > || optab_handler (op, TYPE_MODE (type)) =3D=3D CODE_FOR_nothing= )) >=20 > and/or >=20 > if (compute_type =3D=3D NULL_TREE) > compute_type =3D get_compute_type (code, op, type); > if (compute_type =3D=3D type) > return; >=20 > note that lowering sth like VEC_PACK_TRUNC_EXPR into scalars is pointless= - > at least in the way the lowering code does. >=20 > Index: gcc/tree-vect-generic.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D > --- gcc/tree-vect-generic.c (revision 251642) > +++ gcc/tree-vect-generic.c (working copy) > @@ -1439,7 +1439,7 @@ get_compute_type (enum tree_code code, o > /* For very wide vectors, try using a smaller vector mode. */ > tree compute_type =3D type; > if (op > - && (!VECTOR_MODE_P (TYPE_MODE (type)) > + && (TYPE_MODE (type) =3D=3D BLKmode > || optab_handler (op, TYPE_MODE (type)) =3D=3D CODE_FOR_nothing)) > { > tree vector_compute_type > @@ -1459,7 +1459,7 @@ get_compute_type (enum tree_code code, o > if (compute_type =3D=3D type) > { > machine_mode compute_mode =3D TYPE_MODE (compute_type); > - if (VECTOR_MODE_P (compute_mode)) > + if (compute_mode !=3D BLKmode) > { > if (op && optab_handler (op, compute_mode) !=3D > CODE_FOR_nothing) > return compute_type; >=20 > fixes this and we pass the testcase again. Note we vectorize that way ev= en > with the cost model enabled so it might show us that the cost model fails= to > account for some costs: >=20 > /tmp/trunk/gcc/testsuite/gcc.dg/vect/pr68577.c:18:3: note: Cost model > analysis: > Vector inside of loop cost: 8 > Vector prologue cost: 2 > Vector epilogue cost: 0 > Scalar iteration cost: 16 > Scalar outside cost: 0 > Vector outside cost: 2 > prologue iterations: 0 > epilogue iterations: 0 > Calculated minimum iters for profitability: 1 >=20 > SLP costing seems to fail to account for promotion/demotion costs it seems > accounting for that still doesn't push it over the edge. >=20 > Richard. >=20 > > Thanks, > > Andrew > > > > > > > > > > So I don't quite understand how we end up with this expression. > > > > > > Regards, > > > Tamar > > > > > >> > > >> Richard. > > >> > > >> > ________________________________________ > > >> > From: gcc-patches-owner@gcc.gnu.org > > >> > > > >> on > > >> > behalf of Andreas Schwab > > >> > Sent: Saturday, September 2, 2017 10:58 PM > > >> > To: Jon Beniston > > >> > Cc: 'Richard Biener'; gcc-patches@gcc.gnu.org > > >> > Subject: Re: [RFC, vectorizer] Allow single element vector types > > >> > for vector reduction operations > > >> > > > >> > On Aug 30 2017, "Jon Beniston" wrote: > > >> > > > >> > > gcc/ > > >> > > 2017-08-30 Jon Beniston > > >> > > Richard Biener > > >> > > > > >> > > diff --git a/gcc/tree-vect-patterns.c > > >> > > b/gcc/tree-vect-patterns.c index cfdb72c..5ebeac2 100644 > > >> > > --- a/gcc/tree-vect-patterns.c > > >> > > +++ b/gcc/tree-vect-patterns.c > > >> > > @@ -4150,7 +4150,7 @@ vect_pattern_recog_1 (vect_recog_func > > >> *recog_func, > > >> > > loop_vinfo =3D STMT_VINFO_LOOP_VINFO (stmt_info); > > >> > > > > >> > > if (VECTOR_BOOLEAN_TYPE_P (type_in) > > >> > > - || VECTOR_MODE_P (TYPE_MODE (type_in))) > > >> > > + || VECTOR_TYPE_P (type_in)) > > >> > > { > > >> > > /* No need to check target support (already checked by the > pattern > > >> > > recognition function). */ diff --git > > >> > > a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c index > > >> > > 013fb1f..fc62efb 100644 > > >> > > --- a/gcc/tree-vect-stmts.c > > >> > > +++ b/gcc/tree-vect-stmts.c > > >> > > @@ -9098,7 +9098,8 @@ get_vectype_for_scalar_type_and_size > > >> > > (tree scalar_type, unsigned size) > > >> > > else > > >> > > simd_mode =3D mode_for_vector (inner_mode, size / nbytes); > > >> > > nunits =3D GET_MODE_SIZE (simd_mode) / nbytes; > > >> > > - if (nunits <=3D 1) > > >> > > + /* NOTE: nunits =3D=3D 1 is allowed to support single element= vector > types. > > >> > > */ > > >> > > + if (nunits < 1) > > >> > > return NULL_TREE; > > >> > > > > >> > > vectype =3D build_vector_type (scalar_type, nunits); > > >> > > > > >> > > > > >> > > > > >> > > > >> > That breaks vect/pr68577.c on aarch64. > > >> > > > >> > during RTL pass: expand > > >> > /opt/gcc/gcc-20170902/gcc/testsuite/gcc.dg/vect/pr68577.c: In > > >> > function > > >> 'slp_test': > > >> > /opt/gcc/gcc-20170902/gcc/testsuite/gcc.dg/vect/pr68577.c:20:12: > > >> > internal compiler error: in simplify_subreg, at > > >> > simplify-rtx.c:6050 > > >> > 0xb55983 simplify_subreg(machine_mode, rtx_def*, machine_mode, > > >> unsigned int) > > >> > ../../gcc/simplify-rtx.c:6049 > > >> > 0xb595f7 simplify_gen_subreg(machine_mode, rtx_def*, > > >> > machine_mode, > > >> unsigned int) > > >> > ../../gcc/simplify-rtx.c:6278 > > >> > 0x81d277 store_bit_field_1 > > >> > ../../gcc/expmed.c:798 > > >> > 0x81d55f store_bit_field(rtx_def*, unsigned long, unsigned long, > > >> > unsigned > > >> long, unsigned long, machine_mode, rtx_def*, bool) > > >> > ../../gcc/expmed.c:1133 > > >> > 0x840bf7 store_field > > >> > ../../gcc/expr.c:6950 > > >> > 0x84792f store_constructor_field > > >> > ../../gcc/expr.c:6142 > > >> > 0x83edbf store_constructor > > >> > ../../gcc/expr.c:6726 > > >> > 0x840443 expand_constructor > > >> > ../../gcc/expr.c:8027 > > >> > 0x82d5bf expand_expr_real_1(tree_node*, rtx_def*, > machine_mode, > > >> expand_modifier, rtx_def**, bool) > > >> > ../../gcc/expr.c:10133 > > >> > 0x82eaeb expand_expr_real_1(tree_node*, rtx_def*, > machine_mode, > > >> expand_modifier, rtx_def**, bool) > > >> > ../../gcc/expr.c:9819 > > >> > 0x82dadf expand_expr_real_1(tree_node*, rtx_def*, > machine_mode, > > >> expand_modifier, rtx_def**, bool) > > >> > ../../gcc/expr.c:10942 > > >> > 0x82eaeb expand_expr_real_1(tree_node*, rtx_def*, > machine_mode, > > >> expand_modifier, rtx_def**, bool) > > >> > ../../gcc/expr.c:9819 > > >> > 0x83d197 expand_expr > > >> > ../../gcc/expr.h:276 > > >> > 0x83d197 expand_assignment(tree_node*, tree_node*, bool) > > >> > ../../gcc/expr.c:4971 > > >> > 0x71e2f3 expand_gimple_stmt_1 > > >> > ../../gcc/cfgexpand.c:3653 > > >> > 0x71e2f3 expand_gimple_stmt > > >> > ../../gcc/cfgexpand.c:3751 0x721cdb > > >> > expand_gimple_basic_block > > >> > ../../gcc/cfgexpand.c:5750 > > >> > 0x726b07 execute > > >> > ../../gcc/cfgexpand.c:6357 > > >> > > > >> > Andreas. > > >> > > > >> > -- > > >> > Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint =3D 58CA > > >> > 54C7 6D53 942B 1756 01D3 44D5 214B 8276 > > >> > 4ED5 "And now for something completely different." > > >> > > > >> > > > >> > > >> -- > > >> Richard Biener > > >> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham > > >> Norton, HRB 21284 (AG Nuernberg) > > > > >=20 > -- > Richard Biener > SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, > HRB 21284 (AG Nuernberg)