From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id DC0283858D28 for ; Thu, 6 Apr 2023 13:15:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DC0283858D28 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=ibm.com Received: from pps.filterd (m0098420.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 336DCM2O016161; Thu, 6 Apr 2023 13:15:10 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=from : to : cc : date : message-id : references : in-reply-to : content-type : mime-version : subject; s=pp1; bh=2yzgTaHbtNx46cgjFkRoVoTB8Ki9xJEx2dVQ9/RTfIs=; b=O0n9INarIxxrHd1vhdNNnEvxJTCkWi43kDJuRXZv60JklJIj6yNgXOKK5Vhp7uLvdNVx kAUF5r+2w3+0/VQP1XIjZBGy2V5dlNA6ztiFT0cOg5vcnWGyX7dkPgKexSaj1negFN9i Cb5afd40JLW5DfE/TnGdhuueVxf/96141F/xiZ1XysQCTei7VbKQO1k4XtfsyQX0Ocyc aK/7hNSgNV05BFQRiaUfabp2z5lbZ79LgjoEFl5tSev3gSQSPDOuyCEPvF9FNUr99zp1 9JztwrWMoMykYfxtnzlf1xzCp8FrQjdZl1WWPVsqHWTSnP7edSeyCvSLJW+EBNqfAmi3 CQ== Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2104.outbound.protection.outlook.com [104.47.58.104]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3psajnux6c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 06 Apr 2023 13:15:09 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SG/aww9rsXhiAmS/E6aN0lnwQ0n7hCYBSjnx+XOn1WOElb2S9vacVwAno6ToqWjefSHJVzTr597S+ZfWfOy4dOxYELRHoZzdkiXDV/gjL4hwL3vH4s9kjX02xDP1uSP+DsYdymfOWb0xKbug4A0s098ScmNNJEL7d/y5fcAH8NnHpJvw+vZBaPycKxF8zxCC7tWa+asJ96f7cceUw+c6epime+BTaBL+64k70YUs3YY7gwHIHH6ZscGuWTwQfcbDZjwzK3UG9Wql//a+JnK86TgYj8GNF6MXzaMOc2ZQ0og2F608J0NpPETLBPegAqgo99ot0tizZnN08WKmPs1jCQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=2yzgTaHbtNx46cgjFkRoVoTB8Ki9xJEx2dVQ9/RTfIs=; b=Lqml97mmsiZzU7pFweSTpNPisewKI7Ht9t19l31D8xZpvld5jjvd9eGOlDOPdO/fD45JgL2H0boUx2szEHixDDEk5d/9er9945XnNcOvC+Ei/Fy8Bn14hsnQjI0aEcsYYGBijlh9KZFQIGsKeJGPRQiAzQA7oY2c8UfV42ev6PVffaoyj0G/3ChTauQMAJO2bUYqALYzEtISpARX2hY2onNKndPiymvxHV+B/c14w6Vrec82iz5WhT//GmiKsirE62TTU1o6b6m55zjQhfjEigxQAORApUmtELyhC8b87QPmVjLeSmiTD2+xdF1O682Fo8baoMMq9T8K1zddnkHKgQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ibm.com; dmarc=pass action=none header.from=ibm.com; dkim=pass header.d=ibm.com; arc=none Received: from CH2PR15MB3544.namprd15.prod.outlook.com (2603:10b6:610:5::26) by MW4PR15MB4652.namprd15.prod.outlook.com (2603:10b6:303:10d::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6254.35; Thu, 6 Apr 2023 13:15:07 +0000 Received: from CH2PR15MB3544.namprd15.prod.outlook.com ([fe80::fc4b:b8cb:1472:d50a]) by CH2PR15MB3544.namprd15.prod.outlook.com ([fe80::fc4b:b8cb:1472:d50a%6]) with mapi id 15.20.6254.035; Thu, 6 Apr 2023 13:15:07 +0000 From: Aditya Kamath1 To: Pedro Alves , Ulrich Weigand , "gdb-patches@sourceware.org" , "tom@tromey.com" CC: Sangamesh Mallayya , "simon.marchi@efficios.com" Thread-Topic: [EXTERNAL] Re: [PATCH] Modify align-c/align-c++ test case for AIX Thread-Index: AQHZXAEQQ9maDMU2LkakAv3jr+hZe68Rm2+FgAAzigCAAww/+YAIJXWAgAFOjVs= Date: Thu, 6 Apr 2023 13:15:07 +0000 Message-ID: References: <87edpwmzpz.fsf@tromey.com> <3636157c35660e96f2da98eb70cbac597d0a092c.camel@de.ibm.com> <87r0tqchea.fsf@tromey.com> <87zg8bave2.fsf@tromey.com> <61289f79c8c08ebe15112711954e1b05d49c92be.camel@de.ibm.com> <877cvagpeh.fsf@tromey.com> <82c24017291c399d58fc87d7ae7fc1b17c665295.camel@de.ibm.com> <488d8a7c-1144-c78e-7ba7-e9be3db6c19a@palves.net> In-Reply-To: <488d8a7c-1144-c78e-7ba7-e9be3db6c19a@palves.net> Accept-Language: en-IN, en-US Content-Language: en-IN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: CH2PR15MB3544:EE_|MW4PR15MB4652:EE_ x-ms-office365-filtering-correlation-id: 2d41e6f9-dfe9-46b7-99e3-08db36a0f126 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: kFFwcq2AHlFCkQCdwBgcEwep+SeSSybguWchZB29xDzbgsxpl0fBQBGFMbCWyGu9/EJVOm4NnGPiIJstyShTNQ8lzbHnuv/msXcGX0sRDnbk/1QRp36ybUdAQgb8HH+de5efH4vZVVwaLK5gPtkRPycSV+83rQOwkUbFTCzl1G3bJ5eWYV4dRXOPOhbOLGwu0bqNRO0MAH/XqAmkfCdJNtOiP6FFyacQjJiysoTXbgIMVOcWyrYREtTJ+FQUuDVwtEsSOpz4iipoZLrRcDcstI54j1NgKRZFTfcWgw91qppP2idF+/Te2oVkoRlYj6rYl20v2mM7QDr3liqNl6bEMasBdQm+Ow257Euwoc+Tu6OoJlOWXWTbTzcKeOJeGAlVZTDIn2TYnzTPhQx7FXQzEFrUXih8Nv+u1g7sf+srXv+mg/7N2xG26BK+6tku3mwT/FnV8g+kqnbFOyOnznfxRryUc2EhxIkLvFQo4xPkGPzP8QglWN5dB3AxZdKYiHiNd8P5bEfSjgwDx/D2yROrslZQn0P6jtgDOp4JWnhCbgvaR3de3NW9nPPa4SeMqFNTshbObyBai/tp5Ll/chTbE8SFeV7kRehsHR/qkyNuoOI= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH2PR15MB3544.namprd15.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230028)(346002)(136003)(376002)(396003)(366004)(39860400002)(451199021)(66446008)(84970400001)(186003)(8936002)(55016003)(53546011)(2906002)(5660300002)(33656002)(86362001)(30864003)(83380400001)(38070700005)(316002)(76116006)(52536014)(4326008)(91956017)(6506007)(110136005)(54906003)(41300700001)(9686003)(8676002)(122000001)(66946007)(478600001)(7696005)(64756008)(71200400001)(66556008)(66476007)(38100700002);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?nTvUxhgA/VaLSvxBMGnhYibQKUrvSI2QA9zNf/DNEFl8bP+xQnM2inVAYFFI?= =?us-ascii?Q?Rxyia0XSxV5cgCJr8OdeshAXBp3g8qbRjaPh2ZlCGs9rdIQ7eabHWKKy0zXW?= =?us-ascii?Q?Vyo7ZCPuLXY/iZttPAumMtj3/vJpZuX+mqPscsM/S1hzkW3Pg9CnVyToOKbU?= =?us-ascii?Q?LRzNmoDcr7o6iErI2Bjf4EVwbCU2zu+6luVTfL1dd9S/WY7gasbRoRfm4D0d?= =?us-ascii?Q?WNsnwGSljAC1tfFxslez87iYqh6I0Dyy+z1zDsDhtRstfv2dQcam/JrwUQiC?= =?us-ascii?Q?DAVIPVxH74aq6WZTckz/SmzSFrgtmGuzTRRfdSXqeCXgGavF0TzreERT1fK3?= =?us-ascii?Q?goBSAD8sJrqP5waMy8WAez2WODgOBuaufdrCN6KhLHqLB8QEKJyIdn2Sc6km?= =?us-ascii?Q?jTaXILVlGhpO/Pxuk+cACb7HpZxE/vcvE/W1lWePvtW8DmEtFNexO1g/txAw?= =?us-ascii?Q?VAmADAqeSDDy7xCgg/NxaywpLn/X9pLvaB1r8Pfr/KZB7enCp+7R5r8tGB1N?= =?us-ascii?Q?2QeZFjV2TME+b5KHHKPexaFY2Jac5D8exck1kYLD090QC6cxGIxZIGTYSIzs?= =?us-ascii?Q?u4MnWKKEDq/8FWsGCA4DCDl6j8XGZ5oyHyfyWp8MVv6gTwfHzYJY/JpzCFBA?= =?us-ascii?Q?tdmFGGkKzru0kidR4de0jjUJ3CvXAykOztJnXcUFHjvLuwVUyfAyP9bT3SCt?= =?us-ascii?Q?FlGtqjC7WoLL8H60ahVPCn7LIT+rOdkyIQpNa4Gp6N8Vk/kw3JdLmigOXm5T?= =?us-ascii?Q?Dx6JG9LWJli0gklaVZ7/6WeeWXRmnBb4QdpWjWbX9Cf+iWiRNB+c54z7QCeE?= =?us-ascii?Q?HbT+k7Pa6644A22Led3cWXUE3z887Pc0mq/LEWY50jorVVoZDddwE9FNp86M?= =?us-ascii?Q?y2lMg5WueljXQuWeEOIO/ny2HOYWu9Phe8i+6ZTgJczRarH9uVG/RH3Na8kX?= =?us-ascii?Q?Fi1kILsjlxSdoil4IeAsHCbyjLZDiQdAFY6N8+9HWWBnr158cKoOG/LjxE/A?= =?us-ascii?Q?O9d4JVWzb9dThaiTdpsu44M6ZTPHKw1xbutcHV6kpqhbQQh47yenpbbfSjP6?= =?us-ascii?Q?ji6aE1sfLcaB64JDglEsDlAallJeuIhYmBipN5nihnfAaYFXCcGeFqudiR1E?= =?us-ascii?Q?MvBgQlR67d7ogrDbL8hNZLY6KuaocePbRAM8AwhVHpYQAzoDN2W7f6/HIObV?= =?us-ascii?Q?ng0jroJCC9knIGiyGFMBEml8upg8l4sZe02j7DD8cFdpS33GwZHIEX8k6V0r?= =?us-ascii?Q?q0Nrh2pvZ6fD8WNy9XQOcxH07/5sOhqn8bvyIojGgCqtD5Yk6kCrDahC3XQq?= =?us-ascii?Q?wl/qokkEb0hLC4u5mkJnyw9htWlHVHxiBPSbeTv3gK0Ml5FV5J7gAr4Ku/FQ?= =?us-ascii?Q?5O4X6YNUnYhZTvtErHbxGFMesS3EMk7wtX+0wqqAGi21UzG1+wWGN+lLQpcj?= =?us-ascii?Q?1pymtyUQ/7h7+3upwAmXw/ldGTt5VhZr40vuLvzn9Ud3sVWZW0UIblIkluuJ?= =?us-ascii?Q?8u1sOpUOsvDN2Y57F6g4Yiz49jV7rD907dd+l3r8ZmY6Sm+zfIMY9NjzkeaE?= =?us-ascii?Q?EMb2zFU4Kx/f5tXephcHfkXxXzZLCKhcht6rn3Gk2I0gyPrey9HN/vPG2bZM?= =?us-ascii?Q?D7lWGNljVcFycJ7V/LbddkJEsOAasIh2AIOXDNhDUY6JEveSY+m6zHvJTHKt?= =?us-ascii?Q?p1/irA=3D=3D?= Content-Type: multipart/alternative; boundary="_000_CH2PR15MB3544E623998D23053A2F649ED6919CH2PR15MB3544namp_" MIME-Version: 1.0 X-OriginatorOrg: ibm.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH2PR15MB3544.namprd15.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2d41e6f9-dfe9-46b7-99e3-08db36a0f126 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2023 13:15:07.1084 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fcf67057-50c9-4ad4-98f3-ffca64add9e9 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: KWHzeE/YlZjuhJPmCkZAUj/+Zy1LdrLFAuZlkcUZWeGXiJDQugaNHYEJQ4SDQuwrbesRJwbtd1yyHOjcHWKlvw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR15MB4652 X-Proofpoint-ORIG-GUID: sC_qSfPBH2QGO1KARUJaMDQoY8S6SIOq X-Proofpoint-GUID: sC_qSfPBH2QGO1KARUJaMDQoY8S6SIOq Subject: RE: [PATCH] Modify align-c/align-c++ test case for AIX X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.942,Hydra:6.0.573,FMLib:17.11.170.22 definitions=2023-04-06_06,2023-04-06_03,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 impostorscore=0 adultscore=0 malwarescore=0 mlxscore=0 suspectscore=0 priorityscore=1501 mlxlogscore=999 lowpriorityscore=0 phishscore=0 spamscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2303200000 definitions=main-2304060115 X-Spam-Status: No, score=-8.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,HTML_MESSAGE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --_000_CH2PR15MB3544E623998D23053A2F649ED6919CH2PR15MB3544namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Pedro, Ulrich, Tom and community, I actually made a mistake while I was experimenting. I copied this line in = two places resulting in this hunk by mistake which was not required. That i= s why I saw the error of initialising a non-static member. I apologise for = the same. @@ -87,6 +87,7 @@ puts $outfile "DEF ($utype, $uinner);" set joined "${utype}_x_${uinner}" puts $outfile "struct align_pair_$joined item_${joined};" + puts $outfile "$utype align_pair_${joined}::one =3D 0;" puts $outfile "unsigned a_${joined}" puts $outfile " =3D ${align_func} (struct align_pair_${joined}= );" So AIX numbers are here:- gdb.base/align-c++ =3D Passes =3D 1134 gdb.base/align-c =3D Passes =3D 406 gdb.base/align =3D Passes =3D 1802 I am okay with the patch with change ID =3D I874b717afde7b6fb1e45e526912b51= 8a20a12716 pasted to me on the 29th of March. It is the same in AIX as well= . Kindly commit the same. Only one more problem Pedro, Tom and Ulrich.. Consider the code below.. #include using namespace std; #define DEF(T,U) struct align_pair_ ## T ## _x_ ## U { T one; U two; } DEF (char, double); struct align_pair_char_x_double item_char_x_double; int main (){ int x =3D alignof (struct align_pair_char_x_double); printf ("%d \n", x); return 0; } The output of this in linux is 8. But in AIX is 4. Though the size is 8 for= double, alignment is 4. bash-5.1$ ~/gdb_tests/align 4 So we have failures in all test cases involving double data type in AIX. Using /home/aditya/latest_gdb/binutils-gdb/gdb/testsuite/config/unix.exp as= tool-and-target-specific interface file. Running /home/aditya/latest_gdb/binutils-gdb/gdb/testsuite/gdb.base/align-c= .exp ... FAIL: gdb.base/align-c.exp: print _Alignof(struct align_pair_char_x_double) FAIL: gdb.base/align-c.exp: print _Alignof(struct align_pair_char_x_long_do= uble) FAIL: gdb.base/align-c.exp: print _Alignof(struct align_pair_unsigned_char_= x_double) FAIL: gdb.base/align-c.exp: print _Alignof(struct align_pair_unsigned_char_= x_long_double) FAIL: gdb.base/align-c.exp: print _Alignof(struct align_pair_short_x_double) FAIL: gdb.base/align-c.exp: print _Alignof(struct align_pair_short_x_long_d= ouble) FAIL: gdb.base/align-c.exp: print _Alignof(struct align_pair_unsigned_short= _x_double) FAIL: gdb.base/align-c.exp: print _Alignof(struct align_pair_unsigned_short= _x_long_double) FAIL: gdb.base/align-c.exp: print _Alignof(struct align_pair_int_x_double) FAIL: gdb.base/align-c.exp: print _Alignof(struct align_pair_int_x_long_dou= ble) FAIL: gdb.base/align-c.exp: print _Alignof(struct align_pair_unsigned_int_x= _double) FAIL: gdb.base/align-c.exp: print _Alignof(struct align_pair_unsigned_int_x= _long_double) FAIL: gdb.base/align-c.exp: print _Alignof(struct align_pair_float_x_double) FAIL: gdb.base/align-c.exp: print _Alignof(struct align_pair_float_x_long_d= ouble) FAIL: gdb.base/align-c.exp: print _Alignof(double) FAIL: gdb.base/align-c.exp: print _Alignof(long double) =3D=3D=3D gdb Summary =3D=3D=3D # of expected passes 406 # of unexpected failures 16 /home/aditya/latest_gdb/binutils-gdb/gdb/gdb version 14.0.50.20230327-git = -nw -nx -iex "set height 0" -iex "set width 0" -data-directory /home/aditya= /latest_gdb/binutils-gdb/gdb/data-directory Number of failures:- gdb.base/align-c++ =3D 42 gdb.base/align-c =3D 16 gdb.cp/align =3D 50 Can we discuss this in the same thread or you want me to handle it in a dif= ferent thread email??Let me know. Have a nice day ahead. Thanks and regards, Aditya. From: Pedro Alves Date: Wednesday, 5 April 2023 at 10:03 PM To: Aditya Kamath1 , Ulrich Weigand , gdb-patches@sourceware.org , tom@= tromey.com Cc: Sangamesh Mallayya , simon.marchi@efficios.= com Subject: [EXTERNAL] Re: [PATCH] Modify align-c/align-c++ test case for AIX On 2023-03-31 1:29 p.m., Aditya Kamath1 wrote: > Hi Pedro, Ulrich, Tom and community members, > > Thank you for your feedback. Please find attached the patch. {See: 0001-M= odify-align-c-align-c-test-case-for-AIX.patch} > >>Like below. Does this work for AIX? > > Hi Pedro and Respected community members. Kindly allow me to disagree wit= h you all for the patch diff that was pasted in the previous email reply th= read. > > Consider a smaller piece of the test case pasted > #include > > using namespace std; > > struct align_pair_char_x_char {char one; char two;}; > > struct align_pair_char_x_char item_char_x_char; > > *char align_pair_char_x_char::one =3D 0;* > > unsigned a_char_x_char > > =3D alignof (struct align_pair_char_x_char); > > int main() { > > printf ("%d \n", a_char_x_char); > > } > > So the line highlighted in bold is a problem. This line is also there in = the patch diff that was pasted in the previous email reply thread. This is= not allowed. We are trying to access something we should not. In case we w= ant to initialise any data member, we need to do it via a constructor. I'm super confused. I don't get a line like the one you highlighted in the= generated code at all. > > In AIX, I can see 'char align_pair_char_x_unsigned_char::one' is not a st= atic data member of 'struct align_pair_char_x_unsigned_char' error How did you get that line in the generated code after my patch? Note the patch has: > diff --git a/gdb/testsuite/gdb.base/align.exp.tcl b/gdb/testsuite/gdb.bas= e/align.exp.tcl > index 6a75a14d887..550afe1c47d 100644 > --- a/gdb/testsuite/gdb.base/align.exp.tcl > +++ b/gdb/testsuite/gdb.base/align.exp.tcl > @@ -94,12 +94,15 @@ proc prepare_test_source_file { lang } { > puts $outfile "DEF_WITH_1_STATIC ($utype, $uinner);" > set joined "static_${utype}_x_${uinner}" > puts $outfile "struct align_pair_$joined item_${joined};" > + puts $outfile "$utype align_pair_${joined}::one =3D 0;" > puts $outfile "unsigned a_${joined}" > puts $outfile " =3D ${align_func} (struct align_pair_${= joined});" > > puts $outfile "DEF_WITH_2_STATIC ($utype, $uinner);" > set joined "static_${utype}_x_static_${uinner}" > puts $outfile "struct align_pair_$joined item_${joined};" > + puts $outfile "$utype align_pair_${joined}::one =3D 0;" > + puts $outfile "$uinner align_pair_${joined}::two =3D 0;" > puts $outfile "unsigned a_${joined}" > puts $outfile " =3D ${align_func} (struct align_pair_${= joined});" > } DEF_WITH_1_STATIC and DEF_WITH_2_STATIC look like this: #define DEF_WITH_1_STATIC(T,U) struct align_pair_static_ ## T ## _x_ ## U = { static T one; U two; } #define DEF_WITH_2_STATIC(T,U) struct align_pair_static_ ## T ## _x_static= _ ## U { static T one; static U two; } The first has one static field, the second has two static fields. The line= s I added in the patch hunk above are meant to initialize those static fields. That's why I= have: Initialize one static field here: puts $outfile "DEF_WITH_1_STATIC ($utype, $uinner);" ... puts $outfile "$utype align_pair_${joined}::one =3D 0;" Initialize two static fields here: puts $outfile "DEF_WITH_2_STATIC ($utype, $uinner);" ... puts $outfile "$utype align_pair_${joined}::one =3D 0;" puts $outfile "$uinner align_pair_${joined}::two =3D 0;" Both of these commands came out empty for me, meaning the "::one" and "::tw= o" initializations are only done on lines with types that have "static" in the= ir name: $ grep "::one" testsuite/outputs/gdb.base/align-c++/align.cpp | grep -v s= tatic $ grep "::two" testsuite/outputs/gdb.base/align-c++/align.cpp | grep -v s= tatic Diffing the align.cpp file generated before my patch against a align.cpp fi= le generated after my patch, I get a lot of changes that looks like this: --- align.cpp 2023-04-05 17:20:54.002858720 +0100 +++ align-pedro.cpp 2023-04-05 17:20:33.228766715 +0100 @@ -28,10 +28,13 @@ unsigned a_char_x_char =3D alignof (struct align_pair_char_x_char); DEF_WITH_1_STATIC (char, char); struct align_pair_static_char_x_char item_static_char_x_char; +char align_pair_static_char_x_char::one =3D 0; unsigned a_static_char_x_char =3D alignof (struct align_pair_static_char_x_char); DEF_WITH_2_STATIC (char, char); struct align_pair_static_char_x_static_char item_static_char_x_static_char; +char align_pair_static_char_x_static_char::one =3D 0; +char align_pair_static_char_x_static_char::two =3D 0; ... Again, the "::one" and "::one" lines only appear on types that have "static" in their name. > > > I did not try in PowerPc Linux or another Linux machine. But from the lit= tle knowledge I have, it should not work there as well. Someone needs to ch= eck this in Linux. May be you or Ulrich or Tom can confirm this from your e= xperience in Linux. Let me know. > I had tested my patch on Linux before sending it. It works here just fine,= like so: $ make check TESTS=3D"gdb.*/align*.exp" Running /home/pedro/rocm/gdb/build-master/gdb/testsuite/../../../src/gdb/t= estsuite/gdb.base/align-c++.exp ... Running /home/pedro/rocm/gdb/build-master/gdb/testsuite/../../../src/gdb/t= estsuite/gdb.cp/align.exp ... Running /home/pedro/rocm/gdb/build-master/gdb/testsuite/../../../src/gdb/t= estsuite/gdb.base/align-c.exp ... =3D=3D=3D gdb Summary =3D=3D=3D # of expected passes 3450 Your patch doesn't fix the issue I pointed at in the commit log, this one: For the C++ test, that reveals that the static variable members of the generated structs are not defined anywhere, leading to undefined references. Fixed by emitting initialization for all static members. I.e., if I test with: $ make check TESTS=3D"gdb.*/align-*.exp" RUNTESTFLAGS=3D"CC_FOR_TARGET=3D'= clang -flto' CXX_FOR_TARGET=3D'clang++ -flto'" then I see hundreds of failures like these: print /d a_static_char_x_char Missing ELF symbol "a_static_char_x_char". (gdb) FAIL: gdb.base/align-c++.exp: get integer valueof "a_static_char_x_c= har" ... Going back to this: > So the line highlighted in bold is a problem. This line is also there in = the patch diff that was pasted in the previous email reply thread. This is= not allowed. We are trying to access something we should not. In case we w= ant to initialise any data member, we need to do it via a constructor. I'm attaching the attach.cpp file that the testsuite generates for me. --_000_CH2PR15MB3544E623998D23053A2F649ED6919CH2PR15MB3544namp_--