[Bug c/95645] New: Linux kernel regression "during GIMPLE pass: adjust_alignment"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95645 Bug ID: 95645 Summary: Linux kernel regression "during GIMPLE pass: adjust_alignment" Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: elver at google dot com Target Milestone: --- Created attachment 48720 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48720&action=edit Preprocessed source With GCC at trunk (87af4f40453a9c84363bde5d9a58466de7fbee2e), compiling the Linux kernel (v5.7, x86-64) fails for the following source file: gcc -Wp,-MD,arch/x86/boot/.string.o.d -nostdinc -isystem /usr/local/google/home/elver/third_party/gcc/local/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include -I./arch/x86/include -I./arch/x86/include/generated -I./include -I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__ -m16 -g -Os -DDISABLE_BRANCH_PROFILING -Wall -Wstrict-prototypes -march=i386 -mregparm=3 -fno-strict-aliasing -fomit-frame-pointer -fno-pic -mno-mmx -mno-sse -ffreestanding -fno-stack-protector -Wno-address-of-packed-member -mpreferred-stack-boundary=2 -D_SETUP -fmacro-prefix-map=./= -fno-asynchronous-unwind-tables -DKBUILD_MODFILE='"arch/x86/boot/string"' -DKBUILD_BASENAME='"string"' -DKBUILD_MODNAME='"string"' -c -o arch/x86/boot/string.o arch/x86/boot/string.c during GIMPLE pass: adjust_alignment arch/x86/boot/string.c: In function ‘simple_strtoull’: arch/x86/boot/string.c:121:20: internal compiler error: in execute, at adjust-alignment.c:74 121 | unsigned long long simple_strtoull(const char *cp, char **endp, unsigned int base) |^~~ 0x7964a5 execute ../.././gcc/adjust-alignment.c:74 This can be reproduced with the following command line and the attached preprocessed source: /usr/local/google/home/elver/third_party/gcc/local/bin/gcc -nostdinc -m16 -g -Os -Wall -Wstrict-prototypes -march=i386 -mregparm=3 -fno-strict-aliasing -fomit-frame-pointer -fno-pic -mno-mmx -mno-sse -ffreestanding -fno-stack-protector -Wno-address-of-packed-member -mpreferred-stack-boundary=2 -fmacro-prefix-map=./= -fno-asynchronous-unwind-tables -c -o /dev/null string-preprocessed.c
[Bug gcov-profile/80223] RFE: Exclude functions from profile instrumentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80223 --- Comment #19 from Marco Elver --- (In reply to Fangrui Song from comment #18) [...] > Our problem is that a boolean attribute with 1 bit information cannot > express whether a neg attribute function can be inlined into a pos attribute > function. > > Let's agree to disagree. I don't see why a no_profile_instrument_function > function suppress inlining into a function without the attribute. For the > use cases where users want to suppress inlining, they can add noinline. What > I worry about is that now GCC has an attitude and if the LLVM side doesn't > follow it is like diverging. However, the GCC patch is still in review. I > think a similar topic may need to be raided on llvm-dev side as I feel this > is the tip of the iceberg - more attributes can be similarly leveraged. So, > how about a llvm-dev discussion? I have mentioned this several times now, but it seems nobody is listening: It's _not_ about inlining -- the inlining discussion is about a particular implementation strategy. It's about the _contract an attribute promises_, which is treating the code in the function a certain way (e.g. do not instrument). That can be done by either: a) even if the code is inlined, respect the original attribute for the inlined code (e.g. do not instrument), or b) just don't inline. It looks like (b) is easier to do. I probably do not understand how hard (a) is. If you break the contract because it's too hard to do (a), then that's your problem. Just don't break the contract. Because that's how we get impossible-to-diagnose bugs. Correctness comes first: if it is impossible for a user to reason about the behaviour of their code due to unspecified behaviour (viz. breaking the contract) of an attribute, then the code is doomed to be incorrect. Therefore, do _not_ implement attributes with either unspecified or ridiculously specified behaviour. Ridiculous in this case is saying "this attribute only does what it promises if you also add noinline". It's ridiculous, because the user will then rightfully wonder "?!?!? Why doesn't it imply noinline then?!?!?!". Thanks.
[Bug sanitizer/108777] Add support for --param asan-kernel-mem-intrinsic-prefix=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108777 --- Comment #3 from Marco Elver --- (In reply to Jakub Jelinek from comment #2) > Marco, is this what you are looking for? Yes, looks good - the tests verify the behaviour I'd expect. Thanks!
[Bug sanitizer/108777] Add support for --param asan-kernel-mem-intrinsic-prefix=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108777 --- Comment #8 from Marco Elver --- Thanks for the quick turnaround!
[Bug target/110899] New: RFE: Attributes preserve_most and preserve_all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110899 Bug ID: 110899 Summary: RFE: Attributes preserve_most and preserve_all Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: elver at google dot com Target Milestone: --- Clang/LLVM implements the function attributes "preserve_most" and "preserve_all": [1] preserve_most: "On X86-64 and AArch64 targets, this attribute changes the calling convention of a function. The preserve_most calling convention attempts to make the code in the caller as unintrusive as possible. This convention behaves identically to the C calling convention on how arguments and return values are passed, but it uses a different set of caller/callee-saved registers. This alleviates the burden of saving and recovering a large register set before and after the call in the caller. If the arguments are passed in callee-saved registers, then they will be preserved by the callee across the call. This doesn’t apply for values returned in callee-saved registers. - On X86-64 the callee preserves all general purpose registers, except for R11. R11 can be used as a scratch register. Floating-point registers (XMMs/YMMs) are not preserved and need to be saved by the caller. - On AArch64 the callee preserve all general purpose registers, except X0-X8 and X16-X18." [2] preserve_all: "On X86-64 and AArch64 targets, this attribute changes the calling convention of a function. The preserve_all calling convention attempts to make the code in the caller even less intrusive than the preserve_most calling convention. This calling convention also behaves identical to the C calling convention on how arguments and return values are passed, but it uses a different set of caller/callee-saved registers. This removes the burden of saving and recovering a large register set before and after the call in the caller. If the arguments are passed in callee-saved registers, then they will be preserved by the callee across the call. This doesn’t apply for values returned in callee-saved registers. - On X86-64 the callee preserves all general purpose registers, except for R11. R11 can be used as a scratch register. Furthermore it also preserves all floating-point registers (XMMs/YMMs). - On AArch64 the callee preserve all general purpose registers, except X0-X8 and X16-X18. Furthermore it also preserves lower 128 bits of V8-V31 SIMD - floating point registers." [1] https://clang.llvm.org/docs/AttributeReference.html#preserve-most [2] https://clang.llvm.org/docs/AttributeReference.html#preserve-all These attributes, esp. preserve_most, provides a convenient way to optimize the generated code for calls to rarely taken slow paths, such as error-reporting functions. Recently, we're looking to make use of this in the Linux kernel [3], with potentially additional usecases being discussed. [3] https://lkml.kernel.org/r/20230804090621.400-1-el...@google.com
