[Bug target/94780] [8/9 Regression] ICE in walk_body at gcc/tree-nested.c:713 since r6-3632-gf6f69fb09c5f81df
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94780 --- Comment #13 from CVS Commits --- The releases/gcc-10 branch has been updated by Xi Ruoyao : https://gcc.gnu.org/g:613e4ebc9c6a156f9efc656a2f2620ab22fc6b52 commit r10-10016-g613e4ebc9c6a156f9efc656a2f2620ab22fc6b52 Author: Xi Ruoyao Date: Fri Jul 30 23:44:14 2021 +0800 mips: Fix up mips_atomic_assign_expand_fenv [PR94780] Commit message shamelessly copied from 1777beb6b129 by jakub: This function, because it is sometimes called even outside of function bodies, uses create_tmp_var_raw rather than create_tmp_var. But in order for that to work, when first referenced, the VAR_DECLs need to appear in a TARGET_EXPR so that during gimplification the var gets the right DECL_CONTEXT and is added to local decls. gcc/ PR target/94780 * config/mips/mips.c (mips_atomic_assign_expand_fenv): Use TARGET_EXPR instead of MODIFY_EXPR. (cherry picked from commit 2065654435e3d97676366f82b939bc9273382dbe)
[Bug tree-optimization/83234] Aggressive loop optim warning for loop iteration that cannot happen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83234 Matthijs van Duin changed: What|Removed |Added CC||matthijsvanduin at gmail dot com --- Comment #2 from Matthijs van Duin --- Probably same as bug 100801 ?
[Bug tree-optimization/100801] Aggressive loop optimizations cause incorrect warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100801
Matthijs van Duin changed:
What|Removed |Added
CC||matthijsvanduin at gmail dot
com
--- Comment #3 from Matthijs van Duin ---
Simpler testcase:
/* compiler flags required to trigger warning: -O1 -ftree-vrp */
static void foo(int *x, long n)
{
long i = 0;
for (; i + 4 <= n; i += 4) {
}
for (; i < n; i++) {
x[i]++;
}
}
void bar(int *x)
{
foo(x, 128);
}
A workaround with no runtime overhead is adding the following check between the
loops:
if (__builtin_constant_p(n % 4 == 0) && n % 4 == 0)
return;
[Bug c/101702] New: [12 Regression] ICE: in handle_argspec_attribute, at c-family/c-attribs.c:3623
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101702
Bug ID: 101702
Summary: [12 Regression] ICE: in handle_argspec_attribute, at
c-family/c-attribs.c:3623
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anbu1024.me at gmail dot com
Target Milestone: ---
$ cat 44.c
double foo(double x[!__builtin_copysignf(~2, 3)]);
double bar(double x)
{
return foo(x);
}
$ gcc-sp12 --version
gcc (GCC) 12.0.0 20210718 (experimental)
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc-sp12 44.c
44.c:2:1: internal compiler error: in handle_argspec_attribute, at
c-family/c-attribs.c:3623
2 | double foo(double x[!__builtin_copysignf(~2, 3)]);
| ^~
0x69526e handle_argspec_attribute
../../gcc-12-20210718/gcc/c-family/c-attribs.c:3623
0x873fcc decl_attributes(tree_node**, tree_node*, int, tree_node*)
../../gcc-12-20210718/gcc/attribs.c:720
0x891fc2 push_parm_decl(c_parm const*, tree_node**)
../../gcc-12-20210718/gcc/c/c-decl.c:5903
0x8e9a39 c_parser_parms_list_declarator
../../gcc-12-20210718/gcc/c/c-parser.c:4291
0x8e9d88 c_parser_parms_declarator
../../gcc-12-20210718/gcc/c/c-parser.c:4217
0x8e1e48 c_parser_direct_declarator_inner
../../gcc-12-20210718/gcc/c/c-parser.c:4130
0x8ee858 c_parser_declaration_or_fndef
../../gcc-12-20210718/gcc/c/c-parser.c:2148
0x8f7773 c_parser_external_declaration
../../gcc-12-20210718/gcc/c/c-parser.c:1777
0x8f81b9 c_parser_translation_unit
../../gcc-12-20210718/gcc/c/c-parser.c:1650
0x8f81b9 c_parse_file()
../../gcc-12-20210718/gcc/c/c-parser.c:22121
0x957cbd c_common_parse_file()
../../gcc-12-20210718/gcc/c-family/c-opts.c:1223
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug middle-end/101674] gcc.dg/uninit-pred-9_b.c fails after jump threading rewrite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101674 --- Comment #4 from CVS Commits --- The master branch has been updated by Hans-Peter Nilsson : https://gcc.gnu.org/g:309ddde04f2335f51062690328f03ce889be7e22 commit r12-2647-g309ddde04f2335f51062690328f03ce889be7e22 Author: Hans-Peter Nilsson Date: Sat Jul 31 01:23:20 2021 +0200 gcc.dg/uninit-pred-9_b.c: Xfail for MMIX too Looks like MMIX is the "correct target" too (cf. 2f6bdd51cfe15) and from https://gcc.gnu.org/pipermail/gcc-testresults/2021-July/710188.html it seems powerpc-ibm-aix7.2.3.0 is too, but I've not found other targets failing. gcc/testsuite: PR middle-end/101674 * gcc.dg/uninit-pred-9_b.c: Xfail for mmix-*-* too.
[Bug tree-optimization/101701] GCC optimization and code generation for if-else chains vs ternary chains vs a switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101701 --- Comment #4 from Jeremy R. --- I see with gcc x86_64 it does get the fold correct if another term (val == 5) is added to the if-else chain: https://godbolt.org/z/TE15Wf1bo.
[Bug tree-optimization/101701] GCC optimization and code generation for if-else chains vs ternary chains vs a switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101701 Andrew Pinski changed: What|Removed |Added Depends on||94566 --- Comment #3 from Andrew Pinski --- Oh yes PR 94566. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94566 [Bug 94566] conversion between std::strong_ordering and int
[Bug tree-optimization/101701] GCC optimization and code generation for if-else chains vs ternary chains vs a switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101701 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-07-30 Status|UNCONFIRMED |NEW Severity|normal |enhancement --- Comment #2 from Andrew Pinski --- So the problem here is iftoswitch should ignore if it is profitable to convert the ifs to a switch statement (unless there are only two ifs) and then allow the switchlower pass to lower the switch again. I thought there was a bug about this already too. What is interesting is that the cost for ifs are so high on arm target (compared to a switch), we end up with the best code already: foo(int): subsr3, r0, #1 cmp r3, #3 it hi movhi r0, #-1 bx lr bar(int): subsr3, r0, #1 cmp r3, #3 it hi movhi r0, #-1 bx lr baz(int): subsr3, r0, #1 cmp r3, #4 it cs movcs r0, #-1 bx lr :) So x86 we get: ;; Canonical GIMPLE case clusters: 1 2 3 4 For foo and then for bar: ;; Canonical GIMPLE case clusters: 1 2 3 4 ;; BT can be built: BT(values:4 comparisons:8 range:4 density: 200.00%):1-4 /app/example.cpp:10:21: optimized: Condition chain with 4 BBs transformed into a switch statement.
[Bug tree-optimization/101701] GCC optimization and code generation for if-else chains vs ternary chains vs a switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101701
--- Comment #1 from Andrew Pinski ---
int foo(int val) {
if (val == 1) return val;
else if(val == 2) return val;
else if(val == 3) return val;
else if(val == 4) return val;
else return -1;
}
int bar(int val) {
return val == 1 ? val :
(val == 2 ? val :
(val == 3 ? val :
(val == 4 ? val : -1)));
}
int baz(int val) {
switch(val) {
case 1:
case 2:
case 3:
case 4:
return val;
default:
return -1;
}
}
[Bug c++/101701] New: GCC optimization and code generation for if-else chains vs ternary chains vs a switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101701 Bug ID: 101701 Summary: GCC optimization and code generation for if-else chains vs ternary chains vs a switch Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: llvm at rifkin dot dev Target Milestone: --- I'm looking at an example of three equivalent functions implemented with if-else chains, ternary chains, and a switch. Gcc is not compiling them equivalently: https://godbolt.org/z/8cjGr7M7W. For the if-else chain, gcc does not optimize away the jumps. For the ternary chain, gcc does its codegen well. For the switch, gcc also does its codegen well but there is an extra mov instruction compared to the ternary chain. I don't think it's idealistic to say these should compile equivalently - if someone told me to prefer one over the other for performance reasons I'd dismiss it as a micro-optimization. Clang does not do this perfectly either at the moment. This bug is probably miscategorized. I am not sure the correct category for it.
[Bug tree-optimization/57858] AVX2: ymm used for div, not for sqrt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57858 --- Comment #8 from Andrew Pinski --- (In reply to Richard Biener from comment #7) > It was fixed by adding another loop header copying pass before > vectorization, aka ch_vect. But that went in way in GCC 6 (r6-1951) but the loop header copying was not happening until GCC 8.
[Bug c++/101689] ICE with -fvtable-verify=std and -fnon-call-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101689
Andrew Pinski changed:
What|Removed |Added
Summary|Internal compiler error |ICE with
|during GIMPLE pass: |-fvtable-verify=std and
|ehcleanup |-fnon-call-exceptions
Ever confirmed|0 |1
Last reconfirmed||2021-07-30
Status|UNCONFIRMED |NEW
Keywords||ice-on-valid-code
--- Comment #6 from Andrew Pinski ---
Confirmed, this has been a bug since -fvtable-verify=std was introduced.
ICE with checking turned on:
: In member function 'virtual void A::foo(int)':
:2:16: error: statement marked for throw in middle of block
2 | virtual void foo (int x) { C e(, ); bar (); }
|^~~
# VUSE <.MEM_8>
_9 = this_6(D)->_vptr.A;
during GIMPLE pass: vtable-verify
[Bug tree-optimization/96921] Failure to optimize combined boolean not patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96921 --- Comment #7 from Andrew Pinski --- (In reply to Andrew Pinski from comment #4) > Hmm, thinking about expanding this further: I am going to handle the non-special (bool) case as PR 101610.
[Bug tree-optimization/101610] CST - (x ^ (CST-1)) can be optimized to x + 1 if x < CST and CST is a power of 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101610
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> So looking at this one (and one which I just assigned myself):
> unsigned long f(unsigned long x)
> {
> if (x >= 64)__builtin_unreachable();
> x = x ^ 63;
> unsigned long y = x; ;; Range is still [0,63]
> unsigned long z = 64 - y; ;; is similar to (63 - y) +1 -> (y ^ 63) + 1 -> x
> + 1
> return z;
> }
>
> So mine:
>
> Something like:
> (simplify
> (minus INTEGER_CST@0 SSA_NAME@1)
> (if (exact_power2(@0) && get_nonzero_bits(@1) == (@0 - 1)
> (add (bit_xor! @1 @0) {build_one_cst (type); }))
But I don't think this should be done at the gimple level unless we have a
place were we decide it should be considered "lowered gimple".
I will be doing a simplify-rtx.c patch for this case which should get some code
generation improvement but not with the original case as we need to export the
non-zero bits down from gimple to RTL still (though I hear someone is working
on keeping around the non-zero bits around through out the whole RTL phase).
[Bug d/101691] d: Use of LOOP_EXPR prevents removing no-op loops.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101691 --- Comment #2 from Andrew Pinski --- LOOP_EXPR has nothing to do with this problem really.
[Bug d/101691] d: Use of LOOP_EXPR prevents removing no-op loops.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101691 --- Comment #1 from Andrew Pinski --- cannot prove finiteness of loop 1 Note the C code you posted is not the same as the D code. Using int is able to optimize away for C++ code but not for C code. The reason why it is able to optimize away for C++ code is because -ffinite-loops is turned on there.
[Bug fortran/101514] ICE: out of memory allocating 18446744073709551600 bytes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101514 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |10.4 --- Comment #7 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-12, and on 11- and 10-branch. Not a regression, so not backporting further. Closing. Thanks for the report!
[Bug fortran/101514] ICE: out of memory allocating 18446744073709551600 bytes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101514 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:fa9729e7d2ee69fa0b18c925aeb3c2750874a05b commit r10-10015-gfa9729e7d2ee69fa0b18c925aeb3c2750874a05b Author: Harald Anlauf Date: Wed Jul 21 18:54:00 2021 +0200 Fortran: ICE, OOM while calculating sizes of derived type array components gcc/fortran/ChangeLog: PR fortran/101514 * target-memory.c (gfc_interpret_derived): Size of array component of derived type can only be computed here for explicit shape. * trans-types.c (gfc_get_nodesc_array_type): Do not dereference NULL pointers. gcc/testsuite/ChangeLog: PR fortran/101514 * gfortran.dg/pr101514.f90: New test. (cherry picked from commit c2b15fe27e6a0e42b108111d51acce69628593b4)
[Bug fortran/101700] New: [Coarrays] segmentation fault calling member function of derived type coarray object on remote image
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101700 Bug ID: 101700 Summary: [Coarrays] segmentation fault calling member function of derived type coarray object on remote image Product: gcc Version: 11.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: harris at sourceryinstitute dot org Target Milestone: --- A segmentation fault occurs at runtime when using a member function of a derived type to access an allocatable member variable on a remote image. That's a lot of words, so it might be easier to explain by example. The following program should print "1, 2, 3" twice. Instead, image 1 prints "1, 2, 3" but images 2+ crash with a segmentation fault. Note that if you replace "mailbox[1]%stuff()" with "mailbox[1]%stuff_" then it works correctly. module container_m type :: container_t integer, allocatable :: stuff_(:) contains procedure :: stuff end type contains function stuff(self) class(container_t), intent(in) :: self integer, allocatable :: stuff(:) stuff = self%stuff_ end function end module program main use container_m type(container_t) :: mailbox[*] if (this_image() == 1) then allocate(mailbox%stuff_(3)) mailbox%stuff_ = [1, 2, 3] end if sync all print *, mailbox[1]%stuff() end program I am using OpenCoarrays 2.9.2 and gfortran 11.1.1: $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/11/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl=/builddir/build/BUILD/gcc-11.1.1-20210531/obj-x86_64-redhat-linux/isl-install --enable-offload-targets=nvptx-none --without-cuda-driver --enable-gnu-indirect-function --enable-cet --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.1.1 20210531 (Red Hat 11.1.1-3) (GCC)
[Bug fortran/101536] ICE in gfc_conv_expr_descriptor, at fortran/trans-array.c:7324
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101536 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |10.4 Resolution|--- |FIXED --- Comment #7 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-12, and on 11- and 10-branch. Not a regression, so not backporting further. Closing. Thanks for the report!
[Bug fortran/101536] ICE in gfc_conv_expr_descriptor, at fortran/trans-array.c:7324
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101536 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:95cda605a8f7e6b54c428b7d2c37b4f2ebe4a8d8 commit r10-10014-g95cda605a8f7e6b54c428b7d2c37b4f2ebe4a8d8 Author: Harald Anlauf Date: Fri Jul 23 21:00:10 2021 +0200 Fortran: extend check for array arguments and reject CLASS array elements. gcc/fortran/ChangeLog: PR fortran/101536 * check.c (array_check): Adjust check for the case of CLASS arrays. gcc/testsuite/ChangeLog: PR fortran/101536 * gfortran.dg/pr101536.f90: New test. (cherry picked from commit e314cfc371d8b2405a1d81e51b90f9fb24b9061f)
[Bug fortran/101699] [Coarrays] deferred-length character inside a derived type coarray cannot be accessed by coindexing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101699 --- Comment #1 from Harris Snyder --- Sorry, I neglected to include gfortran version information: $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/11/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl=/builddir/build/BUILD/gcc-11.1.1-20210531/obj-x86_64-redhat-linux/isl-install --enable-offload-targets=nvptx-none --without-cuda-driver --enable-gnu-indirect-function --enable-cet --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.1.1 20210531 (Red Hat 11.1.1-3) (GCC)
[Bug fortran/101699] New: [Coarrays] deferred-length character inside a derived type coarray cannot be accessed by coindexing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101699 Bug ID: 101699 Summary: [Coarrays] deferred-length character inside a derived type coarray cannot be accessed by coindexing Product: gcc Version: 11.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: harris at sourceryinstitute dot org Target Milestone: --- A deferred-length string inside a derived-type coarray cannot be accessed correctly by coindexing. This is true even if the coindex is the local image... The relevant fact seems to be whether or not coindexing is used. Example: the following program should print "Hello, World!" twice. With -fcoarray=single, it works correctly. When using -fcoarray=lib (OpenCoarrays 2.9.2), the first print statement works but the second one prints an empty string. program main type :: with_character character(len=:), allocatable :: chars end type type(with_character) :: mailbox[*] mailbox%chars = "Hello, World!" print *, mailbox%chars print *, mailbox[this_image()]%chars end program
[Bug c++/96636] ICE in build_value_init_noctor, at cp/init.c:451
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96636 --- Comment #4 from Andrew Pinski --- Should be fixed by https://gcc.gnu.org/pipermail/gcc-patches/2021-July/576431.html which rejects this code.
[Bug c/101682] gcc incorrectly rejects C2x attributes after declaration-specifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101682 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- (In reply to Paul Eggert from comment #5) > PS. It is a bit annoying that one can't do this: > > int f (int) [[nodiscard]]; This appertains to the function type, not the function declaration.
[Bug c++/101698] New: Template type conversion operator from base class preferred over matching overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101698
Bug ID: 101698
Summary: Template type conversion operator from base class
preferred over matching overload
Product: gcc
Version: 11.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ammiera at hotmail dot com
Target Milestone: ---
There are two conversion operators, template and non-templated.
Their return type might match:
virtual operator const std::string&() const;
template operator const T&() const;
If so, when trying to call it, the template is always preferred over
non-template and there's no way to SFINAE out of it:
#include
#include
#include
class Base {
public:
template
operator const T&() const {
std::cout << "use template method" << std::endl;
static T tmp{};
return tmp;
}
virtual operator const std::string&() const {
std::cout << "use overload method" << std::endl;
const static std::string tmp;
return tmp;
}
};
template
class Derive : public Base {
public:
operator const T&() const override {
using Y = std::string;
static_assert(std::is_same::value, "");
std::string static res;
res = Base::operator const Y&();
res = Base::operator const T&();
return res;
}
};
int main() {
Derive a;
const std::string& b = a;
(void)b;
}
Reproduced locally on:
gcc (SUSE Linux) 11.1.1 20210721 [revision
076930b9690ac3564638636f6b13bbb6bc608aea]
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Did a quick bisection via godbolt.org, the last version it's didn't occur is
7.5.
https://gcc.godbolt.org/z/KcbK9vv5z
[Bug c/101682] gcc incorrectly rejects C2x attributes after declaration-specifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101682 Paul Eggert changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Paul Eggert --- Thanks for the clarification, Joseph. I'll fix Gnulib accordingly. Marking the bug as RESOLVED INVALID. FWIW the comment 2 code works even with bleeding-edge clang because __has_c_attribute (nodiscard) is still 0 in there. PS. It is a bit annoying that one can't do this: int f (int) [[nodiscard]]; as that would match the existing Gnulib style of putting attributes at the end of the function declarations. I don't know whether such a thing could be added as a GCC extension, but I suppose it's not worth the trouble since it wouldn't be portable as per draft C2x.
[Bug target/101697] [11/12 regression] ICE compiling uClibc-ng for h8300-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101697 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.3 Keywords||ice-on-valid-code
[Bug target/101697] New: [11/12 regression] ICE compiling uClibc-ng for h8300-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101697
Bug ID: 101697
Summary: [11/12 regression] ICE compiling uClibc-ng for
h8300-linux
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: mikpelinux at gmail dot com
Target Milestone: ---
Created attachment 51226
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51226=edit
pre-processed source of uClibc's getaddrinfo.c
Attempting to build uClibc-ng-1.0.38 with a gcc-11.2.0 cross to
h8300-unknown-linux-uclibc fails with an ICE:
libc/inet/getaddrinfo.c: In function 'gaih_inet':
libc/inet/getaddrinfo.c:801:1: error: unrecognizable insn:
801 | }
| ^
(insn 1444 1443 164 31 (parallel [
(set (mem/f:SI (pre_dec:SI (reg/f:SI 7 sp)) [3 S4 A32])
(reg/f:SI 7 sp))
(clobber (reg:CC 12 cc))
]) "libc/inet/getaddrinfo.c":466:11 -1
(expr_list:REG_ARGS_SIZE (const_int 4 [0x4])
(nil)))
during RTL pass: split2
libc/inet/getaddrinfo.c:801:1: internal compiler error: in extract_insn, at
recog.c:2770
0x41a6f0 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/mnt/scratch/cross/sources/gcc-11.2.0/gcc/rtl-error.c:108
0x41a70c _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/mnt/scratch/cross/sources/gcc-11.2.0/gcc/rtl-error.c:116
0x4199e8 extract_insn(rtx_insn*)
/mnt/scratch/cross/sources/gcc-11.2.0/gcc/recog.c:2770
0x8cf1c4 extract_insn_cached(rtx_insn*)
/mnt/scratch/cross/sources/gcc-11.2.0/gcc/recog.c:2659
0x67c782 cleanup_subreg_operands(rtx_insn*)
/mnt/scratch/cross/sources/gcc-11.2.0/gcc/final.c:3330
0x8cd42f split_insn
/mnt/scratch/cross/sources/gcc-11.2.0/gcc/recog.c:3399
0x8d2407 split_all_insns()
/mnt/scratch/cross/sources/gcc-11.2.0/gcc/recog.c:3467
0x8d2498 execute
/mnt/scratch/cross/sources/gcc-11.2.0/gcc/recog.c:4385
A gcc-12 cross also ICEs on the same location, but with a different message:
libc/inet/getaddrinfo.c: In function 'gaih_inet':
libc/inet/getaddrinfo.c:801:1: error: could not split insn
801 | }
| ^
(insn 163 1443 1444 (set (mem/f:SI (pre_dec:SI (reg/f:SI 7 sp)) [3 S4 A32])
(reg/f:SI 7 sp)) "libc/inet/getaddrinfo.c":466:11 19 {*movsi}
(expr_list:REG_ARGS_SIZE (const_int 4 [0x4])
(nil)))
during RTL pass: final
libc/inet/getaddrinfo.c:801:1: internal compiler error: in final_scan_insn_1,
at final.c:2861
0x41abf2 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/mnt/scratch/cross/sources/gcc-12-20210725/gcc/rtl-error.c:108
0x40ded8 final_scan_insn_1
/mnt/scratch/cross/sources/gcc-12-20210725/gcc/final.c:2861
0x687d9b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/mnt/scratch/cross/sources/gcc-12-20210725/gcc/final.c:2940
0x688064 final_1
/mnt/scratch/cross/sources/gcc-12-20210725/gcc/final.c:1997
0x688842 rest_of_handle_final
/mnt/scratch/cross/sources/gcc-12-20210725/gcc/final.c:4285
0x688842 execute,
/mnt/scratch/cross/sources/gcc-12-20210725/gcc/final.c:4363
gcc-10.3.0 has no problems building uClibc-1.0.38 for the h8300.
Attaching the preprocessed getaddrinfo.i. Compile with -fno-builtin and -Os,
-O2, or -O3 to trigger the ICE. Removing -fno-builtin or reducing optimization
to -Og, -O1, or -O0 stops the ICE.
The cross-compilers were configured (yes there's some redundancies there):
--target=h8300-unknown-linux-uclibc --build=x86_64-pc-linux-gnu
--prefix=/mnt/scratch/cross/cross-h8300
--with-sysroot=/mnt/scratch/cross/cross-h8300
--with-gmp=/mnt/scratch/cross/host-tools/gmp-6.2.1
--with-mpfr=/mnt/scratch/cross/host-tools/mpfr-4.1.0
--with-mpc=/mnt/scratch/cross/host-tools/mpc-1.2.1 --without-cloog
--without-isl --disable-libatomic --disable-libgomp --disable-libitm
--disable-libmpx --disable-libmudflap --disable-libquadmath
--disable-libsanitizer --disable-lto --disable-nls --disable-plugin
--disable-shared --enable-checking=release --enable-languages=c
--enable-multilib --disable-threads --disable-libssp
[Bug target/101132] [11/12 regression] [MIPS/MSA] internal compiler error: in do_store_flag, at expr.c:12541
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101132 Xi Ruoyao changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Xi Ruoyao --- Fixed for trunk and releases/gcc-11.
[Bug c++/71003] __extension__ silences pedwarn for "\e" in C but not in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71003 --- Comment #6 from Eric Gallager --- The issue of __extension__ not working with the preprocessor came up again here: https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575414.html
[Bug middle-end/101671] pr83510 fails with -Os because threader confuses -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101671 --- Comment #3 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:0b3560d3a9f2b55ba4807f2b0f8cbbf6cee9e6e3 commit r12-2634-g0b3560d3a9f2b55ba4807f2b0f8cbbf6cee9e6e3 Author: Martin Sebor Date: Fri Jul 30 11:41:02 2021 -0600 Move failed part of a test to a new file [PR101671] Related: PR middle-end/101671 - pr83510 fails with -Os because threader confuses -Warray-bounds gcc/testsuite: PR middle-end/101671 * gcc.c-torture/compile/pr83510.c: Move test functions... * gcc.dg/Warray-bounds-87.c: ...to this file.
[Bug testsuite/101517] Some testcases were lost when tree-ssa was merged
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101517 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Andrew Pinski --- Fixed.
[Bug middle-end/90773] Improve piecewise operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90773 --- Comment #9 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:e5e164effa30fd2b5c5bc3e6883d63889e96d8da commit r12-2633-ge5e164effa30fd2b5c5bc3e6883d63889e96d8da Author: H.J. Lu Date: Sun Mar 6 06:38:21 2016 -0800 Add QI vector mode support to by-pieces for memset 1. Replace scalar_int_mode with fixed_size_mode in the by-pieces infrastructure to allow non-integer mode. 2. Rename widest_int_mode_for_size to widest_fixed_size_mode_for_size to return QI vector mode for memset. 3. Add op_by_pieces_d::smallest_fixed_size_mode_for_size to return the smallest integer or QI vector mode. 4. Remove clear_by_pieces_1 and use builtin_memset_read_str in clear_by_pieces to support vector mode broadcast. 5. Add lowpart_subreg_regno, a wrapper around simplify_subreg_regno that uses subreg_lowpart_offset (mode, prev_mode) as the offset. 6. Add TARGET_GEN_MEMSET_SCRATCH_RTX to allow the backend to use a hard scratch register to avoid stack realignment when expanding memset. gcc/ PR middle-end/90773 * builtins.c (builtin_memcpy_read_str): Change the mode argument from scalar_int_mode to fixed_size_mode. (builtin_strncpy_read_str): Likewise. (gen_memset_value_from_prev): New function. (builtin_memset_read_str): Change the mode argument from scalar_int_mode to fixed_size_mode. Use gen_memset_value_from_prev and support CONST_VECTOR. (builtin_memset_gen_str): Likewise. (try_store_by_multiple_pieces): Use by_pieces_constfn to declare constfun. * builtins.h (builtin_strncpy_read_str): Replace scalar_int_mode with fixed_size_mode. (builtin_memset_read_str): Likewise. * expr.c (widest_int_mode_for_size): Renamed to ... (widest_fixed_size_mode_for_size): Add a bool argument to indicate if QI vector mode can be used. (by_pieces_ninsns): Call widest_fixed_size_mode_for_size instead of widest_int_mode_for_size. (pieces_addr::adjust): Change the mode argument from scalar_int_mode to fixed_size_mode. (op_by_pieces_d): Make m_len read-only. Add a bool member, m_qi_vector_mode, to indicate that QI vector mode can be used. (op_by_pieces_d::op_by_pieces_d): Add a bool argument to initialize m_qi_vector_mode. Call widest_fixed_size_mode_for_size instead of widest_int_mode_for_size. (op_by_pieces_d::get_usable_mode): Change the mode argument from scalar_int_mode to fixed_size_mode. Call widest_fixed_size_mode_for_size instead of widest_int_mode_for_size. (op_by_pieces_d::smallest_fixed_size_mode_for_size): New member function to return the smallest integer or QI vector mode. (op_by_pieces_d::run): Call widest_fixed_size_mode_for_size instead of widest_int_mode_for_size. Call smallest_fixed_size_mode_for_size instead of smallest_int_mode_for_size. (store_by_pieces_d::store_by_pieces_d): Add a bool argument to indicate that QI vector mode can be used and pass it to op_by_pieces_d::op_by_pieces_d. (can_store_by_pieces): Call widest_fixed_size_mode_for_size instead of widest_int_mode_for_size. Pass memsetp to widest_fixed_size_mode_for_size to support QI vector mode. Allow all CONST_VECTORs for memset if vec_duplicate is supported. (store_by_pieces): Pass memsetp to store_by_pieces_d::store_by_pieces_d. (clear_by_pieces_1): Removed. (clear_by_pieces): Replace clear_by_pieces_1 with builtin_memset_read_str and pass true to store_by_pieces_d to support vector mode broadcast. (string_cst_read_str): Change the mode argument from scalar_int_mode to fixed_size_mode. * expr.h (by_pieces_constfn): Change scalar_int_mode to fixed_size_mode. (by_pieces_prev): Likewise. * rtl.h (lowpart_subreg_regno): New. * rtlanal.c (lowpart_subreg_regno): New. A wrapper around simplify_subreg_regno. * target.def (gen_memset_scratch_rtx): New hook. * doc/tm.texi.in: Add TARGET_GEN_MEMSET_SCRATCH_RTX. * doc/tm.texi: Regenerated. gcc/testsuite/ * gcc.target/i386/pr100865-3.c: Expect vmovdqu8 instead of vmovdqu. * gcc.target/i386/pr100865-4b.c: Likewise.
[Bug testsuite/101517] Some testcases were lost when tree-ssa was merged
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101517 --- Comment #4 from CVS Commits --- The master branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:d68d275a00573be49f5e83eba52ce3f26d11db9e commit r12-2632-gd68d275a00573be49f5e83eba52ce3f26d11db9e Author: Andrew Pinski Date: Thu Jul 29 12:56:18 2021 -0700 Add testcases that got lost when tree-ssa was merged So I was looking at some older PRs (PR 16016 in this case), I noticed that some of the testcases were removed when the tree-ssa branch was merged. This adds them back in. OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. Thanks, Andrew Pinski gcc/testsuite/ChangeLog: PR testsuite/101517 * g++.dg/warn/Wunused-18.C: New test. * gcc.c-torture/compile/20030405-2.c: New test. * gcc.c-torture/compile/20040304-2.c: New test. * gcc.dg/20030612-2.c: New test.
[Bug libstdc++/65018] Use secure_getenv when available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65018 --- Comment #5 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:3dbd4d94bf380f3efa8bba9b203ce7d4c8f47fbb commit r12-2631-g3dbd4d94bf380f3efa8bba9b203ce7d4c8f47fbb Author: Jonathan Wakely Date: Fri Jul 30 13:56:14 2021 +0100 libstdc++: Use secure_getenv for filesystem::temp_directory_path() [PR65018] This adds a configure check for the GNU extension secure_getenv and then uses it for looking up TMPDIR and similar variables. Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/65018 * configure.ac: Check for secure_getenv. * config.h.in: Regenerate. * configure: Regenerate. * src/filesystem/ops-common.h (get_temp_directory_from_env): New helper function to obtain path from the environment. * src/c++17/fs_ops.cc (fs::temp_directory_path): Use new helper. * src/filesystem/ops.cc (fs::temp_directory_path): Likewise. * testsuite/27_io/filesystem/operations/temp_directory_path.cc: Print messages if test cannot be run. * testsuite/experimental/filesystem/operations/temp_directory_path.cc: Likewise. Fix incorrect condition. Use "TMP" to work with Windows as well as POSIX.
[Bug target/94780] [8/9 Regression] ICE in walk_body at gcc/tree-nested.c:713 since r6-3632-gf6f69fb09c5f81df
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94780 --- Comment #12 from CVS Commits --- The master branch has been updated by Xi Ruoyao : https://gcc.gnu.org/g:2065654435e3d97676366f82b939bc9273382dbe commit r12-2630-g2065654435e3d97676366f82b939bc9273382dbe Author: Xi Ruoyao Date: Fri Jul 30 23:44:14 2021 +0800 mips: Fix up mips_atomic_assign_expand_fenv [PR94780] Commit message shamelessly copied from 1777beb6b129 by jakub: This function, because it is sometimes called even outside of function bodies, uses create_tmp_var_raw rather than create_tmp_var. But in order for that to work, when first referenced, the VAR_DECLs need to appear in a TARGET_EXPR so that during gimplification the var gets the right DECL_CONTEXT and is added to local decls. gcc/ PR target/94780 * config/mips/mips.c (mips_atomic_assign_expand_fenv): Use TARGET_EXPR instead of MODIFY_EXPR.
[Bug target/101132] [11/12 regression] [MIPS/MSA] internal compiler error: in do_store_flag, at expr.c:12541
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101132 --- Comment #10 from CVS Commits --- The master branch has been updated by Xi Ruoyao : https://gcc.gnu.org/g:45cb789e6adf5d571c574a94b77413c845fed106 commit r12-2629-g45cb789e6adf5d571c574a94b77413c845fed106 Author: Xi Ruoyao Date: Sun Jun 20 15:21:39 2021 +0800 mips: add MSA vec_cmp and vec_cmpu expand pattern [PR101132] Middle-end started to emit vec_cmp and vec_cmpu since GCC 11, causing ICE on MIPS with MSA enabled. Add the pattern to prevent it. gcc/ PR target/101132 * config/mips/mips-protos.h (mips_expand_vec_cmp_expr): Declare. * config/mips/mips.c (mips_expand_vec_cmp_expr): New function. * config/mips/mips-msa.md (vec_cmp): New expander. (vec_cmpu): New expander. gcc/testsuite/ PR target/101132 * gcc.target/mips/pr101132.c: New test.
[Bug c++/101539] [C++20] Implement builtins for layout-compatibility and pointer-interconvertibility traits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101539
--- Comment #7 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:6cd005a255f15c1b4b3eaae71c844ea2592c9dce
commit r12-2628-g6cd005a255f15c1b4b3eaae71c844ea2592c9dce
Author: Jakub Jelinek
Date: Fri Jul 30 18:38:41 2021 +0200
c++: Implement P0466R5 __cpp_lib_is_pointer_interconvertible compiler
helpers [PR101539]
The following patch attempts to implement the compiler helpers for
libstdc++ std::is_pointer_interconvertible_base_of trait and
std::is_pointer_interconvertible_with_class template function.
For the former __is_pointer_interconvertible_base_of trait that checks
first
whether base and derived aren't non-union class types that are the same
ignoring toplevel cv-qualifiers, otherwise if derived is unambiguously
derived from base without cv-qualifiers, derived being a complete type,
and if so, my limited understanding of any derived object being
pointer-interconvertible with base subobject IMHO implies (because one
can't
inherit from unions or unions can't inherit) that we check if derived is
standard layout type and we walk bases of derived
recursively, stopping on a class that has any non-static data members and
check if any of the bases is base. On class with non-static data members
no bases are compared already.
Upon discussions, this is something that maybe should have been changed
in the standard with CWG 2254 and the patch no longer performs this and
assumes all base subobjects of standard-layout class types are
pointer-interconvertible with the whole class objects.
The latter is implemented using a FE
__builtin_is_pointer_interconvertible_with_class, but because on the
library
side it will be a template function, the builtin takes ... arguments and
only during folding verifies it has a single argument with pointer to
member
type. The initial errors IMHO can only happen if one uses the builtin
incorrectly by hand, the template function should ensure that it has
exactly a single argument that has pointer to member type.
Otherwise, again with my limited understanding of what
the template function should do and pointer-interconvertibility,
it folds to false for pointer-to-member-function, errors if
basetype of the OFFSET_TYPE is incomplete, folds to false
for non-std-layout non-union basetype, then finds the first non-static
data member in the basetype or its bases (by ignoring
DECL_FIELD_IS_BASE FIELD_DECLs that are empty, recursing into
DECL_FIELD_IS_BASE FIELD_DECLs type that are non-empty (I think
std layout should ensure there is at most one), for unions
checks if membertype is same type as any of the union FIELD_DECLs,
for non-unions the first other FIELD_DECL only, and for anonymous
aggregates similarly (union vs. non-union) but recurses into the
anon aggr types with std layout check for anon structures. If
membertype doesn't match the type of first non-static data member
(or for unions any of the members), then the builtin folds to false,
otherwise the built folds to a check whether the argument is equal
to OFFSET_TYPE of 0 or not, either at compile time if it is constant
(e.g. for constexpr folding) or at runtime otherwise.
As I wrote in the PR, I've tried my testcases with MSVC on godbolt
that claims to implement it, and https://godbolt.org/z/3PnjM33vM
for the first testcase shows it disagrees with my expectations on
static_assert (std::is_pointer_interconvertible_base_of_v);
static_assert (std::is_pointer_interconvertible_base_of_v);
static_assert (!std::is_pointer_interconvertible_base_of_v);
static_assert (!std::is_pointer_interconvertible_base_of_v);
static_assert (std::is_pointer_interconvertible_base_of_v);
Is that a bug in my patch or is MSVC buggy on these (or mix thereof)?
https://godbolt.org/z/aYeYnne9d
shows the second testcase, here it differs on:
static_assert (std::is_pointer_interconvertible_with_class
(::b));
static_assert (std::is_pointer_interconvertible_with_class
(::g));
static_assert (std::is_pointer_interconvertible_with_class
(::b));
static_assert (std::is_pointer_interconvertible_with_class (::a));
static_assert (std::is_pointer_interconvertible_with_class (::b));
Again, my bug, MSVC bug, mix thereof?
According to Jason the , case are the subject of the
CWG 2254 above discussed change and the rest are likely MSVC bugs.
Oh, and there is another thing, the standard has an example:
struct A { int a; };// a standard-layout class
struct B { int b; };// a standard-layout class
struct C: public A, public B { }; // not a standard-layout class
static_assert( is_pointer_interconvertible_with_class( ::b ) );
// Succeeds because, despite its
[Bug target/101104] test case gcc.c-torture/execute/ieee/cdivchkld.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101104 --- Comment #3 from Patrick McGehearty --- I meant to say "IF mode" instead of KF mode. Shall I resubmit with that correction? - patrick On 7/20/2021 5:46 PM, segher at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101104 > > Segher Boessenkool changed: > > What|Removed |Added > > CC||segher at gcc dot gnu.org >Component|testsuite |target > > --- Comment #2 from Segher Boessenkool --- > (In reply to Patrick McGehearty from comment #1) >> I identified the root cause as not fully understanding the IBM native >> format. The gcc internal representation uses KF mode for IBM 128-bit >> floating point. > KFmode is IEEE QP float. IFmode is double-double, "IBM extended double", > a pair of DP float numbers (with some rules, not every pair is valid). > > TFmode is one of those. >
[Bug target/100340] Bootstrap fails with Clang 12.0.5 (XCode 12.5)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100340 --- Comment #15 from Iain Sandoe --- (In reply to Chris Jones from comment #14) > Apologies, typo above. I meant to say the --without-build-config workaround > no longer works with 11.2.0 OK.. I plan to do a Darwin/macOS 11.2 patch set this weekend - I'll see what we can do about that (other than rolling back to Xcode 12.4 on X86_64 macOS).
[Bug target/100340] Bootstrap fails with Clang 12.0.5 (XCode 12.5)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100340 --- Comment #14 from Chris Jones --- Apologies, typo above. I meant to say the --without-build-config workaround no longer works with 11.2.0
[Bug target/100340] Bootstrap fails with Clang 12.0.5 (XCode 12.5)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100340 Chris Jones changed: What|Removed |Added CC||jonesc at hep dot phy.cam.ac.uk --- Comment #13 from Chris Jones --- Just to add, the --disable-bootstrap workaround no longer works with the recently released 11.2.0, as it still fails to build due to jit errors. :info:build Bootstrap comparison failure! :info:build gcc/jit/jit-recording.o differs The same build configuration and workaround worked fine with gcc 11.1.0. See https://build.macports.org/builders/ports-11_x86_64-builder/builds/41670/steps/install-port/logs/stdio for a full build log.
[Bug c++/101677] [11/12 Regression] Concept with use of incomplete type succeeds on GCC 10.3.0, fails on GCC 11 onward
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101677 --- Comment #2 from Joe Loser --- (In reply to Andrew Pinski from comment #1) > >This bug can be worked around by using a complete type instead when defining > >the concept. > > It does not even have to be complete type; just defined before. > So adding: > class S; > at the begining causes GCC to accept the code. Yep, you're right. That's actually what I use in my codebase as a workaround. I misspoke in the description -- sorry about that. Updated Godbolt link is at https://godbolt.org/z/KGq48WYq4
[Bug c++/98859] pedantic error on use of __VA_OPT__ before C++20 is unnecessary and counterproductive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98859 Yongwei Wu changed: What|Removed |Added CC||wuyongwei at gmail dot com --- Comment #2 from Yongwei Wu --- Here is anotehr good reason: https://stackoverflow.com/questions/48045470/portably-detect-va-opt-support/48045656 People can detect the presence of __VA_OPT__ support. Currently, the detection code would cause warnings when -std is set to something like "c++17" (though luckily not "gnu++17").
[Bug lto/79062] -Walloca-larger-than and -Wformat-overflow warnings disabled by -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79062
Martin Sebor changed:
What|Removed |Added
Priority|P3 |P2
--- Comment #9 from Martin Sebor ---
The same problem affects _FORTIFY_SOURCE. Since this effectively disables
compile-time buffer overflow detection for the sprintf family of functions I'm
bumping Importance up to P2. (The runtime prevention still works.)
$ (set -x && cat pr79062.c && gcc -D_FORTIFY_SOURCE=2 -O2 -Wall -flto -c
pr79062.c && gcc -D_FORTIFY_SOURCE=2 -O2 -Wall -flto pr79062.o && ./a.out)
+ cat pr79062.c
#include
#include
int main (void)
{
char *d = (char*)alloca (2);
int n = sprintf (d, "%i", 123); // missing warning with -flto
puts (d);
if (n > 1)
abort ();
}
+ gcc -D_FORTIFY_SOURCE=2 -O2 -Wall -flto -c pr79062.c
+ gcc -D_FORTIFY_SOURCE=2 -O2 -Wall -flto pr79062.o
+ ./a.out
*** buffer overflow detected ***: ./a.out terminated
[Bug c/101696] New: Function multiversioning not usable with new x86-64-v*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101696
Bug ID: 101696
Summary: Function multiversioning not usable with new x86-64-v*
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: h2+bugs at fsfe dot org
Target Milestone: ---
I really like the new feature levels, so I have created the respective binaries
for an application. I now want to dispatch to the correct one, so I thought the
easiest thing would be to have a small "arch_detect" program that gives me the
feature level as return value:
__attribute__ ((target ("default")))
int foo ()
{
// The default version of foo.
return 0;
}
__attribute__ ((target ("arch=x86-64")))
int foo ()
{
return 1;
}
__attribute__ ((target ("arch=x86-64-v2")))
int foo ()
{
return 2;
}
__attribute__ ((target ("arch=x86-64-v3")))
int foo ()
{
return 3;
}
__attribute__ ((target ("arch=x86-64-v4")))
int foo ()
{
return 4;
}
int main ()
{
return foo();
}
This builds fine but always returns 0 -- independent of whether I build the
binary without -march or with -march=x86-64-v4.
Curiously, if I add the following overload:
__attribute__ ((target ("sse4.2")))
int foo ()
{
// The default version of foo.
return 7;
}
it will no longer build without -march=x86-64-v4, complaining that "no
dispatcher was found for the versioning attributes". If I add -march=x86-64-v4,
it will build without errors but always return 7 and not the feature level.
What am I missing?
[Bug lto/79062] -Walloca-larger-than and -Wformat-overflow warnings disabled by -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79062
Martin Sebor changed:
What|Removed |Added
Last reconfirmed|2017-01-12 00:00:00 |2021-7-30
Known to fail||10.2.0, 11.2.0, 12.0,
||7.3.0, 8.3.0, 9.2.0
--- Comment #8 from Martin Sebor ---
Reconfirmed with GCC 12 for the missing -Wformat-overflow:
$ (cc='/build/gcc-master/gcc/xgcc -B /build/gcc-master/gcc'; set -x && cat
pr79062.c && $cc -O2 -Wall -flto -c pr79062.c && $cc -O2 -Wall -flto pr79062.o
&& valgrind ./a.out)
+ cat pr79062.c
int main (void)
{
char *d = (char*)__builtin_alloca (2);
int n = __builtin_sprintf (d, "%i", 123); // missing warning with -flto
__builtin_puts (d);
if (n > 1)
__builtin_abort ();
}
+ /build/gcc-master/gcc/xgcc -B /build/gcc-master/gcc -O2 -Wall -flto -c
pr79062.c
+ /build/gcc-master/gcc/xgcc -B /build/gcc-master/gcc -O2 -Wall -flto pr79062.o
+ valgrind ./a.out
==5314== Memcheck, a memory error detector
==5314== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==5314== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==5314== Command: ./a.out
==5314==
123
==5314==
==5314== Process terminating with default action of signal 6 (SIGABRT): dumping
core
==5314==at 0x48A357F: raise (in /usr/lib64/libc-2.28.so)
==5314==by 0x488D894: abort (in /usr/lib64/libc-2.28.so)
==5314==by 0x4010A6: main (in /ssd/build/tmp/a.out)
==5314==
==5314== HEAP SUMMARY:
==5314== in use at exit: 0 bytes in 0 blocks
==5314== total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated
==5314==
==5314== All heap blocks were freed -- no leaks are possible
==5314==
==5314== For lists of detected and suppressed errors, rerun with: -s
==5314== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
[Bug middle-end/101688] g++.dg/warn/Wstringop-overflow-4.C fails on 32-bit archs with new jump threader
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101688 Aldy Hernandez changed: What|Removed |Added CC||seurer at gcc dot gnu.org --- Comment #1 from Aldy Hernandez --- *** Bug 101694 has been marked as a duplicate of this bug. ***
[Bug other/101694] [12 regression] g++.dg/warn/Wstringop-overflow-4.C fails after r12-2591 for 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101694 Aldy Hernandez changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Aldy Hernandez --- Duplicate. *** This bug has been marked as a duplicate of bug 101688 ***
[Bug c++/101695] New: calling incorrect destructor of same-name class in anonymous namespaces in separate translation units
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101695 Bug ID: 101695 Summary: calling incorrect destructor of same-name class in anonymous namespaces in separate translation units Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tom_maly at volny dot cz Target Milestone: --- Created attachment 51225 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51225=edit commit 079009b17cac42fb7c46adcee6055b4776b1360f I have two cpp files, each with anonymous namespace with a class with same name. I store member function pointer to method that call the destructor. Destructor from same translation unit is used in both cases. Tested with g++ 9, 10, and 11 - all incorrect. Also tested with clang 10 and msvc - both correct. All source code to reproduce the bug (in addition to the attached archive) is available at: https://github.com/malytomas/gppBugAnonDestr The github actions show results for all mentioned compilers. More detailed info: At least two translation units are required to separate the anonymous namespaces. Example command line used for compilation: /usr/bin/g++-11 -Wall -Wextra -g -std=gnu++17 -MD -MT CMakeFiles/gppBugAnonDestr.dir/sources/aaa.cpp.o -MF CMakeFiles/gppBugAnonDestr.dir/sources/aaa.cpp.o.d -o CMakeFiles/gppBugAnonDestr.dir/sources/aaa.cpp.o -c /home/runner/work/gppBugAnonDestr/gppBugAnonDestr/sources/aaa.cpp Example g++ version: g++-11 (Ubuntu 11.1.0-1ubuntu1~20.04) 11.1.0 In the test code, a counter is used to detect which constructors/destructors are called and an exception is thrown when number of constructors does not match number of destructors. Structure MemoryArena is used to create and destroy the Tester structures. I could not reproduce the bug without it (using just free functions). The struct Holder is very simplified std::unique_ptr. Struct Delegate is simpler std::function. Simplifying it even further (making it non template) also partially fixes the bug, therefore I keep it as is. Feel free to contact me if you need any further information. Thanks
[Bug tree-optimization/100494] [11/12 Regression] Unterminated recursion in gimple-range.cc (x86_64-w64-mingw32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100494 Andrew Macleod changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #14 from Andrew Macleod --- The call chain is a bit less deep in GCC 12 now, but I doubt it can still operate with a stack as small as the original. As there is no un-terminated recursion, I will now close this as I don't plan any additional reductions in the call chain beyond what has been done. Future enhancements may improve it further however.
[Bug c/101682] gcc incorrectly rejects C2x attributes after declaration-specifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101682 --- Comment #4 from joseph at codesourcery dot com --- On Thu, 29 Jul 2021, eggert at gnu dot org via Gcc-bugs wrote: > The grammar at the start of section 6.7 of the current C2x draft (N2596) says > that attribute specifiers may appear either before or after declaration > specifiers. Unfortunately, GCC rejects attribution specifiers after > declaration > specifiers. For example, for this this source code: > > extern [[nodiscard]] int f (void); That's not syntactically valid. You can have attribute specifiers before declaration specifiers in a declaration, or at the end of declaration specifiers, but you can't have them in the middle; the syntax productions don't allow it. > extern int [[nodiscard]] g (void); > int [[nodiscard]] h (void); Those violate the constraints on the nodiscard attribute. As per 6.7#8, "The optional attribute specifier sequence terminating a sequence of declaration specifiers appertains to the type determined by the preceding sequence of declaration specifiers.". That is, this syntax is applying the attribute to the type int, but the constraints for nodiscard (6.7.11.2#1) say "The nodiscard attribute shall be applied to the identifier in a function declaration or to the definition of a structure, union, or enumeration type.". To apply the nodiscard attribute to a function, either place it before the declaration specifiers (in which case it applies to all declared entities in that declaration, so don't so that if you have multiple declarators in the declaration but only want nodiscard to apply to some of them), or after the identifier in the declarator.
[Bug other/101694] New: [12 regression] g++.dg/warn/Wstringop-overflow-4.C fails after r12-2591 for 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101694
Bug ID: 101694
Summary: [12 regression] g++.dg/warn/Wstringop-overflow-4.C
fails after r12-2591 for 32 bits
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: seurer at gcc dot gnu.org
Target Milestone: ---
g:2e96b5f14e4025691b57d2301d71aa6092ed44bc, r12-2591
make -k check-gcc RUNTESTFLAGS="--target_board=unix'{-m32}'
dg.exp=g++.dg/warn/Wstringop-overflow-4.C"
FAIL: g++.dg/warn/Wstringop-overflow-4.C -std=gnu++98 (test for excess errors)
FAIL: g++.dg/warn/Wstringop-overflow-4.C -std=gnu++14 (test for excess errors)
FAIL: g++.dg/warn/Wstringop-overflow-4.C -std=gnu++17 (test for excess errors)
FAIL: g++.dg/warn/Wstringop-overflow-4.C -std=gnu++2a (test for excess errors)
# of expected passes56
# of unexpected failures4
This appears to be a 32 bit only problem.
spawn -ignore SIGHUP
/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C
-m64 -fdiagnostics-plain-output -nostdinc++
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/backward
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/util -fmessage-length=0
-std=gnu++2a -O2 -Wall -Wno-array-bounds -ftrack-macro-expansion=0 -S -o
Wstringop-overflow-4.s
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C:
In function 'void test_strcpy_new_char(size_t)':
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C:32:3:
warning: 'void* __builtin_memcpy(void*, const void*, long unsigned int)'
writing 2 bytes into a region of size between 0 and 1 [-Wstringop-overflow=]
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C:32:3:
note: destination object of size [0, 1] allocated by 'operator new []'
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C:36:3:
warning: 'void* __builtin_memcpy(void*, const void*, long unsigned int)'
writing 3 bytes into a region of size between 1 and 2 [-Wstringop-overflow=]
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C:36:3:
note: destination object of size [1, 2] allocated by 'operator new []'
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C:40:3:
warning: 'void* __builtin_memcpy(void*, const void*, long unsigned int)'
writing 4 bytes into a region of size between 2 and 3 [-Wstringop-overflow=]
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C:40:3:
note: destination object of size [2, 3] allocated by 'operator new []'
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C:41:3:
warning: 'void* __builtin_memcpy(void*, const void*, long unsigned int)'
writing 10 bytes into a region of size between 2 and 3 [-Wstringop-overflow=]
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C:41:3:
note: destination object of size [2, 3] allocated by 'operator new []'
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C:
In function 'void test_strcpy_new_char_array(size_t)':
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C:81:3:
warning: 'void* __builtin_memcpy(void*, const void*, long unsigned int)'
writing 2 bytes into a region of size between 0 and 1 [-Wstringop-overflow=]
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C:81:3:
note: destination object of size [0, 1] allocated by 'operator new []'
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C:83:3:
warning: 'void* __builtin_memcpy(void*, const void*, long unsigned int)'
writing 3 bytes into a region of size between 0 and 2 [-Wstringop-overflow=]
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C:83:3:
note: destination object of size [0, 2] allocated by 'operator new []'
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C:86:3:
warning: 'void* __builtin_memcpy(void*, const void*, long unsigned int)'
writing 1 byte into a region of size 0 [-Wstringop-overflow=]
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C:86:3:
note: destination object of size 0 allocated by 'operator new []'
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C:89:3:
warning: 'void* __builtin_memcpy(void*, const void*, long unsigned int)'
writing 3 bytes into
[Bug rtl-optimization/101693] Terrible SIMD register allocation with a tight loop operating on 8 registers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101693 --- Comment #1 from Tomasz Sobczyk --- PS. when #define USE_VNNI is commented out it exhibits similar behaviour to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80283
[Bug rtl-optimization/101693] New: Terrible SIMD register allocation with a tight loop operating on 8 registers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101693 Bug ID: 101693 Summary: Terrible SIMD register allocation with a tight loop operating on 8 registers. Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ts.tomeksopel at gmail dot com Target Milestone: --- There are a few issues regarding unnecessary register spilling, but this also exhibits a lot of unnecessary juggling between registers. See https://godbolt.org/z/da76fY1n7 and https://www.reddit.com/r/cpp_questions/comments/oui5tc/simd_what_to_do_when_your_compiler_forgets_how_to/ The gist is that there's a tight loop, executed a constant number of times (~64 times) where accumulation happens to 8 ymm registers, and only those 8 registers are used from outside of the loop. Before the loop zeros are assinged, and after the loop horizontal addition is performed. GCC generates suboptimal code, whereas clang gets it right. It seems to perform unnecessary movs in a pattern following a -> b -> vpdpbusd to b -> a. All versions on godbolt >=8.1 seem to exhibit the issue, including trunk.
[Bug target/101685] [12 Regression] -march=amdfam10 -mno-lzcnt Defines __LZCNT__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101685 H.J. Lu changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from H.J. Lu --- Fixed.
[Bug target/101685] [12 Regression] -march=amdfam10 -mno-lzcnt Defines __LZCNT__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101685 --- Comment #1 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:854ef6e50acf1b182ddaf007cff2cf60545692b0 commit r12-2624-g854ef6e50acf1b182ddaf007cff2cf60545692b0 Author: H.J. Lu Date: Fri Jul 30 05:58:38 2021 -0700 x86: Don't enable LZCNT/POPCNT if disabled explicitly gcc/ PR target/101685 * config/i386/i386-options.c (ix86_option_override_internal): Don't enable LZCNT/POPCNT if they have been disabled explicitly. gcc/testsuite/ PR target/101685 * gcc.target/i386/pr101685.c: New test.
[Bug libstdc++/65018] Use secure_getenv when available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65018 --- Comment #4 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #0) > From Jakub on IRC: "note that at some point, there used to be > __secure_getenv instead. perhaps look at libgfortran configury what it does > for this" secure_getenv was added to glibc in 2.17, before then only the internal __secure_getenv was provided. But I don't think we need to care too much about pre-2.17 so I'm not going to bother checking for __secure_getenv. The profile mode has been removed from libstdc++, so we don't need to care about those variables now. The others in comment 0 are not a problem. Only the queries for TMPDIR etc need to use secure_getenv. I am testing a patch for that.
[Bug c++/101689] Internal compiler error during GIMPLE pass: ehcleanup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101689
--- Comment #5 from Jakub Jelinek ---
Reduced testcase:
struct A {
virtual void foo (int x) { C e(, ); bar (); }
virtual bool bar ();
struct C { C (int *, int *); };
int f;
};
struct B : A {} d;
[Bug rtl-optimization/101683] Floating point exception for double->unsigned conversion on avx512 only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101683 --- Comment #6 from bartoldeman at users dot sourceforge.net --- "really not many people care about floating point exceptions". I think more people should :) but this is indeed the context. We found this issue on a supercomputer running OpenFOAM (which can enable FP exceptions, see https://cpp.openfoam.org/v3/a02284.html), and a small simple MPI program with FP exceptions enabled. Even then it crashed in an underlying library, and not OpenFOAM itself, see https://github.com/ComputeCanada/software-stack/issues/74 In the end the combination of MPI and FP exceptions easily triggers it, but the vast majority of jobs don't crash, so even on our cluster this is very rare indeed. And many other clusters don't compile the UCX library with avx512 optimizations enabled or use precompiled binaries without those enabled.
[Bug d/101692] New: Program crushes at unpredictable moment of time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101692
Bug ID: 101692
Summary: Program crushes at unpredictable moment of time
Product: gcc
Version: 8.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: zed at lab127 dot karelia.ru
Target Milestone: ---
I am not sure this is really a gdc issue,
but a program behaves very strange -
it works normally for some time, and
then receives SIGSEGV at unpredictable moment
(but always at the same place of code).
Here is code snippet, where the crush occurs
struct EpollEvent
{
align(1):
uint event_mask;
EventSource es; // EventSource is a class
/* just do not want to use that union, epoll_data_t */
}
bool wait()
{
EpollEvent event;
if (done)
return false;
int n = epoll_wait(id, , 1, -1);
if (-1 == n)
return false;
writefln("%s, n = %d", __FUNCTION__, n);
writefln("%s", event); // <<< crashes here
EventSource s = event.es;
ulong ecode = s.eventCode(event.event_mask);
mq.putMsg(null, s.owner, ecode, s);
return true;
}
Crush occurs when program is accessing 'event' variable
after return from epoll_wait().
And it does not depend on the type of this variable -
I tried dynamic array EpollEvent[], static array EpollEvent[MAX],
no matter, after some period of normal functioning
program gets SIGSEGV at the indicated line.
gdb says the following:
Core was generated by `./echod'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x7f312ed79380 in ?? ()
(gdb) bt
#0 0x7f312ed79380 in ?? ()
#1 0x555f33107071 in
std.format.formatObject!(std.stdio.File.LockingTextWriter, esrc.EventSource,
char).formatObject(ref std.stdio.File.LockingTextWriter, ref esrc.EventSource,
ref const(std.format.FormatSpec!(char).FormatSpec)) (w=...,
val=@0x7ffec19ab610: 0x7f312edb6300, f=...)
at /usr/lib/gcc/x86_64-linux-gnu/8/include/d/std/format.d:3353
#2 0x555f33106fc9 in
std.format.formatValue!(std.stdio.File.LockingTextWriter, esrc.EventSource,
char).formatValue(ref std.stdio.File.LockingTextWriter, esrc.EventSource, ref
const(std.format.FormatSpec!(char).FormatSpec)) (w=..., val=0x7f312edb6300,
f=...)
at /usr/lib/gcc/x86_64-linux-gnu/8/include/d/std/format.d:3450
#3 0x555f33106f39 in
std.format.formatElement!(std.stdio.File.LockingTextWriter, esrc.EventSource,
char).formatElement(ref std.stdio.File.LockingTextWriter, ref esrc.EventSource,
ref const(std.format.FormatSpec!(char).FormatSpec)) (w=...,
val=@0x7ffec19ab6b0: 0x7f312edb6300, f=...)
at /usr/lib/gcc/x86_64-linux-gnu/8/include/d/std/format.d:3180
#4 0x555f3310683a in
std.format.formatValue!(std.stdio.File.LockingTextWriter, ecap.EpollEvent,
char).formatValue(ref std.stdio.File.LockingTextWriter, ref ecap.EpollEvent,
ref const(std.format.FormatSpec!(char).FormatSpec)) (w=..., val=..., f=...)
at /usr/lib/gcc/x86_64-linux-gnu/8/include/d/std/format.d:3702
#5 0x555f3310634b in
std.format.formattedWrite!(std.stdio.File.LockingTextWriter, char,
ecap.EpollEvent).formattedWrite(ref std.stdio.File.LockingTextWriter,
const(char[]), ecap.EpollEvent) (w=..., fmt=..., _param_2=...) at
/usr/lib/gcc/x86_64-linux-gnu/8/include/d/std/format.d:568
#6 0x555f33105dc5 in std.stdio.File.writefln!(char,
ecap.EpollEvent).writefln(const(char[]), ecap.EpollEvent) (this=..., fmt=...,
_param_1=...)
at /usr/lib/gcc/x86_64-linux-gnu/8/include/d/std/stdio.d:1496
#7 0x555f330f49ad in std.stdio.writefln!(char,
ecap.EpollEvent).writefln(const(char[]), ecap.EpollEvent) (fmt=...,
_param_1=...)
at /usr/lib/gcc/x86_64-linux-gnu/8/include/d/std/stdio.d:3797
#8 0x555f330eca63 in ecap.EventQueue.wait() (this=0x7f312ed76000) at
engine/ecap.d:113
#9 0x555f330f472a in D main (args=...) at echod.d:46
engine/ecap.d:113 is that 'writefln("%s", event);'
Also it seemed to me, that crash is more probable when compiling with -Os.
Also 2, i tried dmd instead of gdc - crushes also occurs, but much less
frequently.
gdc --version
gdc (Ubuntu 8.4.0-1ubuntu1~18.04) 8.4.0
(Linux Mint 19.1 actually)
uname -a
Linux HP-Laptop 4.15.0-151-generic #157-Ubuntu SMP Fri Jul 9 23:07:57 UTC 2021
x86_64 x86_64 x86_64 GNU/Linux
[Bug d/101691] New: d: Use of LOOP_EXPR prevents removing no-op loops.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101691
Bug ID: 101691
Summary: d: Use of LOOP_EXPR prevents removing no-op loops.
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
As observed on compiler explorer.
https://d.godbolt.org/z/eM8Pv91eT
The C, C++ (and Fortran?) front-ends lower loops as labels and gotos, which
*is* optimized away.
https://godbolt.org/z/8Yz9oqx63
---
void fun(int a, int b, int step)
{
for (int i = a; i < b; i += step) {
}
}
[Bug middle-end/101690] New: failure to shrink wrap simple loop with more aggressive jump threading
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101690
Bug ID: 101690
Summary: failure to shrink wrap simple loop with more
aggressive jump threading
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: aldyh at gcc dot gnu.org
CC: jeffreyalaw at gmail dot com
Target Milestone: ---
gcc.dg/shrink-wrap-loop.c is failing after the jump threader rewrite. The test
is:
int foo (int *p1, int *p2);
int
test (int *p1, int *p2)
{
int *p;
for (p = p2; p != 0; p++)
{
if (!foo (p, p1))
return 0;
}
return 1;
}
Compile with -O2 -fdump-rtl-pro_and_epilogue.
The dump file is missing "Performing shrink-wrapping".
What happens is that the new threader is threading things a bit too early.
The gist is this BB inside a loop:
:
# p_2 = PHI
if (p_2 != 0B)
goto ; [INV]
else
goto ; [INV]
Our threader can move this check outside of the loop (good). This is
done before branch probabilities are calculated and causes the probs
to be calculated as:
[local count: 216361238]:
if (p2_6(D) != 0B)
goto ; [54.59%]
else
goto ; [45.41%]
Logically this seems correct to me. A simple check outside of a loop
should slightly but not overwhelmingly favor a non-zero value.
Interestingly however, the old threader couldn't get this, but the IL
ended up identical, albeit with different probabilities. What happens
is that, because the old code could not thread this, the p2 != 0 check
would remain inside the loop and probs would be calculated thusly:
[local count: 1073741824]:
# p_2 = PHI
if (p_2 != 0B)
goto ; [94.50%]
else
goto ; [5.50%]
Then when the loop header copying pass ("ch") shuffled things around,
the IL would end up identical to my early threader code, but with the
probabilities would remain as 94.5/5.5.
The above discrepancy causes the RTL ifcvt pass to generate different
code, and by the time we get to the shrink wrapping pass, things look
sufficiently different such that the legacy code can actually shrink
wrap, whereas our new code does not.
IMO, if the loop-ch pass moves conditionals outside of a loop, the
probabilities should be adjusted, but that does mean the shrink wrap
won't happen for this contrived testcase.
Perhaps someone with more knowledge of loop-ch or the shrink wrapping code
could help here.
[Bug c++/101689] Internal compiler error during GIMPLE pass: ehcleanup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101689 --- Comment #4 from Theodore.Papadopoulo at inria dot fr --- Sorry, it was indeed too big, but I had not seen the message. Attached now. Sorry for not having found time to reduce the test case.
[Bug c++/101689] Internal compiler error during GIMPLE pass: ehcleanup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101689 --- Comment #3 from Theodore.Papadopoulo at inria dot fr --- Created attachment 51224 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51224=edit Preprocessed code
[Bug c++/101689] Internal compiler error during GIMPLE pass: ehcleanup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101689 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- I don't see any attachments. You can gzip/bzip2/xz compress it if it is too large.
[Bug c++/101689] Internal compiler error during GIMPLE pass: ehcleanup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101689 --- Comment #1 from Theodore.Papadopoulo at inria dot fr --- Also submitted as Bug 1986538 - Internal compiler error during GIMPLE pass: ehcleanup in readhat bugzilla, but I guess it is better here. Will close that one.
[Bug c++/101689] New: Internal compiler error during GIMPLE pass: ehcleanup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101689 Bug ID: 101689 Summary: Internal compiler error during GIMPLE pass: ehcleanup Product: gcc Version: 11.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: Theodore.Papadopoulo at inria dot fr Target Milestone: --- Description of problem: The compiler crashes with the mentioned error. Version-Release number of selected component (if applicable): gcc version 11.1.1 20210531 (Red Hat 11.1.1-3) (GCC) How reproducible: Just compile the attached preprocessed code with the options given below. Steps to Reproduce: 1. Download the attached code and name it ovp_main.i 2. /usr/bin/c++ -fvtable-verify=std -fnon-call-exceptions -std=gnu++11 ovp_main.i Actual results: mururoa-> /usr/bin/c++ -fvtable-verify=std -fnon-call-exceptions -std=gnu++11 ovp_main.i during GIMPLE pass: ehcleanup In file included from /home/papadop/compiles/OpenViBe/OpenViBE-f34/dist/sdk-Debug/include/toolkit/ovtk_all.h:75, from /home/papadop/src/Git/OpenViBe/designer/plugins/examples/src/box-algorithms/ovpCBoxAlgorithmModifiableSettings.h:6, from /home/papadop/src/Git/OpenViBe/designer/plugins/examples/src/ovp_main.cpp:3: /home/papadop/compiles/OpenViBe/OpenViBE-f34/dist/sdk-Debug/include/toolkit/box-algorithms/ovtkTBoxAlgorithm.h: In member function ‘uint64_t OpenViBE::Toolkit::TBoxAlgorithm::getClockFrequency(OpenViBE::Kernel::IBoxAlgorithmContext&) [with TBoxAlgorithmParentClass = OpenViBE::Plugins::IBoxAlgorithm]’: /home/papadop/compiles/OpenViBe/OpenViBE-f34/dist/sdk-Debug/include/toolkit/box-algorithms/ovtkTBoxAlgorithm.h:19:26: internal compiler error: in mark_reachable_handlers, at tree-eh.c:4033 19 | virtual uint64_t getClockFrequency(Kernel::IBoxAlgorithmContext& ctx) | ^ 0x7f0bdc834b74 ??? ../csu/libc-start.c:332 Please submit a full bug report, Expected results: No crash
[Bug target/66791] [ARM] Replace builtins with gcc vector extensions code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66791 --- Comment #11 from CVS Commits --- The master branch has been updated by Prathamesh Kulkarni : https://gcc.gnu.org/g:5a973aec601cb69024e0ebf6b0961906cec7c446 commit r12-2609-g5a973aec601cb69024e0ebf6b0961906cec7c446 Author: prathamesh.kulkarni Date: Fri Jul 30 15:10:37 2021 +0530 arm/66791: Replace builtins in vld1. gcc/ChangeLog: PR target/66791 * config/arm/arm_neon.h (vld1_p64): Replace call to builtin by explicitly dereferencing __a. (vld1_s64): Likewise. (vld1_u64): Likewise. * config/arm/arm_neon_builtins.def (vld1): Remove entry for di and change to VAR13.
[Bug libstdc++/65018] Use secure_getenv when available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65018 rschiron at redhat dot com changed: What|Removed |Added CC||rschiron at redhat dot com --- Comment #3 from rschiron at redhat dot com --- Function fs::temp_directory_path() in src/filesystem/ops.cc uses getenv() on TMPDIR/TMP/TEMP/TEMPDIR. Probably secure_getenv() should be used in that case.
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 57858, which changed state. Bug 57858 Summary: AVX2: ymm used for div, not for sqrt https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57858 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/57858] AVX2: ymm used for div, not for sqrt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57858 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Blocks||53947 Resolution|--- |FIXED --- Comment #7 from Richard Biener --- It was fixed by adding another loop header copying pass before vectorization, aka ch_vect. Of course it means we peel one iteration which might be not 100% optimal. Optimally we'd teach PRE that those loop carried dependences are bad(TM) just like we do for loads and extend that to cover calls. The peeling means we need an epilogue, so we didn't really save a sqrt call. That said, the situation is somewhat mitigated now and I'd declare it fixed anyway, the testcase is somewhat artificial (resolvable at compile time). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug middle-end/101688] New: g++.dg/warn/Wstringop-overflow-4.C fails on x86-32 with new jump threader
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101688
Bug ID: 101688
Summary: g++.dg/warn/Wstringop-overflow-4.C fails on x86-32
with new jump threader
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: aldyh at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
Target Milestone: ---
Created attachment 51223
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51223=edit
reduced testcase
FAIL: g++.dg/warn/Wstringop-overflow-4.C -std=gnu++14 (test for excess errors)
FAIL: g++.dg/warn/Wstringop-overflow-4.C -std=gnu++17 (test for excess errors)
FAIL: g++.dg/warn/Wstringop-overflow-4.C -std=gnu++2a (test for excess errors)
FAIL: g++.dg/warn/Wstringop-overflow-4.C -std=gnu++98 (test for excess errors)
Here are the new warnings:
b.C:129:3: note: destination object of size [4, 6] allocated by ‘operator new
[]’
b.C:148:3: warning: ‘void* __builtin_memcpy(void*, const void*, unsigned int)’
writing 2 bytes into a region of size 0 [-Wstringop-overflow=]
148 | T (S (1), new int16_t[r_0_imax]);
| ^
b.C:148:3: note: destination object of size 0 allocated by ‘operator new []’
b.C:149:3: warning: ‘void* __builtin_memcpy(void*, const void*, unsigned int)’
writing 3 bytes into a region of size 2 [-Wstringop-overflow=]
149 | T (S (2), new int16_t[r_0_imax + 1]);
| ^
b.C:149:3: note: destination object of size 2 allocated by ‘operator new []’
What happens is that the new code is threading bb2 -> bb4 -> bb5, and is
presumably confusing the -Wstringop-overflow pass. The transformation is
correct as can be seen in the sequence below:
:
_34 ={v} signed_value_source;
if (_34 < 0)
goto ; [50.00%]
else
goto ; [50.00%]
:
:
# iftmp.4_38 = PHI <0(2), _34(3)>
r_0_imax.1_8 = (sizetype) iftmp.4_38;
if (r_0_imax.1_8 <= 1073741822)
goto ; [INV]
else
goto ; [INV]
:
iftmp.0_10 = r_0_imax.1_8 * 2;
_12 = operator new [] (iftmp.0_10);
__builtin_memcpy (_12, [(void
*)"0123456789abcdefghijklmnopqrstuvwxyz" + 35B], 2);
sink (_12);
_1 = iftmp.4_38 + 1;
_17 = (sizetype) _1;
if (_17 <= 1073741822)
goto ; [INV]
else
goto ; [INV]
The attached reduced testcase can be reproduced with:
./cc1plus a.ii -fdump-tree-all-details-graph -quiet -I/tmp -O2 -Wall
-Wno-array-bounds -ftrack-macro-expansion=0 -m32
a.ii: In function ‘void test_strcpy_new_int16_t(size_t, const size_t*)’:
a.ii:25:12: warning: ‘void* __builtin_memcpy(void*, const void*, unsigned int)’
writing 2 bytes into a region of size 0 [-Wstringop-overflow=]
25 | strcpy (d, s);
| ~~~^~
a.ii:24:42: note: destination object of size 0 allocated by ‘operator new []’
24 | char *d = (char*)new int16_t[r_0_imax]; //blah1
| ^
a.ii:32:12: warning: ‘void* __builtin_memcpy(void*, const void*, unsigned int)’
writing 3 bytes into a region of size 2 [-Wstringop-overflow=]
32 | strcpy (d, s);
| ~~~^~
a.ii:31:46: note: destination object of size 2 allocated by ‘operator new []’
31 | char *d = (char*)new int16_t[r_0_imax + 1]; //blah2
| ^
[Bug c++/101687] New: Scoped enumerators of a member enumeration shall not be referred by a class member access expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101687
Bug ID: 101687
Summary: Scoped enumerators of a member enumeration shall not
be referred by a class member access expression
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: xmh970252187 at gmail dot com
Target Milestone: ---
struct A{
enum class C{
a = 0
};
};
int main(){
A a;
auto c = a.C::a; //#1
}
> Each enum-name and each unscoped enumerator is declared in the scope that
> immediately contains the enum-specifier.
> An enumerator declared in class scope can be referred to using the class
> member access operators (::, . (dot) and -> (arrow)), see [expr.ref].
According to the above rule, A::C::a shouldn't appear in the id-expression of a
member access expression, which means `#1` should be ill-formed.
[Bug c++/101686] export ; or export {} should not be accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101686 --- Comment #1 from Jakub Jelinek --- g++.dg/modules/pr101582-1.C testcase covers it with xfailed dg-error lines.
[Bug c++/101686] New: export ; or export {} should not be accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101686
Bug ID: 101686
Summary: export ; or export {} should not be accepted
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
[module.interface]/3 says:
An exported declaration that is not a module-import-declaration shall declare
at least one name.
If the declaration is not within a header unit, it shall not declare a name
with internal linkage.
but g++ doesn't diagnose this, so it accepts
export ;
export [[]];
export { }
etc.
[Bug c++/101582] C++ FE doesn't accept attribute-declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101582 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug c++/101582] C++ FE doesn't accept attribute-declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101582 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:77ab4e3be2d92b1ff671d58418d852195f10dd20 commit r12-2607-g77ab4e3be2d92b1ff671d58418d852195f10dd20 Author: Jakub Jelinek Date: Fri Jul 30 10:30:16 2021 +0200 c++: Accept C++11 attribute-definition [PR101582] As the following testcase shows, we don't parse properly C++11 attribute-declaration: https://eel.is/c++draft/dcl.dcl#nt:attribute-declaration cp_parser_toplevel_declaration just handles empty-declaration parsing (with diagnostics for C++98) and otherwise calls cp_parser_declaration which on it calls cp_parser_simple_declaration and rejects it with "does not declare anything" permerror. The following patch moves the handling of empty-declaration from cp_parser_toplevel_declaration to cp_parser_declaration and handles attribute-declaration in cp_parser_declaration by parsing the attributes (standard ones only, we've never supported __attribute__((...)); at namespace scope, so I'm not sure we need to introduce that), which for C++98 emits the needed diagnostics, and then warning if there are any attributes that we throw away on the floor. I'll need this later for OpenMP directives at namespace scope, e.g. [[omp::directive (requires, atomic_default_mem_order(seq_cst))]]; should be valid at namespace scope (and many other directives). 2021-07-30 Jakub Jelinek PR c++/101582 * parser.c (cp_parser_skip_std_attribute_spec_seq): Add a forward declaration. (cp_parser_declaration): Parse empty-declaration and attribute-declaration. (cp_parser_toplevel_declaration): Don't parse empty-declaration here. * g++.dg/cpp0x/gen-attrs-45.C: Expect a warning about ignored attributes instead of error. * g++.dg/cpp0x/gen-attrs-75.C: New test. * g++.dg/modules/pr101582-1.C: New test.
[Bug ipa/101396] [12 Regression] ICE in decompose, at wide-int.h:984 with -flto and incompatible enum class definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101396 Xi Ruoyao changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Known to work||11.2.0 --- Comment #5 from Xi Ruoyao --- Fixed in trunk.
[Bug ipa/101396] [12 Regression] ICE in decompose, at wide-int.h:984 with -flto and incompatible enum class definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101396 --- Comment #4 from CVS Commits --- The master branch has been updated by Xi Ruoyao : https://gcc.gnu.org/g:291416d3782e12e983483a3f7b2154a3dbfc9e1f commit r12-2606-g291416d3782e12e983483a3f7b2154a3dbfc9e1f Author: Xi Ruoyao Date: Sat Jul 10 17:46:29 2021 +0800 ipa-devirt: check precision mismatch of enum values [PR101396] We are comparing enum values (in wide_int) to check ODR violation. However, if we compare two wide_int values with different precision, we'll trigger an assert, leading to ICE. With enum-base introduced in C++11, it's easy to sink into this situation. To fix the issue, we need to explicitly check this kind of mismatch, and emit a proper warning message if there is such one. gcc/ PR ipa/101396 * ipa-devirt.c (ipa_odr_read_section): Compare the precision of enum values, and emit a warning if they mismatch. gcc/testsuite/ PR ipa/101396 * g++.dg/lto/pr101396_0.C: New test. * g++.dg/lto/pr101396_1.C: New test.
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #15 from Christoph Reiter --- Still the same error with GCC 11.2 and binutils 2.37: https://github.com/msys2/MINGW-packages/pull/9088/checks?check_run_id=3196226530
[Bug c++/101677] [11/12 Regression] Concept with use of incomplete type succeeds on GCC 10.3.0, fails on GCC 11 onward
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101677 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-07-30 --- Comment #1 from Andrew Pinski --- >This bug can be worked around by using a complete type instead when defining >the concept. It does not even have to be complete type; just defined before. So adding: class S; at the begining causes GCC to accept the code.
[Bug rtl-optimization/101683] Floating point exception for double->unsigned conversion on avx512 only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101683 --- Comment #5 from Andrew Pinski --- (In reply to Richard Biener from comment #4) > eh, guess nothing implemented UNSIGNED_FIX ... Just looked, no; just happened nobody ran into this until now. Either because of luck or really not many people care about floating point exceptions. I think it is the later.
[Bug target/101685] [12 Regression] -march=amdfam10 -mno-lzcnt Defines __LZCNT__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101685 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||hjl.tools at gmail dot com Target||x86_64-*-* i?86-*-* Last reconfirmed||2021-07-30 Ever confirmed|0 |1 Priority|P3 |P1
[Bug rtl-optimization/101683] Floating point exception for double->unsigned conversion on avx512 only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101683 --- Comment #4 from Richard Biener --- eh, guess nothing implemented UNSIGNED_FIX ...
[Bug c++/101680] [9/10 Regression] spurious error: use of ‘this’ in a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101680 Richard Biener changed: What|Removed |Added Last reconfirmed||2021-07-30 Target Milestone|--- |10.4 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Priority|P3 |P2 --- Comment #2 from Richard Biener --- Thus confirmed.
[Bug testsuite/101678] [12 regression] many fortran errors afterr r12-2553
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101678 Richard Biener changed: What|Removed |Added CC||burnus at gcc dot gnu.org Last reconfirmed||2021-07-30 Status|UNCONFIRMED |NEW Target Milestone|--- |12.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed, I believe I saw a duplicate.
[Bug c++/101677] [11/12 Regression] Concept with use of incomplete type succeeds on GCC 10.3.0, fails on GCC 11 onward
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101677 Richard Biener changed: What|Removed |Added Summary|[11 Regression] Concept |[11/12 Regression] Concept |with use of incomplete type |with use of incomplete type |succeeds on GCC 10.3.0, |succeeds on GCC 10.3.0, |fails on GCC 11 onward |fails on GCC 11 onward Known to work||10.3.0 Target Milestone|--- |11.3 Keywords||rejects-valid
[Bug tree-optimization/101676] ^ not changed to | if the non-zero don't overlap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101676 --- Comment #1 from Richard Biener --- why is | better than ^?
[Bug tree-optimization/57858] AVX2: ymm used for div, not for sqrt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57858 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization --- Comment #6 from Andrew Pinski --- So this was fixed in GCC 8 but I cannot tell by what. ch_vect has been there since 2014 which should have done the copying of the header but did not until GCC 8. There is not enough debug output to tell what changed either.
