[Bug target/114049] New: gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3

[Bug target/114049] New: gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3

[ro at gcc dot gnu.org]

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

            Bug ID: 114049
           Summary: gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ro at gcc dot gnu.org
                CC: iains at gcc dot gnu.org
  Target Milestone: ---
            Target: x86_64-apple-darwin23.3.0

When testing Xcode 15.3 beta 3 on macOS 14.3.1, I found (after PR
preprocessor/114007
was fixed) only a single regression compared to Xcode 15.1:

FAIL: gcc.dg/framework-1.c (test for excess errors)

Excess errors:
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Headers/string.h:55:10:
fatal error: machine/trap.h: No such file or directory
compilation terminated.

which seems correct, the only <machine/trap.h> lives in
/Library/Developer/CommandLineTools/SDKs/MacOSX14.4.sdk/System/Librar/Frameworks/Kernel.framework/Versions/A/Headers/machine/trap.h

I haven't digged further yet, like comparing with 15.1.

[Bug target/114049] gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3

[ro at gcc dot gnu.org]

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

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |14.0

[Bug target/114049] gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3

[iains at gcc dot gnu.org]

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

--- Comment #1 from Iain Sandoe <iains at gcc dot gnu.org> ---
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Headers
should be a symlink to
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Versions/A/Headers


so either that's broken or we're failing to follow a symlink somehow.

[Bug target/114049] gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #1 from Iain Sandoe <iains at gcc dot gnu.org> ---
> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Headers
> should be a symlink to
> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Versions/A/Headers

More or less: the symlink is to Versions/Current/Headers.

> so either that's broken or we're failing to follow a symlink somehow.

I've checked: the original invocation is

/private/var/gcc/regression/master/14-gcc/build/gcc/xgcc
-B/private/var/gcc/regression/master/14-gcc/build/gcc/
/vol/gcc/src/hg/master/darwin/gcc/testsuite/gcc.dg/framework-1.c
-fdiagnostics-plain-output -F. -S -o framework-1.s

with cc1 called like

 /private/var/gcc/regression/master/14-gcc/build/gcc/cc1 -quiet -v -F. -iprefix
/private/var/gcc/regression/master/14-gcc/build/gcc/../lib/gcc/x86_64-apple-darwin23.3.0/14.0.1/
-isystem /private/var/gcc/regression/master/14-gcc/build/gcc/include -isystem
/private/var/gcc/regression/master/14-gcc/build/gcc/include-fixed -D__DYNAMIC__
/vol/gcc/src/hg/master/darwin/gcc/testsuite/gcc.dg/framework-1.c -fPIC -quiet
-dumpbase framework-1.c -dumpbase-ext .c -mmacosx-version-min=14.0.0
-mtune=core2 -version -fdiagnostics-color=never -fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers -fdiagnostics-urls=never
-fdiagnostics-path-format=separate-events -fdiagnostics-text-art-charset=none
-o framework-1.s

After the usual messages about nonexistant directories, we get to

#include <...> search starts here:
 .
 /private/var/gcc/regression/master/14-gcc/build/gcc/include
 /private/var/gcc/regression/master/14-gcc/build/gcc/include-fixed
 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include
 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks
End of search list.

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Headers/string.h

has 

#include <machine/trap.h>

which lives in

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Versions/A/Headers/machine/trap.h

Given the above search list, "machine/trap.h" should work, but
<machine/trap.h> doesn't.

When using the bundled clang, I get

$ clang /vol/gcc/src/hg/master/darwin/gcc/testsuite/gcc.dg/framework-1.c -F. -S
-o framework-1.s 
In file included from
/vol/gcc/src/hg/master/darwin/gcc/testsuite/gcc.dg/framework-1.c:4:
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Headers/string.h:55:10:
error: 'machine/trap.h' file not found with <angled> include; use "quotes"
instead
#include <machine/trap.h>
         ^
In file included from
/vol/gcc/src/hg/master/darwin/gcc/testsuite/gcc.dg/framework-1.c:4:
In file included from
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Headers/string.h:55:
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Headers/machine/trap.h:32:10:
fatal error: 'i386/trap.h' file not found
#include "i386/trap.h"
         ^~~~~~~~~~~~~
2 errors generated.

[Bug target/114049] gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3

[iains at gcc dot gnu.org]

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

--- Comment #3 from Iain Sandoe <iains at gcc dot gnu.org> ---
so .. if i follow your discussion correctly - neither clang nor gcc finds it
because it's incorrectly quoted (is that an SDK issue?).. or?

We do have control, IIRC, about adding the frameworks search path to "system"
rather than "user".

[Bug target/114049] gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #3 from Iain Sandoe <iains at gcc dot gnu.org> ---
> so .. if i follow your discussion correctly - neither clang nor gcc finds it
> because it's incorrectly quoted (is that an SDK issue?).. or?

The quoting is one part, certainly.  While clang falls back from <> to
"", gcc does not.  However, even if I change string.h locally to use "",
while this allows machine/trap.h to be found, the subsequent i386/trap.h
is still not found, neither by gcc nor by clang.

I have not idea what they are doing here, but the same construct is used
all over Frameworks/Kernel.framework/Headers.

> We do have control, IIRC, about adding the frameworks search path to "system"
> rather than "user".

That might be an option: I guess we should follow what clang does here.

[Bug target/114049] gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3

[iains at gcc dot gnu.org]

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

--- Comment #5 from Iain Sandoe <iains at gcc dot gnu.org> ---
The manual currently says:
-I dir
-iquote dir
-isystem dir
-idirafter dir

Add the directory dir to the list of directories to be searched for header
files dur- ing preprocessing. If dir begins with ‘=’ or $SYSROOT, then the ‘=’
or $SYSROOT is replaced by the sysroot prefix; see --sysroot and -isysroot.

Directories specified with -iquote apply only to the quote form of the
directive, #include "file".

>>> Directories specified with -I, -isystem, or -idirafter apply to lookup for both the #include "file" and #include <file> directives. <<<

You can specify any number or combination of these options on the command line
to search for header files in several directories. The lookup order is as
follows:
1. Forthequoteformoftheincludedirective,thedirectoryofthecurrentfile is
searched first.
2. For the quote form of the include directive, the directories specified by
-iquote options are searched in left-to-right order, as they appear on the
command line.
3. Directories specified with -I options are scanned in left-to-right order.
4. Directories specified with -isystem options are scanned in left-to-right
order.
5. Standard system directories are scanned.
6. Directories specified with -idirafter options are scanned in left-to-right 

The highlighted bit seems to say we should be searching for either "" or <> ..
I wonder if something is being confused by the user framework path (-F .)

[Bug target/114049] gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3

[iains at gcc dot gnu.org]

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

--- Comment #6 from Iain Sandoe <iains at gcc dot gnu.org> ---
I'm still finding this a bit confusing.

- we have not altered the code in this area (at least not the Darwin parts)
during the gcc-14 cycle.

- apparently, it works with previous Xcode versions/SDKs

- from your comment #2 

"$ clang /vol/gcc/src/hg/master/darwin/gcc/testsuite/gcc.dg/framework-1.c -F.
-S -o framework-1.s 
In file included from
/vol/gcc/src/hg/master/darwin/gcc/testsuite/gcc.dg/framework-1.c:4:
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Headers/string.h:55:10:
error: 'machine/trap.h' file not found with <angled> include; use "quotes"
instead
#include <machine/trap.h>
"

that seems to be an error, not a warning (even if it diagnoses better than we
do).

- even if it tries to fall back to the "" version, that still should not find
the header according to the information in comment #5 - since we so not add any
paths below Library/Frameworks .. so 'machine' is only a top level include
directory in /usr/include (and it does not contain trap.h).

[Bug target/114049] gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:

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

--- Comment #7 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
I'd say that a SDK bug? It definitely shows with clang, so I filed it as
FB13678545 with Apple.

[Bug target/114049] gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3

[iains at gcc dot gnu.org]

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

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2024-03-16

--- Comment #8 from Iain Sandoe <iains at gcc dot gnu.org> ---
according to information from the Apple OSS folks, the Kernel.framework is/was
(never) intended to be used as a regular framework.  [This was news to me,
FWIW, and it does seem a somewhat odd situation, since it's wrapped up in all
the necessary machinery which makes it look like it should work].

.... anyway ....

What we want from this test is that a suitable framework is found in
/System/Library/Frameworks when the user has also given a local framework path
(-F.).

What we want to avoid is the test regressing because of incidental SDK changes
(like unguarded Apple Black usage) - so we have picked the kernel framework and
a suitable low-complexity header.

At present, I am thinking that IOkit/IOReturn.h might be a suitable substitute
- but that needs to be checked across the range of OS versions supported.

[Bug target/114049] gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Iain D Sandoe <iains@gcc.gnu.org>:

https://gcc.gnu.org/g:4adb1a5839e7a3310a127c1776f1f95d7edaa6ff

commit r14-9543-g4adb1a5839e7a3310a127c1776f1f95d7edaa6ff
Author: Iain Sandoe <iain@sandoe.co.uk>
Date:   Mon Mar 18 10:06:44 2024 +0000

    testsuite, Darwin: Use the IOKit framework in framework-1.c [PR114049].

    The intent of the test is to show that we find a framework that
    is installed in /System/Library/Frameworks when the user has added
    a '-F' option.  The trick is to choose some header that is present
    for all the Darwin versions we support and that does not contain any
    content we cannot parse.  We had been using the Kernel framework for
    this, but recent SDK versions have revealed that this is not suitable.

    Replacing with a use of IOKit.

            PR target/114049

    gcc/testsuite/ChangeLog:

            * gcc.dg/framework-1.c: Use an IOKit header instead of a
            Kernel one.

    Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>

[Bug target/114049] gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3

[iains at gcc dot gnu.org]

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

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|14.0                        |11.5

--- Comment #10 from Iain Sandoe <iains at gcc dot gnu.org> ---
fixed on trunk, but this will need back porting to avoid fails when building
the release branches with latest toolchains / on newest OS versions.

[Bug target/114049] gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Iain D Sandoe
<iains@gcc.gnu.org>:

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

commit r13-8584-gb03827b261d3c8351f9c208fe2d89ca987a25bee
Author: Iain Sandoe <iain@sandoe.co.uk>
Date:   Mon Mar 18 10:06:44 2024 +0000

    testsuite, Darwin: Use the IOKit framework in framework-1.c [PR114049].

    The intent of the test is to show that we find a framework that
    is installed in /System/Library/Frameworks when the user has added
    a '-F' option.  The trick is to choose some header that is present
    for all the Darwin versions we support and that does not contain any
    content we cannot parse.  We had been using the Kernel framework for
    this, but recent SDK versions have revealed that this is not suitable.

    Replacing with a use of IOKit.

            PR target/114049

    gcc/testsuite/ChangeLog:

            * gcc.dg/framework-1.c: Use an IOKit header instead of a
            Kernel one.

    Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
    (cherry picked from commit 4adb1a5839e7a3310a127c1776f1f95d7edaa6ff)

[Bug target/114049] gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Iain D Sandoe
<iains@gcc.gnu.org>:

https://gcc.gnu.org/g:4c8d37badaa42e85218eb9b89aef3e4f6cf4486e

commit r12-10375-g4c8d37badaa42e85218eb9b89aef3e4f6cf4486e
Author: Iain Sandoe <iain@sandoe.co.uk>
Date:   Mon Mar 18 10:06:44 2024 +0000

    testsuite, Darwin: Use the IOKit framework in framework-1.c [PR114049].

    The intent of the test is to show that we find a framework that
    is installed in /System/Library/Frameworks when the user has added
    a '-F' option.  The trick is to choose some header that is present
    for all the Darwin versions we support and that does not contain any
    content we cannot parse.  We had been using the Kernel framework for
    this, but recent SDK versions have revealed that this is not suitable.

    Replacing with a use of IOKit.

            PR target/114049

    gcc/testsuite/ChangeLog:

            * gcc.dg/framework-1.c: Use an IOKit header instead of a
            Kernel one.

    Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
    (cherry picked from commit 4adb1a5839e7a3310a127c1776f1f95d7edaa6ff)

[Bug target/114049] gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3

[cvs-commit at gcc dot gnu.org]

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

--- Comment #13 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Iain D Sandoe
<iains@gcc.gnu.org>:

https://gcc.gnu.org/g:729170a45040e96d567be79bda00604a7645a23d

commit r11-11402-g729170a45040e96d567be79bda00604a7645a23d
Author: Iain Sandoe <iain@sandoe.co.uk>
Date:   Mon Mar 18 10:06:44 2024 +0000

    testsuite, Darwin: Use the IOKit framework in framework-1.c [PR114049].

    The intent of the test is to show that we find a framework that
    is installed in /System/Library/Frameworks when the user has added
    a '-F' option.  The trick is to choose some header that is present
    for all the Darwin versions we support and that does not contain any
    content we cannot parse.  We had been using the Kernel framework for
    this, but recent SDK versions have revealed that this is not suitable.

    Replacing with a use of IOKit.

            PR target/114049

    gcc/testsuite/ChangeLog:

            * gcc.dg/framework-1.c: Use an IOKit header instead of a
            Kernel one.

    Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
    (cherry picked from commit 4adb1a5839e7a3310a127c1776f1f95d7edaa6ff)

[Bug target/114049] gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3

[iains at gcc dot gnu.org]

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

Iain Sandoe <iains at gcc dot gnu.org> changed:

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

--- Comment #14 from Iain Sandoe <iains at gcc dot gnu.org> ---
fixed on open branches