[Bug libstdc++/93983] std::filesystem::path is not concept-friendly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93983 --- Comment #9 from Jonathan Wakely --- Thanks, Tim. I'd forgotten about that issue and was about to reinvent the resolution.
[Bug target/70053] Returning a struct of _Decimal128 values generates extraneous stores and loads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70053 luoxhu at gcc dot gnu.org changed: What|Removed |Added CC||bergner at gcc dot gnu.org, ||luoxhu at gcc dot gnu.org --- Comment #4 from luoxhu at gcc dot gnu.org --- Is this just the difference of O3 and O2? Since O3 is OK, maybe this bug is not effective? $ /opt/at10.0/bin/gcc -O3 -S pr70053.c $ cat pr70053.s .file "pr70053.c" .abiversion 2 .section".text" .align 2 .p2align 4,,15 .globl D256_add_finite .type D256_add_finite, @function D256_add_finite: dcmpuq 7,4,6 beq 7,.L3 fmr 7,3 fmr 6,2 fmr 3,7 fmr 2,6 blr .p2align 4,,15 .L3: fmr 5,7 fmr 4,6 fmr 3,7 fmr 2,6 blr .long 0 .byte 0,0,0,0,0,0,0,0 .size D256_add_finite,.-D256_add_finite .ident "GCC: (GNU) 6.4.1 20170720 (Advance-Toolchain-at10.0) IBM AT 10 branch, based on subversion id 250395." .section.note.GNU-stack,"",@progbits
[Bug tree-optimization/88398] vectorization failure for a small loop to do byte comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88398 --- Comment #26 from Jiu Fu Guo --- Had a test on spec2017 xz_r by changing the specified loop manually, on ppc64le. original loop (this loops occur three times in code): while (++len != len_limit) if (pb[len] != cur[len]) break; changed to loop: typedef long long __attribute__((may_alias)) TYPEE; for(++len; len + sizeof(TYPEE) <= len_limit; len += sizeof(TYPEE)) { long long a = *((TYPEE*)(cur+len)); long long b = *((TYPEE*)(pb+len)); if (a != b) { break; //to optimize len can be move forward here. } } for (;len != len_limit; ++len) if (pb[len] != cur[len]) break; We can see xz_r runtime improved from 433s to 382s(>12%). It would be very valuable to do this kind of widening reading/checking.
[Bug target/95251] New: x86 code size expansion inserting field into a union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95251 Bug ID: 95251 Summary: x86 code size expansion inserting field into a union Product: gcc Version: 10.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: michaeljclark at mac dot com Target Milestone: --- Testing code on Godbolt and I came across some pathological code amplification when SSE is enabled for field insertion into a structure containing a union. Here is the Godbolt link: https://godbolt.org/z/z_RpFt Compiler flags: gcc -Os --save-temps -march=ivybridge -c x7b00.c The function `x7b00`, inserts into the structure via char fields and it has a voluminous translation (30 instructions). The functionally equivalent `xyb87` inserts into the structure via an 64-bit integer and it translates simply (5 instructions). `x`, `a7x` and `x7bcd` are for comparison. Not adding -march=ivybridge improves the code size but it is still nowhere near optimal. `xyb87` serves as a reference for near optimal translation. It seemed worthy of filing a bug due to the observed code amplification factor (6X). Can the backend choose the non-SSE code generation if it is more efficient? --- CODE SNIPPET BEGINS --- typedef unsigned long long u64; typedef char u8; typedef struct mr { union { u64 y; struct { u8 a,b,c,d; } i; } u; u64 x; } mr; u64 x(mr mr) { return mr.x; } mr a7x(u64 x) { return (mr) { .u = { .i = { 7,0,0,0 } }, .x = x }; } mr x7bcd(u64 x,u8 b,u8 c,u8 d) { return (mr) {.u={.i={7,b,c,d }}, .x=x }; } mr xyb87(u64 x, u8 b) { return (mr) {.u={ .y =(u64)b << 8|7},.x=x }; } mr x7b00(u64 x, u8 b) { return (mr) {.u={ .i ={7,b,0,0}}, .x=x }; } --- EXPECTED OUTPUT --- .cfi_startproc endbr64 movsbq %sil, %rax movq%rdi, %rdx salq$8, %rax orq $7, %rax ret .cfi_endproc --- OBSERVED OUTPUT --- .cfi_startproc endbr64 pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset 6, -16 movq%rdi, %r8 xorl%eax, %eax movl$6, %ecx movq%rsp, %rbp .cfi_def_cfa_register 6 andq$-32, %rsp leaq-32(%rsp), %rdi rep stosb movq$0, -48(%rsp) movabsq $281474976710655, %rax movq$0, -40(%rsp) movq-48(%rsp), %rdx andq-32(%rsp), %rax movzwl %dx, %edx salq$16, %rax orq %rax, %rdx movq%rdx, -48(%rsp) movb$7, -48(%rsp) vmovdqa -48(%rsp), %xmm1 vpinsrb $1, %esi, %xmm1, %xmm0 vmovaps %xmm0, -48(%rsp) movq-48(%rsp), %rax movq%r8, -40(%rsp) movq-40(%rsp), %rdx leave .cfi_def_cfa 7, 8 ret .cfi_endproc
[Bug libstdc++/93983] std::filesystem::path is not concept-friendly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93983 --- Comment #8 from TC --- (really from Tim) This is https://cplusplus.github.io/LWG/issue3420
[Bug libstdc++/93983] std::filesystem::path is not concept-friendly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93983 --- Comment #7 from Jonathan Wakely --- (In reply to Lyberta from comment #0) > #include > #include > > struct Foo > { > Foo(const std::filesystem::path& p); > }; > > static_assert(std::copyable); The problem is that copyable considers the Foo(const path&) constructor to see if it can be called with a const Foo&. That considers this constructor with Foo substituted for Source: filesystem::path(Source const&, format = auto_format); The constraints for Source involve checking whether Source is a Cpp17InputIterator, which is done with this: template> using __is_path_iter_src = __and_<__is_encoded_char, std::is_base_of>; So we instantiate iterator_traits. In C++20 finding the matching specialization for std::iterator_traits checks for concept satisfaction, which includes checking copyable which is recursive. An even smaller reproducer is: #include struct X { template::iterator_category> X(const T&); }; static_assert( std::copyable ); I can fix filesystem::path to avoid using iterator_traits, but this seems like it's going to cause problems for plenty of other code too.
[Bug c++/93295] ICE in alias_ctad_tweaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93295 Arthur O'Dwyer changed: What|Removed |Added CC||arthur.j.odwyer at gmail dot com --- Comment #6 from Arthur O'Dwyer --- Another test case from Peter O'Rourke on cpplang Slack: https://godbolt.org/z/YEw4v9 template struct A {}; template A() -> A<1>; template using B = A<2>; B bar;
[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218 --- Comment #19 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:7797f5ec58078523a452e5cf239596e13d77d885 commit r11-535-g7797f5ec58078523a452e5cf239596e13d77d885 Author: Uros Bizjak Date: Thu May 21 01:53:09 2020 +0200 i386: Do not use commutative operands with (use) RTX [PR95238] 2020-05-21 Uroš Bizjak gcc/ChangeLog: PR target/95218 * config/i386/mmx.md (*mmx_v2sf): Do not mark operands 1 and 2 commutative. Manually swap operands. (*mmx_nabsv2sf2): Ditto. Partially revert: * config/i386/i386.md (*tf2_1): Mark operands 1 and 2 commutative. (*nabstf2_1): Ditto. * config/i386/sse.md (*2): Mark operands 1 and 2 commutative. Do not swap operands. (*nabs2): Ditto.
[Bug d/95250] New: [D] ICE instead of error when trying to use bad template type inside template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95250 Bug ID: 95250 Summary: [D] ICE instead of error when trying to use bad template type inside template Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: witold.baryluk+gcc at gmail dot com Target Milestone: --- https://godbolt.org/z/xWrXP5 Minimized version ``` module m; import std.traits : Unsigned; void* f(T)(T a, T b) { alias UnsignedVoid = Unsigned!(T); return cast(T)(cast(T)(cast(UnsignedVoid)(a-b) / 2)); } //static assert(is(typeof(f(null, null)) == void*)); // ICE static assert(is(typeof(f!(void*)(null, null)) == void*)); // ICE ``` The code is not correct, but on DMD v2.092.0 and LDC 1.20.1 (LLVM 9.0.1) it does say static assert is false (which is also incorrect), and doesn't crash. Instead it should say, something like this: /usr/lib/gcc/x86_64-linux-gnu/11.0.0/include/d/std/traits.d:7163:13: error: static assert "Type void* does not have an Unsigned counterpart" 7163 | static assert(false, "Type " ~ T.stringof ~ | ^ Here is a local run, on Linux, amd64. $ gdc gdc_ice.d d21: internal compiler error: Segmentation fault 0xbd63ef crash_signal ../../src/gcc/toplev.c:328 0x7f31b746c7ff ??? ./signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0 0x71ed1e isAggregate(Type*) ../../src/gcc/d/dmd/opover.c:161 0x71ed1e visit ../../src/gcc/d/dmd/opover.c:586 0x71e935 op_overload(Expression*, Scope*) ../../src/gcc/d/dmd/opover.c:1385 0x6d0b88 Expression::op_overload(Scope*) ../../src/gcc/d/dmd/expression.h:213 0x6d0b88 ExpressionSemanticVisitor::visit(DivExp*) ../../src/gcc/d/dmd/expressionsem.c:6891 0x6cd7b4 semantic(Expression*, Scope*) ../../src/gcc/d/dmd/expressionsem.c:8214 0x6cd7b4 unaSemantic(UnaExp*, Scope*) ../../src/gcc/d/dmd/expressionsem.c:8164 0x6cd7b4 ExpressionSemanticVisitor::visit(CastExp*) ../../src/gcc/d/dmd/expressionsem.c:4203 0x6cd7b4 semantic(Expression*, Scope*) ../../src/gcc/d/dmd/expressionsem.c:8214 0x6cd7b4 unaSemantic(UnaExp*, Scope*) ../../src/gcc/d/dmd/expressionsem.c:8164 0x6cd7b4 ExpressionSemanticVisitor::visit(CastExp*) ../../src/gcc/d/dmd/expressionsem.c:4203 0x6c5a45 semantic(Expression*, Scope*) ../../src/gcc/d/dmd/expressionsem.c:8214 0x74795f StatementSemanticVisitor::visit(ReturnStatement*) ../../src/gcc/d/dmd/statementsem.c:2757 0x74a949 semantic(Statement*, Scope*) ../../src/gcc/d/dmd/statementsem.c:3782 0x74a949 StatementSemanticVisitor::visit(CompoundStatement*) ../../src/gcc/d/dmd/statementsem.c:142 0x743755 semantic(Statement*, Scope*) ../../src/gcc/d/dmd/statementsem.c:3782 0x6e8ba9 FuncDeclaration::semantic3(Scope*) ../../src/gcc/d/dmd/func.c:1711 0x6e8ba9 FuncDeclaration::semantic3(Scope*) ../../src/gcc/d/dmd/func.c:1354 $ $ gdc -v Using built-in specs. COLLECT_GCC=gdc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 10.1.0-1' --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-10 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none,amdgcn-amdhsa,hsa --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.1.0 (Debian 10.1.0-1) $
[Bug c/95213] GCC -Werror=conversion error when assigning to a bitfield (when mixing constants and variables)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95213 Seth Robertson changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE |--- --- Comment #3 from Seth Robertson --- I disagree that this the same bug as 39170. I know how to disable these warning entirely. I know how to disable them just for the instance it is wrong. However, in this bug, under some circumstances gcc is incorrectly claiming that there is a conversion error where essentially isomorphic code is thought just fine. Thank you for your consideration.
[Bug tree-optimization/95246] Failure to optimize comparison between differently signed chars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95246 Gabriel Ravier changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #3 from Gabriel Ravier --- Welp I actually found the option for it, so I'll close it as RESOLVED INVALID (I guess I really shouldn't be trying to close bug reports at 5 am )
[Bug d/95198] [D] extern(C) private final functions should use 'local' linker attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95198 --- Comment #3 from Witold Baryluk --- > The main example to demonstrate the current behaviour is correct would be the > following: ``` extern(C) private final int f() { return 5; } auto pubf()() { return f(); } ``` I see, I guess you are right. I don't know how would one go to fix this to work correctly with existing linkers and not break other code. Thanks for clarifications.
[Bug tree-optimization/95246] Failure to optimize comparison between differently signed chars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95246 --- Comment #2 from Gabriel Ravier --- Looks like I misread it, LLVM compares `dil` and `sil` with that transformation, not `edi` and `esi` as it does without it. I should stop making bug reports at 1 am... I suppose I should mark thtis as INVALID, but I haven't been able to find how to do it, I can only seem to mark it as RESOLVED (maybe I shouldn't try to close bug reports at 5 am)
[Bug middle-end/95249] Stack protector runtime has to waste one byte on null terminator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95249 --- Comment #2 from Rich Felker --- Indeed, using an extra zero pad byte could bump the stack frame size by 4 or 8 or 16 bytes, or could leave it unchanged, depending on alignment prior to adding the byte and the alignment requirements of the target.
[Bug middle-end/95249] Stack protector runtime has to waste one byte on null terminator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95249 --- Comment #1 from Andrew Pinski --- I doubt you could skip one byte as the protector location has to be aligned. So the trade off is adding at least 4 or 8 bytes (depending on which ABI is used) or 8bits less of the randomness.
[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218 --- Comment #18 from Uroš Bizjak --- Created attachment 48575 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48575=edit Patch in testing.
[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218 --- Comment #17 from Uroš Bizjak --- The problem is with commutative operands, these somehow confuse postreload pass. I'll commit partial revert that basically puts back: (define_insn_and_split "*2" - [(set (match_operand:VF 0 "register_operand" "=x,v") + [(set (match_operand:VF 0 "register_operand" "=x,x,v,v") (absneg:VF - (match_operand:VF 1 "vector_operand" "%0,v"))) - (use (match_operand:VF 2 "vector_operand" "xBm,vm"))] + (match_operand:VF 1 "vector_operand" "0,xBm,v,m"))) + (use (match_operand:VF 2 "vector_operand" "xBm,0,vm,v"))] with manual swapping of operands.
[Bug c++/93083] copy deduction rejected when doing CTAD for NTTP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93083 --- Comment #2 from Hana Dusíková --- Same error is also triggered by template partial specialization: ``` template struct literal { constexpr literal(const char ()[N]) noexcept { } constexpr literal(const literal &) noexcept { } }; template struct field { }; template struct field { }; ```
[Bug middle-end/95249] New: Stack protector runtime has to waste one byte on null terminator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95249 Bug ID: 95249 Summary: Stack protector runtime has to waste one byte on null terminator Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: bugdal at aerifal dot cx Target Milestone: --- At least glibc presently stores a null byte in the first byte of the stack protector canary value, so that string-based read overflows can't leak the canary value. On 32-bit targets, this wastes a significant portion of the randomness, making it possible that massive-scale attacks (e.g. against millions of mobile or IoT devices) will have a decent chance of some success bypassing stack protector. musl presently does not zero the first byte, but I received a suggestion that we should do so, and got to thinking about the tradeoffs involved. If GCC would skip one byte below the canary, the full range of values could be used by the stack protector runtime without the risk of string-read-based disclosure. This should be inexpensive in terms of space and time to store a single 0 byte on the stack.
[Bug bootstrap/95005] zstd.h not found if installed in non-system prefix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95005 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2020-May/546 ||179.html Keywords||patch --- Comment #8 from Eric Gallager --- (In reply to Michael Kuhn from comment #7) > Took me a while, sorry. I have just sent the patch to the list. for reference, that patch is here: https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546179.html
[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #16 from Jeffrey A. Law --- A "naked" use as an INSN should only occur inside the pattern of an insn (there are exceptins that exist internally within reload and delay slot scheduling). It's only supposed to be used to mark that a particular object is live and used by the insn. I'll note the following: ... This means that @code{use} can @emph{only} be used to describe that the register is live. You should think twice before adding @code{use} statements, more often you will want to use @code{unspec} instead. The @code{use} RTX is most commonly useful to describe that a fixed register is implicitly used in an insn. It is also safe to use in patterns where the compiler knows for other reasons that the result of the whole pattern is variable, such as @samp{cpymem@var{m}} or @samp{call} patterns. I think one could reasonably think that we should support (use (mem)) with the same semantics -- it means that the value in memory is used which is helpful in dependency tracking.
[Bug c/95213] GCC -Werror=conversion error when assigning to a bitfield (when mixing constants and variables)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95213 Eric Gallager changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- dup of bug 39170 *** This bug has been marked as a duplicate of bug 39170 ***
[Bug tree-optimization/95246] Failure to optimize comparison between differently signed chars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95246 --- Comment #1 from Marc Glisse --- On which version of LLVM did you see that? For me, gcc produces movzbl %dil, %edi movsbl %sil, %esi cmpl%esi, %edi setg%al while clang skips the first 2 lines (but still emits movl), assuming that the input is already signed/zero extended, which points at ABI conventions. The transformation you suggest doesn't seem right to me.
[Bug c/39170] provide an option to silence -Wconversion warnings for bit-fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39170 Eric Gallager changed: What|Removed |Added CC||in-gcc at baka dot org --- Comment #22 from Eric Gallager --- *** Bug 95213 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/95248] New: GCC produces incorrect code with -O3 for loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95248 Bug ID: 95248 Summary: GCC produces incorrect code with -O3 for loops Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: vsevolod.livinskij at frtk dot ru Target Milestone: --- GCC produces incorrect code with -O3 for loops Error: >$ gcc -O0 driver.cpp func.cpp && ./a.out 1 >$ gcc -O3 driver.cpp func.cpp && ./a.out 0 Reproducer: >$ cat driver.cpp #include int var_2 = -2013646301; int var_3 = -1126567434; unsigned int var_12 = 1; unsigned int var_19; unsigned int arr_25 [24] [21] [15] [17] [15] ; void test(); int main() { test(); printf("%u\n", var_19); } >$ cat func.cpp extern int var_2; extern int var_3; extern unsigned int var_12; extern unsigned int var_19; extern unsigned int arr_25 [24] [21] [15] [17] [15] ; void test() { for (int a = 0; a < 3; a = 42) for (int b = 0; b < 20; b++) for (int c = 0; c < 4; c = 4) for (int d = 0; d < 6; d += 4) for (int e = 0; e < 4; e += 2) { arr_25[a][b][c][d][e] = var_2 || var_3; var_19 = var_12; } } GCC version: gcc version 11.0.0 (ed63c387aa0bc1846082524455a6ff1fcec40f9d)
[Bug target/95247] Backport the DRIVER_SELF_SPECS implementation of -mdejagnu-cpu= to GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95247 Segher Boessenkool changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-05-20 Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED
[Bug target/95247] New: Backport the DRIVER_SELF_SPECS implementation of -mdejagnu-cpu= to GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95247 Bug ID: 95247 Summary: Backport the DRIVER_SELF_SPECS implementation of -mdejagnu-cpu= to GCC 9 Product: gcc Version: 9.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: segher at gcc dot gnu.org Target Milestone: --- Doug Rupp says that it fixes his problems: https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546176.html (thread starts at https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546072.html ). It should be perfectly safe to backport, so I'll do that tomorrow.
[Bug libstdc++/95245] std::sort copies custom comparator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95245 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-05-20 Ever confirmed|0 |1 Keywords||missed-optimization --- Comment #2 from Jonathan Wakely --- I think other implementations automatically wrap the function in a reference-like type. See PR 51965 for similar issues with other recursively-defined algorithms. N.B. GCC 7 is no longer supported or maintained, so bug reports should be for currently-supported versions.
[Bug tree-optimization/95246] New: Failure to optimize comparison between differently signed chars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95246 Bug ID: 95246 Summary: Failure to optimize comparison between differently signed chars Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: gabravier at gmail dot com Target Milestone: --- bool f(unsigned char a, signed char b) { return a > b; } This can be optimized to `return (signed char)a > b;`. This transformation is done by LLVM, but not by GCC.
[Bug libstdc++/95245] std::sort copies custom comparator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95245 --- Comment #1 from Jonathan Wakely --- [algorithms.requirements] paragraph 10 says: [Note: Unless otherwise specified, algorithms that take function objects as arguments are permitted to copy those function objects freely. Programmers for whom object identity is important should consider using a wrapper class that points to a noncopied implementation object such as reference_wrapper 20.14.5), or some equivalent solution. — end note]
[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137 --- Comment #18 from Rafael Avila de Espindola --- (In reply to Avi Kivity from comment #17) > Is that the test were a lambda coroutine is called from future::then()? In > that case it's a real use-after-free. It was reduced from that to just #include #include using namespace seastar; int main(int argc, char** argv) { seastar::app_template app; app.run(argc, argv, [] () -> future<> { future<> xyz = make_ready_future<>().then([] {}); co_await std::move(xyz); }); return 0; } Which doesn't have a user after free.
[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137 --- Comment #17 from Avi Kivity --- Is that the test were a lambda coroutine is called from future::then()? In that case it's a real use-after-free.
[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137 --- Comment #16 from Rafael Avila de Espindola --- > @Rafael: Can you please append output with: > export UBSAN_OPTIONS="print_stacktrace=1" I also added halt_on_error=1:abort_on_error=1: It is ../tests/unit/coroutines_test.cc:11:5: runtime error: member call on misaligned address 0x41b58ab3 for type 'struct awaiter', which requires 8 byte alignment 0x41b58ab3: note: pointer points here Reactor stalled for 261 ms on shard 0. Backtrace: /lib64/libasan.so.6+0x00045bad ... #0 0xf3605a in main::{lambda()#1}::operator()() const [clone .actor] ../tests/unit/coroutines_test.cc:11 #1 0xf3b20b in std::__n4861::coroutine_handle::resume() const /usr/include/c++/10/coroutine:126 #2 0xf3b5ed in seastar::internal::coroutine_traits_base<>::promise_type::run_and_dispose() ../include/seastar/core/coroutine.hh:104 #3 0x11c8892 in seastar::reactor::run_tasks(seastar::reactor::task_queue&) ../src/core/reactor.cc:2151 #4 0x11cc8db in seastar::reactor::run_some_tasks() ../src/core/reactor.cc:2566 #5 0x11d1aa0 in seastar::reactor::run() ../src/core/reactor.cc:2721 #6 0xf4ef5e in seastar::app_template::run_deprecated(int, char**, std::function&&) ../src/core/app-template.cc:202 #7 0xf4cf00 in seastar::app_template::run(int, char**, std::function ()>&&) ../src/core/app-template.cc:115 #8 0xf4d3fa in seastar::app_template::run(int, char**, std::function ()>&&) ../src/core/app-template.cc:130 #9 0xf36a70 in main ../tests/unit/coroutines_test.cc:8 #10 0x7fac0533d041 in __libc_start_main (/lib64/libc.so.6+0x27041) #11 0xf3466d in _start (/home/espindola/scylla/scylla/seastar/build-dbg/tests/unit/coroutines_test+0xf3466d) I will try to reduce the test to not need seastar.
[Bug bootstrap/95005] zstd.h not found if installed in non-system prefix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95005 --- Comment #7 from Michael Kuhn --- Took me a while, sorry. I have just sent the patch to the list.
[Bug libstdc++/95245] New: std::sort copies custom comparator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95245 Bug ID: 95245 Summary: std::sort copies custom comparator Product: gcc Version: 7.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: andrew.bell.ia at gmail dot com Target Milestone: --- std::sort copies a custom comparator numerous times. If the comparator copy is expensive, it makes the sort very slow. Of course, making the comparator cheap to copy is an easy fix, but it took me by surprise that the algorithm copied my comparator at all. Other c++ library implementations don't have this limitation. I found this on version 7.5, but I believe the same behavior is in GCC 10.1. The following program exhibits the issue: #include #include #include #include int main() { struct comp { comp(int i) { v.resize(i); std::iota(v.begin(), v.end(), 0); } comp(const comp& c) : v(c.v) { std::cerr << "Copy ctor!\n"; } comp(comp&& c) : v(std::move(c.v)) { std::cerr << "Move ctor!\n"; } bool operator()(size_t p1, size_t p2) { return p1 < p2; } // Vector is just here to cause an expensive copy and slow the sort, // but it could, // for example, be a cache that is used in the comparison. std::vector v; }; std::vector s(500); std::iota(s.begin(), s.end(), 0); std::random_shuffle(s.begin(), s.end()); std::sort(s.begin(), s.end(), comp(200)); return 0; }
[Bug bootstrap/95244] New: GCC 10 no longer builds on RHEL5 [trivial patch]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95244 Bug ID: 95244 Summary: GCC 10 no longer builds on RHEL5 [trivial patch] Product: gcc Version: 10.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: lopresti at gmail dot com Target Milestone: --- I still compile GCC on Red Hat Enterprise Linux 5. It is an EoL platform, so maybe you do not care... But the only problem (introduced with GCC 10) is the lack of O_CLOEXEC. The following patch fixes my build: diff --git a/libsanitizer/sanitizer_common/sanitizer_posix.cpp b/libsanitizer/sanitizer_common/sanitizer_posix.cpp index d890a3a3177..6ba525d1811 100644 --- a/libsanitizer/sanitizer_common/sanitizer_posix.cpp +++ b/libsanitizer/sanitizer_common/sanitizer_posix.cpp @@ -347,8 +347,14 @@ int GetNamedMappingFd(const char *name, uptr size, int *flags) { CHECK(internal_strlen(name) < sizeof(shmname) - 10); internal_snprintf(shmname, sizeof(shmname), "/dev/shm/%zu [%s]", internal_getpid(), name); +#if defined O_CLOEXEC int fd = ReserveStandardFds( internal_open(shmname, O_RDWR | O_CREAT | O_TRUNC | O_CLOEXEC, S_IRWXU)); +#else + int fd = ReserveStandardFds( + internal_open(shmname, O_RDWR | O_CREAT | O_TRUNC, S_IRWXU)); + fcntl(fd, F_SETFD, FD_CLOEXEC); +#endif I would be happy to make this a pull request if there is any chance it would get accepted. Thanks.
[Bug c++/95223] [11 regression] hash table checking failed: equal operator returns true for a pair of values with a different hash value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95223 --- Comment #10 from Bill Seurer --- It works for me, too, now. Thanks!
[Bug c++/95223] [11 regression] hash table checking failed: equal operator returns true for a pair of values with a different hash value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95223 --- Comment #9 from Dmitry G. Dyachenko --- (In reply to Patrick Palka from comment #8) > Thanks for the reports. This should now hopefully be fixed with r11-522. r11-526 PASS for me. Thanks
[Bug libgomp/95243] New: libgomp documentation should specify GCC Runtime Library Exception license as applicable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95243 Bug ID: 95243 Summary: libgomp documentation should specify GCC Runtime Library Exception license as applicable Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: brentd42 at hotmail dot com CC: jakub at gcc dot gnu.org Target Milestone: --- >From an inspection of the code base, it appears that libgomp uses the GPL v3 license with the GCC Runtime Library exception. However, the libgomp documentation page (https://gcc.gnu.org/onlinedocs/gcc-10.1.0/libgomp/Copying.html#Copying) lists only GPL v3 and not the exception. Conversely, libstc++ specifies the GCC Runtime Library exception license (https://gcc.gnu.org/onlinedocs/gcc-10.1.0/libstdc++/manual/manual/license.html#manual.intro.status.license.gpl) as expected. Similarly to libstc++, could the libgomp documentation be updated to specify the GCC Runtime Library exception license as applicable?
[Bug c++/95242] New: [10 Regression] spurious "warning: zero as null pointer constant [-Wzero-as-null-pointer-constant]" on comparisons with -std=c++2a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95242 Bug ID: 95242 Summary: [10 Regression] spurious "warning: zero as null pointer constant [-Wzero-as-null-pointer-constant]" on comparisons with -std=c++2a Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: gcc at mattwhitlock dot name Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Build: x86_64-pc-linux-gnu /* BEGIN bug.cpp */ #include #include bool bug(std::chrono::milliseconds lhs, std::chrono::milliseconds rhs) { return lhs < rhs; // spurious "warning: zero as null pointer constant" } bool bug(std::string::const_iterator lhs, std::string::const_iterator rhs) { return lhs < rhs; // spurious "warning: zero as null pointer constant" } /* END bug.cpp */ $ g++ -std=c++2a -Wzero-as-null-pointer-constant -c bug.cpp bug.cpp: In function 'bool bug(std::chrono::milliseconds, std::chrono::milliseconds)': bug.cpp:5:15: warning: zero as null pointer constant [-Wzero-as-null-pointer-constant] 5 | return lhs < rhs; // spurious "warning: zero as null pointer constant" | ^~~ bug.cpp: In function 'bool bug(std::__cxx11::basic_string::const_iterator, std::__cxx11::basic_string::const_iterator)': bug.cpp:9:15: warning: zero as null pointer constant [-Wzero-as-null-pointer-constant] 9 | return lhs < rhs; // spurious "warning: zero as null pointer constant" | ^~~ $ g++ --version | head -n1 g++ (Gentoo 10.1.0 p1) 10.1.0 The bug is not present in G++ 9.3, and it also is not present in G++ 10.1 in -std=c++17 (or earlier) mode. This leads me to believe it may be related to the new three-way comparison operator functionality.
[Bug c++/95241] [10/11 Regression] internal compiler error: tree check: expected integer_cst, have range_expr in to_wide, at tree.h:5900
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95241 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug c++/94553] Revise [basic.scope.declarative]/4.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94553 --- Comment #5 from Marek Polacek --- The structured binding part is now fixed, but the variable template part isn't yet, so not closing.
[Bug c++/94553] Revise [basic.scope.declarative]/4.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94553 --- Comment #4 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:2a8565fa1182ed326721a50c700f9f5275355d40 commit r11-529-g2a8565fa1182ed326721a50c700f9f5275355d40 Author: Marek Polacek Date: Tue May 19 23:53:28 2020 -0400 c++: Implement DR 2289, Uniqueness of structured binding names [PR94553] DR 2289 clarified that since structured bindings have no C compatibility implications, they should be unique in their declarative region, see [basic.scope.declarative]/4.2. The duplicate_decls hunk is the gist of the patch, but that alone would not be enough to detect the 'A' case: cp_parser_decomposition_declaration uses 13968 tree decl2 = start_decl (declarator, _specs, SD_INITIALIZED, 13969NULL_TREE, NULL_TREE, _pushed_scope); to create the 'A' VAR_DECL but in this start_decl's grokdeclarator we don't do fit_decomposition_lang_decl because the declarator kind is not cdk_decomp, so then when start_decl calls maybe_push_decl, the decl 'A' isn't DECL_DECOMPOSITION_P and we don't detect this case. So I needed a way to signal to start_decl that it should fit_decomposition_lang_decl. In this patch, I'm adding SD_DECOMPOSITION flag to say that the variable is initialized and it should also be marked as DECL_DECOMPOSITION_P. DR 2289 PR c++/94553 * cp-tree.h (SD_DECOMPOSITION): New flag. * decl.c (duplicate_decls): Make sure a structured binding is unique in its declarative region. (start_decl): If INITIALIZED is SD_DECOMPOSITION, call fit_decomposition_lang_decl. (grokdeclarator): Compare INITIALIZED directly to SD_* flags. * parser.c (cp_parser_decomposition_declaration): Pass SD_DECOMPOSITION to start_decl. * g++.dg/cpp1z/decomp52.C: New test.
[Bug c++/95241] [10/11 Regression] internal compiler error: tree check: expected integer_cst, have range_expr in to_wide, at tree.h:5900
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95241 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 Target Milestone|--- |10.2 Summary|internal compiler error:|[10/11 Regression] internal |tree check: expected|compiler error: tree check: |integer_cst, have |expected integer_cst, have |range_expr in to_wide, at |range_expr in to_wide, at |tree.h:5900 |tree.h:5900 Status|UNCONFIRMED |NEW Last reconfirmed||2020-05-20 CC||mpolacek at gcc dot gnu.org, ||ppalka at gcc dot gnu.org Keywords||ice-on-valid-code --- Comment #1 from Marek Polacek --- Confirmed, started with r10-7556-g37244b217a7329792f4ec48027f63cf5010b0ea8
[Bug c++/95241] New: internal compiler error: tree check: expected integer_cst, have range_expr in to_wide, at tree.h:5900
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95241 Bug ID: 95241 Summary: internal compiler error: tree check: expected integer_cst, have range_expr in to_wide, at tree.h:5900 Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tab.debugteam at gmail dot com Target Milestone: --- Following c++ code: ``` struct Fragment { int offset; int length; constexpr Fragment( int _offset, int _length) : offset(_offset), length(_length) { } constexpr Fragment() : Fragment(0, 1) { } }; struct Field { Fragment fragments[3]; constexpr Field(int offset, int length) : fragments{Fragment(offset, length)} { } }; int main() { auto field = Field(0, 1); return 0; } ``` fails to compile with gcc 10.1 (https://godbolt.org/z/tyPB6V) and later with error message: ``` : In function 'int main()': :28:28: in 'constexpr' expansion of 'Field(0, 1)' :28:28: internal compiler error: tree check: expected integer_cst, have range_expr in to_wide, at tree.h:5900 28 | auto field = Field(0, 1); |^ ``` First spotted on gcc 10.1: https://godbolt.org/z/tyPB6V, but it's also reproducible on latest gcc available on compiler explorer (version 11.0.0 20200511): https://godbolt.org/z/qWivJC. I'm unable to reproduce it on gcc 9.3: https://godbolt.org/z/C2QqxA.
[Bug target/95229] [11 Regression] in mark_jump_label_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95229 --- Comment #8 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:3872a519c8fa65318efa1b481d331ef91b3ff044 commit r11-528-g3872a519c8fa65318efa1b481d331ef91b3ff044 Author: Uros Bizjak Date: Wed May 20 19:00:39 2020 +0200 i386: Fix zero/sign extend expanders [PR95229] 2020-05-20 Uroš Bizjak gcc/ChangeLog: PR target/95229 * config/i386/sse.md (v8qiv8hi2): Use simplify_gen_subreg instead of simplify_subreg. (v8qiv8si2): Ditto. (v4qiv4si2): Ditto. (v4hiv4si2): Ditto. (v8qiv8di2): Ditto. (v4qiv4di2): Ditto. (v2qiv2di2): Ditto. (v4hiv4di2): Ditto. (v2hiv2di2): Ditto. (v2siv2di2): Ditto. gcc/testsuite/ChangeLog: PR target/95229 * g++.target/i386/pr95229.C: New test.
[Bug target/95238] [11 Regression] Invalid *pushsi2_rex64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95238 --- Comment #6 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:2cf6f31527c6d8dd2cc96f4efe8ff70d60d5fb44 commit r11-527-g2cf6f31527c6d8dd2cc96f4efe8ff70d60d5fb44 Author: Uros Bizjak Date: Wed May 20 18:57:32 2020 +0200 i386: Fix *pushsi2_rex64 constraints [PR95238] 2020-05-20 Uroš Bizjak gcc/ChangeLog: PR target/95238 * config/i386/i386.md (*pushsi2_rex64): Use "e" constraint instead of "i".
[Bug analyzer/95240] New: calloc() false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95240 Bug ID: 95240 Summary: calloc() false positives Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: gcc.gnu.org at andred dot net Target Milestone: --- Host: x86_64-linux-gnu Target: x86_64-linux-gnu Build: x86_64-linux-gnu Created attachment 48574 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48574=edit testcase Test with: gcc-10 (Debian 10.1.0-2) 10.1.0 (same behaviour with gcc 10.0) With the attached, I get a false positive: gcc-10 -Os -fanalyzer -fdiagnostics-path-format=separate-events t.c -o t t.c: In function ‘initActiveTroubleArray’: t.c:13:35: warning: leak of ‘’ [CWE-401] [-Wanalyzer-malloc-leak] 13 | return activeTroubleArray ? 0 : 1; |~~~^~~ t.c:12:26: note: (1) allocated here 12 | activeTroubleArray = calloc (1, 1); | ^ t.c:13:35: note: (2) ‘’ leaks here; was allocated at (1) 13 | return activeTroubleArray ? 0 : 1; |~~~^~~ The warning goes away in either of the following cases: * use malloc() instead of calloc() and change nothing else * remove the test in initActiveTroubleArray() and change nothing else * declare activeTroubleArray as void * and change nothing else (note that the warning is triggered when using anything but void * - standard types like char, long, etc, but also when using struct, enum etc.)
[Bug c/95239] New: Unable to ignore -Wattribute-warning in macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95239 Bug ID: 95239 Summary: Unable to ignore -Wattribute-warning in macro Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: e...@coeus-group.com Target Milestone: --- Created attachment 48573 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48573=edit Test case I'm trying to create a macro which evaluates an expression while ignoring warnings generated by the warning attribute. Basically, a slightly simplified version of what I want is: #define IGNORE_WARNING_ATTR(expr) (__extension__({ \ _Pragma("GCC diagnostic push") \ _Pragma("GCC diagnostic ignored \"-Wattribute-warning\"") \ int tmp = expr; \ _Pragma("GCC diagnostic pop") \ tmp; \ })) However, when I use it I still see the warning. If I don't use a macro, but instead just do int c = (__extension__({ _Pragma("GCC diagnostic push") _Pragma("GCC diagnostic ignored \"-Wattribute-warning\"") int tmp = foo(argc); _Pragma("GCC diagnostic pop") tmp; })); It works as intended; no warning. If I use the macro version and preprocess the source file first, then compile the preprocessed file separately, it works. If I compile with g++ it works. Using the attached test case, I get: $ gcc -E -o warn-pp.c warn.c && gcc -o warn warn-pp.c $ g++ -o warn warn.c $ gcc -o warn warn.c warn.c: In function ‘main’: warn.c:23:31: warning: call to ‘foo’ declared with attribute warning: Calling foo [-Wattribute-warning] 23 | int b = IGNORE_WARNING_ATTR(foo(argc)); | ^ warn.c:4:15: note: in definition of macro ‘IGNORE_WARNING_ATTR’ 4 | int tmp = expr; \ | ^~~~
[Bug target/95237] LOCAL_DECL_ALIGNMENT shrinks alignment, FAIL gcc.target/i386/pr69454-2.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95237 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Target Milestone|--- |11.0 Ever confirmed|0 |1 Last reconfirmed||2020-05-20 --- Comment #1 from H.J. Lu --- FAIL: c-c++-common/gomp/declare-variant-5.c (internal compiler error) FAIL: c-c++-common/gomp/declare-variant-5.c (internal compiler error) FAIL: c-c++-common/gomp/declare-variant-5.c (internal compiler error) FAIL: c-c++-common/gomp/declare-variant-5.c (test for excess errors) FAIL: c-c++-common/gomp/declare-variant-5.c (test for excess errors) FAIL: c-c++-common/gomp/declare-variant-5.c (test for excess errors) FAIL: gcc.target/i386/pr69454-2.c (internal compiler error) FAIL: gcc.target/i386/pr69454-2.c (test for excess errors) FAIL: gcc.target/i386/stackalign/longlong-1.c -mno-stackrealign (internal compiler error) FAIL: gcc.target/i386/stackalign/longlong-1.c -mno-stackrealign (test for excess errors) FAIL: gcc.target/i386/stackalign/longlong-1.c -mstackrealign (internal compiler error) FAIL: gcc.target/i386/stackalign/longlong-1.c -mstackrealign (test for excess errors)
[Bug target/95238] [11 Regression] Invalid *pushsi2_rex64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95238 H.J. Lu changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-05-20 Status|UNCONFIRMED |NEW --- Comment #5 from H.J. Lu --- (In reply to Uroš Bizjak from comment #4) > > (define_insn "*pushsi2" > [(set (match_operand:SI 0 "push_operand" "=<,<") > (match_operand:SI 1 "general_no_elim_operand" "ri*m,*v"))] > > This was "i" before my patch. This may generate DT_TEXTREL for "push $symbol" when generating shared object
[Bug tree-optimization/94335] [10/11 Regression] False positive -Wstringop-overflow warning with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94335 Martin Sebor changed: What|Removed |Added Known to fail||10.1.0, 11.0 Blocks||88443 Summary|False positive |[10/11 Regression] False |-Wstringop-overflow warning |positive |with -O2|-Wstringop-overflow warning ||with -O2 --- Comment #7 from Martin Sebor --- Thanks for the small test case! The warning for reference is: pr94335-c6.C: In function ‘int main()’: pr94335-c6.C:8:20: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] 8 | outputs.back() = 1; | ~~~^~~ In file included from /build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/c++allocator.h:33, from /build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/allocator.h:46, from /build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/vector:64, from pr94335-c6.C:3: /build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/ext/new_allocator.h:115:41: note: at offset 0 to an object with size 0 allocated by ‘operator new’ here 115 | return static_cast<_Tp*>(::operator new(__n * sizeof(_Tp))); | ~~^~~ The warning in this case is actually due to a different problem, this one in the warning infrastructure itself. The relevant IL the warning works with (-fdump-tree-strlen) is below: main () { ... unsigned char * _48; ... unsigned char * _59; ... [local count: 1073741825]: ... _59 = operator new (2); [local count: 1073007519]: outputs.D.19139._M_impl.D.18482._M_start = _59; _48 = _59 + 2; ... MEM[(value_type &)_48 + 18446744073709551615] = 1; <<< warning here (18446744073709551615 == -2) ... } To determine the size of what _48 points to the warning code calls the compute_objsize() function. It returns zero because of a design limitation: it returns the size of the remaining space in the object (i.e., the full size of the pointed-to object minus the offset, which is 2 in this case). The caller has no way to increase the size it gets back by its negative offset (the large number which is -2). I have a rewritten the function to avoid this (and other problems with it) and expect to have a fix for GCC 11, and possibly even for GCC 10.2. Since this is a different problem than the originally reported bug I don't want to use it to track it. Feel free to open a separate bug for it. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 [Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
[Bug fortran/20585] [meta-bug] Fortran 2003 support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20585 Bug 20585 depends on bug 39695, which changed state. Bug 39695 Summary: [F03] ProcPtr function results: wrong name in error message https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39695 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/39695] [F03] ProcPtr function results: wrong name in error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39695 markeggleston at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #11 from markeggleston at gcc dot gnu.org --- Committed to master and backported.
[Bug fortran/39695] [F03] ProcPtr function results: wrong name in error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39695 --- Comment #10 from CVS Commits --- The releases/gcc-8 branch has been updated by Mark Eggleston : https://gcc.gnu.org/g:15e518600a9ef82b55d2ec75d8d41d767132f475 commit r8-10261-g15e518600a9ef82b55d2ec75d8d41d767132f475 Author: Mark Eggleston Date: Thu May 7 08:02:02 2020 +0100 Fortran : ProcPtr function results: 'ppr@' in error message PR39695 The value 'ppr@' is set in the name of result symbol, the actual name of the symbol is in the procedure name symbol pointed to by the result symbol's namespace (ns). When reporting errors for symbols that have the proc_pointer attribute check whether the result attribute is set and set the name accordingly. Backport from master. 2020-05-20 Mark Eggleston gcc/fortran/ PR fortran/39695 * resolve.c (resolve_fl_procedure): Set name depending on whether the result attribute is set. For PROCEDURE/RESULT conflict use the name in sym->ns->proc_name->name. * symbol.c (gfc_add_type): Add check for function and result attributes use sym->ns->proc_name->name if both are set. Where the symbol cannot have a type use the name in sym->ns->proc_name->name. 2020-05-20 Mark Eggleston gcc/testsuite/ PR fortran/39695 * gfortran.dg/pr39695_1.f90: New test. * gfortran.dg/pr39695_2.f90: New test. * gfortran.dg/pr39695_3.f90: New test. * gfortran.dg/pr39695_4.f90: New test. (cherry picked from commit eb069ae8819c3a84d7f78becc5501e21ee3a9554)
[Bug target/95238] [11 Regression] Invalid *pushsi2_rex64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95238 --- Comment #4 from Uroš Bizjak --- (In reply to H.J. Lu from comment #3) > (In reply to Uroš Bizjak from comment #2) > > (In reply to H.J. Lu from comment #1) > > > The "i" constraint shouldn't be used for flag_pic since symbolic constant > > > leads to writable text in 32-bit mode and invalid in 64-bit mode. > > > > Just a typo. "i" should be changed back to "e". > > There are other "ri" in push patterns. The 32 bit linker won't complain > but will add DT_TEXTREL for "push $symbol" when generating shared object. (define_insn "*push2" [(set (match_operand:DWI 0 "push_operand" "=<,<") (match_operand:DWI 1 "general_no_elim_operand" "riF*o,*v"))] This will never match symbol, so "i" can be "n" as well. ;; For TARGET_64BIT we always round up to 8 bytes. (define_insn "*pushsi2_rex64" [(set (match_operand:SI 0 "push_operand" "=X,X") (match_operand:SI 1 "nonmemory_no_elim_operand" "re,*v"))] This is changed to "e", as was before. (define_insn "*pushsi2" [(set (match_operand:SI 0 "push_operand" "=<,<") (match_operand:SI 1 "general_no_elim_operand" "ri*m,*v"))] This was "i" before my patch. (define_insn "*push2_prologue" [(set (match_operand:W 0 "push_operand" "=<") (match_operand:W 1 "general_no_elim_operand" "r*m")) This one is in effect "e".
[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218 --- Comment #15 from Uroš Bizjak --- (In reply to Jakub Jelinek from comment #13) > So perhaps pre-reload splitter of that into the UNSPEC form? Vector insns should be able to use pre-reload splitter, but scalar instructions depend on post-reload splitter, because they are split in a different way, depending on a register set of allocated register (FP, XMM or even integer). So, it really needs to be a post-reload splitter.
[Bug target/95238] [11 Regression] Invalid *pushsi2_rex64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95238 --- Comment #3 from H.J. Lu --- (In reply to Uroš Bizjak from comment #2) > (In reply to H.J. Lu from comment #1) > > The "i" constraint shouldn't be used for flag_pic since symbolic constant > > leads to writable text in 32-bit mode and invalid in 64-bit mode. > > Just a typo. "i" should be changed back to "e". There are other "ri" in push patterns. The 32 bit linker won't complain but will add DT_TEXTREL for "push $symbol" when generating shared object.
[Bug fortran/39695] [F03] ProcPtr function results: wrong name in error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39695 --- Comment #9 from CVS Commits --- The releases/gcc-9 branch has been updated by Mark Eggleston : https://gcc.gnu.org/g:7c9bfd404691e5dac7e32830ae6d9726ccf59683 commit r9-8608-g7c9bfd404691e5dac7e32830ae6d9726ccf59683 Author: Mark Eggleston Date: Thu May 7 08:02:02 2020 +0100 Fortran : ProcPtr function results: 'ppr@' in error message PR39695 The value 'ppr@' is set in the name of result symbol, the actual name of the symbol is in the procedure name symbol pointed to by the result symbol's namespace (ns). When reporting errors for symbols that have the proc_pointer attribute check whether the result attribute is set and set the name accordingly. Backported from master. 2020-05-20 Mark Eggleston gcc/fortran/ PR fortran/39695 * resolve.c (resolve_fl_procedure): Set name depending on whether the result attribute is set. For PROCEDURE/RESULT conflict use the name in sym->ns->proc_name->name. * symbol.c (gfc_add_type): Add check for function and result attributes use sym->ns->proc_name->name if both are set. Where the symbol cannot have a type use the name in sym->ns->proc_name->name. 2020-05-20 Mark Eggleston gcc/testsuite/ PR fortran/39695 * gfortran.dg/pr39695_1.f90: New test. * gfortran.dg/pr39695_2.f90: New test. * gfortran.dg/pr39695_3.f90: New test. * gfortran.dg/pr39695_4.f90: New test. (cherry picked from commit eb069ae8819c3a84d7f78becc5501e21ee3a9554)
[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218 Uroš Bizjak changed: What|Removed |Added CC|uros at gcc dot gnu.org| --- Comment #14 from Uroš Bizjak --- Its interesting to note, that only *some* of insns with memory uses get removed.
[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #13 from Jakub Jelinek --- So perhaps pre-reload splitter of that into the UNSPEC form?
[Bug fortran/39695] [F03] ProcPtr function results: wrong name in error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39695 --- Comment #8 from CVS Commits --- The releases/gcc-10 branch has been updated by Mark Eggleston : https://gcc.gnu.org/g:8358ac9bbc57d6986c9bd5dd17c0331a60114f45 commit r10-8160-g8358ac9bbc57d6986c9bd5dd17c0331a60114f45 Author: Mark Eggleston Date: Thu May 7 08:02:02 2020 +0100 Fortran : ProcPtr function results: 'ppr@' in error message PR39695 The value 'ppr@' is set in the name of result symbol, the actual name of the symbol is in the procedure name symbol pointed to by the result symbol's namespace (ns). When reporting errors for symbols that have the proc_pointer attribute check whether the result attribute is set and set the name accordingly. Backported from master. 2020-05-20 Mark Eggleston gcc/fortran/ PR fortran/39695 * resolve.c (resolve_fl_procedure): Set name depending on whether the result attribute is set. For PROCEDURE/RESULT conflict use the name in sym->ns->proc_name->name. * symbol.c (gfc_add_type): Add check for function and result attributes use sym->ns->proc_name->name if both are set. Where the symbol cannot have a type use the name in sym->ns->proc_name->name. 2020-05-20 Mark Eggleston gcc/testsuite/ PR fortran/39695 * gfortran.dg/pr39695_1.f90: New test. * gfortran.dg/pr39695_2.f90: New test. * gfortran.dg/pr39695_3.f90: New test. * gfortran.dg/pr39695_4.f90: New test. (cherry picked from commit eb069ae8819c3a84d7f78becc5501e21ee3a9554)
[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218 --- Comment #12 from Uroš Bizjak --- (In reply to Richard Biener from comment #11) > Note a 'use' is not something that needs to be preserved, so > > (define_insn_and_split "*2" > [(set (match_operand:VF 0 "register_operand" "=x,v") > (absneg:VF > (match_operand:VF 1 "vector_operand" "%0,v"))) >(use (match_operand:VF 2 "vector_operand" "xBm,vm"))] > "TARGET_SSE" > "#" > "&& reload_completed" > [(set (match_dup 0) > (:VF (match_dup 1) (match_dup 2)))] > "" > [(set_attr "isa" "noavx,avx")]) > > doesn't make much sense (before reload). To me, that is. Why do > we go that obfuscated way at all? I think a clean solution is to > use an UNSPEC here (well, "clean"...). The reason for this approach was, that combine still processes the pattern as abs/nop. Please see how *nabstf2_1 is defined.
[Bug target/95238] [11 Regression] Invalid *pushsi2_rex64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95238 --- Comment #2 from Uroš Bizjak --- (In reply to H.J. Lu from comment #1) > The "i" constraint shouldn't be used for flag_pic since symbolic constant > leads to writable text in 32-bit mode and invalid in 64-bit mode. Just a typo. "i" should be changed back to "e".
[Bug c++/95223] [11 regression] hash table checking failed: equal operator returns true for a pair of values with a different hash value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95223 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Patrick Palka --- Thanks for the reports. This should now hopefully be fixed with r11-522.
[Bug target/95229] [11 Regression] in mark_jump_label_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95229 --- Comment #7 from Uroš Bizjak --- (In reply to Richard Biener from comment #6) > That fixes the testcase. But simplify_subreg is used in a lot more places > so leaving to Uros to match up with expectations. Oh, yes... We don't have hard regs here, so all should be changed to simplify_gen_subregs. I have a patch.
[Bug fortran/39695] [F03] ProcPtr function results: wrong name in error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39695 --- Comment #7 from CVS Commits --- The master branch has been updated by Mark Eggleston : https://gcc.gnu.org/g:eb069ae8819c3a84d7f78becc5501e21ee3a9554 commit r11-524-geb069ae8819c3a84d7f78becc5501e21ee3a9554 Author: Mark Eggleston Date: Thu May 7 08:02:02 2020 +0100 Fortran : ProcPtr function results: 'ppr@' in error message PR39695 The value 'ppr@' is set in the name of result symbol, the actual name of the symbol is in the procedure name symbol pointed to by the result symbol's namespace (ns). When reporting errors for symbols that have the proc_pointer attribute check whether the result attribute is set and set the name accordingly. 2020-05-20 Mark Eggleston gcc/fortran/ PR fortran/39695 * resolve.c (resolve_fl_procedure): Set name depending on whether the result attribute is set. For PROCEDURE/RESULT conflict use the name in sym->ns->proc_name->name. * symbol.c (gfc_add_type): Add check for function and result attributes use sym->ns->proc_name->name if both are set. Where the symbol cannot have a type use the name in sym->ns->proc_name->name. 2020-05-20 Mark Eggleston gcc/testsuite/ PR fortran/39695 * gfortran.dg/pr39695_1.f90: New test. * gfortran.dg/pr39695_2.f90: New test. * gfortran.dg/pr39695_3.f90: New test. * gfortran.dg/pr39695_4.f90: New test.
[Bug target/95238] [11 Regression] Invalid *pushsi2_rex64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95238 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0
[Bug c++/95223] [11 regression] hash table checking failed: equal operator returns true for a pair of values with a different hash value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95223 --- Comment #7 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:610ae2dbbf98a291782cb05c0fb31e056193e5e2 commit r11-522-g610ae2dbbf98a291782cb05c0fb31e056193e5e2 Author: Patrick Palka Date: Wed May 20 09:15:48 2020 -0400 c++: spec_hasher and TYPENAME_TYPE resolution [PR95223] After enabling sanitization of the specialization tables, we are triggering one of the hash table sanity checks in the below testcase. The reason is that when looking up the specialization j in the type_specializations table, the sanity check finds that the existing entry j::m> compares equal to j but hashes differently. The discrepancy is due to structural_comptypes looking through TYPENAME_TYPEs (via resolve_typename_type), something which iterative_hash_template_arg doesn't do. So the TYPENAME_TYPE n::m is considered equal to int, but the hashes of these two template arguments are different. It seems wrong for the result of a specialization table lookup to depend on the current scope, so this patch makes structural_comptypes avoid calling resolve_typename_type when comparing_specializations. In order for the below testcase to deterministically trigger the sanitization error without this patch, we also need to fix the location of the call to hash_table::verify within hash_table::find_with_hash. gcc/ChangeLog: PR c++/95223 * hash-table.h (hash_table::find_with_hash): Move up the call to hash_table::verify. gcc/cp/ChangeLog: PR c++/95223 * typeck.c (structural_comptypes): Don't perform context-dependent resolution of TYPENAME_TYPEs when comparing_specializations. gcc/testsuite/ChangeLog: PR c++/95223 * g++.dg/template/typename23.C: New test.
[Bug target/95238] [11 Regression] Invalid *pushsi2_rex64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95238 --- Comment #1 from H.J. Lu --- The "i" constraint shouldn't be used for flag_pic since symbolic constant leads to writable text in 32-bit mode and invalid in 64-bit mode.
[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218 --- Comment #11 from Richard Biener --- Note a 'use' is not something that needs to be preserved, so (define_insn_and_split "*2" [(set (match_operand:VF 0 "register_operand" "=x,v") (absneg:VF (match_operand:VF 1 "vector_operand" "%0,v"))) (use (match_operand:VF 2 "vector_operand" "xBm,vm"))] "TARGET_SSE" "#" "&& reload_completed" [(set (match_dup 0) (:VF (match_dup 1) (match_dup 2)))] "" [(set_attr "isa" "noavx,avx")]) doesn't make much sense (before reload). To me, that is. Why do we go that obfuscated way at all? I think a clean solution is to use an UNSPEC here (well, "clean"...).
[Bug target/95238] New: [11 Regression] Invalid *pushsi2_rex64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95238 Bug ID: 95238 Summary: [11 Regression] Invalid *pushsi2_rex64 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: ubizjak at gmail dot com Target Milestone: --- Target: x86-64 In 64-bit mode, we can only push 16-bit or 64-bit memory/register. commit 75514d157e9e28616c6de4e8c2740d8c87b6857d Author: Uros Bizjak Date: Fri May 15 16:22:19 2020 +0200 i386: Allow SI, DI and TImode pushes from XMM registers Also change XMM register constraint from "x" to "v" in FP push insns. added +;; For TARGET_64BIT we always round up to 8 bytes. +(define_insn "*pushsi2_rex64" + [(set (match_operand:SI 0 "push_operand" "=X,X") + (match_operand:SI 1 "nonmemory_no_elim_operand" "ri,*v"))] + "TARGET_64BIT" + "@ + push{q}\t%q1 + #" + [(set_attr "type" "push,multi") + (set_attr "mode" "DI")]) The "i" constraint should be "n" since symbolic constant is invalid for PIC or PIE.
[Bug tree-optimization/94335] False positive -Wstringop-overflow warning with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94335 kal.conley at dectris dot com changed: What|Removed |Added CC||kal.conley at dectris dot com --- Comment #6 from kal.conley at dectris dot com --- We are hitting this warning too with: #include #include int main() { std::vector inputs(2); std::vector outputs{inputs.begin(), inputs.end()}; outputs.back() = 1; return 0; } Regards, Kal
[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218 --- Comment #10 from rguenther at suse dot de --- On Wed, 20 May 2020, ubizjak at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218 > > Uroš Bizjak changed: > >What|Removed |Added > > CC||law at gcc dot gnu.org, >||rsandifo at gcc dot gnu.org > > --- Comment #9 from Uroš Bizjak --- > (In reply to Uroš Bizjak from comment #7) > > Ooh, yes :( > > > > '(use X)' > > Represents the use of the value of X. It indicates that the value > > in X at this point in the program is needed, even though it may not > > be apparent why this is so. Therefore, the compiler will not > > attempt to delete previous instructions whose only effect is to > > store a value in X. X must be a 'reg' expression. > > > > Partial revert is in works. > > Actually, no. The above applies to single (use ...) RTX, not (use ...) as part > of a parallel. There are plenty of uses of memory_operands in i386.md: > > (define_insn "fix_truncdi_i387" > [(set (match_operand:DI 0 "nonimmediate_operand" "=m") > (fix:DI (match_operand 1 "register_operand" "f"))) >(use (match_operand:HI 2 "memory_operand" "m")) >(use (match_operand:HI 3 "memory_operand" "m")) >(clobber (match_scratch:XF 4 "="))] > > Let's ask experts. The question is what should the (use ...) do? Allow the splitter to use its contents? I guess that's reasonable interpretation though I thought (use ...) apply only to register liveness computation and not to memory. But what do I know about RTL ;)
[Bug target/95237] New: LOCAL_DECL_ALIGNMENT shrinks alignment, FAIL gcc.target/i386/pr69454-2.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95237 Bug ID: 95237 Summary: LOCAL_DECL_ALIGNMENT shrinks alignment, FAIL gcc.target/i386/pr69454-2.c Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- The testcase and a few others now ICEs on x86_64 with -m32 since LOCAL_DECL_ALIGNMENT with -mpreferred-stack-boundary=2 shrinks alignment of 'long long' from 8 to 4. /home/rguenther/src/trunk/gcc/testsuite/gcc.target/i386/pr69454-2.c: In function 'fn1':^M /home/rguenther/src/trunk/gcc/testsuite/gcc.target/i386/pr69454-2.c:7:6: internal compiler error: in execute, at adjust-alignment.c:73^M 0x216245b execute^M ../../src/trunk/gcc/adjust-alignment.c:73^M Please submit a full bug report,^M this was a latent wrong-code bug before if you consider typedef __UINTPTR_TYPE__ uintptr_t; void __attribute__((noipa)) foo (long long *p, uintptr_t a) { if ((uintptr_t)p & (a-1)) __builtin_abort (); } int main() { long long x; uintptr_t a = __alignof__(x); foo(, a); return 0; } and the frame of main not being aligned to 8 bytes.
[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218 Uroš Bizjak changed: What|Removed |Added CC||law at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org --- Comment #9 from Uroš Bizjak --- (In reply to Uroš Bizjak from comment #7) > Ooh, yes :( > > '(use X)' > Represents the use of the value of X. It indicates that the value > in X at this point in the program is needed, even though it may not > be apparent why this is so. Therefore, the compiler will not > attempt to delete previous instructions whose only effect is to > store a value in X. X must be a 'reg' expression. > > Partial revert is in works. Actually, no. The above applies to single (use ...) RTX, not (use ...) as part of a parallel. There are plenty of uses of memory_operands in i386.md: (define_insn "fix_truncdi_i387" [(set (match_operand:DI 0 "nonimmediate_operand" "=m") (fix:DI (match_operand 1 "register_operand" "f"))) (use (match_operand:HI 2 "memory_operand" "m")) (use (match_operand:HI 3 "memory_operand" "m")) (clobber (match_scratch:XF 4 "="))] Let's ask experts.
[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218 --- Comment #8 from Martin Liška --- There's partially reduced test-case: $ cat fma.i double res_test0101[] = { -3,1, 17,51,109, 197, 321, 487, 701, 969, 1297, 1691, 2157, 2701, 3329, 4047, 4861, 5777, 6801, 7939, 9197, 10581, 12097, 13751, 15549, 17497, 19601, 21867, 24301, 26909, 29697, 32671}; double res_test0110[] = {3, -1, -17,-51,-109, -197, -321, -487, -701, -969, -1297, -1691, -2157, -2701, -3329, -4047, -4861, -5777, -6801, -7939, -9197, -10581, -12097, -13751, -15549, -17497, -19601, -21867, -24301, -26909, -29697, -32671}; extern void abort() __attribute__(()) __attribute__(()); static __inline int __get_cpuid(unsigned int __leaf, unsigned int *__eax, unsigned int *__ebx, unsigned int *__ecx, unsigned int *__edx) { __asm__("cpuid\n\t" : "=a"(*__eax), "=b"(*__ebx), "=c"(*__ecx), "=d"(*__edx) : "0"(__leaf)); } static void fma_test(); int main() { unsigned int eax, ebx, ecx, edx; if (!__get_cpuid(1, , , , )) 0; if (ecx & (1 << 12)) fma_test(); return 0; } double m1[] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32}; double m2[] = {2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33}; double m3[] = {3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34}; double m4[32]; int test_fails = 0; void compare_result(double *res) { int i; int good = 1; i = 0; for (i; i < 32; i++) if (m4[i] != res[i]) if (good) good = 0; if (!good) test_fails = 1; } static void fma_test() { double __trans_tmp_3; double __trans_tmp_2; double __trans_tmp_1; int i; for (i = 0; i < 32; i++) m4[i] = 0; i = 0; for (i; i < 32; i++) { double a = m1[i]; double b = m2[i]; double c = m3[i]; __trans_tmp_1 = ((a * b) - c) * a - b; m4[i] = __trans_tmp_1; } compare_result(res_test0101); i = 0; for (i; i < 32; i++) { { double a = m1[i]; double b = m2[i]; double c = m3[i]; __trans_tmp_3 = -((a * b) - c) * a + b; } m4[i] = __trans_tmp_3; } compare_result(res_test0110); i = 0; for (i; i < 32; i++) { double a = m1[i]; double b = m2[i]; double c = m3[i]; __trans_tmp_2 = -((a * b) - c) * a - b; m4[i] = __trans_tmp_2; } if (test_fails) abort(); } $ gcc -O3 -Wno-attributes -mfpmath=sse -mfma fma.i && ./a.out Aborted (core dumped)
[Bug target/95229] [11 Regression] in mark_jump_label_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95229 --- Comment #6 from Richard Biener --- (In reply to Richard Biener from comment #5) > Built by > > #5 0x020c4504 in gen_rtx_fmt_ee_stat (code=VEC_SELECT, > mode=E_V2SImode, arg0=0x0, arg1=0x76ad92e0) at ./genrtl.h:49 > #6 0x0211e242 in gen_sse4_1_zero_extendv2siv2di2 ( > operand0=0x76ada4f8, operand1=0x0) at insn-emit.c:40857 > #7 0x02207aa7 in gen_zero_extendv2siv2di2 (operand0=0x76ada4f8, > operand1=0x76ada4c8) at ../../src/trunk/gcc/config/i386/sse.md:18012 > #8 0x010cfe31 in insn_gen_fn::operator() ( > this=0x3230928 , a0=0x76ada4f8, a1=0x76ada4c8) > at ../../src/trunk/gcc/recog.h:317 > #9 0x014aed21 in maybe_gen_insn > (icode=CODE_FOR_zero_extendv2siv2di2, > nops=2, ops=0x7fffa8d0) at ../../src/trunk/gcc/optabs.c:7444 > #10 0x014a3c7d in maybe_emit_unop_insn ( > icode=CODE_FOR_zero_extendv2siv2di2, target=0x76ada4f8, > --Type for more, q to quit, c to continue without paging-- > op0=0x76ada4c8, code=ZERO_EXTEND) at > ../../src/trunk/gcc/optabs.c:3597 > #11 0x014a3d7f in emit_unop_insn > (icode=CODE_FOR_zero_extendv2siv2di2, > target=0x76ada4f8, op0=0x76ada4c8, code=ZERO_EXTEND) > at ../../src/trunk/gcc/optabs.c:3621 > #12 0x01098d45 in convert_move (to=0x76ada4f8, > from=0x76ada4c8, unsignedp=1) at ../../src/trunk/gcc/expr.c:260 > #13 0x0109bc1e in convert_modes (mode=E_V2DImode, > oldmode=E_V2SImode, > x=0x76ada4c8, unsignedp=1) at ../../src/trunk/gcc/expr.c:737 > #14 0x0109b220 in convert_to_mode (mode=E_V2DImode, > x=0x76ada4c8, > unsignedp=1) at ../../src/trunk/gcc/expr.c:662 > #15 0x010bae75 in expand_expr_real_2 (ops=0x7fffb600, > target=0x0, > tmode=E_VOIDmode, modifier=EXPAND_NORMAL) > at ../../src/trunk/gcc/expr.c:8665 > > frame #7 looks OK while #6 is bogus. Context: > > 18009 if (!MEM_P (operands[1])) > 18010 { > 18011 operands[1] = simplify_subreg (V4SImode, operands[1], > V2SImode, 0); > 18012 emit_insn (gen_sse4_1_v2siv2di2 (operands[0], > operands[1])); > 18013 DONE; > > simplify_subreg returns NULL. It is originally (reg:V2SI 90 [ vect__2.8 ]). > Should that be simplify_gen_subreg? That fixes the testcase. But simplify_subreg is used in a lot more places so leaving to Uros to match up with expectations.
[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218 Uroš Bizjak changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com --- Comment #7 from Uroš Bizjak --- Ooh, yes :( '(use X)' Represents the use of the value of X. It indicates that the value in X at this point in the program is needed, even though it may not be apparent why this is so. Therefore, the compiler will not attempt to delete previous instructions whose only effect is to store a value in X. X must be a 'reg' expression. Partial revert is in works.
[Bug target/95229] [11 Regression] in mark_jump_label_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95229 --- Comment #5 from Richard Biener --- Built by #5 0x020c4504 in gen_rtx_fmt_ee_stat (code=VEC_SELECT, mode=E_V2SImode, arg0=0x0, arg1=0x76ad92e0) at ./genrtl.h:49 #6 0x0211e242 in gen_sse4_1_zero_extendv2siv2di2 ( operand0=0x76ada4f8, operand1=0x0) at insn-emit.c:40857 #7 0x02207aa7 in gen_zero_extendv2siv2di2 (operand0=0x76ada4f8, operand1=0x76ada4c8) at ../../src/trunk/gcc/config/i386/sse.md:18012 #8 0x010cfe31 in insn_gen_fn::operator() ( this=0x3230928 , a0=0x76ada4f8, a1=0x76ada4c8) at ../../src/trunk/gcc/recog.h:317 #9 0x014aed21 in maybe_gen_insn (icode=CODE_FOR_zero_extendv2siv2di2, nops=2, ops=0x7fffa8d0) at ../../src/trunk/gcc/optabs.c:7444 #10 0x014a3c7d in maybe_emit_unop_insn ( icode=CODE_FOR_zero_extendv2siv2di2, target=0x76ada4f8, --Type for more, q to quit, c to continue without paging-- op0=0x76ada4c8, code=ZERO_EXTEND) at ../../src/trunk/gcc/optabs.c:3597 #11 0x014a3d7f in emit_unop_insn (icode=CODE_FOR_zero_extendv2siv2di2, target=0x76ada4f8, op0=0x76ada4c8, code=ZERO_EXTEND) at ../../src/trunk/gcc/optabs.c:3621 #12 0x01098d45 in convert_move (to=0x76ada4f8, from=0x76ada4c8, unsignedp=1) at ../../src/trunk/gcc/expr.c:260 #13 0x0109bc1e in convert_modes (mode=E_V2DImode, oldmode=E_V2SImode, x=0x76ada4c8, unsignedp=1) at ../../src/trunk/gcc/expr.c:737 #14 0x0109b220 in convert_to_mode (mode=E_V2DImode, x=0x76ada4c8, unsignedp=1) at ../../src/trunk/gcc/expr.c:662 #15 0x010bae75 in expand_expr_real_2 (ops=0x7fffb600, target=0x0, tmode=E_VOIDmode, modifier=EXPAND_NORMAL) at ../../src/trunk/gcc/expr.c:8665 frame #7 looks OK while #6 is bogus. Context: 18009 if (!MEM_P (operands[1])) 18010 { 18011 operands[1] = simplify_subreg (V4SImode, operands[1], V2SImode, 0); 18012 emit_insn (gen_sse4_1_v2siv2di2 (operands[0], operands[1])); 18013 DONE; simplify_subreg returns NULL. It is originally (reg:V2SI 90 [ vect__2.8 ]). Should that be simplify_gen_subreg?
[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218 --- Comment #6 from Uroš Bizjak --- I think I found the issue. Before the patch, we had: (insn 375 373 2574 7 (parallel [ (set (reg:V4DF 21 xmm1 [orig:1681 vect__45.441 ] [1681]) (neg:V4DF (mem/c:V4DF (plus:DI (reg/f:DI 7 sp) (const_int 160 [0xa0])) [3 %sfp+-1184 S32 A256]))) (use (reg:V4DF 20 xmm0 [3332])) ]) "fma_1.h":20:10 1487 {*negv4df2} (nil)) after the patch, reload is free to create: (insn 375 3216 2578 7 (parallel [ (set (reg:V4DF 21 xmm1 [orig:1681 vect__45.441 ] [1681]) (neg:V4DF (reg:V4DF 20 xmm0 [3332]))) (use (mem/c:V4DF (plus:DI (reg/f:DI 7 sp) (const_int 160 [0xa0])) [3 %sfp+-1184 S32 A256])) ]) "fma_1.h":20:10 1487 {*negv4df2} (nil)) which postreload pass does not like, and simply deletes it: deleting insn with uid = 375. Just like that. No substitution whatsoever. So, is there some limitation with (use) RTX, so we can't have memory here?
[Bug target/95229] [11 Regression] in mark_jump_label_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95229 Richard Biener changed: What|Removed |Added Target||x86_64-*-* i?86-*-* CC||uros at gcc dot gnu.org Component|middle-end |target --- Comment #4 from Richard Biener --- Program received signal SIGSEGV, Segmentation fault. 0x013747bd in mark_jump_label_1 (x=0x0, insn=0x76ac8b80, in_mem=false, is_target=false) at ../../src/trunk/gcc/jump.c:1087 1087 RTX_CODE code = GET_CODE (x); (gdb) p debug_rtx (insn) (insn 9 8 10 2 (set (reg:V2DI 91 [ vect__3.9 ]) (zero_extend:V2DI (vec_select:V2SI (nil) (parallel [ (const_int 0 [0]) (const_int 1 [0x1]) ] "z.c":15:12 -1 (nil)) the vec_select has a NULL operand somehow. We're expanding from vect__3.9_16 = (vector(2) long unsigned int) vect__2.8_15; so likely Uros change or it triggers a bogus expand helper or forwprop does not properly constrain itself. I'll debug a bit.
[Bug target/95219] [11 Regression] FAIL: gcc.dg/vect/costmodel/x86_64/costmodel-pr30843.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95219 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:b2f26af32b5b031fce761aa090de9476a53e6e5a commit r11-519-gb2f26af32b5b031fce761aa090de9476a53e6e5a Author: Richard Biener Date: Wed May 20 09:22:58 2020 +0200 tree-optimization/95219 - improve IV selection for induction This improves code generation with SSE2 for the testcase by making sure to only generate a single IV when the group size is a multiple of the vector size. It also adjusts the testcase which was passing before. 2020-05-20 Richard Biener PR tree-optimization/95219 * tree-vect-loop.c (vectorizable_induction): Reduce group_size before computing the number of required IVs. * gcc.dg/vect/costmodel/x86_64/costmodel-pr30843.c: Adjust.
[Bug target/95219] [11 Regression] FAIL: gcc.dg/vect/costmodel/x86_64/costmodel-pr30843.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95219 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Richard Biener --- Fixed.
[Bug demangler/85304] Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85304 Trupti Pardeshi changed: What|Removed |Added CC||trupti_pardeshi@persistent. ||co.in --- Comment #3 from Trupti Pardeshi --- Hi, May I know whether this bug is fixed? And if fixed, in which version of binutils this fix has gone? Any heads up will be appreciated. Thanks in advance. Best Regards,
[Bug tree-optimization/95231] [11 Regression] error: the first argument of a ‘vec_cond_expr’ must be of a boolean vector type of the since r11-451-gfe168751c5c1c517
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95231 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:130bb4c79295487c5fc203103d80e3b754640eb4 commit r11-518-g130bb4c79295487c5fc203103d80e3b754640eb4 Author: Richard Biener Date: Wed May 20 11:00:57 2020 +0200 middle-end/95231 - revert parts of PR95171 I mistook the opportunity to also "fix" the [VEC_]COND_EXPR case for PR95171 but I was wrong in that it doesn't need the fix and in the actual fix as well. The following just reverts that part. 2020-05-20 Richard Biener PR middle-end/95231 * tree-inline.c (remap_gimple_stmt): Revert adjusting COND_EXPR and VEC_COND_EXPR for a -fnon-call-exception boundary. * g++.dg/other/pr95231.C: New testcase.
[Bug tree-optimization/95231] [11 Regression] error: the first argument of a ‘vec_cond_expr’ must be of a boolean vector type of the since r11-451-gfe168751c5c1c517
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95231 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed.
[Bug tree-optimization/95171] ICE: verify_flow_info failed (error: wrong outgoing edge flags at end of bb 2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95171 Bug 95171 depends on bug 95231, which changed state. Bug 95231 Summary: [11 Regression] error: the first argument of a ‘vec_cond_expr’ must be of a boolean vector type of the since r11-451-gfe168751c5c1c517 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95231 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137 --- Comment #15 from Iain Sandoe --- (In reply to Martin Liška from comment #14) > The original problem: > > test.cc:3749:5: runtime error: member call on misaligned address > 0x41b58ab3 for type 'struct awaiter', which requires 8 byte alignment > 0x41b58ab3: note: pointer points here > > > @Iain: How do you allocate the awaiter object? The coro frame is laid out according to the types determined for the objects it contains (the awaiter types are known at the point it's laid out). It just uses the 'normal' struct building rules. Awaiters are most often initialised from return values from some promise method, but they can also be local vars or parms - perhaps I slipped up there. I have a thought that I might be failing to copy across excess alignment applied (which I will look at later). ^^^ these are things on my TO-LOOK-AT list. > > @Rafael: Can you please append output with: > export UBSAN_OPTIONS="print_stacktrace=1"
[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218 --- Comment #5 from Martin Liška --- Sure, doing that.
[Bug libgcc/91695] [X86] get_available_features only sets FEATURE_GFNI and FEATURE_VPCLMULQDQ when avx512_usable is true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91695 --- Comment #2 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:1e46a443f25d26816536c0c480211714b123a1d5 commit r11-516-g1e46a443f25d26816536c0c480211714b123a1d5 Author: H.J. Lu Date: Tue May 19 18:55:08 2020 -0700 x86: Update VPCLMULQDQ check Update VPCLMULQDQ check to support processors with AVX version of VPCLMULQDQ. PR target/91695 * config/i386/cpuinfo.c (get_available_features): Fix VPCLMULQDQ check.
[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218 --- Comment #4 from Uroš Bizjak --- (In reply to Martin Liška from comment #3) > Started with r11-455-g94f687bd9ae37ece. It is not obvious from the referred patch what is going wrong here. Unfortunately, I have no FMA capable machine, can someone please isolate one small test that fails?
[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137 --- Comment #14 from Martin Liška --- The original problem: test.cc:3749:5: runtime error: member call on misaligned address 0x41b58ab3 for type 'struct awaiter', which requires 8 byte alignment 0x41b58ab3: note: pointer points here @Iain: How do you allocate the awaiter object? @Rafael: Can you please append output with: export UBSAN_OPTIONS="print_stacktrace=1"
[Bug middle-end/95208] missed switch optimization as bit test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95208 Martin Liška changed: What|Removed |Added Last reconfirmed||2020-05-20 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Looking at the dump files, we select a jump table: switch (c_2(D)) [67.00%], case 33 ... 35: [33.00%], case 37 ... 39: [33.00%], case 42 ... 63: [33.00%], case 65 ... 91: [33.00%], case 93 ... 95: [33.00%], case 97 ... 126: [33.00%]> ;; GIMPLE switch case clusters: JT(values:88 comparisons:12 range:94 density: 12.77%):33-126 We prefer a smaller number of clusters (in this case) one because we don't have to build a decision tree on top of them. In this case one can't handle all in of bit test as the range of values is >= 64.
[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137 --- Comment #13 from Iain Sandoe --- Created attachment 48572 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48572=edit fix for most of the UBSAN fails Most of the UBSAN fails are from a single cause; I reused the built DTOR tree on both resume and destroy edges from the await. There is a single remaining UBSAN fail (which is unrelated). I don't expect this to make any difference to the initial reported fail.
[Bug middle-end/95236] New: OMP 'GOMP_MAP_STRUCT': a structure is more than the sum of all its fields?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95236 Bug ID: 95236 Summary: OMP 'GOMP_MAP_STRUCT': a structure is more than the sum of all its fields? Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: openacc, openmp Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: tschwinge at gcc dot gnu.org CC: jakub at gcc dot gnu.org, jules at gcc dot gnu.org Target Milestone: --- Created attachment 48571 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48571=edit 'itu_.c' ..., and the answer (technically) may easily be "yes", considering ABI-mandated padding, for example. But: is that user friendly? Consider the test case I'm attaching, where 'struct s' consists of fields 'a', 'b', which both get mapped -- yet, 's' itself isn't considered to be. At the user level, should a structure equal the sum of all its fields, or "do we have to be complicated"? I have not fully thought that through, just noticed this when looking into something else. I also have not verified OpenMP behavior.
[Bug fortran/95214] ICE on assumed-rank character array with select rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95214 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||pault at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2020-05-20 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Started with r10-2912-g70570ec192745095, it was rejected before the revision.
[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org, ||uros at gcc dot gnu.org Summary|[11 Regression] FAIL: |[11 Regression] FAIL: |gcc.target/i386/fma_run_dou |gcc.target/i386/fma_run_dou |ble_1.c execution test |ble_1.c execution test ||since ||r11-455-g94f687bd9ae37ece --- Comment #3 from Martin Liška --- Started with r11-455-g94f687bd9ae37ece.
[Bug target/95234] [11 Regression] 416.gamess Miscompare of exam29.out since r11-455-g94f687bd9ae37ece
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95234 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0 --- Comment #2 from Richard Biener --- Maybe related to the recent avx_fma testsuite fails? (anyone bisected those?)
[Bug target/95235] Failure to properly optimize out register use in bit-twiddling code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95235 Richard Biener changed: What|Removed |Added Target||x86_64-*-* i?86-*-* --- Comment #1 from Richard Biener --- That's indeed odd.