From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) by sourceware.org (Postfix) with ESMTPS id 4F5E73858CDA for ; Thu, 29 Sep 2022 11:22:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4F5E73858CDA Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=oracle.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=oracle.com Received: from pps.filterd (m0246617.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 28T9rANM018191; Thu, 29 Sep 2022 11:22:53 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : references : date : in-reply-to : message-id : content-type : content-transfer-encoding : mime-version; s=corp-2022-7-12; bh=qd13tieC4yWCzn+pgvheSCpPZbR9bd1/b2Qk4IiZvJk=; b=KbCZvMXTN8z5x7/O6hQkM7m9bL5pPNGriKDMUYLZGn2sCXfR6EHUFYJJlfvDEVNo1gWx f0fLkwkQ6SGLSdwyqV5uGZpWQX8QxrQfnZ7zrQrdiCCn+JMdg+yr8JZCUdBbHzpHvvFO nPVLegvhJsWr7Lpm2BXdpCw6ff8hD9z2IYzNEOD2WpGK+OYrZ2FAghLwX+Dwsjoi4sow qYIwwFusw1EYLDrBai+i2HE1GbgZsOSj3q+SrqAyWSo91LrrWW3Bj3D+IBV8hiG1hdyO Tbzg0dhCnROSX6dxkSETHJ5UyqY0kkobwGzeFImsw0ASFsa38xa9bvECMpOlRbFG6y2L 6g== Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta02.appoci.oracle.com [147.154.18.20]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3jstet4wtw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 29 Sep 2022 11:22:50 +0000 Received: from pps.filterd (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (8.17.1.5/8.17.1.5) with ESMTP id 28TBG7nO040314; Thu, 29 Sep 2022 11:21:43 GMT Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2109.outbound.protection.outlook.com [104.47.58.109]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 3jtpubrjcb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 29 Sep 2022 11:21:42 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hs8rPouiwqSJH7GErndkiB3XcPAJKtW3WbnGp5gGAHBLq8jsgT8U4A2JzToBVvTCwbkcIj8faMfIyqajC4vhfhcO21V+cOtMWMdgBM1SceuW37R4VSXqcsjf1v3zmLlEdzD0WGtciUDNdMoZHgga2WqfL82wE8QcWTUeNzmVeytmVHegsHkOHQR4gxTkKY8ZT98HKyBaNadLjFhQ/h8x+T1CWo9MuMl4Yt5E4OXAv/UYkOOZGBWgVqMyXK5gpMMGvePJR5XxVeSpn9Zk076a6e7QDbUlb9U/EYrjbYa96UGf0OPqUeml2wsnEm/ypx9tPc0fzNTFihdu986F2bwIBA== 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=qd13tieC4yWCzn+pgvheSCpPZbR9bd1/b2Qk4IiZvJk=; b=hBgjlbTeFOKkNnO5tFxW4gKLCVs5GlUyScESnIKjxYxUHB17pVhK4w87Z9LAGJQaqMJZRBkxlvA5hY4iDBuPHhAPJQrwOe/UdMuM5Zfx5g1qA44O7HLtZXv5C+JaMXFgtxcvQK1jrPWR2XZPPYWJEVXU2119XghvzCdYvgFQyl3FWFb+zVd8aKfG4VshQMZTaSjWfD7l72m/ql8FwMhrY+X8P652x/UQTO3K1aCXLMYWOpibUOchSjG5pOjsVZI3tR3JCcN57V55E4jxe7KOX8v7fzd1hB2sr4E5H5HbzUkODYBOOH4Czadrv99ADcPgn8qBxHPPhC88Atc3YN3v/w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qd13tieC4yWCzn+pgvheSCpPZbR9bd1/b2Qk4IiZvJk=; b=nf5x6gVoj1YU1CtQtTYEmHCyeGPvVgSlBVcbdB6z07L56Ls3L1G6DATptRypTU8as3ihVkuLSgmtsIOd1OGG1RTPKx2w7cKxmeceE+5B0CmKKks6hXl+wv7RtkZPXcFYTbPd4KrdesWuFNcVYvY9/y5GFNiqZlinHqWfEq3oiH0= Received: from DM6PR10MB2890.namprd10.prod.outlook.com (2603:10b6:5:71::31) by BN0PR10MB5061.namprd10.prod.outlook.com (2603:10b6:408:12b::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5676.19; Thu, 29 Sep 2022 11:21:40 +0000 Received: from DM6PR10MB2890.namprd10.prod.outlook.com ([fe80::dce:aa4c:230d:284a]) by DM6PR10MB2890.namprd10.prod.outlook.com ([fe80::dce:aa4c:230d:284a%7]) with mapi id 15.20.5676.017; Thu, 29 Sep 2022 11:21:40 +0000 From: "Jose E. Marchesi" To: Jeff Law via Gcc-patches Cc: Jeff Law Subject: Re: [PATCH V2] place `const volatile' objects in read-only sections References: <87zggiudcr.fsf@oracle.com> <3b34b862-c71b-307c-f884-04fad0a3751b@gmail.com> Date: Thu, 29 Sep 2022 13:25:42 +0200 In-Reply-To: <3b34b862-c71b-307c-f884-04fad0a3751b@gmail.com> (Jeff Law via Gcc-patches's message of "Tue, 27 Sep 2022 18:51:42 -0600") Message-ID: <87k05mzakp.fsf@oracle.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: LO2P265CA0138.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:9f::30) To DM6PR10MB2890.namprd10.prod.outlook.com (2603:10b6:5:71::31) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DM6PR10MB2890:EE_|BN0PR10MB5061:EE_ X-MS-Office365-Filtering-Correlation-Id: 2dd4d074-3429-4988-0a47-08daa20cc7de X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ZykeWL9COj3dwR8b3s0pukKF8gCnoR7QBWmDQTJE3widYec9p8nq1bw6FYQfXAXKxFgu07/WSogIMRCaPyYz+vZY3f47gxAw/6DncSmNrYMZ8VEjIRfZNYKbP8+38lRJ0Jlr5zojtPloR9jsbilDZYYRUanyNRxc4IhTENm8eq28nnB486cY2eMv4RHHwMFPLBM5E+RU1KBz0AIGIMaLFCiISvsFmvgyy77HEUKOb38VGIV6heUW1kviFitCDMAN2QVPZa5n1EM2xmvKZt9jtm0jpP2MAdtPBTEdfrZsjtDw8lDjdrBx35p26a6AILyomPh/dAJVA1YWEGt4Hcrz7efwd/sjOZ6Khi0cD1qsmcgQhieYHArTNCsvLqDdtl1oMwWJS4kn/xSZPlX16x403C1rT+Jx4RYWHPSowD+vDth9VLNRhxFXrlzkEmz7M7IuujtYdTAZFyJkBDEpPEuPrTI0krg+dQEVM5ZQiO0a53arVzL1ov7Ne/w8vGT306nFPo1Yqa8qx09iE5OduFZ+NZsuH8jQBR8dCGGfU8dYFjJ2chLsVxxti/SNUmKi7jHrNtxpaVTVttFQQjTzFpSRBqqRKjfztkPzPZUZ1t6oucZPVQlpOCv3r7SLm4e8zPjQ2TVtZsa2Z8e5yskTcVMdI3H0UxxbK7w3QupiaOy4BGwLqE8cjFbHdbWnXmHJtcI/HcVKqPS025fIelqvn6a7CccvtUMLeqpUfSM+l208T1glxCDMATBT+tBfwa6mHugTzPYo5z0+gvYIWnzZs7YQ0MXgACAw09X9k8ftEUUBfJhGJ4buR8WjdvR+RwiB3SAdcUk1P7VUJqpP90XnZMublA== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM6PR10MB2890.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230022)(366004)(136003)(39860400002)(346002)(396003)(376002)(451199015)(84970400001)(36756003)(5660300002)(8676002)(41300700001)(6506007)(4326008)(86362001)(38100700002)(83380400001)(966005)(2616005)(186003)(26005)(478600001)(6486002)(53546011)(6512007)(66556008)(66476007)(8936002)(316002)(2906002)(6916009)(66946007)(81973001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dnNrUjRneitJeVNwSmVISEcyVFFZMk9FcGZ6RDBrTnJxaXUvVFVySU56TmhP?= =?utf-8?B?SFdtMzloZjM5M1lBSXFSR0EyUE9NUFBrOTBpSUE1MTczOHY3Nm15Z2x4NWZI?= =?utf-8?B?ZzdJamFMQ2ljanVPNEgzaU16L1hjVm1jNFpaMVlmcGpIS0kwRDFrdHZ2Z2JE?= =?utf-8?B?YUZ2dVJRNWNvU3lUc3lVUWVzQ0VuNHJqUkRYZVZMZnZIRjRhRFcxZEJQaXUy?= =?utf-8?B?dGl2ZmpMdDUyUjJTWkVtbDc1c2dIYlhkc01DOVZtT2NaZDg4QitUaUZPZk9u?= =?utf-8?B?TjA1T2hVU0ZFQVdwTjZPaXNsZVFKWVhvRmwwancxcnJ1TnpZb1Vid0J1ZjBl?= =?utf-8?B?TnhVSGg0YXE1Y0o2UEd2NDJpMDNnK0VUWEhrUFIrU0dTNmRzRCt5MTZrU3U2?= =?utf-8?B?dkFML3dPOUdKNFgvcHZDOFJFUXJkZGE0R1BrVEthdUp5UmtiUWRBUUwyNWpl?= =?utf-8?B?OFhsUlA2WHpMRE1QYldyV0pRNkZBK2RyTmR1QUZ1U2YyMVpTNi9nMHQ4NS9s?= =?utf-8?B?UGY1cFBQYjBFRUF0SmtLZVA5b0xsRU9tWE1HSDIvanlTK0tYUnE0U2pHM29F?= =?utf-8?B?Tjg4WVhQby8rUGdoQ2licDlhaS9zY2pJS1Z6N1dteHI5ZC80dFBxRWc0M3d5?= =?utf-8?B?bHNJaDNnUzlsd3RxMHd3N1RibTJxQVlqeTFuVGFPeVVkdXhDUU9DOEw5SXpx?= =?utf-8?B?WkdhRDVBNUxPR3VUTURiUnh1SmRZMW5OSXQxYSs5WEE4R3BsM3g3NUgrYVFL?= =?utf-8?B?WStuNE1QYS9MMis3Yi96STBkeXU3RkVmZkdqeXlZeGNFRUN1V3Z1UktMei8v?= =?utf-8?B?QVkyYW5aS0Z3SlNMTkxucVFHVW1vK1FiU2lwL2wrTWRNQysrSy84NWdxQnBG?= =?utf-8?B?eEVLMk9ueHVqTWx3TmdINHV4SGZUUHNDRDYyaUdFeGpLVWI2aWE2Q2pueC9m?= =?utf-8?B?NWlZbXh1NEw4aEl4UGtLRWtjUjU1eGYxdThyY1dGeXdIR1pTb0YzUStvdkVR?= =?utf-8?B?OStqUzRnS2xCMExnanJib0RlcHVLTWxlTC9SclF1Tm9DL0dLOVFMSUx5VEZT?= =?utf-8?B?QnpFK1c0SENlMXJGQ2FHRmh5dXFlUVM5TVREejQ1NmJYWUlvRUVvemsxNFpo?= =?utf-8?B?L3hmcURyV2pLTnFzTGdPMnRENE1KRlJaNlAwOFZiV1RmUm5pV1FMakR6RU5X?= =?utf-8?B?VENQRERpZ3UvbTBEUnRiWWxCZk1rL2FhZml5YjFHUzdlb0E3a3RIQmZQYnpH?= =?utf-8?B?QWlzNkhYYzVwWXRyVHdKT1dOT0J4cE5NeHJxVG9MRktQcTFPRDVUTXhjRVcv?= =?utf-8?B?aWxxclRLUy82VDBXZmM2VldlTjJHbUNXMjQzaytwd1ZVc1o2OWxJYTFWS0JG?= =?utf-8?B?eFNXcURwSVhTdGFSb1JTRXBoNXhyRWVxQldxUW9kcnh3NnNWLzQ5dDZHNU1Q?= =?utf-8?B?MmlkVUtqZ2FXcnFjalEycGVXWUtZRG45TVFvc0Fia3JYRS9hVGtUNktjbUJu?= =?utf-8?B?OGtTNmppR3kvaGZtS01iS2k4b0plWGx0Ny83Qm5UR1ZTb0ZTbzRFZnJyTlB4?= =?utf-8?B?Z09GK1Npck4xS3VwVURrem1JOXVrWXRtS29jSzZid0RtU3FzbGEyc2pHelFW?= =?utf-8?B?SE9YU2tqUm1Ed3o5MElLK0lLVnQyTVNtYTRpVjY4WTU2aHhHSTQ3QTFBVHEy?= =?utf-8?B?eDV4a0xKT3RIbW5SWGtIdzdjeTRLZ1B6NjlMRzBOMmtrSDhPK2JsTnJKL2JN?= =?utf-8?B?VkUzVkJlb1NNeVNpbGVHcmphU09qWEh5OGUvWk1DM0J2VlViVWNrcXVRQW1S?= =?utf-8?B?Zy9oY3JlR3Z4WDBZOU9nWGFuMW0wRG1UVklteHdoNHdPZUtpajBRUSsydWpQ?= =?utf-8?B?cGQraXJ4Si83SXM3T0N5MWtCbzB3M0FiSmt6VnhXOVBJSnhxMWJEOXVtVG50?= =?utf-8?B?SCt6eHlpMVhQRy9jdjNXbG5vS0ExNHlPUVJoOGdWOXU1Mjd0enNTdXN1NzIv?= =?utf-8?B?QzhmRHppaithdURJOXZRWndqU2wvVXRIRmw4SVg4OVZ5THdJejlVVHJsMTV1?= =?utf-8?B?ZndmbVA0eUcxL2drUDZUOGt6NXBBNTMwV2VWL2hKUzNwcytFZ0sxSkV5WnVJ?= =?utf-8?B?bTVsdlk3Mms3eDFOQmZEcW5Cb0MwaHFZcnJRbE9aTzhHL2dEaUtZVVZ2c0lt?= =?utf-8?B?RHc9PQ==?= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2dd4d074-3429-4988-0a47-08daa20cc7de X-MS-Exchange-CrossTenant-AuthSource: DM6PR10MB2890.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Sep 2022 11:21:40.6152 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: k/ZGUPPYvVmUrNVU8IetG3P+kJPRxwi54XdszhPPWfKc+OcBdJz+ImkPFGA3dWgkecUU3kdLq6TBGdtrZvG806oGehbd22WXdEvDY4z4fp8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN0PR10MB5061 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.528,FMLib:17.11.122.1 definitions=2022-09-29_06,2022-09-29_03,2022-06-22_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 adultscore=0 mlxlogscore=999 phishscore=0 mlxscore=0 suspectscore=0 spamscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2209130000 definitions=main-2209290069 X-Proofpoint-GUID: tYI_be64La7IfCVtW0x2nGBTjw2TGcdQ X-Proofpoint-ORIG-GUID: tYI_be64La7IfCVtW0x2nGBTjw2TGcdQ X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,RCVD_IN_DNSWL_LOW,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: > On 8/5/22 05:41, Jose E. Marchesi via Gcc-patches wrote: >> [Changes from V1: >> - Added a test.] >> >> It is common for C BPF programs to use variables that are implicitly >> set by the BPF loader and run-time. It is also necessary for these >> variables to be stored in read-only storage so the BPF verifier >> recognizes them as such. This leads to declarations using both >> `const' and `volatile' qualifiers, like this: >> >> const volatile unsigned char is_allow_list =3D 0; >> >> Where `volatile' is used to avoid the compiler to optimize out the >> variable, or turn it into a constant, and `const' to make sure it is >> placed in .rodata. >> >> Now, it happens that: >> >> - GCC places `const volatile' objects in the .data section, under the >> assumption that `volatile' somehow voids the `const'. >> >> - LLVM places `const volatile' objects in .rodata, under the >> assumption that `volatile' is orthogonal to `const'. >> >> So there is a divergence, that has practical consequences: it makes >> BPF programs compiled with GCC to not work properly. >> >> When looking into this, I found this bugzilla: >> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D25521 >> "change semantics of const volatile variables" >> >> which was filed back in 2005, long ago. This report was already >> asking to put `const volatile' objects in .rodata, questioning the >> current behavior. >> >> While discussing this in the #gcc IRC channel I was pointed out to the >> following excerpt from the C18 spec: >> >> 6.7.3 Type qualifiers / 5 The properties associated with qualified >> types are meaningful only for expressions that are >> lval-values [note 135] >> >> 135) The implementation may place a const object that is not >> volatile in a read-only region of storage. Moreover, the >> implementation need not allocate storage for such an object if >> its $ address is never used. >> >> This footnote may be interpreted as if const objects that are volatile >> shouldn't be put in read-only storage. Even if I personally was not >> very convinced of that interpretation (see my earlier comment in BZ >> 25521) I filed the following issue in the LLVM tracker in order to >> discuss the matter: >> >> https://github.com/llvm/llvm-project/issues/56468 >> >> As you can see, Aaron Ballman, one of the LLVM hackers, asked the WG14 >> reflectors about this. He reported that the reflectors don't think >> footnote 135 has any normative value. >> >> So, not having a normative mandate on either direction, there are two >> options: >> >> a) To change GCC to place `const volatile' objects in .rodata instead >> of .data. >> >> b) To change LLVM to place `const volatile' objects in .data instead >> of .rodata. >> >> Considering that: >> >> - One target (bpf-unknown-none) breaks with the current GCC behavior. >> >> - No target/platform relies on the GCC behavior, that we know. >> >> - Changing the LLVM behavior at this point would be very severely >> traumatic for the BPF people and their users. >> >> I think the right thing to do at this point is a). >> Therefore this patch. >> >> Regtested in x86_64-linux-gnu and bpf-unknown-none. >> No regressions observed. >> >> gcc/ChangeLog: >> >> PR middle-end/25521 >> * varasm.cc (categorize_decl_for_section): Place `const volatile' >> objects in read-only sections. >> (default_select_section): Likewise. >> >> gcc/testsuite/ChangeLog: >> >> PR middle-end/25521 >> * lib/target-supports.exp (check_effective_target_elf): Define. >> * gcc.dg/pr25521.c: New test. > > The best use I've heard for const volatile is stuff like hardware > status registers which are readonly from the standpoint of the > compiler, but which are changed by the hardware.=C2=A0=C2=A0 But for thos= e, > we're looking for the const to trigger compiler diagnostics if we try > to write the value.=C2=A0 The volatile (of course) indicates the value > changes behind our back. > > What you're trying to do seems to parallel that case reasonably well > for the volatile aspect.=C2=A0 You want to force the compiler to read the > data for every access. > > Your need for the const is a bit different.=C2=A0 Instead of looking to g= et > a diagnostic out of the compiler if its modified, you need the data to=20 > live in .rodata so the BPF verifier knows the compiler/code won't > change the value.=C2=A0 Presumably the BPF verifier can't read debug info > to determine the const-ness. > > > I'm not keen on the behavior change, but nobody else is stepping in to > review and I don't have a strong case to reject.=C2=A0 So OK for the trun= k. Thanks. To me the biggest advantage of the change is that now there is no divergence on how GCC and Clang handle `const' and `volatile'. Just pushed to master after bootregtesting in x86_64-linux-gnu. Thanks! --- master-tests/all.sum 2022-09-29 12:35:30.994514528 +0200 +++ consvolatile-tests/all.sum 2022-09-29 12:35:41.152420906 +0200 @@ -173,7 +173,7 @@ # of expected failures 98 # of expected passes 14142 # of expected passes 15607 -# of expected passes 183688 +# of expected passes 183690 # of expected passes 232848 # of expected passes 2840 # of expected passes 44 @@ -170478,6 +170478,8 @@ PASS: gcc.dg/pr25376.c scan-assembler my_named_section PASS: gcc.dg/pr25376.c scan-assembler-symbol-section symbol simple$ (found= simple) has section\ ^\\.?my_named_section|simple\\[DS\\]|^\\"\\.opd\\" (f= ound my_named_section) PASS: gcc.dg/pr25376.c (test for excess errors) +PASS: gcc.dg/pr25521.c scan-assembler \\.rodata +PASS: gcc.dg/pr25521.c (test for excess errors) PASS: gcc.dg/pr25529.c scan-tree-dump optimized "& 2147483647" PASS: gcc.dg/pr25529.c (test for excess errors) PASS: gcc.dg/pr25530.c scan-tree-dump optimized "& -2|4294967294"