Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[clang] -print-target-triple doesn't work properly on Apple platforms #61762

Open
ldionne opened this issue Mar 28, 2023 · 9 comments · Fixed by #104037
Open

[clang] -print-target-triple doesn't work properly on Apple platforms #61762

ldionne opened this issue Mar 28, 2023 · 9 comments · Fixed by #104037
Labels
clang:driver 'clang' and 'clang++' user-facing binaries. Not 'clang-cl'

Comments

@ldionne
Copy link
Member

ldionne commented Mar 28, 2023

$ echo | clang -xc - -###
[...]/bin/clang" "-cc1" "-triple" "arm64-apple-macosx11.0.0" [...]

$ clang -print-target-triple
arm64-apple-darwin22.4.0

So we can see that the compiler knows (at some point) that it should be compiling for macosx11.0.0, but -print-target-triple doesn't know that yet. That's because -print-target-triple is implemented in HandleImmediateArgs which is run before the toolchains::Darwin object is initialized.

@ldionne ldionne added the clang:driver 'clang' and 'clang++' user-facing binaries. Not 'clang-cl' label Mar 28, 2023
@llvmbot
Copy link
Member

llvmbot commented Mar 28, 2023

@llvm/issue-subscribers-clang-driver

@ldionne
Copy link
Member Author

ldionne commented Aug 6, 2024

CC @Xazax-hun Do you think the fix is similar to what you did for #98325?

@Xazax-hun
Copy link
Collaborator

Probably something similar needs to be done for this as well, but I vaguely remember trying this out and had the impression doing the same change for this flag was not sufficient to get the desired results. I did not look deeply why this was the case, and it is also possible I was missing something obvious.

@Xazax-hun
Copy link
Collaborator

Actually, it only needed a minor change after initializing the targets early. Opened a PR: #104037

@Xazax-hun
Copy link
Collaborator

Xazax-hun commented Aug 16, 2024

Reopening, since the PR was reverted. See the discussion at the PR why.

@ldionne
Copy link
Member Author

ldionne commented Aug 21, 2024

Not sure why this was closed again @s-barannikov .

@ldionne ldionne reopened this Aug 21, 2024
@s-barannikov
Copy link
Contributor

s-barannikov commented Aug 21, 2024

I'm shocked. I just pushed some refs to my private clone of llvm. I couldn't imagine such a thing could happen.
This is how it is rendered on my side:
image

@ldionne
Copy link
Member Author

ldionne commented Aug 21, 2024

@tstellar Are you aware of this? Is there a setting we could enable/disable in the monorepo to prevent issues from being closed from pushes to other repositories? That seems like a very dangerous thing to me.

@s-barannikov
Copy link
Contributor

s-barannikov commented Aug 21, 2024

I think it might have happened because the commit message contains the full link to the issue instead of just a hash sign and a number.

I've never seen such an issue before, google is silent, and I didn't even receive a notification.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clang:driver 'clang' and 'clang++' user-facing binaries. Not 'clang-cl'
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants