diff mbox series

[Fortran] PR91253 fix continuation-line handling with -pre_include

Message ID 36f2cd06-e86a-bcd1-20cf-546b0b5a7d32@codesourcery.com
State New
Headers show
Series [Fortran] PR91253 fix continuation-line handling with -pre_include | expand

Commit Message

Tobias Burnus Nov. 7, 2019, 8:41 p.m. UTC 
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

Comments

Jerry DeLisle Nov. 8, 2019, 2:50 a.m. UTC | #1 
On 11/7/19 12:41 PM, Tobias Burnus wrote:
> 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
> 

Yes, OK, thanks for patch.

Jerry
diff mbox series

Patch

2019-11-07  Tobias Burnus  <tobias@codesourcery.com

	PR fortran/91253
	* scanner.c (skip_fixed_comments): Move comment
	lines to next if block.
	(gfc_next_char_literal): Fix continue_line setting.
	(get_file): Remove bogus ATTRIBUTE_UNUSED.

diff --git a/gcc/fortran/scanner.c b/gcc/fortran/scanner.c
index e54d483baff..40c06b6b674 100644
--- a/gcc/fortran/scanner.c
+++ b/gcc/fortran/scanner.c
@@ -1050,6 +1050,10 @@  skip_fixed_comments (void)
 	      return;
 	    }
 
+	  if (gfc_current_locus.lb != NULL
+	      && continue_line < gfc_linebuf_linenum (gfc_current_locus.lb))
+	    continue_line = gfc_linebuf_linenum (gfc_current_locus.lb);
+
 	  /* If -fopenmp/-fopenacc, we need to handle here 2 things:
 	     1) don't treat !$omp/!$acc|c$omp/c$acc|*$omp / *$acc as comments, 
 		but directives
@@ -1057,10 +1061,6 @@  skip_fixed_comments (void)
 		!$|c$|*$ should be treated as 2 spaces if the characters
 		in columns 3 to 6 are valid fixed form label columns
 		characters.  */
-	  if (gfc_current_locus.lb != NULL
-	      && continue_line < gfc_linebuf_linenum (gfc_current_locus.lb))
-	    continue_line = gfc_linebuf_linenum (gfc_current_locus.lb);
-
 	  if ((flag_openmp || flag_openmp_simd) && !flag_openacc)
 	    {
 	      if (next_char () == '$')
@@ -1313,6 +1313,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;
       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;