From patchwork Wed May 21 14:04:34 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Yash Shinde X-Patchwork-Id: 63463 X-Patchwork-Delegate: steve@sakoman.com Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3175EC2D0CD for ; Wed, 21 May 2025 14:04:59 +0000 (UTC) Received: from mx0a-0064b401.pphosted.com (mx0a-0064b401.pphosted.com [205.220.166.238]) by mx.groups.io with SMTP id smtpd.web11.12023.1747836295121720098 for ; Wed, 21 May 2025 07:04:55 -0700 Authentication-Results: mx.groups.io; dkim=none (message not signed); spf=permerror, err=parse error for token &{10 18 %{ir}.%{v}.%{d}.spf.has.pphosted.com}: invalid domain name (domain: windriver.com, ip: 205.220.166.238, mailfrom: prvs=72362efbbd=yash.shinde@windriver.com) Received: from pps.filterd (m0250810.ppops.net [127.0.0.1]) by mx0a-0064b401.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 54L6vocb008810 for ; Wed, 21 May 2025 07:04:54 -0700 Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-0064b401.pphosted.com (PPS) with ESMTPS id 46rwfs9fhv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 21 May 2025 07:04:54 -0700 (PDT) Received: from m0250810.ppops.net (m0250810.ppops.net [127.0.0.1]) by pps.reinject (8.18.0.8/8.18.0.8) with ESMTP id 54LE36gs032097 for ; Wed, 21 May 2025 07:04:53 -0700 Received: from nam11-bn8-obe.outbound.protection.outlook.com (mail-bn8nam11lp2169.outbound.protection.outlook.com [104.47.58.169]) by mx0a-0064b401.pphosted.com (PPS) with ESMTPS id 46rwfs9fhs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 21 May 2025 07:04:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=B+b4fWRyCJMD2SxDkOm1aVPdMhMv6WOOnaNdiD/OmxK8ozKQXXfkP6x4ruK1r2gI8ZCR3t6Kz0C+c8rnzPfct1iOFYI1ETv4NnBNy4B5TH2cBs1hQCSltpT2m29b/UaXCKSUFzaH+gCv5oM9KuJ2k4Mk/8MOiFKM5NuVEvNn8e9Fk3YXjVm4cGK969nFwpBv8MEci6q+6yVsP7jrFBOjrO2VEoPLGPU2elEiw2kZDgIc6jvHaZlZ+dnpKyHuctbULc7iAwEK7jcDIhs6F6Xpr5gIZsYu1wT6ECs0Fmi0oNh9ugqhxA6zEyARgp7EoM7mk0yqtsE3nXbv+Fky0AHayw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; 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=gE3c3DxoV7xhoymBxBVH1hqkFmubZ/9sItGtNZ2KNhY=; b=OOlnRbA/LwVfLeLZ1oXbx62cEvnxvMxEDPBW+WW48IootRPOp47h88LizR6dxwCPXRhRw72PvmAxL1dtE4rw1LkG5gz8z+gkR82JP8t7/WyWPWx1ViL+NTHslt5Xof/K66/Vj5bhwOYjG6U4N+SyZKjI7b7TP/M1JXhwa3QRJmdFMoY1mvonEC2nHtAF3hFUDUjZ3UsikDj7q3U9pySOboHzmYuFZ7GdHYEaHFFbf8bfivNOag4Bc3dZZHwFPOgbC3/5byf+72U60QRxwno1aycnJwZPPAt6B6l2m0+J/GU1TzOKyghQ8g42sanNxsRjEi/pPYO81wB4Yhe9aQAEzQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=windriver.com; dmarc=pass action=none header.from=windriver.com; dkim=pass header.d=windriver.com; arc=none Received: from PH7PR11MB7593.namprd11.prod.outlook.com (2603:10b6:510:27f::9) by SA2PR11MB4971.namprd11.prod.outlook.com (2603:10b6:806:118::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.19; Wed, 21 May 2025 14:04:50 +0000 Received: from PH7PR11MB7593.namprd11.prod.outlook.com ([fe80::2688:e731:421b:5ebc]) by PH7PR11MB7593.namprd11.prod.outlook.com ([fe80::2688:e731:421b:5ebc%3]) with mapi id 15.20.8746.030; Wed, 21 May 2025 14:04:49 +0000 From: Yash.Shinde@windriver.com To: openembedded-core@lists.openembedded.org Cc: steve@sakoman.com, Randy.MacLeod@windriver.com, Sundeep.Kokkonda@windriver.com, Yash.Shinde@windriver.com Subject: [walnascar][PATCH] gcc: fix incorrect preprocessor line numbers in large files Date: Wed, 21 May 2025 07:04:34 -0700 Message-ID: <20250521140436.301495-1-Yash.Shinde@windriver.com> X-Mailer: git-send-email 2.49.0 X-ClientProxiedBy: SJ0PR03CA0261.namprd03.prod.outlook.com (2603:10b6:a03:3a0::26) To PH7PR11MB7593.namprd11.prod.outlook.com (2603:10b6:510:27f::9) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH7PR11MB7593:EE_|SA2PR11MB4971:EE_ X-MS-Office365-Filtering-Correlation-Id: fafadc65-205a-4943-2002-08dd98707357 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|52116014|376014|13003099007|38350700014; X-Microsoft-Antispam-Message-Info: =?utf-8?q?BZHjZUvj/ftjrowC8wLzyNt4RLb21tP?= =?utf-8?q?J3ub1q1HnUgFij044pjynGSsfZc6YbCXK41HEXOArbuW3aOQy7ih/Xzy/PsTZZSTY?= =?utf-8?q?xkquSLIPt0xlLgs25FCQAK/ICuBjHxMB9iGRlDrJt+6xy/yC1ZONBlebCKGxFxbB2?= =?utf-8?q?rYl1a/vO1tSJSn0+2vndwOYSMhVe4eYLIuCeIaUpMazMve2rNql0RYUOzAe6K0MZ1?= =?utf-8?q?jbc4eui6pkPzPj7zJMNbVBeDZAVz2XNA8QlZzr84hLNHbCvhqYgDbW6EthhFjF080?= =?utf-8?q?i51tS20A4CqGo0k0xk+DjeAZp00qdzU/dG4j+kbvJ8AaH1N4aTYTCEhGJaHOdqWSv?= =?utf-8?q?D2FtyREUliRIywpM60LoNv3QLABYpiFRC9I9vroWvbu8fhdIT4A3DEIbQf1LOkdcg?= =?utf-8?q?CsrLjirHR3+Hk2Xem8slrYjrB8c+Xa6MPcBQaRJ+fSFgym5Liwmg61SrrfHUCg2wX?= =?utf-8?q?Bu9GS+2bwmPmrggsTAWXiHIRkjoCYbjmeaEum9gRM4RDoHngIAAykJDtRezJOCX9j?= =?utf-8?q?9UXKuM61JKa/HRWxKW7HGMHnMlphPiYvUMUSZxSl7h+7bQxZ3aozNCKK4cn6Gb5TX?= =?utf-8?q?g/WHuk8/A5T99uAnheRrsotHSfIXAmuO2Sa9MnZ7sDPREfsghOf9l/m0YlGSNYhyQ?= =?utf-8?q?M1ieEAxoGg0Kj8Jc4vBh7/MqBP+5Ram1pHrp+4CU72+jY+LlgUWKc02Rd0jxgLTV6?= =?utf-8?q?7Yg2ZNuUBgnf5B8ZV7U3sGj2q5+ah8JOkSAgAsAJHLgdKzRgSzuX3hby7MIBqlgVP?= =?utf-8?q?9XT+VlZEEkm/vArdrNZR6AKLGeN1PfpPZOeX7ABbe+QR1GKdoL3cXY5W48KNi5ztD?= =?utf-8?q?+V6Z+BoWKWnRAJeoORs3km/S0QYEtS4PUW3zUXUG94SUfBDm5GOuh36dxM1/sA7Y/?= =?utf-8?q?jyZrXXosFqtHxBx5F8D3NNyPcB40KVRzAhRY4DOf3iFOpvgRM0uAhQ6KQlUzTxz4t?= =?utf-8?q?nEJoWxxDPFxChMEQhTZfIHGARFNWSelkb2EHWg5DTGKm1aXaKVtPlhL2K1DI1SdbM?= =?utf-8?q?RnVuiNxbsyKqA3dKce+kLQox+TTwbVjkA0GeSQ2SdIpBiEFEe286Btbp6Qw1YDzza?= =?utf-8?q?pDV4E6/9VXsgUw/vKep7oDpeuX/lX3nCJuU1bb0utKpbtCULXqCKp+2ggIq6vD+iK?= =?utf-8?q?Oo30TFxJ1oy5b6ynIShi0KDbpH7DrXZC0YNT0bEdD+FTtQ7MYVVxI0RioQPXiZ832?= =?utf-8?q?bVgz4KfOGKmR2DVYNJvg3wu4SMcqsbLMhoU/NyA6Ho+bebryGzW9ZZ5UMSANMMJg3?= =?utf-8?q?7GePy+3fD2nI7ygjL1Dajtp0kI1yNRch0dtwlZdCr3dxLcoy0Z1lsHI1VNZIQDz9t?= =?utf-8?q?79K5iYjrUcCGd0fX6JHu0+ieXSqOuxetg7fFmjIfovRAeAfWuCSyai8=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH7PR11MB7593.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(52116014)(376014)(13003099007)(38350700014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?q?Gfgp42CdIk+jVJe1N6yciZCZwa+G?= =?utf-8?q?gAipelxPTSoYEosJd7e2d/D1sc5DsjZbJ4NGgKsm+jHjLvEeKkfNqPIsYFQggyWUg?= =?utf-8?q?BhJoDNSsCom+E7zv3B5ya/A863kUKskf65ksg2j7ThqoZmCq7zkmJB7BM1+jSKURW?= =?utf-8?q?zRHIqv00vqm/QOlyLhr4QtPm2ZCgztzI+awkvDCDSGyesX+lgfzPRiKjtk4LY6MeX?= =?utf-8?q?XfSMJgKhKGHjGYzobEKHn3Y7XkFyzog0lCdv75pWjJqqIKomcFgIG0O6Mb+EV3ELt?= =?utf-8?q?IeFyl/rMNGSgOcMyBGH45cmUXf+8tqXCOuPk5khNcMHU3/UYv7Mma8YEqRh4CIdNG?= =?utf-8?q?f2tzt599RsVqbVvy0Xk7Q0fz8gTbP1bxhyXlWVBXPqx2tQsZXLUj6AEsA23vQppqa?= =?utf-8?q?XTn9Rh9/3og4uZoNvuqKHJ86PELoZt+XkpUPrm1tO3Fwfg435P9D/54NcsvnrGIpj?= =?utf-8?q?GdeWRH96RE2TQnESLSRRJBgomDsa0j4B8CK9mToU/H3DBe3sdGI9dLi6TKLgCJ5ma?= =?utf-8?q?KJrEinrnldP/+6OZiFTJHQSRCGq6R00+SOCu2tWaRQ+dWnZdgwsLU3oTsne0BOmrs?= =?utf-8?q?l3KDJzpRmXYQ6USpfMLqzEHLjjJg5ctkOZCC6SgJ9N17M+oqk7IG5Zkr02uYZLR42?= =?utf-8?q?POlGHq+eSAhCIgruFpLhe3/sOUgf0elUUQL9EP0Nx+PtUrGMSpMjkzQDtCmmasFwO?= =?utf-8?q?MBrv8/TJBd3OcghJQIDBZ3VCVNG3i9fBonW0Sige0x6cvoFjZC65CDOB9thsGDkGp?= =?utf-8?q?xGDIfFqGCpQUXERSOaEd+8tmjj2TB+GMvrBORrdXYQxuEPFBA7I5U3fm1FfzrUe+h?= =?utf-8?q?/Z7wO48HtHQkNcSTutdoajAEuTByRrWGSZFOJ+o4B2Ux3CIiAPyuOEY6PG5TOH3cf?= =?utf-8?q?/kUxCfa4qnbe5wnR6KjETSqdFK8jptpvWSL0pWaLq+RQClpJ18hS9MUQl3ZanemJF?= =?utf-8?q?BDULLtS39/YFmrUvJA+Rn2IFyA+GR9TSJk4te2cdP88Js5B1eeTCHQxksvDOL4Czn?= =?utf-8?q?9OFG3HLtfA3n6Gex7BipMARkwIU2tHQtDepjgEQG4ZA3tfC4luU4AzfaV2qC7JH2z?= =?utf-8?q?tZ/N2ze6RjuXE2Fg/DdUPLdmILFKtOtLqYNWXE4ocxJuqHlodABZOopHMHEOPRUSb?= =?utf-8?q?ILniJvfSWoTHf/XgnW1LFAVPZqMjgub9Yvug8XhQA5UespsqBa0o+zkIsQq4iqf7z?= =?utf-8?q?2RNjB5TM1OdiY1NN18WIO01uhVJEbCs3BPKZVltHiMD9I8TCq1n3qF47KC4tEaTl+?= =?utf-8?q?vdKYxn3D0/9seeC6PUvLeLehHiMfLZDrWu5nFBdWmx5YeaRWxRKxOPGvzbyKRUWnc?= =?utf-8?q?SvfUZoLjisHH3/F97DC9/VfXVC0ccejppli1DteMZXCzlXI8Q5TROErT7OnA3NHrE?= =?utf-8?q?jSWch8dlckllEBsnWqkf/9L0nqKGEvxGUSABfk4u63nyDsV6m60Oz/6veSG7Bih8X?= =?utf-8?q?QdrKJH9s9l+ZF2/AnOeP7MUxlawxhp55vqvBKdrlbUtmNGiBR2fRNRqu4aTWXUJjn?= =?utf-8?q?HXWAuHsTnZvyKnr1mfQPKXBdZlYCMH43QQ=3D=3D?= X-OriginatorOrg: windriver.com X-MS-Exchange-CrossTenant-Network-Message-Id: fafadc65-205a-4943-2002-08dd98707357 X-MS-Exchange-CrossTenant-AuthSource: PH7PR11MB7593.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 May 2025 14:04:49.8705 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 8ddb2873-a1ad-4a18-ae4e-4644631433be X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: jt9O/oOn2V/96GIaAzzspH4qPygzMoaGlCDiGYQcKT9794GOMSOeLBci3PEg+kjMEgUUWObReK0oAeeBTCDnWqB7REVaL/etr4A7hsHxKLA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR11MB4971 X-Proofpoint-GUID: P-Tvvqs8q-YFcwxJFP5FsRj9zKVzVIjr X-Proofpoint-ORIG-GUID: lcUS8NkCo_J414EYbKONC07PVBt_mCPN X-Authority-Analysis: v=2.4 cv=KJNaDEFo c=1 sm=1 tr=0 ts=682ddd86 cx=c_pps a=NZTPE88KBhpz0z3fOSYQ1w==:117 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=wKuvFiaSGQ0qltdbU6+NXLB8nM8=:19 a=Ol13hO9ccFRV9qXi2t6ftBPywas=:19 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=dt9VzEwgFbYA:10 a=mDV3o1hIAAAA:8 a=t7CeM3EgAAAA:8 a=20KFwNOVAAAA:8 a=317HPcoRKb9w4eVG2_AA:9 a=N371p7YIYwourpHR:21 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=FnvyL7ShRj4A:10 a=FdTzh2GWekK77mhwV6Dw:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNTIxMDEzNiBTYWx0ZWRfX16JxSUe0Zl/c u+fdC12v2776LElpVgR4FZXEsorojlIcODHwskL4Uex3ss3okHB6XZNM7x0TGBm6JXzf23MgSM5 tMab70bdTiJevmk2W0DkCV73OlcpHeDxdy3NxmGE5MRr/cPk/PKKFJbiOo66eRzsfwqjaNntBWp vEgsUdKRJuTRJbadQbme5w3pos2+Aki+7HljX9x6/fTg8benEB36A7wrzt3cKYQHVqLQ9dw7OIP xiqF2FH0AZt7SEkIN50drBxKwZCQAmhnvOLAulkbbDKOSB7NVKfXbzKx547dn+w96/Lf1ap/GM2 Uq0muIg67PliI746/vF7rZitRmJgXyYApZzQIN+Mql1gWclh1YVnRa/gNs/A/4DqXbLENxc1D+J cRaJ3v2w9En1Wyo73BDdztzk8dXX/+zxHwVjQZgy/bHxj8RLhYMO0rU2gHdbysh0kNPZyneK X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40 definitions=2025-05-21_04,2025-05-20_03,2025-03-28_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=999 bulkscore=0 spamscore=0 priorityscore=1501 lowpriorityscore=0 suspectscore=0 clxscore=1015 mlxscore=0 malwarescore=0 phishscore=0 adultscore=0 impostorscore=0 classifier=spam authscore=0 authtc=n/a authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.21.0-2505160000 definitions=main-2505210136 X-MIME-Autoconverted: from 8bit to quoted-printable by mx0a-0064b401.pphosted.com id 54L6vocb008810 List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Wed, 21 May 2025 14:04:59 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-core/message/217032 From: Yash Shinde Resolve static assertion failures caused by incorrect line numbers after #include directives, introduced by the backport of PR108900 to GCC. Update line map handling to correctly compute locations in large files, including fixes for both LC_ENTER and LC_LEAVE to ensure accurate line number resolution in rare edge cases. https://gcc.gnu.org/cgit/gcc/commit/?id=edf745dc519ddbfef127e2789bf11bfbacd300b7 Signed-off-by: Yash Shinde --- meta/recipes-devtools/gcc/gcc-14.2.inc | 1 + ...-incorrect-preprocessor-line-numbers.patch | 475 ++++++++++++++++++ 2 files changed, 476 insertions(+) create mode 100644 meta/recipes-devtools/gcc/gcc/0028-fix-incorrect-preprocessor-line-numbers.patch diff --git a/meta/recipes-devtools/gcc/gcc-14.2.inc b/meta/recipes-devtools/gcc/gcc-14.2.inc index 3d65bed92a..17f874f29a 100644 --- a/meta/recipes-devtools/gcc/gcc-14.2.inc +++ b/meta/recipes-devtools/gcc/gcc-14.2.inc @@ -71,6 +71,7 @@ SRC_URI = "${BASEURI} \ file://0026-gcc-Fix-c-tweak-for-Wrange-loop-construct.patch \ file://0027-gcc-backport-patch-to-fix-data-relocation-to-ENDBR-s.patch \ file://gcc.git-ab884fffe3fc82a710bea66ad651720d71c938b8.patch \ + file://0028-fix-incorrect-preprocessor-line-numbers.patch \ " S = "${TMPDIR}/work-shared/gcc-${PV}-${PR}/${SOURCEDIR}" diff --git a/meta/recipes-devtools/gcc/gcc/0028-fix-incorrect-preprocessor-line-numbers.patch b/meta/recipes-devtools/gcc/gcc/0028-fix-incorrect-preprocessor-line-numbers.patch new file mode 100644 index 0000000000..5185236a3d --- /dev/null +++ b/meta/recipes-devtools/gcc/gcc/0028-fix-incorrect-preprocessor-line-numbers.patch @@ -0,0 +1,475 @@ +From 8cbe033a8a88fe6437cc5d343ae0ddf8dd3455c8 Mon Sep 17 00:00:00 2001 +From: Jakub Jelinek +Date: Thu, 8 May 2025 11:14:24 +0200 +Subject: libcpp: Further fixes for incorrect line numbers in large files + [PR120061] +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +The backport of the PR108900 fix to 14 branch broke building chromium +because static_assert (__LINE__ == expected_line_number, ""); now triggers +as the __LINE__ values are off by one. +This isn't the case on the trunk and 15 branch because we've switched +to 64-bit location_t and so one actually needs far longer header files +to trigger it. +https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c11 +https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c12 +contain (large) testcases in patch form which show on the 14 branch +that the first one used to fail before the PR108900 backport and now +works correctly, while the second one attempts to match the chromium +behavior and it used to pass before the PR108900 backport and now it +FAILs. +The two testcases show rare problematic cases, because +do_include_common -> parse_include -> check_eol -> check_eol_1 -> +cpp_get_token_1 -> _cpp_lex_token -> _cpp_lex_direct -> linemap_line_start +triggers there + /* Allocate the new line_map. However, if the current map only has a + single line we can sometimes just increase its column_bits instead. */ + if (line_delta < 0 + || last_line != ORDINARY_MAP_STARTING_LINE_NUMBER (map) + || SOURCE_COLUMN (map, highest) >= (1U << (column_bits - range_bits)) + || ( /* We can't reuse the map if the line offset is sufficiently + large to cause overflow when computing location_t values. */ + (to_line - ORDINARY_MAP_STARTING_LINE_NUMBER (map)) + >= (((uint64_t) 1) + << (CHAR_BIT * sizeof (linenum_type) - column_bits))) + || range_bits < map->m_range_bits) + map = linemap_check_ordinary + (const_cast + (linemap_add (set, LC_RENAME, + ORDINARY_MAP_IN_SYSTEM_HEADER_P (map), + ORDINARY_MAP_FILE_NAME (map), + to_line))); +and so creates a new ordinary map on the line right after the +(problematic) #include line. +Now, in the spot that r14-11679-g8a884140c2bcb7 patched, +pfile->line_table->highest_location in all 3 tests (also +https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c13 +) is before the decrement the start of the line after the #include line and so +the decrement is really desirable in that case to put highest_location +[jakub@tucnak gcc-15]$ git log -1 --format=%B r15-9638-gbfcb5da69a41f7a5e41faab39b763d9d7c8bd2ea | cat +libcpp: Further fixes for incorrect line numbers in large files [PR120061] + +The backport of the PR108900 fix to 14 branch broke building chromium +because static_assert (__LINE__ == expected_line_number, ""); now triggers +as the __LINE__ values are off by one. +This isn't the case on the trunk and 15 branch because we've switched +to 64-bit location_t and so one actually needs far longer header files +to trigger it. +https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c11 +https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c12 +contain (large) testcases in patch form which show on the 14 branch +that the first one used to fail before the PR108900 backport and now +works correctly, while the second one attempts to match the chromium +behavior and it used to pass before the PR108900 backport and now it +FAILs. +The two testcases show rare problematic cases, because +do_include_common -> parse_include -> check_eol -> check_eol_1 -> +cpp_get_token_1 -> _cpp_lex_token -> _cpp_lex_direct -> linemap_line_start +triggers there + /* Allocate the new line_map. However, if the current map only has a + single line we can sometimes just increase its column_bits instead. */ + if (line_delta < 0 + || last_line != ORDINARY_MAP_STARTING_LINE_NUMBER (map) + || SOURCE_COLUMN (map, highest) >= (1U << (column_bits - range_bits)) + || ( /* We can't reuse the map if the line offset is sufficiently + large to cause overflow when computing location_t values. */ + (to_line - ORDINARY_MAP_STARTING_LINE_NUMBER (map)) + >= (((uint64_t) 1) + << (CHAR_BIT * sizeof (linenum_type) - column_bits))) + || range_bits < map->m_range_bits) + map = linemap_check_ordinary + (const_cast + (linemap_add (set, LC_RENAME, + ORDINARY_MAP_IN_SYSTEM_HEADER_P (map), + ORDINARY_MAP_FILE_NAME (map), + to_line))); +and so creates a new ordinary map on the line right after the +(problematic) #include line. +Now, in the spot that r14-11679-g8a884140c2bcb7 patched, +pfile->line_table->highest_location in all 3 tests (also +https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c13 +) is before the decrement the start of the line after the #include line and so +the decrement is really desirable in that case to put highest_location +somewhere on the line where the #include actually is. +But at the same time it is also undesirable, because if we do decrement it, +then linemap_add LC_ENTER called from _cpp_do_file_change will then + /* Generate a start_location above the current highest_location. + If possible, make the low range bits be zero. */ + location_t start_location = set->highest_location + 1; + unsigned range_bits = 0; + if (start_location < LINE_MAP_MAX_LOCATION_WITH_COLS) + range_bits = set->default_range_bits; + start_location += (1 << range_bits) - 1; + start_location &= ~((1 << range_bits) - 1); + + linemap_assert (!LINEMAPS_ORDINARY_USED (set) + || (start_location + >= MAP_START_LOCATION (LINEMAPS_LAST_ORDINARY_MAP (set)))); +and we can end up with the new LC_ENTER ordinary map having the same +start_location as the preceding LC_RENAME one. +Next thing that happens is computation of included_from: + if (reason == LC_ENTER) + { + if (set->depth == 0) + map->included_from = 0; + else + /* The location of the end of the just-closed map. */ + map->included_from + = (((map[0].start_location - 1 - map[-1].start_location) + & ~((1 << map[-1].m_column_and_range_bits) - 1)) + + map[-1].start_location); +The normal case (e.g. with the testcase included at the start of this comment) is +that map[-1] starts somewhere earlier and so map->included_from computation above +nicely computes location_t which expands to the start of the #include line. +With r14-11679 reverted, for #c11 as well as #c12 +map[0].start_location == map[-1].start_location above, and so it is +((location_t) -1 & ~((1 << map[-1].m_column_and_range_bits) - 1))) ++ map[-1].start_location, +which happens to be start of the #include line. +For #c11 map[0].start_location is 0x500003a0 and map[-1] has +m_column_and_range_bits 7 and map[-2] has m_column_and_range_bits 12 and +map[0].included_from is set to 0x50000320. +For #c12 map[0].start_location is 0x606c0402 and map[-2].start_location is +0x606c0400 and m_column_and_range_bits is 0 for all 3 maps. +map[0].included_from is set to 0x606c0401. +The last important part is again in linemap_add when doing LC_LEAVE: + /* (MAP - 1) points to the map we are leaving. The + map from which (MAP - 1) got included should be the map + that comes right before MAP in the same file. */ + from = linemap_included_from_linemap (set, map - 1); + + /* A TO_FILE of NULL is special - we use the natural values. */ + if (to_file == NULL) + { + to_file = ORDINARY_MAP_FILE_NAME (from); + to_line = SOURCE_LINE (from, from[1].start_location); + sysp = ORDINARY_MAP_IN_SYSTEM_HEADER_P (from); + } +Here it wants to compute the right to_line which ought to be the line after +the #include directive. +On the #c11 testcase that doesn't work correctly though, because +map[-1].included_from is 0x50000320, from[0] for that is LC_ENTER with +start_location 0x4080 and m_column_and_range_bits 12 but note that we've +earlier computed map[-1].start_location + (-1 & 0xffffff80) and so only +decreased by 7 bits, so to_line is still on the line with #include and not +after it. In the #c12 that doesn't happen, all the ordinary maps involved +there had 0 m_column_and_range_bits and so this computes correct line. + +Below is a fix for the trunk including testcases using the +location_overflow_plugin hack to simulate the bugs without needing huge +files (in the 14 case it is just 330KB and almost 10MB, but in the 15 +case it would need to be far bigger). +The pre- r15-9018 trunk has +FAIL: gcc.dg/plugin/location-overflow-test-pr116047.c -fplugin=./location_overflow_plugin.so scan-file static_assert[^\n\r]*6[^\n\r]*== 6 +and current trunk +FAIL: gcc.dg/plugin/location-overflow-test-pr116047.c -fplugin=./location_overflow_plugin.so scan-file static_assert[^\n\r]*6[^\n\r]*== 6 +FAIL: gcc.dg/plugin/location-overflow-test-pr120061.c -fplugin=./location_overflow_plugin.so scan-file static_assert[^\n\r]*5[^\n\r]*== 5 +and with the patch everything PASSes. + +The patch reverts the r14-11679 change, because it is incorrect, +we really need to decrement it even when crossing ordinary map +boundaries, so that the location is not on the line after the #include +line but somewhere on the #include line. It also patches two spots +in linemap_add mentioned above to make sure we get correct locations +both in the included_from location_t when doing LC_ENTER (second +line-map.cc hunk) and when doing LC_LEAVE to compute the right to_line +(first line-map.cc hunk), both in presence of an added LC_RENAME +with the same start_location as the following LC_ENTER (i.e. the +problematic cases). +The LC_ENTER hunk is mostly to ensure included_form location_t is +at the start of the #include line (column 0), without it we can +decrease include_from not enough and end up at some random column +in the middle of the line, because it is masking away +map[-1].m_column_and_range_bits bits even when in the end the resulting +include_from location_t will be found in map[-2] map with perhaps +different m_column_and_range_bits. That alone doesn't fix the bug +though. +The more important is the LC_LEAVE hunk and the problem there is +caused by linemap_line_start not actually doing + r = set->highest_line + (line_delta << map->m_column_and_range_bits); +when adding a new map (the LC_RENAME one because we need to switch to +different number of directly encoded ranges, or columns, etc.). +So, in the original PR108900 case that + to_line = SOURCE_LINE (from, from[1].start_location); +doesn't do the right thing, from there is the last < 0x50000000 map +with m_column_and_range_bits 12, from[1] is the first one above it +and map[-1].included_from is the correct location of column 0 on +the #include line, but as the new LC_RENAME map has been created without +actually increasing highest_location to be on the new line (we've just +set to_line of the new LC_RENAME map to the correct line), + to_line = SOURCE_LINE (from, from[1].start_location); +stays on the same source line. I've tried to just replace that with + to_line = SOURCE_LINE (from, linemap_included_from (map - 1)) + 1; +i.e. just find out the #include line from map[-1].included_from and +add 1 to it, unfortunately that breaks the +c-c++-common/cpp/line-4.c +test where we expect to stay on the same 0 line for LC_LEAVE from + and gcc.dg/cpp/trad/Wunused.c, gcc.dg/cpp/trad/builtins.c +and c-c++-common/analyzer/named-constants-via-macros-traditional.c tests +all with -traditional-cpp preprocessing where to_line is also off-by-one +from the expected one. +So, this patch instead conditionalizes it, uses the + to_line = SOURCE_LINE (from, linemap_included_from (map - 1)) + 1; +way only if from[1] is a LC_RENAME map (rather than the usual +LC_ENTER one), that should limit it to the problematic cases of when +parse_include peeked after EOL and had to create LC_RENAME map with +the same start_location as the LC_ENTER after it. + +Some further justification for the LC_ENTER hunk, using the +https://gcc.gnu.org/pipermail/gcc-patches/2025-May/682774.html testcase +(old is 14 before r14-11679, vanilla current 14 and new with the 14 patch) +I get +$ /usr/src/gcc-14/obj/gcc/cc1.old -quiet -std=c23 pr116047.c -nostdinc +In file included from pr116047-1.h:327677:21, + from pr116047.c:4: +pr116047-2.h:1:1: error: unknown type name ‘a’ + 1 | a b c; + | ^ +pr116047-2.h:1:5: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘c’ + 1 | a b c; + | ^ +pr116047-1.h:327677:1: error: static assertion failed: "" +327677 | #include "pr116047-2.h" + | ^~~~~~~~~~~~~ +$ /usr/src/gcc-14/obj/gcc/cc1.vanilla -quiet -std=c23 pr116047.c -nostdinc +In file included from pr116047-1.h:327678, + from pr116047.c:4: +pr116047-2.h:1:1: error: unknown type name ‘a’ + 1 | a b c; + | ^ +pr116047-2.h:1:5: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘c’ + 1 | a b c; + | ^ +$ /usr/src/gcc-14/obj/gcc/cc1.new -quiet -std=c23 pr116047.c -nostdinc +In file included from pr116047-1.h:327677, + from pr116047.c:4: +pr116047-2.h:1:1: error: unknown type name ‘a’ + 1 | a b c; + | ^ +pr116047-2.h:1:5: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘c’ + 1 | a b c; + | ^ + +pr116047-1.h has on lines 327677+327678: + #include "pr116047-2.h" + static_assert (__LINE__ == 327678, ""); +so the static_assert failure is something that was dealt mainly in the +LC_LEAVE hunk and files.cc reversion, but please have a look at the +In file included from lines. +14.2 emits correct line (#include "pr116047-2.h" is indeed on line +327677) but some random column in there (which is not normally printed +for smaller headers; 21 is the . before extension in the filename). +Current trunk emits incorrect line (327678 instead of 327677, clearly +it didn't decrement). +And the patched compiler emits the right line with no column, as would +be printed if I remove e.g. 300000 newlines from the file. + +2025-05-08 Jakub Jelinek + + PR preprocessor/108900 + PR preprocessor/116047 + PR preprocessor/120061 + * files.cc (_cpp_stack_file): Revert 2025-03-28 change. + * line-map.cc (linemap_add): Use + SOURCE_LINE (from, linemap_included_from (map - 1)) + 1; instead of + SOURCE_LINE (from, from[1].start_location); to compute to_line + for LC_LEAVE if from[1].reason is LC_RENAME. For LC_ENTER + included_from computation, look at map[-2] or even lower if map[-1] + has the same start_location as map[0]. + + * gcc.dg/plugin/plugin.exp: Add location-overflow-test-pr116047.c + and location-overflow-test-pr120061.c. + * gcc.dg/plugin/location_overflow_plugin.c (plugin_init): Don't error + on unknown values, instead just break. + * gcc.dg/plugin/location-overflow-test-pr116047.c: New test. + * gcc.dg/plugin/location-overflow-test-pr116047-1.h: New test. + * gcc.dg/plugin/location-overflow-test-pr116047-2.h: New test. + * gcc.dg/plugin/location-overflow-test-pr120061.c: New test. + * gcc.dg/plugin/location-overflow-test-pr120061-1.h: New test. + * gcc.dg/plugin/location-overflow-test-pr120061-2.h: New test. + +Upstream-Status: Backport [https://gcc.gnu.org/cgit/gcc/commit/?id=edf745dc519ddbfef127e2789bf11bfbacd300b7] +Signed-off-by: Yash Shinde +--- + .../plugin/location-overflow-test-pr116047-1.h | 6 +++ + .../plugin/location-overflow-test-pr116047-2.h | 1 + + .../plugin/location-overflow-test-pr116047.c | 5 +++ + .../plugin/location-overflow-test-pr120061-1.h | 6 +++ + .../plugin/location-overflow-test-pr120061-2.h | 1 + + .../plugin/location-overflow-test-pr120061.c | 6 +++ + .../gcc.dg/plugin/location_overflow_plugin.c | 2 +- + gcc/testsuite/gcc.dg/plugin/plugin.exp | 4 +- + libcpp/line-map.cc | 48 ++++++++++++++++++---- + 10 files changed, 69 insertions(+), 18 deletions(-) + create mode 100644 gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr116047-1.h + create mode 100644 gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr116047-2.h + create mode 100644 gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr116047.c + create mode 100644 gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr120061-1.h + create mode 100644 gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr120061-2.h + create mode 100644 gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr120061.c + +diff --git a/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr116047-1.h b/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr116047-1.h +new file mode 100644 +index 000000000000..3dd6434a938b +--- /dev/null ++++ b/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr116047-1.h +@@ -0,0 +1,6 @@ ++ ++ ++ ++ ++#include "location-overflow-test-pr116047-2.h" ++static_assert (__LINE__ == 6, ""); +diff --git a/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr116047-2.h b/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr116047-2.h +new file mode 100644 +index 000000000000..048f715b4656 +--- /dev/null ++++ b/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr116047-2.h +@@ -0,0 +1 @@ ++int i; +diff --git a/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr116047.c b/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr116047.c +new file mode 100644 +index 000000000000..33f2c4ce8def +--- /dev/null ++++ b/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr116047.c +@@ -0,0 +1,5 @@ ++/* PR preprocessor/116047 */ ++/* { dg-do preprocess } */ ++/* { dg-options "-nostdinc -std=c23 -fplugin-arg-location_overflow_plugin-value=0x4fff8080" } */ ++#include "location-overflow-test-pr116047-1.h" ++/* { dg-final { scan-file location-overflow-test-pr116047.i "static_assert\[^\n\r]\*6\[^\n\r]\*== 6" } } */ +diff --git a/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr120061-1.h b/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr120061-1.h +new file mode 100644 +index 000000000000..ebf7704f568e +--- /dev/null ++++ b/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr120061-1.h +@@ -0,0 +1,6 @@ ++ ++ ++ ++ ++#include "location-overflow-test-pr120061-2.h" ++ +diff --git a/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr120061-2.h b/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr120061-2.h +new file mode 100644 +index 000000000000..048f715b4656 +--- /dev/null ++++ b/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr120061-2.h +@@ -0,0 +1 @@ ++int i; +diff --git a/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr120061.c b/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr120061.c +new file mode 100644 +index 000000000000..e8e803898da3 +--- /dev/null ++++ b/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr120061.c +@@ -0,0 +1,6 @@ ++/* PR preprocessor/120061 */ ++/* { dg-do preprocess } */ ++/* { dg-options "-nostdinc -std=c23 -fplugin-arg-location_overflow_plugin-value=0x61000000" } */ ++#include "location-overflow-test-pr120061-1.h" ++static_assert (__LINE__ == 5, ""); ++/* { dg-final { scan-file location-overflow-test-pr120061.i "static_assert\[^\n\r]\*5\[^\n\r]\*== 5" } } */ +diff --git a/gcc/testsuite/gcc.dg/plugin/location_overflow_plugin.c b/gcc/testsuite/gcc.dg/plugin/location_overflow_plugin.c +index d0a6b0755648..6f4497a1cb16 100644 +--- a/gcc/testsuite/gcc.dg/plugin/location_overflow_plugin.c ++++ b/gcc/testsuite/gcc.dg/plugin/location_overflow_plugin.c +@@ -101,7 +101,7 @@ plugin_init (struct plugin_name_args *plugin_info, + break; + + default: +- error_at (UNKNOWN_LOCATION, "unrecognized value for plugin argument"); ++ break; + } + + return 0; +diff --git a/gcc/testsuite/gcc.dg/plugin/plugin.exp b/gcc/testsuite/gcc.dg/plugin/plugin.exp +index 933f9a5850bc..438c6d87aad9 100644 +--- a/gcc/testsuite/gcc.dg/plugin/plugin.exp ++++ b/gcc/testsuite/gcc.dg/plugin/plugin.exp +@@ -126,7 +126,9 @@ set plugin_test_list [list \ + { location_overflow_plugin.c \ + location-overflow-test-1.c \ + location-overflow-test-2.c \ +- location-overflow-test-pr83173.c } \ ++ location-overflow-test-pr83173.c \ ++ location-overflow-test-pr116047.c \ ++ location-overflow-test-pr120061.c } \ + { must_tail_call_plugin.c \ + must-tail-call-1.c \ + must-tail-call-2.c } \ +diff --git a/libcpp/line-map.cc b/libcpp/line-map.cc +index d5200b317eee..1e659638d9f7 100644 +--- a/libcpp/line-map.cc ++++ b/libcpp/line-map.cc +@@ -618,8 +618,8 @@ linemap_add (line_maps *set, enum lc_reason reason, + #include "included", inside the same "includer" file. */ + + linemap_assert (!MAIN_FILE_P (map - 1)); +- /* (MAP - 1) points to the map we are leaving. The +- map from which (MAP - 1) got included should be the map ++ /* (MAP - 1) points to the map we are leaving. The ++ map from which (MAP - 1) got included should be usually the map + that comes right before MAP in the same file. */ + from = linemap_included_from_linemap (set, map - 1); + +@@ -627,7 +627,24 @@ linemap_add (line_maps *set, enum lc_reason reason, + if (to_file == NULL) + { + to_file = ORDINARY_MAP_FILE_NAME (from); +- to_line = SOURCE_LINE (from, from[1].start_location); ++ /* Compute the line on which the map resumes, for #include this ++ should be the line after the #include line. Usually FROM is ++ the map right before LC_ENTER map - the first map of the included ++ file, and in that case SOURCE_LINE (from, from[1].start_location); ++ computes the right line (and does handle even some special cases ++ (e.g. where for returning from we still want to ++ be at line 0 or some -traditional-cpp cases). In rare cases ++ FROM can be followed by LC_RENAME created by linemap_line_start ++ for line right after #include line. If that happens, ++ start_location of the FROM[1] map will be the same as ++ start_location of FROM[2] LC_ENTER, but FROM[1] start_location ++ might not have advance enough for moving to a full next line. ++ In that case compute the line of #include line and add 1 to it ++ to advance to the next line. See PR120061. */ ++ if (from[1].reason == LC_RENAME) ++ to_line = SOURCE_LINE (from, linemap_included_from (map - 1)) + 1; ++ else ++ to_line = SOURCE_LINE (from, from[1].start_location); + sysp = ORDINARY_MAP_IN_SYSTEM_HEADER_P (from); + } + else +@@ -657,11 +674,26 @@ linemap_add (line_maps *set, enum lc_reason reason, + if (set->depth == 0) + map->included_from = 0; + else +- /* The location of the end of the just-closed map. */ +- map->included_from +- = (((map[0].start_location - 1 - map[-1].start_location) +- & ~((1 << map[-1].m_column_and_range_bits) - 1)) +- + map[-1].start_location); ++ { ++ /* Compute location from whence this line map was included. ++ For #include this should be preferrably column 0 of the ++ line on which #include directive appears. ++ map[-1] is the just closed map and usually included_from ++ falls within that map. In rare cases linemap_line_start ++ can insert a new LC_RENAME map for the line immediately ++ after #include line, in that case map[-1] will have the ++ same start_location as the new one and so included_from ++ would not be from map[-1] but likely map[-2]. If that ++ happens, mask off map[-2] m_column_and_range_bits bits ++ instead of map[-1]. See PR120061. */ ++ int i = -1; ++ while (map[i].start_location == map[0].start_location) ++ --i; ++ map->included_from ++ = (((map[0].start_location - 1 - map[i].start_location) ++ & ~((1 << map[i].m_column_and_range_bits) - 1)) ++ + map[i].start_location); ++ } + set->depth++; + if (set->trace_includes) + trace_include (set, map); +--