[Bug fortran/56659] New: Segfault due to missing libcpp error handler for "gfortran -cpp"

[Bug fortran/56659] New: Segfault due to missing libcpp error handler for "gfortran -cpp"

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56659

             Bug #: 56659
           Summary: Segfault due to missing libcpp error handler for
                    "gfortran -cpp"
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Keywords: ice-on-invalid-code
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: burnus@gcc.gnu.org
                CC: kapinos@rz.rwth-aachen.de


Reported by Paul Kapinos at fortran@gcc,
http://thread.gmane.org/gmane.comp.gcc.fortran/40495
http://gcc.gnu.org/ml/fortran/2013-03/msg00083.html

The problem is that libcpp calls an error handler, which is not set in f951.


Namely,   pfile->cb.error == NULL  but should be point to a function; it has
the the prototype:
 bool (*)(cpp_reader *, int, int, source_location, unsigned int, const char *,
          va_list *) 
C/C++ use:
   in c-opts.c: "cb->error = c_cpp_error;"
the function is declared in c-family/c-common.c.


Test case:
* mkdir -p foo/bar
* chmod 000 foo
* gfortran -cpp some_file.F90

[Bug fortran/56659] Segfault due to missing libcpp error handler for "gfortran -cpp"

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56659

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-03-20
     Ever Confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> 2013-03-20 10:49:24 UTC ---
Confirmed.

[Bug fortran/56659] Segfault due to missing libcpp error handler for "gfortran -cpp"

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56659

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> ---
I think this issue is already fixed for a while.

An issue related to the callback init coming too late for libcpp / incpath.c's
call has been fixed by the first of the second commit in PR 55534 – However,
for the issue reported in this PR, the callbacks were already initialized
before the PR55534 fix.

Hence close as FIXED.

[Bug fortran/56659] Segfault due to missing libcpp error handler for "gfortran -cpp"

[kapinos at rz dot rwth-aachen.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56659

--- Comment #5 from Paul <kapinos at rz dot rwth-aachen.de> ---
Just tried all versions of gfortran available up to 10.2.0: the very same
'internal compiler error' is still reported using the initial reproducer. 

May that be connected to the old Linux we're using (CentOS 7.8)? 

pk224850@linuxc2:~/bugreports/GCC/007-ICE_unavailbale_Idir[524]$ ./runme007.sh  
mkdir: cannot create directory ‘foo’: Permission denied
------------------------------------------------------------------------------
f951: Warning: Include directory ‘./foo/bar’: Permission denied
f951: internal compiler error: in cpp_diagnostic_at, at libcpp/errors.c:41
0x14f3468 cpp_diagnostic_at
        ../../../SOURCES/gcc-10.2.0/libcpp/errors.c:41
0x14f3468 cpp_diagnostic_at
        ../../../SOURCES/gcc-10.2.0/libcpp/errors.c:34
0x14f3468 cpp_diagnostic
        ../../../SOURCES/gcc-10.2.0/libcpp/errors.c:75
0x14f34f9 cpp_error(cpp_reader*, cpp_diagnostic_level, char const*, ...)
        ../../../SOURCES/gcc-10.2.0/libcpp/errors.c:89
0x9d5326 remove_duplicates
        ../../../SOURCES/gcc-10.2.0/gcc/incpath.c:260
0x9d58c9 merge_include_chains
        ../../../SOURCES/gcc-10.2.0/gcc/incpath.c:371
0x9d58c9 register_include_chains(cpp_reader*, char const*, char const*, char
const*, int, int, int)
        ../../../SOURCES/gcc-10.2.0/gcc/incpath.c:498
0x654169 gfc_cpp_register_include_paths()
        ../../../SOURCES/gcc-10.2.0/gcc/fortran/cpp.c:722
0x654169 gfc_cpp_post_options()
        ../../../SOURCES/gcc-10.2.0/gcc/fortran/cpp.c:494
0x6c8b50 gfc_post_options(char const**)
        ../../../SOURCES/gcc-10.2.0/gcc/fortran/options.c:488
0x63044a process_options
        ../../../SOURCES/gcc-10.2.0/gcc/toplev.c:1384
0x63044a do_compile
        ../../../SOURCES/gcc-10.2.0/gcc/toplev.c:2200
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
------------------------------------------------------------------------------
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local_rwth/sw/gcc/10.2.0/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
Target: x86_64-pc-linux-gnu
Configured with: ../../SOURCES/gcc-10.2.0/configure
--prefix=/usr/local_rwth/sw/gcc/10.2.0 --enable-offload-targets=nvptx-none
--enable-languages=c,c++,objc,obj-c++,fortran --enable-lto
--enable-install-libiberty
--with-gmp=/w0/tmp/pk224850/GCC/build/destdir/usr/local_rwth/sw/gcc/10.2.0
--with-mpfr=/w0/tmp/pk224850/GCC/build/destdir/usr/local_rwth/sw/gcc/10.2.0
--with-mpc=/w0/tmp/pk224850/GCC/build/destdir/usr/local_rwth/sw/gcc/10.2.0
--with-ppl=/w0/tmp/pk224850/GCC/build/destdir/usr/local_rwth/sw/gcc/10.2.0
--with-isl --with-default-libstdcxx-abi=gcc4-compatible
LDFLAGS='-Wl,-rpath,/usr/local_rwth/sw/gcc/10.2.0/lib64
-Wl,-rpath,/usr/local_rwth/sw/gcc/10.2.0/lib'
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (GCC)

[Bug fortran/56659] Segfault due to missing libcpp error handler for "gfortran -cpp"

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56659

--- Comment #6 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Paul from comment #5)
> Just tried all versions of gfortran available up to 10.2.0: the very same
> 'internal compiler error' is still reported using the initial reproducer. 

Can you share the initial reproducer? The email link to gmane no longer works
and what is written in the the original description and in the other email
lacks the details. It only has:

Test case:
* mkdir -p foo/bar
* chmod 000 foo
* gfortran -cpp some_file.F90

But that obviously does not use 'foo/bar' at all.

I have no idea what's in 'some_file.F90'; the most straight-forward input would
be:
  echo '#include "foo/bar/file.f90"' > some_file.F90
but when I try this, GCC 7, 8, 9, 10 of Ubuntu and the current development
version all show the same:
  some_file.F90:2:2:
  Fatal Error: foo/bar/file.f90: Permission denied

(The off-by-one line number issue is PR 100904.)

I assume that your file contains something different - but what? Can you
enlighten me?

 * * *

A couple of fixes were done in the development branch (to be released as GCC 12
around April), cf. PR 55534.

[Bug fortran/56659] Segfault due to missing libcpp error handler for "gfortran -cpp"

[kapinos at itc dot rwth-aachen.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56659

--- Comment #7 from kapinos at itc dot rwth-aachen.de ---
Sorry, for not adding the reproducer again. It is very K.I.S.S.:

- make (or reuse) an dir w/o read permissions
- use it as include dir at *any* Fortran source including empty ones.

The output of gfortran 10.2.0 was added previously, cf.
 > f951: Warning: Include directory ‘./foo/bar’: Permission denied
 > f951: internal compiler error: in cpp_diagnostic_at, at libcpp/errors.c:41
.......




$ cat runme007.sh
mkdir -p foo/bar
chmod 000 foo
echo
"-------------------------------------------------------------------------"
gfortran -c  -I./foo/bar mini.F90
echo "------------------------------------------------------------------------"
gfortran -v

$ cat mini.F90
program mini
end







On 10/6/21 11:23 PM, burnus at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56659
> 
> --- Comment #6 from Tobias Burnus <burnus at gcc dot gnu.org> ---
> (In reply to Paul from comment #5)
>> Just tried all versions of gfortran available up to 10.2.0: the very same
>> 'internal compiler error' is still reported using the initial reproducer.
> 
> Can you share the initial reproducer? The email link to gmane no longer works
> and what is written in the the original description and in the other email
> lacks the details. It only has:
> 
> Test case:
> * mkdir -p foo/bar
> * chmod 000 foo
> * gfortran -cpp some_file.F90
> 
> But that obviously does not use 'foo/bar' at all.
> 
> I have no idea what's in 'some_file.F90'; the most straight-forward input would
> be:
>    echo '#include "foo/bar/file.f90"' > some_file.F90
> but when I try this, GCC 7, 8, 9, 10 of Ubuntu and the current development
> version all show the same:
>    some_file.F90:2:2:
>    Fatal Error: foo/bar/file.f90: Permission denied
> 
> (The off-by-one line number issue is PR 100904.)
> 
> I assume that your file contains something different - but what? Can you
> enlighten me?
> 
>   * * *
> 
> A couple of fixes were done in the development branch (to be released as GCC 12
> around April), cf. PR 55534.
>

[Bug fortran/56659] Segfault due to missing libcpp error handler for "gfortran -cpp"

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56659

--- Comment #8 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to kapinos from comment #7)
> The output of gfortran 10.2.0 was added previously, cf.
>  > f951: Warning: Include directory ‘./foo/bar’: Permission denied
>  > f951: internal compiler error: in cpp_diagnostic_at, at libcpp/errors.c:41

I can reproduce this with GCC 7 to 10. But with my patch for PR 100904 (see
commit there), this is fixed in GCC 12:

  f951: Warning: Include directory ‘foo/bar/’: Permission denied
  <built-in>: Error: foo/bar: Permission denied

(The <built-in> shows up when entering a file but the file is not yet there.
Not ideal,
but not that quick to fix. Once the file is read, that's replaced by the file
name and line number. Still, the <built-in> issue should be fixed eventually.)

[Bug fortran/56659] Segfault due to missing libcpp error handler for "gfortran -cpp"

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56659

--- Comment #9 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Tobias Burnus from comment #8)
>   f951: Warning: Include directory ‘foo/bar/’: Permission denied
>   <built-in>: Error: foo/bar: Permission denied
> 
> (The <built-in> shows up when entering a file but the file is not yet there.
> Not ideal,
> but not that quick to fix. Once the file is read, that's replaced by the
> file name and line number. Still, the <built-in> issue should be fixed
> eventually.)

Hi Tobias,

Are you sure the Error is produced *after* entering the file (by entering I
mean pushing the file into the include stack and thus updating the line-map).
If so, then the line-maps are not correctly named and the diagnostic wants to
print some filename but the line-map or the include stack says that the name of
the file is <built-in>.

But it could also be that the Error is produced *before* entering the file.
Then, the bug is that something else has pushed the <built-in> context into the
line-map stack. This should be command-line context and produce:

f951: Error: foo/bar: Permission denied

or:

<command-line>: Error: foo/bar: Permission denied

In either case, this points to some mess in the line-map stack.

[Bug fortran/56659] Segfault due to missing libcpp error handler for "gfortran -cpp"

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56659

--- Comment #10 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #9)
> (In reply to Tobias Burnus from comment #8)
> >   f951: Warning: Include directory ‘foo/bar/’: Permission denied
> >   <built-in>: Error: foo/bar: Permission denied
> > (The <built-in> 
>
> Are you sure the Error is produced *after* entering the file (by entering I
> mean pushing the file into the include stack and thus updating the
> line-map).

I was too brief. It occurs between the two. The full version is:

If everything is not on the file stack 'f951' is printed, then the '<build-in>'
stuff happens, from "gfc_cpp_init":

    cpp_change_file (cpp_in, LC_RENAME, _("<built-in>"));
    ....
  cpp_change_file (cpp_in, LC_RENAME, _("<command-line>"));

(similar: c-family/c-opts.c: c_finish_options)

This could be undone (to print 'f951') by calling cpp_change_file with to_file
= NULL – but I am sure it won't have undesired side effect.


And only after the file has been successfully opened, linemap_add is called.
Thus, the '<built-in>' shows up between gfc_cpp_init() and linemap_add.

Or code wise, in gfc_init:

  if (!gfc_cpp_enabled ())
    {
      linemap_add (line_table, LC_ENTER, false, gfc_source_file, 1);
      linemap_add (line_table, LC_RENAME, false, "<built-in>", 0);
    }
  else
    gfc_cpp_init_0 ();
...
  if (gfc_cpp_enabled ())
    gfc_cpp_init ();
...
  gfc_new_file ();

with gfc_new_file:

  if (gfc_cpp_enabled ())
    {
      gfc_cpp_preprocess (gfc_source_file);
      if (!gfc_cpp_preprocess_only ())
        load_file (gfc_cpp_temporary_file (), gfc_source_file, true);
    }
  else
    load_file (gfc_source_file, NULL, true);

and in load_file:

        input = gfc_open_file (realfilename);

      if (input == NULL)
        gfc_fatal_error ("Cannot open file %qs", filename);
...
  f = get_file (filename, (initial && !preprocessed_p) ? LC_RENAME : LC_ENTER);

the latter then calls

  linemap_add (line_table, reason, false, f->filename, 1);

> In either case, this points to some mess in the line-map stack.

Suggestions how to improve the code above?