[Bug target/71056] [6/7 Regression] __builtin_bswap32 NEON instruction error with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71056 --- Comment #4 from Yichao Yu --- (Sorry I'm not sure how to understand that cross link). Is the fix merged?
[Bug other/71414] New: 2x slower than clang summing small float array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71414 Bug ID: 71414 Summary: 2x slower than clang summing small float array Product: gcc Version: 6.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: yyc1992 at gmail dot com Target Milestone: --- Ref https://llvm.org/bugs/show_bug.cgi?id=28002 C source code. ```c __attribute__((noinline)) float sum32(float *a, size_t n) { /* a = (float*)__builtin_assume_aligned(a, 64); */ float s = 0; for (size_t i = 0;i < n;i++) s += a[i]; return s; }``` See [this gist](https://gist.github.com/yuyichao/5b07f71c1f19248ec5511d758532a4b0) for assembly output by different compilers. GCC appears to be ~2x slower than clang on the two machines (4702HQ and 6700K) I benchmarked this.
[Bug other/71414] 2x slower than clang summing small float array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71414 --- Comment #4 from Yichao Yu --- The C code is in the gist linked `a` is a cacheline aligned pointer and `n` is 1024 so `a` should even fits in L1d, which is 32kB on both processors I benchmarked. More precise timing (ns per loop) 6700K ``` % ./benchmark-gcc 80.553456 % ./benchmark-clang37 28.81 % ./benchmark-clang38 41.782532 ``` 4702HQ ``` % ./benchmark-gcc 140.744893 % ./benchmark-clang37 50.835441 % ./benchmark-clang38 70.220946 ``` Pasting the whole program over for completeness. The alignment line gives some weird timing on clang without `-mcore-avx2` but doesn't change anything too much with `-Ofast -mcore-avx2` ``` // #include #include #include #include #include uint64_t gettime_ns() { struct timespec t; clock_gettime(CLOCK_MONOTONIC, &t); return t.tv_sec * (uint64_t) 1e9 + t.tv_nsec; } __attribute__((noinline)) float sum32(float *a, size_t n) { /* a = (float*)__builtin_assume_aligned(a, 64); */ float s = 0; for (size_t i = 0;i < n;i++) s += a[i]; __asm__ volatile ("" ::: "memory"); return s; } int main() { float *p = aligned_alloc(64, sizeof(float) * 1024); memset(p, 0, sizeof(float) * 1024); uint64_t start = gettime_ns(); for (int i = 0;i < 1024 * 1024;i++) sum32(p, 1024); free(p); uint64_t end = gettime_ns(); printf("%f\n", (end - start) / (1024.0 * 1024.0)); return 0; } ```
[Bug tree-optimization/71414] 2x slower than clang summing small float array, GCC should consider larger vectorization factor for "unrolling" reductions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71414 --- Comment #7 from Yichao Yu --- If I add `-fvariable-expansion-in-unroller` (omg this options is like half the command line ;-p ...), the performance matches the clang one after the clang 3.8 regression. ``` % gcc -funroll-loops -fvariable-expansion-in-unroller -Ofast -march=core-avx2 benchmark.c -o benchmark2 % ./benchmark2 45.588861 % ./benchmark-gcc 80.518152 % ./benchmark-clang38 41.920054 % ./benchmark-clang37 25.093145 ```
[Bug target/70814] atomic store of __int128 is not lock free on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70814 --- Comment #4 from Yichao Yu --- Thanks for the explanation. I didn't realize that the load is the problem. Just curious (since I somehow can't find documentation about it), would `ldaxp` provide the right semantics without the corresponding store?
[Bug target/67458] x86: atomic store with memory_order_release doesn't order other stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67458 Yichao Yu changed: What|Removed |Added CC||yyc1992 at gmail dot com --- Comment #1 from Yichao Yu --- I've just hit this when I was expecting the stores to the non-atomic variables to be optimized to before the atomic store. I have a slightly more self-contained repro that can trigger an assertion on x64 when running repeatedly https://github.com/yuyichao/explore/commit/0b70ee0b14c5d20f0e98d8e0d0ebc5032bd12892 (I was going to report a bug with the code and discovered this report and I realized that I happened to pick exactly the same variable names and values)
[Bug target/70814] New: atomic store of __int128 is not lock free on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70814 Bug ID: 70814 Summary: atomic store of __int128 is not lock free on aarch64 Product: gcc Version: 5.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: yyc1992 at gmail dot com Target Milestone: --- `std::atomic<__int128>::store` on aarch64 is not lock free and generates a function call `__atomic_store_16`. However, required atomic instructions (`stlxp`) exists in armv8 and is used by clang. Should gcc use the same instruction as well? Ref https://llvm.org/bugs/show_bug.cgi?id=27081, which fixes the clang codegen for this case.
[Bug target/70814] atomic store of __int128 is not lock free on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70814 --- Comment #2 from Yichao Yu --- As an update, it seems that the llvm trunk recently switched to using `__atomic_*` function call for int128 on all platforms (that I can test anyway). I'm not sure how that decision is made or if there's any communication with GCC but IMHO it would be nice to agree on using the atomic instruction on aarch64 as long as it provides all the necessary ones.
[Bug target/71056] New: __builtin_bswap32 NEON instruction error with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71056 Bug ID: 71056 Summary: __builtin_bswap32 NEON instruction error with -O3 Product: gcc Version: 6.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: yyc1992 at gmail dot com Target Milestone: --- The following code generate a NEON instruction not available error when compiling with `gcc -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -O3 -o /dev/null -c a.c` on ARM on gcc 6.1.1 (ArchLinuxARM). ```c #include #include extern char *buff; int f2(); struct T1 { int32_t reserved[2]; uint32_t ip; uint16_t cs; uint16_t rsrv2; }; void f3(const char *p) { struct T1 x; memcpy(&x, p, sizeof(struct T1)); x.reserved[0] = __builtin_bswap32(x.reserved[0]); x.reserved[1] = __builtin_bswap32(x.reserved[1]); x.ip = __builtin_bswap32(x.ip); x.cs = x.cs << 8 | x.cs >> 8; x.rsrv2 = x.rsrv2 << 8 | x.rsrv2 >> 8; if (f2()) { memcpy(buff, "\n", 1); } } ``` Error message ``` alarm% gcc -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -O3 -o /dev/null -c a.c a.c: In function ‘f3’: a.c:16:21: fatal error: You must enable NEON instructions (e.g. -mfloat-abi=softfp -mfpu=neon) to use these intrinsics. x.reserved[0] = __builtin_bswap32(x.reserved[0]); ^~~~ compilation terminated. ``` Note that `NEON` isn't enabled and there's no direct use of NEON instructions/intrinsics in the code so the NEON instructions must have been added by the optimizer. Seemingly subtle change can make the error disappear. This includes. 1. -O3 -> -O2 (ok, this one is not particularly subtle) 2. Remove any of the byteswap or field 3. Remove any of the memcpy 4. Make the second memcpy unconditional 5. Remove `f2()` (but leave the memcpy condition in some other way) 6. Pass in `x` as argument (either as value or pointer) The asm generated when compiling with `fpu=neon` ``` f3: @ args = 0, pretend = 0, frame = 16 @ frame_needed = 0, uses_anonymous_args = 0 mov r3, r0 str lr, [sp, #-4]! sub sp, sp, #20 ldr r2, [r3, #8]@ unaligned ldr r1, [r3, #4]@ unaligned mov ip, sp ldr r0, [r0]@ unaligned ldr r3, [r3, #12] @ unaligned stmia ip!, {r0, r1, r2, r3} mov r3, r2 ldrhip, [sp, #12] rev r3, r3 ldrhr0, [sp, #14] vldrd16, [sp] lsr r1, ip, #8 str r3, [sp, #8] vrev32.8d16, d16 lsr r2, r0, #8 orr r2, r2, r0, lsl #8 orr r1, r1, ip, lsl #8 strhr2, [sp, #14] @ movhi strhr1, [sp, #12] @ movhi vstrd16, [sp] bl f2 cmp r0, #0 movwne r3, #:lower16:buff movtne r3, #:upper16:buff movne r2, #10 ldrne r3, [r3] strbne r2, [r3] add sp, sp, #20 @ sp needed ldr pc, [sp], #4 .size f3, .-f3 .ident "GCC: (GNU) 6.1.1 20160501" ``` And it seems that the NEON instruction it want to generate is `vrev32.8` The case is simplified from https://github.com/llvm-mirror/llvm/blob/da4b82ab1387da8c959a4e2439bce10b9cefbc8a/tools/llvm-objdump/MachODump.cpp#L8240-L8263 I don't remember seeing this on gcc 5.
[Bug target/82641] Unable to enable crc32 for a certain function with target attribute on ARM (aarch32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82641 --- Comment #20 from Yichao Yu --- Just want to mention that the lack of a way to locally change the arch settings without lying to the compiler is exactly why I reported this issue.
[Bug c++/69550] Need a way to disable "flexible array member in an otherwise empty struct" error on GCC 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69550 Yichao Yu changed: What|Removed |Added CC||yyc1992 at gmail dot com --- Comment #17 from Yichao Yu --- I didn't write that code originally but I think I know why it is written this way when trying to fix the compiler warning/errors. What we want is basically, ``` struct _jl_value_t { struct _jl_value_t *fieldptr[]; }; ``` It needs to be a flexible array rather than an zero-length array since it will cause a runtime error on OSX otherwise. (Ref https://github.com/JuliaLang/julia/pull/13845 I don't have a mac to check but I assume it is done by clang in certain debug mode). However, this doesn't work since the struct mush have another (in priciple non-empty) member and that's why we added a zero length array member in the struct which is non-standard but seems to have worked around the compiler warning on GCC < 6. If this change is made intentionally in C++ mode, I'm fine with keeping it as is given we've already fixed it on our master and it's easy enough (at least for us) to work around this on our stable branch without breaking any existng setup. I'm not sure if other projects will have the same problem though.
[Bug target/82641] New: Unable to enable crc32 for a certain function with target attribute on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82641 Bug ID: 82641 Summary: Unable to enable crc32 for a certain function with target attribute on ARM Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: yyc1992 at gmail dot com Target Milestone: --- The assembler complains about the target not supporting CRC32 instructions for certain (generic) targets on ARM and AArch64. On AArch64, this can be lifted with the `target("+crc")` attribute (or pragma though I've only tested the function attribute) when writing inline assembly code that uses non-default processor features and cpu-feature dispatch. However, none of these approaches works on ARM. There are multiple issues when trying to do this, 1. "+crc" is not accepted as a feature on ARM (32bit), not even when `march` is set to `armv8-a`. OTOH, "armv8-a+crc" works though that makes supporting different arch profile harder... 2. No `.arch` or `.arch_feature` directives are generated in the assembly which cause the assembler to complain. This is the case for either function attribute or pragma. I've tried to manually added a `.arch armv8-a` and a `.arch_extension crc` before the function that uses the `crc32` instruction and then reset it back with `.arch armv7-a` in the assembly code and it behaves correctly so I believe this should be fixable on the GCC side.
[Bug target/82641] Unable to enable crc32 for a certain function with target attribute on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82641 --- Comment #1 from Yichao Yu --- I've found a workaround in https://sourceware.org/ml/binutils/2017-04/msg00171.html but it's extremely ugly (albeit also very clever...).
[Bug target/82641] Unable to enable crc32 for a certain function with target attribute on ARM (aarch32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82641 --- Comment #3 from Yichao Yu --- > ARMv8-a is the only architecture variant where the CRC extension is optional Not really. There's also armv8-r and armv8-m. Also, I believe code compiled for armv7-a can run on armv8-a hardware and can also optionally enable armv8 features including CRC extension. I was hoping that GCC can be smart enough to enable the correct armv8 variant automatically. Test case is just ``` #include #pragma GCC push_options #pragma GCC target("armv8-a+crc") __attribute__((target("armv8-a+crc"))) uint32_t crc32cw(uint32_t crc, uint32_t val) { uint32_t res; /* asm(".arch armv8-a"); */ /* asm(".arch_extension crc"); */ asm("crc32cw %0, %1, %2" : "=r"(res) : "r"(crc), "r"(val)); /* asm(".arch armv7-a"); */ return res; } #pragma GCC pop_options ``` Compiled with either armv7-a or armv8-a march.
[Bug target/82641] Unable to enable crc32 for a certain function with target attribute on ARM (aarch32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82641 --- Comment #7 from Yichao Yu --- It would be great if `+crc` can work if it's not ambiguous. Requiring `arch=armv8-a+crc` works for me too, and it'll just require more preprocessor checks.
[Bug target/83110] New: Relocation error when taking address of protected function in shared library.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83110 Bug ID: 83110 Summary: Relocation error when taking address of protected function in shared library. Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: yyc1992 at gmail dot com Target Milestone: --- This is very similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65248 although that one is marked as fixed. (This could be a dup of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520 but I can't really tell...) The difference from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65248 is that this now only happens for me with protected functions and not global variables. The code to reproduce is ``` __attribute__((visibility("protected"))) void f() { } // __attribute__((visibility("protected"))) // int f; void f2(void (*cb)(void*)) { cb((void*)&f); } ``` Which gives the error ``` % LANG=C g++ a.cpp -o liba.so -pthread -fPIC -shared /bin/ld: /tmp/ccvUACGZ.o: relocation R_X86_64_PC32 against protected symbol `_Z1fv' can not be used when making a shared object /bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status ```
[Bug target/83110] Relocation error when taking address of protected function in shared library.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83110 --- Comment #2 from Yichao Yu --- What might be invalid about the source?
[Bug target/80732] target_clones does not work with dlsym
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80732 --- Comment #9 from Yichao Yu --- Thanks for the fix! Does it fix https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78366 at the same time?
[Bug target/77728] [5/6/7 Regression] Miscompilation multiple vector iteration on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77728 --- Comment #5 from Yichao Yu --- Ping again? Anything new or I can help with here?
[Bug target/77728] [5/6/7 Regression] Miscompilation multiple vector iteration on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77728 --- Comment #6 from Yichao Yu --- Anything new here?
[Bug target/77728] [5/6 Regression] Miscompilation multiple vector iteration on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77728 --- Comment #48 from Yichao Yu --- Thanks for fixing this. I didn't follow all the comments since I'm not familiar with the C++ ABI so just to make sure I understand what's happening is it that the bug is caused by a inconsistency in C++ ABI for certain classes which can happen on both ARM and AArch64 (although not for AArch64 in this case)? Is this now fixed for gcc 7+ for both ARM and AArch64? (Should this be closed now or only when there's a release?) And btw, when is the estimated release time of 7.1?
[Bug target/80732] New: target_clones does not work with dlsym
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80732 Bug ID: 80732 Summary: target_clones does not work with dlsym Product: gcc Version: 6.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: yyc1992 at gmail dot com Target Milestone: --- Compiling the code below to a executable with `gcc -Wall -Wextra -O3 -fPIC -ldl -rdynamic`. On a haswell+ system, the output is ``` 1: 0, 4.93038e-32, 0 2: 4.93038e-32, 4.93038e-32, 4.93038e-32 ``` Showing that with the manually created ifunc, dlsym, direct function call, and accessing function address produces the same result (the fma version) whereas with `target_clones` only direct function call uses the fma versison. This might be related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78366 but I'm not entirely sure. From that bug report I can understand that this is just how `target_clones` is currently implemented but I do think this is not a documentation issue and should be fixed / improved instead since 1. in this case there is user observable inconsistency in the result generated when different code paths are used. The fast math object should be allowed to produce slightly inaccurate result but I do think it should produce consistent result every time the function is called. 2. probably more importantly, this behavior makes the `target_clone` attribute useless for used in public interface if the shared library can ever by dynamically loaded. ``` #include #include __attribute__((target_clones("default","fma"),noinline,optimize("fast-math"))) double f1(double a, double b, double c) { return a * b + c; } double k1(double a, double b, double c, void **p) { *p = f1; return f1(a, b, c); } __attribute__((target("fma"),optimize("fast-math"))) static double f2_fma(double a, double b, double c) { return a * b + c; } __attribute__((optimize("fast-math"))) static double f2_default(double a, double b, double c) { return a * b + c; } static void *f2_resolve(void) { __builtin_cpu_init (); if (__builtin_cpu_supports("fma")) return f2_fma; else return f2_default; } double f2(double a, double b, double c) __attribute__((ifunc("f2_resolve"))); double k2(double a, double b, double c, void **p) { *p = f2; return f2(a, b, c); } int main() { volatile double a = 1.0002; volatile double b = -0.9998; volatile double c = 1.0; void *hdl = dlopen(NULL, RTLD_NOW); printf("1:\n"); double (*pf1)(double, double, double) = dlsym(hdl, "f1"); double (*pk1)(double, double, double, void**) = dlsym(hdl, "k1"); double (*_pf1)(double, double, double); double v1_1 = pf1(a, b, c); double v1_2 = pk1(a, b, c, (void**)&_pf1); double v1_3 = _pf1(a, b, c); printf("%g, %g, %g\n", v1_1, v1_2, v1_3); printf("2:\n"); double (*pf2)(double, double, double) = dlsym(hdl, "f2"); double (*pk2)(double, double, double, void**) = dlsym(hdl, "k2"); double (*_pf2)(double, double, double); double v2_1 = pf2(a, b, c); double v2_2 = pk2(a, b, c, (void**)&_pf2); double v2_3 = _pf2(a, b, c); printf("%g, %g, %g\n", v2_1, v2_2, v2_3); return 0; } ```
[Bug target/80732] target_clones does not work with dlsym
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80732 --- Comment #4 from Yichao Yu --- `double (*pf1)(double, double, double) = dlsym(hdl, "f1.ifunc");` Wouldn't it be better if GCC generates local functions `f1.default`, `f1.fma` as implementation and `f1` to replace `f1.ifunc`? It's quite incontinent if this detail is exposed. If one have to use `f1.ifunc`, does it also mean that the declaration of the function in the header must also have `target_clone` applied?
[Bug target/80732] target_clones does not work with dlsym
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80732 --- Comment #6 from Yichao Yu --- Good to know. Thanks.
[Bug c++/65255] std::thread does not work for cross compiling on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65255 --- Comment #6 from Yichao Yu --- Adding `-march=armv7-a` indeed fixes the issue. Thanks. Does this mean that `std::thread` is not supported on armv6? Would be nice to have a warning/error if it is possible to detect this. FWIW, `clang -march=armv6` doesn't have this issue...
[Bug c++/65255] std::thread does not work for cross compiling on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65255 Yichao Yu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #9 from Yichao Yu --- Thanks for the explaination. > I have a patch for std::thread which would mean it doesn't use shared_ptr, so > this wouldn't be a problem even if you don't use the same arm version. I guess this might be the implementation detail that causes this to not happen for clang but I agree in general finding the right version of library at runtime is more of a distribution / system manager problem.
[Bug middle-end/68336] New: False positive Wreturn-type warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68336 Bug ID: 68336 Summary: False positive Wreturn-type warning Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: yyc1992 at gmail dot com Target Milestone: --- The following code gives a warning about control flow reaching the end of function without returning a value even though the function will always reach the `return 1;` statement and won't reach the end of the function. ``` int f() { for (int i = 1;--i >= 0;) { return 1; } } ``` Given no warning about this is given if the loop condition is replaced with `1` I hope it is also possible for gcc to figure out that the loop is executed as least once and silence the warning. This (admittedly stupid) code pattern arise from macro expansion to setup a single time local context.
[Bug middle-end/68336] False positive Wreturn-type warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68336 --- Comment #1 from Yichao Yu --- Ref clang bug report https://llvm.org/bugs/show_bug.cgi?id=25521
[Bug target/77728] New: Miscompilation multiple vector iteration on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77728 Bug ID: 77728 Summary: Miscompilation multiple vector iteration on ARM Product: gcc Version: 6.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: yyc1992 at gmail dot com Target Milestone: --- Code to reproduce is at https://gist.github.com/yuyichao/a66edb9d05d18755fb7587b12e021a8a. The two cpp files are ```c++ #include #include typedef std::vector> DWARFAddressRangesVector; void dumpRanges(const DWARFAddressRangesVector& Ranges) { for (const auto &Range: Ranges) { (void)Range; } } void collectChildrenAddressRanges(DWARFAddressRangesVector& Ranges) { const DWARFAddressRangesVector &DIERanges = DWARFAddressRangesVector(); Ranges.insert(Ranges.end(), DIERanges.begin(), DIERanges.end()); } ``` ```c++ #include #include typedef std::vector> DWARFAddressRangesVector; void collectAddressRanges(DWARFAddressRangesVector &CURanges, const DWARFAddressRangesVector &CUDIERanges) { CURanges.insert(CURanges.end(), CUDIERanges.begin(), CUDIERanges.end()); } int main() { std::vector> CURanges; std::vector> CUDIERanges{{1, 2}}; collectAddressRanges(CURanges, CUDIERanges); return 0; } ``` Both compiled with `g++ -O2` and linked together. When running the compiled program, it raises an exception in the `insert` ``` terminate called after throwing an instance of 'std::length_error' what(): vector::_M_range_insert ``` which shouldn't happen. The issue seems to be related to merging duplicated code since it is important to put the code into two files and the present of the second .o file is important even though none of the code in it is used. The iterations also have to be all on the const reference of vector. Removing one of the const also makes the issue go away. The g++ is version 6.2.1 from the ArchLinuxARM armv7h repository. This might be a regression in gcc 5 since other devs using gcc <=4.9 doesn't seem to have this issue and I was able to reproduce this on archlinux on 4-5 different systems with gcc >=5. This causes https://github.com/JuliaLang/julia/issues/14550
[Bug target/77728] [5/6/7 Regression] Miscompilation multiple vector iteration on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77728 --- Comment #2 from Yichao Yu --- I should add that turning on lto works around the issue both in the simple code attached and for the original issue I was having in julia (i.e. compiling llvm with LTO makes the issue go away).
[Bug lto/77996] New: Miscompilation due to LTO on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77996 Bug ID: 77996 Summary: Miscompilation due to LTO on aarch64 Product: gcc Version: 6.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: yyc1992 at gmail dot com Target Milestone: --- I'm seeing a miscompilation of LLVM's tablegen on AArch64 by gcc 6.2.1 when LTO is enabled. I've tried very hard to reduce it but unfortunately it wasn't very successful this time and the current repro is still 8000 lines of code. Attached are the source and resulting binaries. The code/ directory has a simple cmake projects reduced from the LLVM one (I can turn that into a makefile or a shell script on request but the current form should be pretty simple already). To reproduce make a `build/` directory in `code/` and run `CFLAGS='-flto -O3' CXXFLAGS='-flto -O3' LDFLAGS='-O3 -flto' cmake .. -DCMAKE_BUILD_TYPE=Release; make llvm-tblgen; bin/llvm-tblgen`. Remove the `-flto` should get rid of the error in the last command. Changes in seemingly unrelated lines can also make the error go away. (If there's anything I learnt from reducing it, the error seems to appear only when the code is complex). One of such changes is commenting out `SCTrans.PredTerm = Preds;` close to the end of `CodeGenSchedule.cpp` (used to generate the good/ version included). In fact, removing almost any lines in this file can make the error go away even though not a single line of code there should be executed. The bad/ and the good/ directories conatins compilation results using the flags mentioned above with the unmodified code and the code with the one line commented out. They have all the object files, binary files and the disassemble of the resulting executable/the bad function. The asm's are disassembled from the final binary since I don't know how to get it directly when compiling with LTO. The direct error seems to be in `CodeGenRegister::computeSubRegs` in the branch before the `printf("5\n")`. The `DenseMap::insert` method (which is called twice in this function and nowhere else) is inlined but returns corrupted iterator sometimes when the inserted key already exists in the map causing the check to fail. The difference of asm of this function is in the toplevel of the tarball. Original repro is compiling LLVM with LTO on on AArch64. The compilation should fail when generating target information for AArch64. GCC version is GCC binary package from ArchLinux ARM repo. `gcc --version` gives `gcc (GCC) 6.2.1 20160830`
[Bug lto/77997] New: Miscompilation due to LTO on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77997 Bug ID: 77997 Summary: Miscompilation due to LTO on aarch64 Product: gcc Version: 6.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: yyc1992 at gmail dot com Target Milestone: --- I'm seeing a miscompilation of LLVM's tablegen on AArch64 by gcc 6.2.1 when LTO is enabled. I've tried very hard to reduce it but unfortunately it wasn't very successful this time and the current repro is still 8000 lines of code. Attached are the source and resulting binaries. (Edit: the tarball is too big (3M) so I uploaded to gist instead. Please find it here https://gist.githubusercontent.com/yuyichao/6c24d4a4bc374425906138359a44479c/raw/f5edb6ae8205d5e4d1eb03a7fb900f15711f/report.md) The `code/` directory has a simple cmake projects reduced from the LLVM one (I can turn that into a makefile or a shell script on request but the current form should be pretty simple already). To reproduce make a `build/` directory in `code/` and run `CFLAGS='-flto -O3' CXXFLAGS='-flto -O3' LDFLAGS='-O3 -flto' cmake .. -DCMAKE_BUILD_TYPE=Release; make llvm-tblgen; bin/llvm-tblgen`. Remove the `-flto` should get rid of the error in the last command. Changes in seemingly unrelated lines can also make the error go away. (If there's anything I learnt from reducing it, the error seems to appear only when the code is complex). One of such changes is commenting out `SCTrans.PredTerm = Preds;` close to the end of `CodeGenSchedule.cpp` (used to generate the `good/` version included). In fact, removing almost any lines in this file can make the error go away even though not a single line of code there should be executed. The `bad/` and the `good/` directories conatins compilation results using the flags mentioned above with the unmodified code and the code with the one line commented out. They have all the object files, binary files and the disassemble of the resulting executable/the bad function. The asm's are disassembled from the final binary since I don't know how to get it directly when compiling with LTO. The direct error seems to be in `CodeGenRegister::computeSubRegs` in the branch before the `printf("5\n")`. The `DenseMap::insert` method (which is called twice in this function and nowhere else) is inlined but returns corrupted iterator sometimes when the inserted key already exists in the map causing the check to fail. The difference of asm of this function is in the toplevel of the tarball. Original repro is compiling LLVM with LTO on on AArch64. The compilation should fail when generating target information for AArch64. GCC version is GCC binary package from ArchLinux ARM repo. `gcc --version` gives `gcc (GCC) 6.2.1 20160830`
[Bug lto/77997] Miscompilation due to LTO on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77997 --- Comment #2 from Yichao Yu --- . Sorry the first submission gave me a time out so I did again..
[Bug middle-end/77996] Miscompilation due to LTO on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77996 --- Comment #3 from Yichao Yu --- > What exact version of LLVM are you trying to compile? Revision of the LLVM > sources including revision of clang, etc. I was compiling the trunk version. The version I started reducing from was https://github.com/llvm-mirror/llvm/commit/0885462106134999f8aa80a3a71bfed160910248 but it happens on at least 3 different version I've tried before this commit. > Can you try compile GCC from the 6 branch and try again because having just a > date might not be enough to reproduce the problem. The script used to compile GCC is https://github.com/archlinuxarm/PKGBUILDs/blob/master/core/gcc/PKGBUILD so it seems to be using commit `c2103c17` I can also try to compile a more recent version locally (will take some time).
[Bug middle-end/77996] Miscompilation due to LTO on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77996 --- Comment #5 from Yichao Yu --- Compiling current llvm trunk (r284322) still shows the same error. The script I used to compile LLVM is here https://github.com/yuyichao/arch-pkg/blob/master/pkg/all/llvm-svn/PKGBUILD. Compiling gcc 951db45 now.
[Bug middle-end/77996] Miscompilation due to LTO on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77996 --- Comment #6 from Yichao Yu --- I've compiled a gcc at 951db45 using the same configuration as archlinux arm PKGBUILD and I can reproduce the problem using the `code/` in https://gist.github.com/yuyichao/6c24d4a4bc374425906138359a44479c/raw/f5edb6ae8205d5e4d1eb03a7fb900f15711f/gcc-debug.tar.bz2
[Bug middle-end/77996] Miscompilation due to LTO on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77996 --- Comment #8 from Yichao Yu --- > Can you try with -fno-strict-aliasing ? That seems to fix it for both the original case (LLVM) and the reduced case (the linked tarball). Is there a way to figure out the problematic (either bug in LLVM's code or gcc's alias detection) aliasing assumption?
[Bug middle-end/77996] Miscompilation due to LTO on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77996 --- Comment #10 from Yichao Yu --- That does look like an violation (this particular one should be hidden behind shared library boundary in the reduced case though). Reported to LLVM at https://llvm.org/bugs/show_bug.cgi?id=30711 .
[Bug middle-end/77996] Miscompilation due to LTO on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77996 --- Comment #11 from Yichao Yu --- The case pointed out is fixed in https://reviews.llvm.org/rL284336 although as expected that doesn't fix the error. Still not sure whose bug is this...
[Bug target/77728] [5/6/7 Regression] Miscompilation multiple vector iteration on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77728 --- Comment #4 from Yichao Yu --- Ping. Anything I can help with debugging this?
[Bug middle-end/77996] Miscompilation due to LTO on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77996 --- Comment #12 from Yichao Yu --- Since the LLVM miscompilation isn't fixed, is there any way to check the alias assumptions more programmatically? (I can see that the TrailingObject might easily introduce something like this but given the complexity it's a little hard for me to see if that's actually the case.)
[Bug rtl-optimization/96539] New: Unnecessary no-op copy with Os and tail call with struct argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96539 Bug ID: 96539 Summary: Unnecessary no-op copy with Os and tail call with struct argument Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: yyc1992 at gmail dot com Target Milestone: --- Test C code, ``` struct A { int a; int b; int c; int d; int e; int f; void *p1; void *p2; void *p3; void *p4; void *p5; void *p6; void *p7; }; int k(int a); int f(int a, int b, int c, void *p, struct A s); int g(int a, int b, int c, void *p, struct A s) { k(a); return f(a, b, c, p, s); } ``` At `-O2`, the code produced is ``` g: pushq %r14 movq%rcx, %r14 pushq %r13 movl%edx, %r13d pushq %r12 movl%esi, %r12d pushq %rbp movl%edi, %ebp subq$8, %rsp callk@PLT addq$8, %rsp movq%r14, %rcx movl%r13d, %edx movl%r12d, %esi movl%ebp, %edi popq%rbp popq%r12 popq%r13 popq%r14 jmp f@PLT ``` I'm not sure why the spill of register and save the argument in those registers (maybe for latency for the final call?) but both clang and gcc does that so I assume that's good for performance. However, when I tried `-Os`, the code produced is, ``` g: pushq %r14 movq%rcx, %r14 pushq %r12 movl%esi, %r12d pushq %rbp movl%edi, %ebp subq$16, %rsp movl%edx, 12(%rsp) callk@PLT leaq48(%rsp), %rdi movl$20, %ecx movq%rdi, %rsi rep movsl movq%r14, %rcx movl%r12d, %esi movl%ebp, %edi movl12(%rsp), %edx addq$16, %rsp popq%rbp popq%r12 popq%r14 jmp f@PLT ``` AFAICT, the ``` movq%rdi, %rsi rep movsl ``` is basically always a no-op (moving from and to the same memory location) other than potentially triggering memory fault. The memory being copied in place here is the area where the argument is stored (80 bytes starting at `rsp + 48`) so maybe it's the copying of the argument that failed to be removed when it becomes an no-op for tail call? At `-O1`, the code produced is ``` g: pushq %r13 pushq %r12 pushq %rbp pushq %rbx subq$8, %rsp movl%edi, %ebx movl%esi, %ebp movl%edx, %r12d movq%rcx, %r13 callk@PLT pushq 120(%rsp) pushq 120(%rsp) pushq 120(%rsp) pushq 120(%rsp) pushq 120(%rsp) pushq 120(%rsp) pushq 120(%rsp) pushq 120(%rsp) pushq 120(%rsp) pushq 120(%rsp) movq%r13, %rcx movl%r12d, %edx movl%ebp, %esi movl%ebx, %edi callf@PLT addq$88, %rsp popq%rbx popq%rbp popq%r12 popq%r13 ret ``` which shows the copying of 10 pointers that was not no-op without tail call.
[Bug rtl-optimization/96539] Unnecessary no-op copy with Os and tail call with struct argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96539 --- Comment #4 from Yichao Yu --- Wow that was fast... thx.
[Bug c/96629] New: spurious uninitialized variable warning with branches at -O1 and higher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96629 Bug ID: 96629 Summary: spurious uninitialized variable warning with branches at -O1 and higher Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: yyc1992 at gmail dot com Target Milestone: --- Reduced test code: ``` int mem(char *data); int cond(void); void f(char *data, unsigned idx, unsigned inc) { char *d2; int c = cond(); if (idx >= 2) { if (c) d2 = data; mem(data); } else if (inc > 3) { if (c) d2 = data; mem(data); } else { if (c) { d2 = data; } } if (*data) { } else if (c) { mem(d2); } } ``` Compiling with `gcc -Wall -Wextra -O{1,2,s,3,fast}` warns about ``` a.c: In function 'f': a.c:27:9: warning: 'd2' may be used uninitialized in this function [-Wmaybe-uninitialized] 27 | mem(d2); | ^~~ ``` However, it should be clear that `d2` is always assigned when `c` is true. In fact, it seems that GCC could figure this out in some cases. Changes that can surpress the warning includes, 1. Remove any of the `mem(data)` calls. 2. Remove any one of the `if`s (leaving only the if or else branch unconditionally) 3. Change first condition to be on inc instead. 4. Removing the last `*data` branch. Version tested: AArch64: 10.2.0 ARM: 9.1.0 x86_64: 10.1.0 mingw64: 10.2.0
[Bug c/96629] spurious maybe uninitialized variable warning with difficult control-flow analysis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96629 --- Comment #3 from Yichao Yu --- Just curious, is it some particular structure that is upsetting it or did it simply hit some depth limit.
[Bug c/96990] New: Regression in aarch64 struct vector member initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96990 Bug ID: 96990 Summary: Regression in aarch64 struct vector member initialization Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: yyc1992 at gmail dot com Target Milestone: --- The following code used to work on gcc 9.3 but stops working with 10.2 with an error ``` a.c: In function ‘test_aa64_vec_2’: a.c:19:24: error: incompatible types when initializing type ‘signed char’ using type ‘int8x8_t’ 19 | struct_aa64_3 x = {v1 + v1, v2 - v2}; |^~ a.c:19:33: error: incompatible types when initializing type ‘signed char’ using type ‘float32x2_t’ 19 | struct_aa64_3 x = {v1 + v1, v2 - v2}; | ^~ ``` Any one of the "working" version or compiling with c++ works. >From the error message it seems that GCC correctly inferred the return type of the `v1 + v1` or `v2 - v2` but instead got confused about the field type. Reverssing the order of `v1` and `v2` in the struct causes the error to change to `float` instead of `signed char` so it seems that gcc thinks the code is trying to initialize the first vector member (with element type of `signed char` or `float` instead). I thought such initialization should have an additional `{}` instead... Given that explicit casting or compiling in c++ mode helps I think this is a bug... ``` #include typedef struct { int8x8_t v1; float32x2_t v2; } struct_aa64_3; struct_aa64_3 test_aa64_vec_2(int8x8_t v1, float32x2_t v2) { // works /* int8x8_t vi8 = v1 + v1; */ /* float32x2_t vf = v2 - v2; */ /* struct_aa64_3 x = {vi8, vf}; */ // works /* struct_aa64_3 x = {(int8x8_t)(v1 + v1), (float32x2_t)(v2 - v2)}; */ // not struct_aa64_3 x = {v1 + v1, v2 - v2}; return x; } ```
[Bug target/95775] New: Command line argument for target_clones?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95775 Bug ID: 95775 Summary: Command line argument for target_clones? Product: gcc Version: 10.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: yyc1992 at gmail dot com Target Milestone: --- Would it make sense to add a command line argument that is roughly equivalent to to adding `target_clones` to all functions? In terms of usefulness, I believe it will be a very cheap way for many libraries to turn on the support with minimal code change. It certainly won't be as optimized as best possible but neither is target_clones attribute itself compared to hand wrote different implementations using compiler intrinsics/assembly... In terms of implementation, I believe most of the issues I've hit when adding such attribute to functions has been fixed so I have little issue using it now. It'll also be a new feature so it shouldn't really break any existing code. And for further improvement, the compiler should have fair knowledge of what instruction can be/has been used and can omit some of the cloning in order to reduce code size. I don't think this needs to be included in the first version though... And IIUC this is something that icc does automatically? (If that can serve as a argument for this feature...)
[Bug lto/95776] New: Reduce indirection with target_clones at link time (with LTO)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95776 Bug ID: 95776 Summary: Reduce indirection with target_clones at link time (with LTO) Product: gcc Version: 10.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: yyc1992 at gmail dot com CC: marxin at gcc dot gnu.org Target Milestone: --- Currently, if a function is not not visible outside the final library (static, or internal or hidden visibility), the call of the plt will be replaced with the call to the function directly. With target_clones, this is also possible within the same compilation unit for static functions as callees. The caller that has the same cloning attribute will simply call the cloned function without indirection. However, this stops working when the two are combined. Even with the maximum options and attribute to help it (hidden visibility, same compilation unit, -Wl,-Bsymbolic, LTO) the call to the cloned function from a caller with matching cloning attribute still go through the PLT. Test code ``` __attribute__((noinline,visibility("hidden"))) int f1(int *p) { asm volatile ("" :: "r"(p) : "memory"); return *p; } __attribute__((noinline,visibility("hidden"),target_clones("default,avx2"))) int f2(int *p) { asm volatile ("" :: "r"(p) : "memory"); return *p; } __attribute__((noinline)) int g1(int *p) { return f1(p); } __attribute__((noinline,target_clones("default,avx2"))) int g2(int *p) { return f2(p); } ``` Compiled with `-fPIC -flto -O3 -Wl,-Bsymbolic -shared`. The `f1` call calls `f1` directly whereas the two cloned `f2` calls both call `f2@plt`. The same also applies to inlining, target_clones kills inlining even with lto on. I assume this happens because this can only be done at link time which either didn't get passed enough info to determine this or simply didn't get implemented? I assume this should be possible since it can be done within a single compilation unit.
[Bug c/95777] New: Allow specifying more than one target options at the same time in target and target_clones attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95777 Bug ID: 95777 Summary: Allow specifying more than one target options at the same time in target and target_clones attribute Product: gcc Version: 10.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: yyc1992 at gmail dot com Target Milestone: --- Currently it seems that (document and own tests) only a single option is allowed for each version of the function using `target` and `target_clones`. This can be a problem for options that are not strict subset of each other (e.g. the AVX512 ones IIUC). Of course specifying `cpu=haswell` and `cpu=skylake` for the same target doesn't make much sense so some checking should be in place but I believe allowing multiple directly testable features to be specified at the same time should be allowed. A related issue is that while one can indeed do some of these by specifying a `arch=`. However, even if the runtime CPU supports all the features it'll still not get selected if the name doesn't exactly match (tested with `arch=haswell` on my kabelake laptop). If a fallback could be implemented to make this work that will be also good enough for me at least...
[Bug other/95778] New: target_clones indirection eliminates requires noinline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95778 Bug ID: 95778 Summary: target_clones indirection eliminates requires noinline Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: yyc1992 at gmail dot com Target Milestone: --- Compiling ``` static __attribute__((noinline,target_clones("default,avx2"))) int f2(int *p) { asm volatile ("" :: "r"(p) : "memory"); return *p; } __attribute__((target_clones("default,avx2"))) int g2(int *p) { return f2(p); } ``` with `-fPIC -O3` generates ``` g2.avx2.0: jmp f2.avx2.0 ``` However, if any of the two `noinline` is removed, the generated code becomes, ``` g2.avx2.0: jmp f2@PLT ``` which cannot get eliminated later https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95776 I think this should be possible to do and should be possible without LTO (hence a slightly different bug than https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95776 even though if that one is fixed turning on LTO can particially fix this). Also, in this case, the `f2` should be inlinable to `g2`. However, no combination of `inline`, `always_inline`, `flatten` I've tested can do that, even though when both functions are marked with `noinline` gcc clearly knows which function is calling what so it should have no problem inlining.
[Bug other/95779] New: Unnecessary dispatch function for static target_clones function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95779 Bug ID: 95779 Summary: Unnecessary dispatch function for static target_clones function. Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: yyc1992 at gmail dot com Target Milestone: --- Using the code in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95778 the full assembly generated (the version with both noinline) is (disabled unwind info), ``` .file "b.c" .text .p2align 4 .type f2.default.1, @function f2.default.1: movl(%rdi), %eax ret .size f2.default.1, .-f2.default.1 .p2align 4 .type g2.default.1, @function g2.default.1: jmp f2.default.1 .size g2.default.1, .-g2.default.1 .p2align 4 .type f2.avx2.0, @function f2.avx2.0: movl(%rdi), %eax ret .size f2.avx2.0, .-f2.avx2.0 .p2align 4 .type g2.avx2.0, @function g2.avx2.0: jmp f2.avx2.0 .size g2.avx2.0, .-g2.avx2.0 .section.text.g2.resolver,"axG",@progbits,g2.resolver,comdat .p2align 4 .weak g2.resolver .type g2.resolver, @function g2.resolver: subq$8, %rsp call__cpu_indicator_init@PLT movq__cpu_model@GOTPCREL(%rip), %rax leaqg2.avx2.0(%rip), %rdx testb $4, 13(%rax) leaqg2.default.1(%rip), %rax cmovne %rdx, %rax addq$8, %rsp ret .size g2.resolver, .-g2.resolver .globl g2 .type g2, @gnu_indirect_function .setg2,g2.resolver .text .p2align 4 .type f2.resolver, @function f2.resolver: subq$8, %rsp call__cpu_indicator_init@PLT movq__cpu_model@GOTPCREL(%rip), %rax leaqf2.avx2.0(%rip), %rdx testb $4, 13(%rax) leaqf2.default.1(%rip), %rax cmovne %rdx, %rax addq$8, %rsp ret .size f2.resolver, .-f2.resolver .ident "GCC: (GNU) 10.1.0" .section.note.GNU-stack,"",@progbits ``` AFAICT the `f2.resolver` is never used anywhere and can be omitted (all caller of `f2` are statically dispatched).
[Bug other/95780] New: target_clones treats internal visibility different from static functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95780 Bug ID: 95780 Summary: target_clones treats internal visibility different from static functions Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: yyc1992 at gmail dot com Target Milestone: --- Again using the code in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95778. If the static function `f2` is changed to `visibility("internal")`, i.e. ``` __attribute__((visibility("internal"),noinline,target_clones("default,avx2"))) int f2(int *p) { asm volatile ("" :: "r"(p) : "memory"); return *p; } __attribute__((noinline,target_clones("default,avx2"))) int g2(int *p) { return f2(p); } ``` the call to `f2` will then use the PLT again. Without `target_clone` the two has similar effects and both produce a direct call.
[Bug other/95781] New: Missing dead code elimination when a recursive function is inlined.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95781 Bug ID: 95781 Summary: Missing dead code elimination when a recursive function is inlined. Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: yyc1992 at gmail dot com Target Milestone: --- Code, ``` static int 2(int *p, int k) { int res = 0; if (k > 0) res += 2(p, k - 1); return *p + res; } int g2(int *p) { return 2(p, 3); } ``` Compiling with -O3 the code produced for `g2` is ``` g2: movl(%rdi), %eax sall$2, %eax ret ``` i.e. `*p * 4` that doesn't need to call `2`. However, the code for `2` is still generated even though it is never used. It seems that this only happens when the recursive function is sufficiently complex. Replacing `*p` with a constant or making the `k > 0` branch returning directly produces code that does not have `2` in it. Seems that there's some smart late optimization pass that doesn't have a global DCE pass afterwards? Looks similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80680 but I'm not sure if they have the same root cause.
[Bug other/95778] target_clones indirection eliminates requires noinline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95778 --- Comment #1 from Yichao Yu --- Ah, I think this might be the fix for both this issue and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95780 . I'll test more and will try to submit it later. ``` diff --git a/gcc/multiple_target.c b/gcc/multiple_target.c index c1cfe8ff978..79a4c87545f 100644 --- a/gcc/multiple_target.c +++ b/gcc/multiple_target.c @@ -483,7 +483,7 @@ redirect_to_specific_clone (cgraph_node *node) DECL_ATTRIBUTES (e->callee->decl)); /* Function is not calling proper target clone. */ - if (!attribute_list_equal (attr_target, attr_target2)) + if (!attribute_value_equal (attr_target, attr_target2)) { while (fv2->prev != NULL) fv2 = fv2->prev; @@ -494,7 +494,7 @@ redirect_to_specific_clone (cgraph_node *node) cgraph_node *callee = fv2->this_node; attr_target2 = lookup_attribute ("target", DECL_ATTRIBUTES (callee->decl)); - if (attribute_list_equal (attr_target, attr_target2)) + if (attribute_value_equal (attr_target, attr_target2)) { e->redirect_callee (callee); cgraph_edge::redirect_call_stmt_to_callee (e); ```
[Bug other/95778] target_clones indirection eliminates requires noinline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95778 --- Comment #2 from Yichao Yu --- Also, the original code example had an error, the code that works properly was ``` static __attribute__((noinline,target_clones("default,avx2"))) int f2(int *p) { asm volatile ("" :: "r"(p) : "memory"); return *p; } __attribute__((noinline,target_clones("default,avx2"))) int g2(int *p) { return f2(p); } ```
[Bug tree-optimization/95786] New: Too aggressive target indirection elimination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95786 Bug ID: 95786 Summary: Too aggressive target indirection elimination Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: yyc1992 at gmail dot com Target Milestone: --- I realize this issue when debugging PR95778 and PR95780 (ref https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548631.html) It seems that the indirection elimination logic does not take into account the linkage and visibility of the callee and will eliminate the indirection even in cases where a function without target attribute would have use a PLT and, for example, allows a override from a different library. The following code generates a direct call beween g2 and f2 without going through PLT. ``` __attribute__((target_clones("default,avx2"))) int f2(int *p) { asm volatile ("" :: "r"(p) : "memory"); return *p; } __attribute__((target_clones("default,avx2"))) int g2(int *p) { return f2(p); } ``` but removing the target_clones attribute uses the PLT.
[Bug ipa/95790] New: Incorrect static target dispatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95790 Bug ID: 95790 Summary: Incorrect static target dispatch Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: yyc1992 at gmail dot com CC: marxin at gcc dot gnu.org Target Milestone: --- The indirection elimination code currently only check for match of the target for the specific version but doesn't check if all the targets are matching. Modifying from https://github.com/gcc-mirror/gcc/commit/b8ce8129a560f64f8b2855c4a3812b7c3c0ebf3f#diff-e2d535917af8555baad2e9c8749e96a5 ``` __attribute__ ((target ("default"))) static unsigned foo(const char *buf, unsigned size) { return 1; } __attribute__ ((target ("avx"))) static unsigned foo(const char *buf, unsigned size) { return 2; } __attribute__ ((target ("avx512f"))) static unsigned foo(const char *buf, unsigned size) { return 3; } __attribute__ ((target ("default"))) unsigned bar() { char buf[4096]; unsigned acc = 0; for (int i = 0; i < sizeof(buf); i++) { acc += foo(&buf[i], 1); } return acc; } __attribute__ ((target ("avx"))) unsigned bar() { char buf[4096]; unsigned acc = 0; for (int i = 0; i < sizeof(buf); i++) { acc += foo(&buf[i], 1); } return acc; } ``` With the optimization disabled, which is possible by adding a flatten attribute to the functions and triggering PR95780 and PR95778, a resolver function is automatically generated for foo like ``` .text .LHOTB0: .p2align 4 .type _ZL3fooPKcj.resolver, @function _ZL3fooPKcj.resolver: subq$8, %rsp call__cpu_indicator_init@PLT movq__cpu_model@GOTPCREL(%rip), %rax movl12(%rax), %eax testb $-128, %ah je .L8 leaq_ZL3fooPKcj.avx512f(%rip), %rax .L7: addq$8, %rsp ret .section.text.unlikely .type _ZL3fooPKcj.resolver.cold, @function _ZL3fooPKcj.resolver.cold: .L8: testb $2, %ah leaq_ZL3fooPKcj.avx(%rip), %rdx leaq_ZL3fooPKcj(%rip), %rax cmovne %rdx, %rax jmp .L7 .text .size _ZL3fooPKcj.resolver, .-_ZL3fooPKcj.resolver .section.text.unlikely .size _ZL3fooPKcj.resolver.cold, .-_ZL3fooPKcj.resolver.cold .LCOLDE0: .text .LHOTE0: .type _Z11_ZL3fooPKcjPKcj, @gnu_indirect_function .set_Z11_ZL3fooPKcjPKcj,_ZL3fooPKcj.resolver ``` and the calls from bar goes through the PLT. This is the correct behavior (albeit sub-optimal since the default could call the default directly) and allows avx512f version of foo to be called on the correct processor from the avx version of bar. With the optimization enabled, however, the call of foo's are inlined to bar and the avx512f version is never used. This is somewhat a regression caused by b8ce8129a560f64f8b2855c4a3812b7c3c0ebf3f. It'll also affect my fix for PR95780 and PR95778. https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548631.html
[Bug other/95778] target_clones indirection eliminates requires noinline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95778 --- Comment #4 from Yichao Yu --- Yeah, after digging further the two issue are indeed the same. I initially didn't think they are since I didn't realize PR95786 (that the visibility attribute is simply ignored completely...) and thought static was handled specially It also seems that when target attribute is used directly the inlining can work. Maybe a pass order issue? and that's certainly a different issue so I'll file another one if there isn't one already when I have time.
[Bug ipa/95790] Incorrect static target dispatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95790 --- Comment #2 from Yichao Yu --- The C++ code attached above produces the following incorrect code with `g++ -O2 -S` .file "a.c" .text .p2align 4 .globl _Z3barv .type _Z3barv, @function _Z3barv: .LFB3: .cfi_startproc movl$4096, %eax ret .cfi_endproc .LFE3: .size _Z3barv, .-_Z3barv .p2align 4 .globl _Z3barv.avx .type _Z3barv.avx, @function _Z3barv.avx: .LFB4: .cfi_startproc movl$8192, %eax ret .cfi_endproc .LFE4: .size _Z3barv.avx, .-_Z3barv.avx .ident "GCC: (GNU) 10.1.0" .section.note.GNU-stack,"",@progbits Triggering the bug PR95778 with __attribute__ ((flatten,target ("default"))) static unsigned foo(const char *buf, unsigned size) { return 1; } __attribute__ ((flatten,target ("avx"))) static unsigned foo(const char *buf, unsigned size) { return 2; } __attribute__ ((flatten,target ("avx512f"))) static unsigned foo(const char *buf, unsigned size) { return 3; } __attribute__ ((target ("default"))) unsigned bar() { char buf[4096]; unsigned acc = 0; for (int i = 0; i < sizeof(buf); i++) { acc += foo(&buf[i], 1); } return acc; } __attribute__ ((target ("avx"))) unsigned bar() { char buf[4096]; unsigned acc = 0; for (int i = 0; i < sizeof(buf); i++) { acc += foo(&buf[i], 1); } return acc; } produces the correct code.
[Bug ipa/95790] Incorrect static target dispatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95790 --- Comment #3 from Yichao Yu --- And the assembly showing the correct dispatch is .file "a.c" .text .p2align 4 .type _ZL3fooPKcj, @function _ZL3fooPKcj: .LFB0: .cfi_startproc movl$1, %eax ret .cfi_endproc .LFE0: .size _ZL3fooPKcj, .-_ZL3fooPKcj .p2align 4 .type _ZL3fooPKcj.avx, @function _ZL3fooPKcj.avx: .LFB1: .cfi_startproc movl$2, %eax ret .cfi_endproc .LFE1: .size _ZL3fooPKcj.avx, .-_ZL3fooPKcj.avx .p2align 4 .type _ZL3fooPKcj.avx512f, @function _ZL3fooPKcj.avx512f: .LFB2: .cfi_startproc movl$3, %eax ret .cfi_endproc .LFE2: .size _ZL3fooPKcj.avx512f, .-_ZL3fooPKcj.avx512f .section.text.unlikely,"ax",@progbits .LCOLDB0: .text .LHOTB0: .p2align 4 .type _ZL3fooPKcj.resolver, @function _ZL3fooPKcj.resolver: .LFB6: .cfi_startproc subq$8, %rsp .cfi_def_cfa_offset 16 call__cpu_indicator_init@PLT movq__cpu_model@GOTPCREL(%rip), %rax movl12(%rax), %eax testb $-128, %ah je .L8 leaq_ZL3fooPKcj.avx512f(%rip), %rax .L7: addq$8, %rsp .cfi_def_cfa_offset 8 ret .cfi_endproc .section.text.unlikely .cfi_startproc .type _ZL3fooPKcj.resolver.cold, @function _ZL3fooPKcj.resolver.cold: .LFSB6: .L8: .cfi_def_cfa_offset 16 testb $2, %ah leaq_ZL3fooPKcj.avx(%rip), %rdx leaq_ZL3fooPKcj(%rip), %rax cmovne %rdx, %rax jmp .L7 .cfi_endproc .LFE6: .text .size _ZL3fooPKcj.resolver, .-_ZL3fooPKcj.resolver .section.text.unlikely .size _ZL3fooPKcj.resolver.cold, .-_ZL3fooPKcj.resolver.cold .LCOLDE0: .text .LHOTE0: .type _Z11_ZL3fooPKcjPKcj, @gnu_indirect_function .set_Z11_ZL3fooPKcjPKcj,_ZL3fooPKcj.resolver .p2align 4 .globl _Z3barv .type _Z3barv, @function _Z3barv: .LFB3: .cfi_startproc pushq %r12 .cfi_def_cfa_offset 16 .cfi_offset 12, -16 xorl%r12d, %r12d pushq %rbp .cfi_def_cfa_offset 24 .cfi_offset 6, -24 pushq %rbx .cfi_def_cfa_offset 32 .cfi_offset 3, -32 subq$4112, %rsp .cfi_def_cfa_offset 4144 movq%fs:40, %rax movq%rax, 4104(%rsp) xorl%eax, %eax movq%rsp, %rbx leaq4096(%rsp), %rbp .p2align 4,,10 .p2align 3 .L12: movq%rbx, %rdi movl$1, %esi addq$1, %rbx call_Z11_ZL3fooPKcjPKcj@PLT addl%eax, %r12d cmpq%rbp, %rbx jne .L12 movq4104(%rsp), %rax subq%fs:40, %rax jne .L16 addq$4112, %rsp .cfi_remember_state .cfi_def_cfa_offset 32 movl%r12d, %eax popq%rbx .cfi_def_cfa_offset 24 popq%rbp .cfi_def_cfa_offset 16 popq%r12 .cfi_def_cfa_offset 8 ret .L16: .cfi_restore_state call__stack_chk_fail@PLT .cfi_endproc .LFE3: .size _Z3barv, .-_Z3barv .p2align 4 .globl _Z3barv.avx .type _Z3barv.avx, @function _Z3barv.avx: .LFB4: .cfi_startproc pushq %r12 .cfi_def_cfa_offset 16 .cfi_offset 12, -16 xorl%r12d, %r12d pushq %rbp .cfi_def_cfa_offset 24 .cfi_offset 6, -24 pushq %rbx .cfi_def_cfa_offset 32 .cfi_offset 3, -32 subq$4112, %rsp .cfi_def_cfa_offset 4144 movq%fs:40, %rax movq%rax, 4104(%rsp) xorl%eax, %eax movq%rsp, %rbx leaq4096(%rsp), %rbp .p2align 4,,10 .p2align 3 .L18: movq%rbx, %rdi movl$1, %esi addq$1, %rbx call_Z11_ZL3fooPKcjPKcj@PLT addl%eax, %r12d cmpq%rbp, %rbx jne .L18 movq4104(%rsp), %rax subq%fs:40, %rax jne .L22 addq$4112, %rsp .cfi_remember_state .cfi_def_cfa_offset 32 movl%r12d, %eax popq%rbx .cfi_def_cfa_offset 24 popq%rbp .cfi_def_cfa_offset 16 popq%r12 .cfi_def_cfa_offset 8 ret .L22: .cfi_restore_state call__stack_chk_fail@PLT .cfi_endproc .LFE4: .size _Z3barv.avx, .-_Z3barv.avx .ident "GCC: (GNU) 10.1.0" .section.note.GNU-stack,"",@progbits
[Bug ipa/95790] Incorrect static target dispatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95790 --- Comment #5 from Yichao Yu --- It’s wrong when running on a target that has avx512f. The unoptimuzed version will call the correct foo but the unoptimized case won’t. As I said, this is an issue when the total targets are different between the callee and caller.
[Bug ipa/95790] Incorrect static target dispatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95790 --- Comment #7 from Yichao Yu --- > Your testcase has nested function multi-versioning. I don't think it works at all. I opened PR 95793. I'm sorry but what is nested function multi-versioning? and what's the difference between the test case here and the one in PR95793?
[Bug ipa/95790] Incorrect static target dispatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95790 --- Comment #8 from Yichao Yu --- And the reason I reported this as a mis-optimization rather than something completely unsupported is that the following code. ``` #include // #define disable_opt __attribute__((flatten)) #define disable_opt disable_opt __attribute__ ((target ("default"))) static unsigned foo(const char *buf, unsigned size) { return 1; } disable_opt __attribute__ ((target ("avx"))) static unsigned foo(const char *buf, unsigned size) { return 2; } disable_opt __attribute__ ((target ("avx2"))) static unsigned foo(const char *buf, unsigned size) { return 3; } __attribute__ ((target ("default"))) unsigned bar() { char buf[4096]; unsigned acc = 0; for (int i = 0; i < sizeof(buf); i++) { acc += foo(&buf[i], 1); } return acc; } __attribute__ ((target ("avx"))) unsigned bar() { char buf[4096]; unsigned acc = 0; for (int i = 0; i < sizeof(buf); i++) { acc += foo(&buf[i], 1); } return acc; } int main() { printf("%u\n", bar()); return 0; } ``` when compiled with `#define disable_opt`, prints the wrong answer `8192` on my avx2 laptop. OTOH, with `#define disable_opt __attribute__((flatten))` to disable the inlining using the bug, it prints the correct result of 12288. Other ways force an independent dispatch like the following using a volatile slot also works. ``` #include __attribute__ ((target ("default"))) static unsigned _foo(const char *buf, unsigned size) { return 1; } __attribute__ ((target ("avx"))) static unsigned _foo(const char *buf, unsigned size) { return 2; } __attribute__ ((target ("avx2"))) static unsigned _foo(const char *buf, unsigned size) { return 3; } static unsigned (* volatile foo)(const char *buf, unsigned size) = _foo; __attribute__ ((target ("default"))) unsigned bar() { char buf[4096]; unsigned acc = 0; for (int i = 0; i < sizeof(buf); i++) { acc += foo(&buf[i], 1); } return acc; } __attribute__ ((target ("avx"))) unsigned bar() { char buf[4096]; unsigned acc = 0; for (int i = 0; i < sizeof(buf); i++) { acc += foo(&buf[i], 1); } return acc; } int main() { printf("%u\n", bar()); return 0; } ``` I think this suggests that the most basic codegen without optimization is clearly working and this usage (being it nested multiversioning or not) isn't something that's just not supported. Rather it's only the optimization that's wrong.
[Bug ipa/95796] New: Inlining works between functions with the same target attribute but not target_clones
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95796 Bug ID: 95796 Summary: Inlining works between functions with the same target attribute but not target_clones Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: yyc1992 at gmail dot com CC: marxin at gcc dot gnu.org Target Milestone: --- If two functions with the same target attribute calls each other, GCC can inline one into another one (although sometimes incorrectly... PR95790). This can be shown with the following code (all compilation using `g++ -O2 -S -fno-exceptions -fno-asynchronous-unwind-tables`). ``` __attribute__ ((target ("default"))) static unsigned foo() { return 1; } __attribute__ ((target ("avx"))) static unsigned foo() { return 1; } __attribute__ ((target ("default"))) unsigned bar() { return foo(); } __attribute__ ((target ("avx"))) unsigned bar() { return foo(); } ``` which is compiled to ``` .text .p2align 4 .globl _Z3barv .type _Z3barv, @function _Z3barv: movl$1, %eax ret .size _Z3barv, .-_Z3barv .p2align 4 .globl _Z3barv.avx .type _Z3barv.avx, @function _Z3barv.avx: movl$1, %eax ret .size _Z3barv.avx, .-_Z3barv.avx ``` OTOH, the equivalent code using `target_clones` ``` __attribute__ ((target_clones ("default,avx"))) static unsigned foo() { return 1; } __attribute__ ((target_clones ("default,avx"))) unsigned bar() { return foo(); } ``` compiles to ``` .text .p2align 4 .type _ZL3foov.default.1, @function _ZL3foov.default.1: movl$1, %eax ret .size _ZL3foov.default.1, .-_ZL3foov.default.1 .p2align 4 .type _Z3barv.default.1, @function _Z3barv.default.1: jmp _ZL3foov.default.1 .size _Z3barv.default.1, .-_Z3barv.default.1 .p2align 4 .type _ZL3foov.avx.0, @function _ZL3foov.avx.0: movl$1, %eax ret .size _ZL3foov.avx.0, .-_ZL3foov.avx.0 .p2align 4 .type _Z3barv.avx.0, @function _Z3barv.avx.0: jmp _ZL3foov.avx.0 .size _Z3barv.avx.0, .-_Z3barv.avx.0 .section .text._Z3barv.resolver,"axG",@progbits,_Z3barv.resolver,comdat .p2align 4 .weak _Z3barv.resolver .type _Z3barv.resolver, @function _Z3barv.resolver: subq$8, %rsp call__cpu_indicator_init@PLT movq__cpu_model@GOTPCREL(%rip), %rax leaq_Z3barv.avx.0(%rip), %rdx testb $2, 13(%rax) leaq_Z3barv.default.1(%rip), %rax cmovne %rdx, %rax addq$8, %rsp ret .size _Z3barv.resolver, .-_Z3barv.resolver .globl _Z3barv .type _Z3barv, @gnu_indirect_function .set_Z3barv,_Z3barv.resolver .text .p2align 4 .type _ZL3foov.resolver, @function _ZL3foov.resolver: subq$8, %rsp call__cpu_indicator_init@PLT movq__cpu_model@GOTPCREL(%rip), %rax leaq_ZL3foov.avx.0(%rip), %rdx testb $2, 13(%rax) leaq_ZL3foov.default.1(%rip), %rax cmovne %rdx, %rax addq$8, %rsp ret .size _ZL3foov.resolver, .-_ZL3foov.resolver ``` instead. Which only eliminates the indirect call but does not inline `foo` into `bar`. (Note that the useless resolver for foo is PR95779). I believe the two versions should behave the same... Ref PR95778 (PLT elimination) Ref PR71990 (similar title but different. That one is about inlining of the dispatcher itself IIUC and is not about the case that can already be statically dispatched. It is also not specific to target_clones like this one is)
[Bug ipa/95775] Command line argument for target_clones?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95775 --- Comment #2 from Yichao Yu --- > But it will blow up code-size considerably. > So without some major work I don't think simply slapping target_clones on > each function is going to fly in practice. I mean, it'll blow up not much more than the number of targets. I do agree this is not something that the compiler should just do automatically and especially not for big libraries and the user has to ask for it. However, I don't believe code side consumes most memory on any modern desktop or server systems and when using shared library different process won't even consume much more memory anyway. It's for sure still the user's choice but OTOH I think the compiler shouldn't have to make this choice for the user. Additionally, there are some libraries, like math heavy ones, where virtually every single functions could benefit from this. Those are the ones that I would like to apply this option too. I'm also hoping, and I forgot to mention this in the first post, that this can just work on gfortran as well... > Eventually it should be possible to do sth like target_clones(auto) where > with a new option, the target (or the user) can define "default" targets to > clone for but the user still figures which are the important functions to > optimize In julia I'm currently using a simple heuristic of detecting floating point operation, vector operation and loops... > [and GCC may, via IPA "spread" the cloned cgraph portion a bit]. and I do this in julia too.
[Bug c/95777] Allow specifying more than one target options at the same time in target and target_clones attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95777 --- Comment #2 from Yichao Yu --- I only tested this with `target_clones` and it seems that I misread the document for `target`. So this is only an issue with `target_clones` attribute. `target` support this just fine. So to be more clear, using an example from the doc, it seems impossible to do the equivalent of `target("sse4.1,arch=core2")` using `target_clones`. Doing `target_clones("sse4.1,arch=core2")` will create two functions instead of one. (of course in reality what I might actually want is to make `target_clones` do `target("sse4.1,arch=core2")` and target("default")).
[Bug c/95777] Allow specifying more than one target options at the same time in target and target_clones attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95777 --- Comment #3 from Yichao Yu --- And for backward compatibility maybe `target_clones("(sse4.1,arch=core2),default")` would work?
[Bug ipa/95775] Command line argument for target_clones?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95775 --- Comment #4 from Yichao Yu --- > Hey. My opinion is similar to Richi's. If you really want a highly optimized > library, you should rather use a dlopen mechanism with pre-built set of > options. Well, a few things, 1. That sounds like an argument against `target_clone` and `target`. If dlopen'ing different libraries is your recommended solution then none of these would be needed. 2. The solution you propose put all the pression on the user of the library. That has a few problems. 2.1. There are strictly more users than libraries. (Assuming the library is used at all) so this is forcing more (repeated) work to be done. 2.2. The author of the library and to a lesser degree the builder of the library has the best knowledge of the set of features that can benefit the library/the most useful for the deployment environment. The author of the user code of the library, who has to implement the dispatch/loading logic in general has much less complete knowledge of what the target to support. 2.3. It'll be even worse for code size since this forces each user to carry their own library, and now all data has to be duplicated as well in additional to code. Also because, 3. There's no standard way of doing this AFAICT. Now (3) is really the main point. I'm fine with whatever mechanism that allows multiple versions of the code to be available as long as it requires no more effort/cost from/for the user (and to a lesser degree the author) of the library. If one such mechanism is provided by gcc/glibc/binutils so that library writers don't have to invent their own loading and detection mechanism and won't cause unnecessary indirection (as cheap as ifunc) and will just work for the user to either link or dlopen, then I think it doesn't really matter if that's backed by one file/multiple files or whatever one can come up with. Currently, the only mechanism available that fits this description AFAICT is `target_clones`/`ifunc`. Unless there's a roadmap that I'm not aware of to replace this mechanism with a similar one backed by multiple files I don't think suggesting such a mechanism is the right approach. Again, I said in the very first post that I totally agree this won't be the method to give absolutely the best performance, but neither is `target_clones`. I also completely agree that this option can be misused and the compiler should not do it on its own before getting smarter but this is far from the first option that can be misused and given how cheap memory is and how multiple load of the same library doesn't take more memory this isn't even closoed to be the worse misused either.
[Bug fortran/96069] New: -ffile-prefix-map does not affect print in gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96069 Bug ID: 96069 Summary: -ffile-prefix-map does not affect print in gfortran Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: yyc1992 at gmail dot com Target Milestone: --- Compiling the following code `a.f` ``` subroutine f(name) implicit none character*(*) name print *,name return end ``` with `gfortran -fdebug-prefix-map="${PWD}"=/usr/src/debug -ffile-prefix-map="${PWD}"=/usr/src/debug -O3 -fPIC "${PWD}/"a.f -o - -S` will cause the full path to the file to be included in the generated assembly without respecting the prefix map. This works in C with `-ffile-prefix-map` which implies `-fmacro-prefix-map` but the lattr isn't supported by gfortran.
[Bug fortran/96069] -ffile-prefix-map does not affect print in gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96069 --- Comment #2 from Yichao Yu --- Why should this feature be c only?
[Bug preprocessor/96069] -ffile-prefix-map does not affect print in gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96069 --- Comment #4 from Yichao Yu --- > Apparently it is. Yes, but my question is about why should this be "WONTFIX". This feature (reproducible build) is certainly as useful in fortran as it is in C family. > Let move the component to 'preprocessor'. At least for the issue for the fortran code I had it doesn't seem to be in the preprocessor. I do agree that other frontends should probably use this too but I have no idea what are the cases they should do it. Also note that I've already submitted patches to fix this though I haven't got a reply yet.
[Bug preprocessor/96069] -ffile-prefix-map does not affect print in gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96069 --- Comment #6 from Yichao Yu --- https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549411.html and https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549413.html
[Bug preprocessor/96069] -ffile-prefix-map does not affect print in gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96069 --- Comment #8 from Yichao Yu --- OK, done. It would be nice to mention it on https://gcc.gnu.org/contribute.html#patches
[Bug ipa/94656] New: target_clones on alias leads to segfault in the compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94656 Bug ID: 94656 Summary: target_clones on alias leads to segfault in the compiler Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: yyc1992 at gmail dot com CC: marxin at gcc dot gnu.org Target Milestone: --- Compiling the following code with `gcc -c` leads to a segfault in the compiler targetclone pass. ``` __attribute__((target_clones("default,avx"))) void f1() { } __attribute__((target_clones("default,avx"))) void f2() __attribute__((alias("f1"))); ``` The error was. ``` during IPA pass: targetclone src/s_nextafterl.c:6:1: internal compiler error: Segmentation fault 6 | __attribute__((target_clones("default,avx"))) void f2() __attribute__((alias("f1"))); | ^ ``` Now this came from a hack I was playing around and I'm not going to argue if having a target_clone on a alias should be supported (though if the target agrees I think it would be nice to support it... and if not agree a warning would be better IMHO). However, I don't think a segfault is what should happen here = =
[Bug lto/94659] New: Missing symbol with LTO and target_clones
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94659 Bug ID: 94659 Summary: Missing symbol with LTO and target_clones Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: yyc1992 at gmail dot com CC: marxin at gcc dot gnu.org Target Milestone: --- This is basically the same as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80732 except now it only happens with LTO enabled. It seems that if a function with `target_clones` attribute isn't used in the final library and if LTO is enabled, the function will be missing from the resulting library. Only the `.resolver` symbol appears. The test code is ``` // b.c __attribute__((target_clones("default,avx"))) int f1() { return 2; } ``` when compiled with `gcc -g -flto -O3 -fPIC b.c -shared -o libb-lto.so`, the exported symbols available are, ``` $ objdump -T libb-lto.so libb-lto.so: file format elf64-x86-64 DYNAMIC SYMBOL TABLE: w D *UND* _ITM_deregisterTMCloneTable w D *UND* __gmon_start__ w D *UND* _ITM_registerTMCloneTable w DF *UND* GLIBC_2.2.5 __cxa_finalize 1730 gDF .text 002b Basef1.resolver ``` Compared to the output lilbrary from `gcc -g -O3 -fPIC b.c -shared -o libb.so` ``` $ objdump -T libb.so libb.so: file format elf64-x86-64 DYNAMIC SYMBOL TABLE: w D *UND* _ITM_deregisterTMCloneTable w D *UND* __gmon_start__ w D *UND* _ITM_registerTMCloneTable w DF *UND* GLIBC_2.2.5 __cxa_finalize 1730 w DF .text 002b Basef1.resolver 1730 g iD .text 002b Basef1 ``` The exported symbol has the wrong name for the LTO version. `dlsym` result confirms the difference. If the function is used somewhere else in the library, the resulting symbol will then looks the same as the non-LTO version.
[Bug c/89485] New: Support vectorcall calling convention on windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89485 Bug ID: 89485 Summary: Support vectorcall calling convention on windows Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: yyc1992 at gmail dot com Target Milestone: --- I'm very surprised that I didn't find an issue for this so sorry if this is discussed/rejected somewhere else. It appears that both MSVC and clang supports a vectorcall calling convention which is very similar to the one used on linux and passes large vectors in the corresponding vector register instead of on the stack. It'll be nice if gcc can support that both for efficiency and for compatibility. Ref https://docs.microsoft.com/en-us/cpp/cpp/vectorcall?view=vs-2017 https://clang.llvm.org/docs/AttributeReference.html#id335
[Bug target/54412] minimal 32-byte stack alignment with -mavx on 64-bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412 Yichao Yu changed: What|Removed |Added CC||yyc1992 at gmail dot com --- Comment #23 from Yichao Yu --- > It is GCC does not realign the stack at all that is the issue. I hit another related issue that might confirm this as well. I noticed this when I tried to manually align the stack with inline assembly. C++ code reduced from my test case, ``` #include #include #include __attribute__((target("avx"))) __attribute__((noinline)) __m256d f(__m256d x, uint32_t a, const double *p) { __m256d res; asm volatile ("vxorpd %0, %0, %0" : "=x"(res), "+x"(x), "+r"(a), "+r"(p) :: "memory", "rax", "rcx", "rdx", "r8", "r9", "r10", "r11", "rbp"); return res; } __attribute__((target("avx"))) __attribute__((noinline)) __m256d f2(__m256d x, uint32_t a, const double *p) { __m256d res; asm volatile ("vxorpd %0, %0, %0" : "=x"(res), "+x"(x), "+r"(a), "+r"(p) :: "memory", "rax", "rcx", "rdx", "r8", "r9", "r10", "r11", "rbp"); return res; } __attribute__((target("avx"))) __attribute__((noinline)) __m256d f(__m256d x, __m256d y, __m256d z, uint32_t a, const double *p) { __m256d res; asm volatile ("vxorpd %0, %0, %0" : "=x"(res), "+x"(x), "+x"(y), "+x"(z), "+r"(a), "+r"(p) :: "memory", "rax", "rcx", "rdx", "r8", "r9", "r10", "r11", "rbp"); return res; } const double points[] = {0, 0.1, 0.2, 0.6}; __attribute__((target("avx"))) void test_avx() { f(__m256d{0, 0, 0, 0}, __m256d{0, 0, 0, 0}, __m256d{0, 0, 0, 0}, 4, points); f(__m256d{0, 0, 0, 0}, 4, points); } __attribute__((target("avx"))) void test_avx2() { f2(__m256d{0, 0, 0, 0}, 4, points); } static void call_aligned_stack(void (*p)(void)) { asm volatile ("movq %%rsp, %%rbp\n" "andq $-64, %%rsp\n" "subq $64, %%rsp\n" "callq *%0\n" "movq %%rbp, %%rsp\n" :: "r"(p) : "memory", "rax", "rcx", "rdx", "r8", "r9", "r10", "r11", "rbp"); } int main() { call_aligned_stack(test_avx); fprintf(stderr, "\n"); fflush(stderr); call_aligned_stack(test_avx2); return 0; } ``` (The `fprintf` is there only to make it easier to see when the crash happens.) The stack alignment code makes sure that the stack is aligned to 64bytes before making the `call`, which is verified in the debugger, however, when compiled with GCC 8.2.1 on msys2 (using the mingw-w64-x86_64-gcc package) the `test_avx` function is happy while `test_avx2` function is not. Looking at the generated code, for the crashing function: ``` 004015c0 <_Z9test_avx2v>: 4015c0: 48 83 ec 68 sub$0x68,%rsp 4015c4: c5 f9 57 c0 vxorpd %xmm0,%xmm0,%xmm0 4015c8: 4c 8d 0d 51 7a 00 00lea0x7a51(%rip),%r9# 409020 <_ZL6points> 4015cf: 41 b8 04 00 00 00 mov$0x4,%r8d 4015d5: 48 8d 4c 24 40 lea0x40(%rsp),%rcx 4015da: 48 8d 54 24 20 lea0x20(%rsp),%rdx 4015df: c5 fd 29 44 24 20 vmovapd %ymm0,0x20(%rsp) 4015e5: c5 f8 77vzeroupper 4015e8: e8 a3 ff ff ff callq 401590 <_Z2f2Dv4_djPKd> 4015ed: 90 nop 4015ee: 48 83 c4 68 add$0x68,%rsp 4015f2: c3 retq ``` which tries to write with 32byte alignment with a stack offset from the initial call instruction: -8 - 0x68 + 0x20 = -80. OTOH, for the "good" function, ``` 00401640 <_Z8test_avxv>: 401640: 57 push %rdi 401641: 56 push %rsi 401642: 53 push %rbx 401643: 48 81 ec b0 00 00 00sub$0xb0,%rsp 40164a: c5 d9 57 e4 vxorpd %xmm4,%xmm4,%xmm4 40164e: 48 8d 3d cb 79 00 00lea0x79cb(%rip),%rdi# 40902
[Bug target/54412] minimal 32-byte stack alignment with -mavx on 64-bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412 --- Comment #24 from Yichao Yu --- Oh, and the test case above was compiled with -O3 (and -g -Wall -Wextra).
[Bug target/89581] New: Unneeded stack alignment on windows x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89581 Bug ID: 89581 Summary: Unneeded stack alignment on windows x86 Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: yyc1992 at gmail dot com Target Milestone: --- On windows, when compiling the following code with ` gcc -mavx2 a.c -o - -S -O3 -g0 -fno-asynchronous-unwind-tables -fomit-frame-pointer -Wall -Wextra` ``` typedef struct { double x1; double x2; } vdouble __attribute__((aligned(16))); vdouble f(vdouble x, vdouble y) { return (vdouble){x.x1 + y.x1, x.x2 + y.x2}; } ``` I got ``` pushq %rbp vmovdqa (%r8), %xmm0 movq%rcx, %rax vaddpd (%rdx), %xmm0, %xmm0 movq%rsp, %rbp andq$-16, %rsp vmovaps %xmm0, (%rcx) leave ret ``` which include 4 extra instructions to align the stack without actually using it FWIW, clang has a similar problem on linux... https://bugs.llvm.org/show_bug.cgi?id=40844 Also worth noting that with -O2 all three vector instructions are splitted into scalar ones whereas clang does this transformation at -O2...
[Bug target/89582] New: Suboptimal code generated for floating point struct in -O3 compare to -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89582 Bug ID: 89582 Summary: Suboptimal code generated for floating point struct in -O3 compare to -O2 Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: yyc1992 at gmail dot com Target Milestone: --- When testing the code for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89581 on linux, I noticed that the code seems suboptimum when compiled under -O3 rather than -O2 on linux x64. ``` typedef struct { double x1; double x2; } vdouble __attribute__((aligned(16))); vdouble f(vdouble x, vdouble y) { return (vdouble){x.x1 + y.x1, x.x2 + y.x2}; } ``` Compiled with `-O2` produces ``` f: addsd %xmm3, %xmm1 addsd %xmm2, %xmm0 ret ``` With `-O3` or `-Ofast`, however, the code produced is, ``` f: movq%xmm0, -40(%rsp) movq%xmm1, -32(%rsp) movapd -40(%rsp), %xmm4 movq%xmm2, -24(%rsp) movq%xmm3, -16(%rsp) addpd -24(%rsp), %xmm4 movaps %xmm4, -40(%rsp) movsd -32(%rsp), %xmm1 movsd -40(%rsp), %xmm0 ret ``` It seems that gcc tries to use the vector instruction but had to use the stack for that. I did a quick benchmark which confirms that the -O3 version is much slower than the -O2 version. Clang produces ``` f: addsd %xmm2, %xmm0 addsd %xmm3, %xmm1 retq ``` As long as any optimizations are on, which seems appropriate.
[Bug target/89581] Unneeded stack alignment on windows x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89581 --- Comment #1 from Yichao Yu --- The problem is still there when compiled with -O2 ``` f: pushq %rbp vmovq (%r8), %xmm1 movq%rcx, %rax vmovq 8(%r8), %xmm0 vaddsd (%rdx), %xmm1, %xmm1 vaddsd 8(%rdx), %xmm0, %xmm0 movq%rsp, %rbp andq$-16, %rsp vmovsd %xmm1, (%rcx) vmovsd %xmm0, 8(%rcx) leave ret ``` but is not there under `-O2` when the arguments and results are passed explicitly by reference. ``` void f2(vdouble *res, const vdouble *x, const vdouble *y) { *res = (vdouble){x->x1 + y->x1, x->x2 + y->x2}; } ``` ``` f2: vmovsd 8(%rdx), %xmm0 vmovsd (%rdx), %xmm1 vaddsd 8(%r8), %xmm0, %xmm0 vaddsd (%r8), %xmm1, %xmm1 vmovsd %xmm0, 8(%rcx) vmovsd %xmm1, (%rcx) ``` The problem comes back, however, with the explicit pass by reference version when compiled under -O3 ``` f2: pushq %rbp vmovapd (%rdx), %xmm0 vaddpd (%r8), %xmm0, %xmm0 movq%rsp, %rbp andq$-16, %rsp vmovaps %xmm0, (%rcx) leave ret ```
[Bug target/89597] New: Inconsistent vector calling convention on windows with Clang and MSVC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89597 Bug ID: 89597 Summary: Inconsistent vector calling convention on windows with Clang and MSVC Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: yyc1992 at gmail dot com Target Milestone: --- For 256bit and 512bit vector return values, Clang and MSVC always returns them in the corresponding registers even without `__vectorcall`. GCC, however, returns the value as reference. Together with the missing support of `__vectorcall`[1], this means that the code GCC generate for functions that returns vector value is not compatible with any other compilers. The problem does not exist for 128bit vectors. Test case. ``` typedef double vdouble __attribute__((vector_size(32))); vdouble f(vdouble x, vdouble y) { return x + y; } ``` GCC compiles this to, ``` f: vmovapd (%r8), %ymm0 vaddpd (%rdx), %ymm0, %ymm0 movq%rcx, %rax vmovapd %ymm0, (%rcx) vzeroupper ret ``` Clang compiles this to, ``` f: vmovapd (%rcx), %ymm0 vaddpd (%rdx), %ymm0, %ymm0 retq ``` Given the stack alignment issue[2], I wonder if this can be fixed now without breaking anyone's code. (i.e. everyone that's using it is probably broken anyway due to the other bug...) Disclaimer. I did all my test with clang. I believe MSVC behaves the same from the compiled result I got from someone else and I don't have MSVC to personally test it. [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89485 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412
[Bug target/89606] New: Extra mov after structure load instructions on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89606 Bug ID: 89606 Summary: Extra mov after structure load instructions on aarch64 Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: yyc1992 at gmail dot com Target Milestone: --- Code to reproduce, ``` #include #ifdef __aarch64__ float64x2x2_t f(const double *p1, const double *p2) { float64x2x2_t v = vld2q_f64(p1); return vld2q_lane_f64(p2, v, 1); } float32x2x2_t f2(const float *p1, const float *p2) { float32x2x2_t v = vld2_f32(p1); return vld2_lane_f32(p2, v, 1); } #endif void f3(float32x2x2_t *p, const float *p1, const float *p2) { float32x2x2_t v = vld2_f32(p1); *p = vld2_lane_f32(p2, v, 1); } ``` GCC produces (aarch64, -O1/-O2/-O3/-Ofast/-Os), ``` f: ld2 {v4.2d - v5.2d}, [x0] mov v0.16b, v4.16b mov v1.16b, v5.16b ld2 {v0.d - v1.d}[1], [x1] ret f2: ld2 {v0.2s - v1.2s}, [x0] mov v2.8b, v0.8b mov v3.8b, v1.8b ld2 {v2.s - v3.s}[1], [x1] mov v1.8b, v3.8b mov v0.8b, v2.8b ret f3: ld2 {v2.2s - v3.2s}, [x1] mov v0.8b, v2.8b mov v1.8b, v3.8b ld2 {v0.s - v1.s}[1], [x2] stp d0, d1, [x0] ret ``` For all three functions, none of the mov's seems necessary. Even if there's some performance issue when reusing the registers (I highly doubt it...) at least the `-Os` version should not have those mov's. Clang produces what I expect in this case, ``` f: ld2 { v0.2d, v1.2d }, [x0] ld2 { v0.d, v1.d }[1], [x1] ret f2: ld2 { v0.2s, v1.2s }, [x0] ld2 { v0.s, v1.s }[1], [x1] ret f3: ld2 { v0.2s, v1.2s }, [x1] ld2 { v0.s, v1.s }[1], [x2] stp d0, d1, [x0] ret ``` Aarch32 doesn't have this issue either with GCC, ``` f3: vld2.32 {d16-d17}, [r1] vld2.32 {d16[1], d17[1]}, [r2] vst1.64 {d16-d17}, [r0:64] bx lr ``` so this seems to be aarch64 specific.
[Bug target/89607] New: Missing optimization for store of multiple registers on arm and aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89607 Bug ID: 89607 Summary: Missing optimization for store of multiple registers on arm and aarch64 Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: yyc1992 at gmail dot com Target Milestone: --- Test code, Compiled for arm/aarch64 with -O1/-O2/-O3/-Os/-Ofast ``` #include void f4(float32x4x2_t *p, const float *p1) { *p = vld2q_f32(p1); } void f5(float32x4x2_t *p, float32x4_t v1, float32x4_t v2) { p->val[0] = v1; p->val[1] = v2; } ``` arm: ``` f4: vld2.32 {d16-d19}, [r1] vst1.64 {d16-d19}, [r0:64] bx lr f5: vst1.64 {d0-d1}, [r0:64] vstrd2, [r0, #16] vstrd3, [r0, #24] bx lr ``` aarch64: ``` f4: ld2 {v0.4s - v1.4s}, [x1] str q0, [x0] str q1, [x0, 16] ret f5: str q0, [x0] str q1, [x0, 16] ret ``` For arm, it seems that f5 could follow f4 and uses a `vst1.64 {d0-d3}, [r0:64]` instead. For aarch64, both function should have used a `stp q0, q1, [x0]` Clang produces what I expected on aarch64 but it only uses pair store instruction on arm, which use one more instuction for `f4` and one fewer for `f5`. (I'm not sure why GCC decided to use a pair store and then two single stores) Similar to pr89606, this optimization should at least happen with `-Os` if not for all other optimization levels. Tested with 8.2.1 on arm and 8.3.0 on aarch64.
[Bug target/89607] Missing optimization for store of multiple registers on arm and aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89607 --- Comment #2 from Yichao Yu --- Sure. I'll do that.
[Bug target/89614] New: Missing optimization for store of multiple registers on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89614 Bug ID: 89614 Summary: Missing optimization for store of multiple registers on arm Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: yyc1992 at gmail dot com Target Milestone: --- Separated from pr89607 as requested. Test code and result compiled with any non-zero optimization levels, ``` #include void f4(float32x4x2_t *p, const float *p1) { *p = vld2q_f32(p1); } void f5(float32x4x2_t *p, float32x4_t v1, float32x4_t v2) { p->val[0] = v1; p->val[1] = v2; } ``` ``` f4: vld2.32 {d16-d19}, [r1] vst1.64 {d16-d19}, [r0:64] bx lr f5: vst1.64 {d0-d1}, [r0:64] vstrd2, [r0, #16] vstrd3, [r0, #24] bx lr ``` I believe `f5` should use a single `vst1.64 {d0-d3}, [r0:64]` just like `f4`. If for some reason doing that is bad for performance (doubt it...) it should at least be used for -Os.
[Bug target/89607] Missing optimization for store of multiple registers on arm and aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89607 --- Comment #3 from Yichao Yu --- Done pr89614
[Bug target/89607] Missing optimization for store of multiple registers on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89607 --- Comment #5 from Yichao Yu --- I just compiled the 9-20190303 snapshot and this is indeed seems to be fixed. Should this be closed now or after GCC 9 is released?
[Bug target/89607] Missing optimization for store of multiple registers on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89607 --- Comment #6 from Yichao Yu --- > For aarch64, there was talk about adding stp for q registers. What do you mean? I was initially unsure about it too but I assume it already exist since clang (and now GCC 9) emits it and the arm arch reference manual also mentions it without mentioning it only available in a later version.
[Bug target/89607] Missing optimization for store of multiple registers on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89607 --- Comment #8 from Yichao Yu --- I see. I don't imagine this to cause a major local speed up though I assume it should at least not be slower? That's also why I mentioned that this should at least be done for `-Os`.
[Bug target/89606] Extra mov after structure load instructions on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89606 --- Comment #1 from Yichao Yu --- Compiled a GCC 9 snapshot for pr89607 and the issue is still present.
[Bug target/54412] minimal 32-byte stack alignment with -mavx on 64-bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412 --- Comment #29 from Yichao Yu --- See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412#c25 GCC is fully capable of aligning the stack. It just seems that different part of it disagrees on what the current stack alignment is and whether a realignment is needed.
[Bug tree-optimization/89582] Suboptimal code generated for floating point struct in -O3 compare to -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89582 --- Comment #6 from Yichao Yu --- For the vfloat test case, isn't the optimum code just ``` addps %xmm2, %xmm0 addps %xmm3, %xmm1 retq ``` It's not making full use of the vector but I assume not having to spill is a win? This is what clang produces. And for the LLVM early lowering of the calling convention, a less awkward way is. ``` define { <2 x float>, <2 x float> } @f2({<2 x float>, <2 x float>}, {<2 x float>, <2 x float>}) { %v0 = extractvalue { <2 x float>, <2 x float> } %0, 0 %v1 = extractvalue { <2 x float>, <2 x float> } %0, 1 %v2 = extractvalue { <2 x float>, <2 x float> } %1, 0 %v3 = extractvalue { <2 x float>, <2 x float> } %1, 1 %v5 = fadd <2 x float> %v0, %v2 %v6 = fadd <2 x float> %v1, %v3 %v7 = insertvalue { <2 x float>, <2 x float> } undef, <2 x float> %v5, 0 %v8 = insertvalue { <2 x float>, <2 x float> } %v7, <2 x float> %v6, 1 ret { <2 x float>, <2 x float> } %v8 } ```
[Bug c/90728] New: False positive Wmemset-elt-size with zero size array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90728 Bug ID: 90728 Summary: False positive Wmemset-elt-size with zero size array Product: gcc Version: 9.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: yyc1992 at gmail dot com Target Milestone: --- The code below comes from a template expansion (when certain cache feature is disabled) and all the operation on the `buff` member are no-op. ``` #include struct A { A() { memset(&buff, 0xff, sizeof(buff)); } int buff[0]; }; ``` However, this start to raise a warning on GCC 9 ``` a.cpp: In constructor 'A::A()': a.cpp:8:41: warning: 'memset' used with length equal to number of elements without multiplication by element size [-Wmemset-elt-size] 8 | memset(&buff, 0xff, sizeof(buff)); | ^ ``` It seems that the warning logic simply compare the size (as well as checking element size != 1) without taking into account the 0 size case.
[Bug target/90826] New: Weak symbol does not work reliably on windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90826 Bug ID: 90826 Summary: Weak symbol does not work reliably on windows Product: gcc Version: 9.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: yyc1992 at gmail dot com Target Milestone: --- The following code does not link correctly with all optimization levels on windows with the mingw-w64-x86_64-g++ compiler. ``` #include extern "C" void f() __attribute__((weak)); int main() { return (int)(uintptr_t)f; } ``` The assembly generated is ``` .file "weak.cpp" .text .def__main; .scl2; .type 32; .endef .section.text.startup,"x" .p2align 4 .globl main .defmain; .scl2; .type 32; .endef .seh_proc main main: .LFB1: subq$56, %rsp .seh_stackalloc 56 .seh_endprologue call__main movq.refptr.f(%rip), %rax movq%rax, 40(%rsp) addq$56, %rsp ret .seh_endproc .ident "GCC: (Rev2, Built by MSYS2 project) 9.1.0" .section.rdata$.refptr.f, "dr" .globl .refptr.f .linkonce discard .refptr.f: .quad f ``` and the error, ``` C:\msys64\tmp\ccQkPfOi.o:weak.cpp:(.rdata$.refptr.f[.refptr.f]+0x0): undefined reference to `f' ``` This should not happen since `f` is declared weak. (I realized that the symbol resolution happens at compile time for weak symbol, which is fine for me, but I just want it to compile...) Another case where the optimization actually makes this work is, ``` #include extern "C" void f() __attribute__((weak)); int main() { printf("%p\n", f); return 0; } ``` With -O0, the assembly generated is ``` .file "weak.cpp" .text .def__main; .scl2; .type 32; .endef .section .rdata,"dr" .LC0: .ascii "%p\12\0" .text .globl main .defmain; .scl2; .type 32; .endef .seh_proc main main: .LFB28: pushq %rbp .seh_pushreg%rbp movq%rsp, %rbp .seh_setframe %rbp, 0 subq$32, %rsp .seh_stackalloc 32 .seh_endprologue call__main movq.refptr.f(%rip), %rdx leaq.LC0(%rip), %rcx callprintf movl$0, %eax addq$32, %rsp popq%rbp ret .seh_endproc .ident "GCC: (Rev2, Built by MSYS2 project) 9.1.0" .defprintf; .scl2; .type 32; .endef .section.rdata$.refptr.f, "dr" .globl .refptr.f .linkonce discard .refptr.f: .quad f ``` with error, ``` C:\msys64\tmp\ccTiwMKh.o:weak.cpp:(.rdata$.refptr.f[.refptr.f]+0x0): undefined reference to `f' ``` with -O1 or higher, the assembly produced is, ``` .file "weak.cpp" .text .def__main; .scl2; .type 32; .endef .section .rdata,"dr" .LC0: .ascii "%p\12\0" .text .globl main .defmain; .scl2; .type 32; .endef .seh_proc main main: .LFB30: subq$40, %rsp .seh_stackalloc 40 .seh_endprologue call__main leaqf(%rip), %rdx leaq.LC0(%rip), %rcx callprintf movl$0, %eax addq$40, %rsp ret .seh_endproc .weak f .ident "GCC: (Rev2, Built by MSYS2 project) 9.1.0" .deff; .scl2; .type 32; .endef .defprintf; .scl2; .type 32; .endef .section.rdata$.refptr.f, "dr" .globl .refptr.f .linkonce discard .refptr.f: .quad f ``` The difference between the two assembly is ``` --- weak1.s 2019-06-10 19:42:27.039467600 -0400 +++ weak0.s 2019-06-10 19:42:23.709467500 -0400 @@ -9,21 +9,24 @@ .defmain; .scl2; .type 32; .endef .seh_proc main main: -.LFB30: - subq$40, %rsp - .seh_stackalloc 40 +.LFB28: + pushq %rbp + .seh_pushreg%rbp + movq%rsp, %rbp + .seh_setframe %rbp, 0 + subq$32, %rsp + .seh_stackalloc 32 .seh_endprologue call__main - leaqf(%rip), %rdx + movq.refptr.f(%rip), %rdx leaq.LC0(%rip), %rcx callprintf movl$0, %eax - addq$40, %rsp + addq$32, %rsp + popq%rbp ret .seh_endproc -
[Bug target/90826] Weak symbol does not work reliably on windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90826 --- Comment #1 from Yichao Yu --- Oh, forgot to mention that the first assembly was generated with -O3 and adding `.weak f` to the generated file fixes the issue as well.
[Bug target/90826] Weak symbol does not work reliably on windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90826 --- Comment #2 from Yichao Yu --- Also, I just upgraded the compiler on this computer from 7.x to 9.1.0. The issue appeared before the upgrade as well but I didn't investigate until the upgrade finished.
[Bug libstdc++/92759] New: Typo in libstdcxx/v6/xmethods.py
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92759 Bug ID: 92759 Summary: Typo in libstdcxx/v6/xmethods.py Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: yyc1992 at gmail dot com Target Milestone: --- I get the following warning when running gdb/rr. ``` /usr/lib/../share/gcc-9.2.0/python/libstdcxx/v6/xmethods.py:731: SyntaxWarning: list indices must be integers or slices, not str; perhaps you missed a comma? refcounts = ['_M_refcount']['_M_pi'] ``` Looking at the [code](https://github.com/gcc-mirror/gcc/blob/daa87973f7a00bf3bb81d0644dd60f4efb83bb65/libstdc%2B%2B-v3/python/libstdcxx/v6/xmethods.py#L731) I think that line should read ``` refcounts = obj['_M_refcount']['_M_pi'] ``` instead. I could submit a patch but I feel like it'll be faster/easier for someone here to just fix this
[Bug c++/65255] New: std::thread does not work for cross compiling on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65255 Bug ID: 65255 Summary: std::thread does not work for cross compiling on ARM Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: yyc1992 at gmail dot com Created attachment 34903 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34903&action=edit PKGBUILD used to compile the cross compiling version of gcc Duplicate of the problem reported in the comment of #42734. However, IMHO, that bug was tracking a different issue and it should be better to open a new bug for this one although the error message produced at runtime are very similar. See attached file for the script used to compile the cross-compiler (CHOST=x86_64-unknown-linux-gnu). Minimum source that produces the problem ``` #include int main() { std::thread([] {}).join(); return 0; } ``` When compiling with `arm-linux-gnueabihf-g++` on x86_64 and run on arm, it throws an runtime error ``` pure virtual method called terminate called without an active exception Aborted (core dumped) ``` However, the error disappeared if run with gdb The same source works on the host machine (x86_64), with clang cross compiling on ARM and with both clang and gcc natively compiled on ARM. Adding `-latomic` as suggested in #42734 does not help either and is also not needed using the native compiler on arm. Command line option used to compile: gcc cross compile: arm-linux-gnueabihf-g++ -pthread -std=c++14 -Os -Wall -Wextra thread.cpp -o thread-arm clang cross compile: clang++ --target=arm-linux-gnueabihf -pthread -std=c++14 -Os -Wall -Wextra thread.cpp -o thread-arm_clang -I /usr/arm-linux-gnueabihf/include/c++/4.9.2/arm-linux-gnueabihf gcc native compile (on ARM): g++ -pthread -std=c++14 -Os -Wall -Wextra thread.cpp -o thread-arm_native clang native compile (on ARM): clang++ -pthread -std=c++14 -Os -Wall -Wextra thread.cpp -o thread-arm_native_clang I'll try to upload the binaries (if they are allowed) or the output of `objdump -S` (if I cannot upload binaries).
[Bug c++/65255] std::thread does not work for cross compiling on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65255 --- Comment #1 from Yichao Yu --- Created attachment 34904 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34904&action=edit Source and output programs