FailedChanges

Summary

  1. [libcxxabi] Don't use -fvisibility-global-new-delete-hidden when not defining them When builing the hermetic static library, the compiler switch -fvisibility-global-new-delete-hidden is necessary to get the new and delete operator definitions made correctly. However, when those definitions are not included in the library, then this switch does harm. With lld (though not all linkers) setting STV_HIDDEN on SHN_UNDEF symbols makes it an error to leave them undefined or defined via dynamic linking that should generate PLTs for -shared linking (lld makes this a hard error even without -z defs). Though leaving the symbols undefined would usually work in practice if the linker were to allow it (and the user didn't pass -z defs), this actually indicates a real problem that could bite some target configurations more subtly at runtime. For example, x86-32 ELF -fpic code generation uses hidden visibility on declarations in the caller's scope as a signal that the call will never be resolved to a PLT entry and so doesn't have to meet the special ABI requirements for PLT calls (setting %ebx). Since these functions might actually be resolved to PLT entries at link time (we don't know what the user is linking in when the hermetic library doesn't provide all the symbols itself), it's not safe for the compiler to treat their declarations at call sites as having hidden visibility. Differential Revision: https://reviews.llvm.org/D61572
  2. [libcxx] Don't use -fvisibility-global-new-delete-hidden when not defining them When builing the hermetic static library, the compiler switch -fvisibility-global-new-delete-hidden is necessary to get the new and delete operator definitions made correctly. However, when those definitions are not included in the library, then this switch does harm. With lld (though not all linkers) setting STV_HIDDEN on SHN_UNDEF symbols makes it an error to leave them undefined or defined via dynamic linking that should generate PLTs for -shared linking (lld makes this a hard error even without -z defs). Though leaving the symbols undefined would usually work in practice if the linker were to allow it (and the user didn't pass -z defs), this actually indicates a real problem that could bite some target configurations more subtly at runtime. For example, x86-32 ELF -fpic code generation uses hidden visibility on declarations in the caller's scope as a signal that the call will never be resolved to a PLT entry and so doesn't have to meet the special ABI requirements for PLT calls (setting %ebx). Since these functions might actually be resolved to PLT entries at link time (we don't know what the user is linking in when the hermetic library doesn't provide all the symbols itself), it's not safe for the compiler to treat their declarations at call sites as having hidden visibility. Differential Revision: https://reviews.llvm.org/D61571
Revision 360004 by phosek:
[libcxxabi] Don't use -fvisibility-global-new-delete-hidden when not defining them

When builing the hermetic static library, the compiler switch
-fvisibility-global-new-delete-hidden is necessary to get the new and
delete operator definitions made correctly. However, when those
definitions are not included in the library, then this switch does harm.
With lld (though not all linkers) setting STV_HIDDEN on SHN_UNDEF
symbols makes it an error to leave them undefined or defined via dynamic
linking that should generate PLTs for -shared linking (lld makes this a
hard error even without -z defs). Though leaving the symbols undefined
would usually work in practice if the linker were to allow it (and the
user didn't pass -z defs), this actually indicates a real problem that
could bite some target configurations more subtly at runtime. For
example, x86-32 ELF -fpic code generation uses hidden visibility on
declarations in the caller's scope as a signal that the call will never
be resolved to a PLT entry and so doesn't have to meet the special ABI
requirements for PLT calls (setting %ebx). Since these functions might
actually be resolved to PLT entries at link time (we don't know what the
user is linking in when the hermetic library doesn't provide all the
symbols itself), it's not safe for the compiler to treat their
declarations at call sites as having hidden visibility.

Differential Revision: https://reviews.llvm.org/D61572
Change TypePath in RepositoryPath in Workspace
The file was modified/libcxxabi/trunk/src/CMakeLists.txtN/A
The file was modified/llvm/trunk/utils/gn/secondary/libcxxabi/src/BUILD.gntrunk/utils/gn/secondary/libcxxabi/src/BUILD.gn
Revision 360003 by phosek:
[libcxx] Don't use -fvisibility-global-new-delete-hidden when not defining them

When builing the hermetic static library, the compiler switch
-fvisibility-global-new-delete-hidden is necessary to get the new and
delete operator definitions made correctly. However, when those
definitions are not included in the library, then this switch does harm.
With lld (though not all linkers) setting STV_HIDDEN on SHN_UNDEF
symbols makes it an error to leave them undefined or defined via dynamic
linking that should generate PLTs for -shared linking (lld makes this a
hard error even without -z defs). Though leaving the symbols undefined
would usually work in practice if the linker were to allow it (and the
user didn't pass -z defs), this actually indicates a real problem that
could bite some target configurations more subtly at runtime. For
example, x86-32 ELF -fpic code generation uses hidden visibility on
declarations in the caller's scope as a signal that the call will never
be resolved to a PLT entry and so doesn't have to meet the special ABI
requirements for PLT calls (setting %ebx). Since these functions might
actually be resolved to PLT entries at link time (we don't know what the
user is linking in when the hermetic library doesn't provide all the
symbols itself), it's not safe for the compiler to treat their
declarations at call sites as having hidden visibility.

Differential Revision: https://reviews.llvm.org/D61571
Change TypePath in RepositoryPath in Workspace
The file was modified/libcxx/trunk/src/CMakeLists.txtN/A
The file was modified/llvm/trunk/utils/gn/secondary/libcxx/src/BUILD.gntrunk/utils/gn/secondary/libcxx/src/BUILD.gn

Summary

  1. [clang-tidy] openmp-exception-escape check: point to the structured-block I'm not sure what i was thinking when i wrote it to point at the directive. It's at the very least confusing, and in the `for` is very misleading. We should point at the actual Stmt out of which the exception escapes, to highlight where it should be fixed e.g. via adding try-catch block. Yes, this breaks existing NOLINT, which is why this change needs to happen now, not any later.
Revision 360002 by lebedevri:
[clang-tidy] openmp-exception-escape check: point to the structured-block

I'm not sure what i was thinking when i wrote it to point at the directive.
It's at the very least confusing, and in the `for` is very misleading.

We should point at the actual Stmt out of which the exception escapes,
to highlight where it should be fixed e.g. via adding try-catch block.

Yes, this breaks existing NOLINT, which is why this change needs to
happen now, not any later.
Change TypePath in RepositoryPath in Workspace
The file was modified/clang-tools-extra/trunk/clang-tidy/openmp/ExceptionEscapeCheck.cpptrunk/clang-tidy/openmp/ExceptionEscapeCheck.cpp
The file was modified/clang-tools-extra/trunk/test/clang-tidy/openmp-exception-escape.cpptrunk/test/clang-tidy/openmp-exception-escape.cpp

Summary

  1. [libcxx] Don't use -fvisibility-global-new-delete-hidden when not defining them When builing the hermetic static library, the compiler switch -fvisibility-global-new-delete-hidden is necessary to get the new and delete operator definitions made correctly. However, when those definitions are not included in the library, then this switch does harm. With lld (though not all linkers) setting STV_HIDDEN on SHN_UNDEF symbols makes it an error to leave them undefined or defined via dynamic linking that should generate PLTs for -shared linking (lld makes this a hard error even without -z defs). Though leaving the symbols undefined would usually work in practice if the linker were to allow it (and the user didn't pass -z defs), this actually indicates a real problem that could bite some target configurations more subtly at runtime. For example, x86-32 ELF -fpic code generation uses hidden visibility on declarations in the caller's scope as a signal that the call will never be resolved to a PLT entry and so doesn't have to meet the special ABI requirements for PLT calls (setting %ebx). Since these functions might actually be resolved to PLT entries at link time (we don't know what the user is linking in when the hermetic library doesn't provide all the symbols itself), it's not safe for the compiler to treat their declarations at call sites as having hidden visibility. Differential Revision: https://reviews.llvm.org/D61571
Revision 360003 by phosek:
[libcxx] Don't use -fvisibility-global-new-delete-hidden when not defining them

When builing the hermetic static library, the compiler switch
-fvisibility-global-new-delete-hidden is necessary to get the new and
delete operator definitions made correctly. However, when those
definitions are not included in the library, then this switch does harm.
With lld (though not all linkers) setting STV_HIDDEN on SHN_UNDEF
symbols makes it an error to leave them undefined or defined via dynamic
linking that should generate PLTs for -shared linking (lld makes this a
hard error even without -z defs). Though leaving the symbols undefined
would usually work in practice if the linker were to allow it (and the
user didn't pass -z defs), this actually indicates a real problem that
could bite some target configurations more subtly at runtime. For
example, x86-32 ELF -fpic code generation uses hidden visibility on
declarations in the caller's scope as a signal that the call will never
be resolved to a PLT entry and so doesn't have to meet the special ABI
requirements for PLT calls (setting %ebx). Since these functions might
actually be resolved to PLT entries at link time (we don't know what the
user is linking in when the hermetic library doesn't provide all the
symbols itself), it's not safe for the compiler to treat their
declarations at call sites as having hidden visibility.

Differential Revision: https://reviews.llvm.org/D61571
Change TypePath in RepositoryPath in Workspace
The file was modified/libcxx/trunk/src/CMakeLists.txttrunk/src/CMakeLists.txt
The file was modified/llvm/trunk/utils/gn/secondary/libcxx/src/BUILD.gnN/A