[PATCH] D80791: [AArch64] Generate .note.gnu.property based on module flags.

nsz added a comment. In D80791#2210207 , @chill wrote: > In D80791#2210124 , @danielkiss > wrote: > it is not useful to have a bti annotated function unless everything else is bti compatible too: it is a

[PATCH] D80791: [AArch64] Generate .note.gnu.property based on module flags.

nsz added a comment. In D80791#2209703 , @chill wrote: > In D80791#2209624 , @nsz wrote: > >> - it is not useful to have a bti annotated function unless everything else >> is bti compatible too: it is all or nothin

[PATCH] D80791: [AArch64] Generate .note.gnu.property based on module flags.

nsz added a comment. In D80791#2207203 , @chill wrote: > I would prefer to avoid the situation where the markings of two otherwise > identical files were different, > depending on how the files were produced, no matter if it was a common or a > special c

[PATCH] D80791: [AArch64] Generate .note.gnu.property based on module flags.

nsz added a comment. In D80791#2206933 , @chill wrote: > In D80791#2206853 , @nsz wrote: > >> i think that cannot work. >> >> the implementation is free to inject arbitrary code into >> user code so if the user does

[PATCH] D80791: [AArch64] Generate .note.gnu.property based on module flags.

nsz added a comment. the gcc behaviour is not exactly ideal, but it's better if llvm is compatible with it or fix gcc if something is broken there. the assumption is that the intended branch protection is implied via cmdline flags for the tu and function attributes are only used in source code

[PATCH] D72222: [Driver][CodeGen] Add -fpatchable-function-entry=N[,0]

nsz added a comment. In D7#1837536 , @MaskRay wrote: > A -DLLVM_ENABLE_ASSERTIONS=on build is required to trigger the assertion > failure. My `make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- HOSTGCC=gcc > CC=~/llvm/ReleaseAssert/bin/clang LD=~/llvm/

[PATCH] D40673: Add _Float128 as alias to __float128 to enable compilations on Fedora27/glibc2-26

nsz added a comment. In https://reviews.llvm.org/D40673#973638, @efriedma wrote: > > as this patch is committed clang is broken (cannot use glibc headers) > > This patch was supposed to *fix* compatibility with the glibc headers. If it > doesn't, we should clearly revert it... but we need to fi

[PATCH] D40673: Add _Float128 as alias to __float128 to enable compilations on Fedora27/glibc2-26

nsz added a comment. also note that there is less than 3 weeks until glibc-2.27 is released, if the headers need a fix for clang then say so quickly i opened https://sourceware.org/bugzilla/show_bug.cgi?id=22700 but it needs attention from some clang developers, in particular there is no way to

[PATCH] D40673: Add _Float128 as alias to __float128 to enable compilations on Fedora27/glibc2-26

nsz added a comment. if clang wants to provide _Float128 then the f128 constant suffix (specified by TS18661-3) and __builtin_inff128, __builtin_nanf128, __builtin_nansf128, __builtin_huge_valf128 (gcc builtins required by math.h) need to be supported too. as this patch is committed clang is b