From patchwork Thu Nov 7 20:41:31 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Tobias Burnus X-Patchwork-Id: 1191418 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-512754-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="UwnGa0vK"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 478Fgs3NZ7z9sPV for ; Fri, 8 Nov 2019 07:41:59 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:to :from:subject:message-id:date:mime-version:content-type; q=dns; s=default; b=vN+GtxnULnSMQh62xyQdR7PfsIVk8IuE4t14ZDulsfFOFWFbs0 +/odzik30eEFymwgOFUH4LedpLwuzAlsUloLh0Mk/tTxcD9Cb3JEDMRyoz3iXA7c z6i1Hd9mLFDI529ugsr37+GniXGwDhPLco5i89A8TLOK+/sKBuXFxnC7A= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:to :from:subject:message-id:date:mime-version:content-type; s= default; bh=ZAgTDe7Uw30/Dg6yD9NkoAi30jk=; b=UwnGa0vK0Sew8FPK+Gn0 Kj4FdR6wQeR8WJqfZOyBL2HAGIA5h/6SkhE7qMeMBRYeaX1XrTz998WFtC+RFT30 zU3NT2ZD4ibvgIYqvnnAe5ycLgvaxfCMbyIICbf8z7W3vy72IZQ3Mcms00pLt1Tm j0iwiuagdovqsyt3T774/2U= Received: (qmail 47057 invoked by alias); 7 Nov 2019 20:41:48 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 47042 invoked by uid 89); 7 Nov 2019 20:41:47 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-21.5 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, SPF_PASS autolearn=ham version=3.3.1 spammy=fpreinclude, fpre-include X-HELO: esa3.mentor.iphmx.com Received: from esa3.mentor.iphmx.com (HELO esa3.mentor.iphmx.com) (68.232.137.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 07 Nov 2019 20:41:46 +0000 IronPort-SDR: TnG8R4YqVIbG0l1kmdPRtozj2ak4tsKKJ4bpipucXVS75fy49RTdUxNyMJxZoSHRb8n4MiVN/Z CrEln1XSP7AmeHUnXvuySRD/BR4p7/P0+lCT+Ezi+t0ZSHklysHfQJ02rAKN+2xwciY+PpC4w0 LdnybL5mWtGFNJwFTyn9Clh25lJgFlc0amiNfSeJNVu+HZQ495GLlVfwIE8aajRBbYsMCZQfOi 2IIVSlEwPBaB8BvMWNYAEc3MKfXtabalYW9OMDeQAOR0QwlRrqBtcyP69VlZ6Qk8fr+B2ZHFDX Hg4= Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa3.mentor.iphmx.com with ESMTP; 07 Nov 2019 12:41:44 -0800 IronPort-SDR: 04+FPLwEju6xUCj3VpModMDdN2n3D1XXBVg2xSnwoubU0yXkT0GtpFtg0Yy+NRC+pnO02KJoCM JPaTkKnBnBQBX/Btv/6Uhjjn5ktoEU/RoldpA6JVRPT8WbKts6rFgZZOUcKPMncCBCd1p8OZEw JQRHgdwyL7JAP5DLLKkfwIlvHQ/HMP6hjj2HYX6Po0xUOBtvJPC7h1NTbkX2SXI/p0ooUkC9rb mFpq+dyi1hAiF4Rwld5gPnwuq415PBtqJEf0MgyXEZ0CawkZ6umYmmyES0IdTOdu4k5IJrypss WkI= To: gcc-patches , fortran From: Tobias Burnus Subject: [Patch][Fortran] PR91253 fix continuation-line handling with -pre_include Message-ID: <36f2cd06-e86a-bcd1-20cf-546b0b5a7d32@codesourcery.com> Date: Thu, 7 Nov 2019 21:41:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.0 MIME-Version: 1.0 X-IsSubscribed: yes This fixes the gfortran.dg/continuation_6.f fails testsuite fails with newer GLIBC. The continuation line handling assumes that the line number starts at 0 (→ continue_line) and then can be incremented, if needed. The problem came up with -pre_include, which is used with newer GLIBC to provide things like "!GCC$ builtin (cos) attributes simd (notinbranch) if('x86_64')". There, first the file math-vector-fortran.h file is loaded, then the actual file. The 'continue_line' gets incremented for math-vector-fortran.h but nothing resets it before parsing the actual input file. For the 'include_stmt' function, the reset happens during parsing – while for our case, this knowledge is only in the line information, but on file change, 'continue_line' is not updated/reset. I think the same issue can occur with #include, especially as one plays with #line, but I have not actually tested it. Obviously, if one plays around with #line during a continuation block, this check won't work either. However, it should fix the most common occurrence. Additionally, I have removed the ATTRIBUTE_UNUSED from get_file's 'reason' as it is used in the linemap_add call. And I have moved the OpenMP/OpenACC comment before if openmp/openacc condition, where in my opinion it belongs to. OK for the trunk? Tobias 2019-11-07 Tobias Burnus gfc_linebuf_linenum (gfc_current_locus.lb) + 1) + continue_line = gfc_linebuf_linenum (gfc_current_locus.lb) + 1; + continue_flag = 1; if (c == '!') skip_comment_line (); @@ -1475,6 +1483,14 @@ restart: if (flag_openacc) prev_openacc_flag = openacc_flag; + /* This can happen if the input file changed or via cpp's #line + without getting reset (e.g. via input_stmt). It also happens + when pre-including files via -fpre-include=. */ + if (continue_count == 0 + && gfc_current_locus.lb + && continue_line > gfc_linebuf_linenum (gfc_current_locus.lb) + 1) + continue_line = gfc_linebuf_linenum (gfc_current_locus.lb) + 1; + continue_flag = 1; old_loc = gfc_current_locus; @@ -1943,7 +1959,7 @@ next_char: the file stack. */ static gfc_file * -get_file (const char *name, enum lc_reason reason ATTRIBUTE_UNUSED) +get_file (const char *name, enum lc_reason reason) { gfc_file *f;