[Bug libfortran/101820] New: fatal error: ISO_Fortran_binding.h: No such file or directory

[Bug libfortran/101820] New: fatal error: ISO_Fortran_binding.h: No such file or directory

[ubizjak at gmail dot com]

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

            Bug ID: 101820
           Summary: fatal error: ISO_Fortran_binding.h: No such file or
                    directory
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libfortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ubizjak at gmail dot com
  Target Milestone: ---

There are quite some FAILs in the gfortran testsuite, e.g.:

FAIL: gfortran.dg/ISO_Fortran_binding_1.f90   -O0  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_1.f90   -O1  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_1.f90   -O2  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_1.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess
errors)
FAIL: gfortran.dg/ISO_Fortran_binding_1.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_1.f90   -Os  (test for excess errors)
...

where:

/home/uros/git/gcc/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_1.c:3:10:
fatal error: ISO_Fortran_binding.h: No such file or directory
compilation terminated.
compiler exited with status 1
FAIL: gfortran.dg/ISO_Fortran_binding_1.f90   -O3 -g  (test for excess errors)
Excess errors:
/home/uros/git/gcc/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_1.c:3:10:
fatal error: ISO_Fortran_binding.h: No such file or directory
compilation terminated.

UNRESOLVED: gfortran.dg/ISO_Fortran_binding_1.f90   -O3 -g  compilation failed
to produce executable


The file ISO_Fortran_binding.h is present in the libgfortran build directory,
but it looks to me that -I is missing when building the testcase:

/home/uros/gcc-build/gcc/testsuite/gfortran/../../gfortran
-B/home/uros/gcc-build/gcc/testsuite/gfortran/../../
-B/home/uros/gcc-build/x86_64-pc-linux-gnu/./libgfortran/
/home/uros/git/gcc/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_1.f90
-fdiagnostics-plain-output -fdiagnostics-plain-output -O3 -g -pedantic-errors
/home/uros/git/gcc/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_1.c -dumpbase 
-B/home/uros/gcc-build/x86_64-pc-linux-gnu/./libgfortran/.libs
-L/home/uros/gcc-build/x86_64-pc-linux-gnu/./libgfortran/.libs
-L/home/uros/gcc-build/x86_64-pc-linux-gnu/./libgfortran/.libs
-L/home/uros/gcc-build/x86_64-pc-linux-gnu/./libatomic/.libs
-B/home/uros/gcc-build/x86_64-pc-linux-gnu/./libquadmath/.libs
-L/home/uros/gcc-build/x86_64-pc-linux-gnu/./libquadmath/.libs
-L/home/uros/gcc-build/x86_64-pc-linux-gnu/./libquadmath/.libs -lm -o
./ISO_Fortran_binding_1.exe
/home/uros/git/gcc/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_1.c:3:10:
fatal error: ISO_Fortran_binding.h: No such file or directory
compilation terminated.

Adding "-I/home/uros/gcc-build/x86_64-pc-linux-gnu/libgfortran" to the above
command fixes the compilation.

[Bug libfortran/101820] fatal error: ISO_Fortran_binding.h: No such file or directory

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-08-09
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.

[Bug libfortran/101820] fatal error: ISO_Fortran_binding.h: No such file or directory

[ubizjak at gmail dot com]

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

Uroš Bizjak <ubizjak at gmail dot com> changed:

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

--- Comment #2 from Uroš Bizjak <ubizjak at gmail dot com> ---
Dup.

*** This bug has been marked as a duplicate of bug 101660 ***

[Bug libfortran/101820] fatal error: ISO_Fortran_binding.h: No such file or directory

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>:

https://gcc.gnu.org/g:be4a4fb516688d7cfe28a80a4aa333f4ecf0b518

commit r12-2991-gbe4a4fb516688d7cfe28a80a4aa333f4ecf0b518
Author: Patrick Palka <ppalka@redhat.com>
Date:   Wed Aug 18 08:37:45 2021 -0400

    c++: aggregate CTAD and brace elision [PR101344]

    Here the problem is ultimately that collect_ctor_idx_types always
    recurses into an eligible sub-CONSTRUCTOR regardless of whether the
    corresponding pair of braces was elided in the original initializer.
    This causes us to reject some completely-braced forms of aggregate
    CTAD as in the first testcase below, because collect_ctor_idx_types
    effectively assumes that the original initializer is always minimally
    braced (and so the aggregate deduction candidate is given a function
    type that's incompatible with the original completely-braced initializer).

    In order to fix this, collect_ctor_idx_types needs to somehow know the
    shape of the original initializer when iterating over the reshaped
    initializer.  To that end this patch makes reshape_init flag sub-ctors
    that were built to undo brace elision in the original ctor, so that
    collect_ctor_idx_types that determine whether to recurse into a sub-ctor
    by simply inspecting this flag.

    This happens to also fix PR101820, which is about aggregate CTAD using
    designated initializers, for much the same reasons.

    A curious case is the "intermediately-braced" initialization of 'e3'
    (which we reject) in the first testcase below.  It seems to me we're
    behaving as specified here (according to [over.match.class.deduct]/1)
    because the initializer element x_1={1, 2, 3, 4} corresponds to the
    subobject e_1=E::t, hence the type T_1 of the first function parameter
    of the aggregate deduction candidate is T(&&)[2][2], but T can't be
    deduced from x_1 using this parameter type (as opposed to say T(&&)[4]).

            PR c++/101344
            PR c++/101820

    gcc/cp/ChangeLog:

            * cp-tree.h (CONSTRUCTOR_BRACES_ELIDED_P): Define.
            * decl.c (reshape_init_r): Set it.
            * pt.c (collect_ctor_idx_types): Recurse into a sub-CONSTRUCTOR
            iff CONSTRUCTOR_BRACES_ELIDED_P.

    gcc/testsuite/ChangeLog:

            * g++.dg/cpp2a/class-deduction-aggr11.C: New test.
            * g++.dg/cpp2a/class-deduction-aggr12.C: New test.

[Bug libfortran/101820] fatal error: ISO_Fortran_binding.h: No such file or directory

[ppalka at gcc dot gnu.org]

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

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ppalka at gcc dot gnu.org

--- Comment #4 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Whoops, wrong PR number.. the above commit should refer to PR101803 not
PR101820