[clang] Use value_or instead of getValueOr (NFC)

[clang-cl] Add support for /kernel

MSVC defines _KERNEL_MODE when /kernel is passed.
Also, /kernel disables RTTI and C++ exception handling.

https://docs.microsoft.com/en-us/cpp/build/reference/ker

[clang-cl] Add support for /kernel

MSVC defines _KERNEL_MODE when /kernel is passed.
Also, /kernel disables RTTI and C++ exception handling.

https://docs.microsoft.com/en-us/cpp/build/reference/kernel-create-kernel-mode-binary?view=msvc-170

Reviewed By: thakis

Differential Revision: https://reviews.llvm.org/D126719

show more ...

[Clang] Add DriverKit support

This is the second patch that upstreams the support for Apple's DriverKit.

The first patch: https://reviews.llvm.org/D118046.

Differential Revision: https://reviews.l

[Clang] Add DriverKit support

This is the second patch that upstreams the support for Apple's DriverKit.

The first patch: https://reviews.llvm.org/D118046.

Differential Revision: https://reviews.llvm.org/D121911

show more ...

Define __STDC_NO_THREADS__ when targeting windows-msvc (PR48704)

MSVC's libc doesn't provide thread.h, so we should set the macro to
indicate that.

We could just set it in C mode, but I noticed tha

Define __STDC_NO_THREADS__ when targeting windows-msvc (PR48704)

MSVC's libc doesn't provide thread.h, so we should set the macro to
indicate that.

We could just set it in C mode, but I noticed that Darwin sets it
unconditionally, so perhaps we should do the same here.

Differential revision: https://reviews.llvm.org/D112081

show more ...

Revert "Revert "Use VersionTuple for parsing versions in Triple, fixing issues that caused the original change to be reverted. This makes it possible to distinguish between "16" and "16.0" after pars

Revert "Revert "Use VersionTuple for parsing versions in Triple, fixing issues that caused the original change to be reverted. This makes it possible to distinguish between "16" and "16.0" after parsing, which previously was not possible.""

This reverts commit 63a6348cad6caccf285c1661bc60d8ba5a40c972.

Differential Revision: https://reviews.llvm.org/D115254

show more ...

Revert "Use VersionTuple for parsing versions in Triple, fixing issues that caused the original change to be reverted. This makes it possible to distinguish between "16" and "16.0" after parsing, whi

Revert "Use VersionTuple for parsing versions in Triple, fixing issues that caused the original change to be reverted. This makes it possible to distinguish between "16" and "16.0" after parsing, which previously was not possible."

This reverts commit 50324670342d9391f62671685f4d6b4880a4ea9a.

show more ...

Use VersionTuple for parsing versions in Triple, fixing issues that caused the original change to be reverted. This makes it possible to distinguish between "16" and "16.0" after parsing, which previ

Use VersionTuple for parsing versions in Triple, fixing issues that caused the original change to be reverted. This makes it possible to distinguish between "16" and "16.0" after parsing, which previously was not possible.

This reverts commit 40d5eeac6cd89a2360c3ba997cbaa816abca828c.

Differential Revision: https://reviews.llvm.org/D114885

show more ...

[clang-cl] Define _MSVC_LANG for -std=c++2b

This matches the value that msvc v19.29 VS16.11 uses for
_MSVC_LANG with /std:c++latest.

Differential Revision: https://reviews.llvm.org/D114952

[clang-cl] Set _MSVC_LANG to 202002L with /std:c++20

MSVC says this should be 202002L for /std:c++20, and of VS16.11
that's indeed the case (older versions warn that they don't
understand /std:c++20

[clang-cl] Set _MSVC_LANG to 202002L with /std:c++20

MSVC says this should be 202002L for /std:c++20, and of VS16.11
that's indeed the case (older versions warn that they don't
understand /std:c++20, and then cl.exe defaults to C++14 and
sets _MSVC_LANG to 201402 accordingly).

Differential Revision: https://reviews.llvm.org/D114867

show more ...

Revert "Use VersionTuple for parsing versions in Triple. This makes it possible to distinguish between "16" and "16.0" after parsing, which previously was not possible."

This reverts commit 1e828646

Revert "Use VersionTuple for parsing versions in Triple. This makes it possible to distinguish between "16" and "16.0" after parsing, which previously was not possible."

This reverts commit 1e8286467036d8ef1a972de723f805a4981b2692.

llvm/test/Transforms/LoopStrengthReduce/X86/2009-11-10-LSRCrash.ll fails
with assertion failure:

llc: /home/nikic/llvm-project/llvm/include/llvm/ADT/Optional.h:196: T& llvm::optional_detail::OptionalStorage<T, true>::getValue() & [with T = unsigned int]: Assertion `hasVal' failed.
...
#8 0x00005633843af5cb llvm::MCStreamer::emitVersionForTarget(llvm::Triple const&, llvm::VersionTuple const&)
#9 0x0000563383b47f14 llvm::AsmPrinter::doInitialization(llvm::Module&)

show more ...

Use VersionTuple for parsing versions in Triple. This makes it possible to distinguish between "16" and "16.0" after parsing, which previously was not possible.

See also https://github.com/android/n

Use VersionTuple for parsing versions in Triple. This makes it possible to distinguish between "16" and "16.0" after parsing, which previously was not possible.

See also https://github.com/android/ndk/issues/1455.

Differential Revision: https://reviews.llvm.org/D114163

show more ...

[PR52549][clang-cl] Predefine _MSVC_EXECUTION_CHARACTER_SET

Since VS 2022 17.1 MSVC predefines _MSVC_EXECUTION_CHARACTER_SET to inform the users of the execution character set defined at compile tim

[PR52549][clang-cl] Predefine _MSVC_EXECUTION_CHARACTER_SET

Since VS 2022 17.1 MSVC predefines _MSVC_EXECUTION_CHARACTER_SET to inform the users of the execution character set defined at compile time. The value the macro expands to is a Windows Code Page Identifier which are documented here: https://docs.microsoft.com/en-us/windows/win32/intl/code-page-identifiers

As clang currently only supports UTF-8 it is defined as 65001. If clang-cl were to support a different execution character set in the future we'd have to change the value.

Fixes https://bugs.llvm.org/show_bug.cgi?id=52549

Differential Revision: https://reviews.llvm.org/D114576

show more ...

[clang][darwin] add support for Mac Catalyst availability

This commit adds support for Mac Catalyst availability attribute, as
supported by the Apple clang compiler. A follow-up commit will provide

[clang][darwin] add support for Mac Catalyst availability

This commit adds support for Mac Catalyst availability attribute, as
supported by the Apple clang compiler. A follow-up commit will provide
additional support for inferring Mac Catalyst availability from macOS
availability using the mapping in the SDKSettings.json.

Differential Revision: https://reviews.llvm.org/D105052

show more ...

C++2a -> C++20 in some identifiers; NFC.

clang: Only define OBJC_NEW_PROPERTIES when -x objective-c

Since 2009 (in r63846) we've been `#define`-ing OBJC_NEW_PROPERTIES all
the time on Darwin, but this macro only makes sense for `-x objecti

clang: Only define OBJC_NEW_PROPERTIES when -x objective-c

Since 2009 (in r63846) we've been `#define`-ing OBJC_NEW_PROPERTIES all
the time on Darwin, but this macro only makes sense for `-x objective-c`
and `-x objective-c++`. Restrict it to those cases (for which there is
already separate logic).

https://reviews.llvm.org/D72970
rdar://problem/10050342

show more ...

Bug 43965 - Value of _MSVC_LANG doesn't match MSVC++ VS2019 /std:c++latest mode

Summary:
The patch adds correct value of _MSVC_LANG to match with MSVC++ VS2019 /std:c++latest mode.

Bugzilla - B

Bug 43965 - Value of _MSVC_LANG doesn't match MSVC++ VS2019 /std:c++latest mode

Summary:
The patch adds correct value of _MSVC_LANG to match with MSVC++ VS2019 /std:c++latest mode.

Bugzilla - Bug 43965
https://bugs.llvm.org/show_bug.cgi?id=43965

The value for a MS specific macro differs from Microsoft starting with VS2019 in /std:c++latest mode.

-bash-4.2$ cat msvclang.cpp
_MSVC_LANG

-bash-4.2$ cl /std:c++latest -E msvclang.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 19.20.27508.1 for x64
Copyright (C) Microsoft Corporation. All rights reserved.

/std:c++latest is provided as a preview of language features from the latest C++
working draft, and we're eager to hear about bugs and suggestions for improvements.
However, note that these features are provided as-is without support, and subject
to changes or removal as the working draft evolves. See
https://go.microsoft.com/fwlink/?linkid=2045807 for details.

msvclang.cpp

201705L

-bash-4.2$ clang-cl /std:c++latest -E msvclang.cpp
201704L

Reviewers: rnk

Reviewed By: rnk

Differential Revision: https://reviews.llvm.org/D70996

show more ...

De-templatize non-dependent VS macro logic, NFC

These macro definitions don't depend on the template parameter, so they
don't need to be part of the template. Move them to a .cpp file.

llvm-svn: 36

De-templatize non-dependent VS macro logic, NFC

These macro definitions don't depend on the template parameter, so they
don't need to be part of the template. Move them to a .cpp file.

llvm-svn: 365556

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

NFC: Remove the ObjC1/ObjC2 distinction from clang (and related projects)

We haven't supported compiling ObjC1 for a long time (and never will again), so
there isn't any reason to keep these separat

NFC: Remove the ObjC1/ObjC2 distinction from clang (and related projects)

We haven't supported compiling ObjC1 for a long time (and never will again), so
there isn't any reason to keep these separate. This patch replaces
LangOpts::ObjC1 and LangOpts::ObjC2 with LangOpts::ObjC.

Differential revision: https://reviews.llvm.org/D53547

llvm-svn: 345637

show more ...

Toolchain: Normalize dwarf, sjlj and seh eh

This is a re-apply of r319294.

adds -fseh-exceptions and -fdwarf-exceptions flags

clang will check if the user has specified an exception model flag,
in

Toolchain: Normalize dwarf, sjlj and seh eh

This is a re-apply of r319294.

adds -fseh-exceptions and -fdwarf-exceptions flags

clang will check if the user has specified an exception model flag,
in the absense of specifying the exception model clang will then check
the driver default and append the model flag for that target to cc1

-fno-exceptions has a higher priority then specifying the model

move __SEH__ macro definitions out of Targets into InitPreprocessor
behind the -fseh-exceptions flag

move __ARM_DWARF_EH__ macrodefinitions out of verious targets and into
InitPreprocessor behind the -fdwarf-exceptions flag and arm|thumb check

remove unused USESEHExceptions from the MinGW Driver

fold USESjLjExceptions into a new GetExceptionModel function that
gives the toolchain classes more flexibility with eh models

Reviewers: rnk, mstorsjo

Differential Revision: https://reviews.llvm.org/D39673

llvm-svn: 319297

show more ...

Revert "Toolchain: Normalize dwarf, sjlj and seh eh"

This reverts rL319294.
The windows sanitizer does not like seh on x86.
Will re apply with None type for x86

llvm-svn: 319295

Toolchain: Normalize dwarf, sjlj and seh eh

adds -fseh-exceptions and -fdwarf-exceptions flags

clang will check if the user has specified an exception model flag,
in the absense of specifying the e

Toolchain: Normalize dwarf, sjlj and seh eh

adds -fseh-exceptions and -fdwarf-exceptions flags

clang will check if the user has specified an exception model flag,
in the absense of specifying the exception model clang will then check
the driver default and append the model flag for that target to cc1

clang cc1 assumes dwarf is the default if none is passed
and -fno-exceptions has a higher priority then specifying the model

move __SEH__ macro definitions out of Targets into InitPreprocessor
behind the -fseh-exceptions flag

move __ARM_DWARF_EH__ macrodefinitions out of verious targets and into
InitPreprocessor behind the -fdwarf-exceptions flag and arm|thumb check

remove unused USESEHExceptions from the MinGW Driver

fold USESjLjExceptions into a new GetExceptionModel function that
gives the toolchain classes more flexibility with eh models

Reviewers: rnk, mstorsjo

Differential Revision: https://reviews.llvm.org/D39673

llvm-svn: 319294

show more ...

Break up Targets.cpp into a header/impl pair per target type[NFCI]

Targets.cpp is getting unwieldy, and even minor changes cause the entire thing
to cause recompilation for everyone. This patch bit

Break up Targets.cpp into a header/impl pair per target type[NFCI]

Targets.cpp is getting unwieldy, and even minor changes cause the entire thing
to cause recompilation for everyone. This patch bites the bullet and breaks
it up into a number of files.

I tended to keep function definitions in the class declaration unless it
caused additional includes to be necessary. In those cases, I pulled it
over into the .cpp file. Content is copy/paste for the most part,
besides includes/format/etc.


Differential Revision: https://reviews.llvm.org/D35701

llvm-svn: 308791

show more ...