[Bug sanitizer/100379] cyclades.h is removed from linux kernel header files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100379 Andrew Pinski changed: What|Removed |Added CC||grgoffe at yahoo dot com --- Comment #4 from Andrew Pinski --- *** Bug 100691 has been marked as a duplicate of this bug. ***
[Bug bootstrap/100691] Build of gcc fails with "linux/cyclades.h" not found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100691 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 100379. *** This bug has been marked as a duplicate of bug 100379 ***
[Bug bootstrap/100691] New: Build of gcc fails with "linux/cyclades.h" not found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100691 Bug ID: 100691 Summary: Build of gcc fails with "linux/cyclades.h" not found Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: grgoffe at yahoo dot com Target Milestone: --- Created attachment 50848 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50848=edit gzip'd build of gcc. Build logs for gmp, mpfr, and mpc are available if needed. Howdy, I have encountered this error for the past few days, each time after updating from the repository... I have used the previous development build gcc as well as the gcc that comes with my distribution (Fedora Core 35). Am I missing something? Did I do something wrong? Best regards, and STAY SAFE. George... libtool: compile: /tools/gcc/obj-x86_64-pc-linux-gnu/./gcc/xgcc -shared-libgcc -B/tools/gcc/obj-x86_64-pc-linux-gnu/./gcc -nostdinc++ -L/tools/gcc/obj-x86_64-pc-linux-gnu/x86_64-pc-linux-gnu/libstdc++-v3/src -L/tools/gcc/obj-x86_64-pc-linux-gnu/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/tools/gcc/obj-x86_64-pc-linux-gnu/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -B/usr/lsd/Linux/x86_64-pc-linux-gnu/bin/ -B/usr/lsd/Linux/x86_64-pc-linux-gnu/lib/ -isystem /usr/lsd/Linux/x86_64-pc-linux-gnu/include -isystem /usr/lsd/Linux/x86_64-pc-linux-gnu/sys-include -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DHAVE_RPC_XDR_H=0 -DHAVE_TIRPC_RPC_XDR_H=0 -I. -I../../../../gcc/libsanitizer/sanitizer_common -I.. -I ../../../../gcc/libsanitizer/include -I ../../../../gcc/libsanitizer -isystem ../../../../gcc/libsanitizer/include/system -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions -fno-rtti -fomit-frame-pointer -funwind-tables -fvisibility=hidden -Wno-variadic-macros -I../../libstdc++-v3/include -I../../libstdc++-v3/include/x86_64-pc-linux-gnu -I../../../../gcc/libsanitizer/../libstdc++-v3/libsupc++ -std=gnu++14 -fcf-protection -mshstk -DSANITIZER_LIBBACKTRACE -DSANITIZER_CP_DEMANGLE -I ../../../../gcc/libsanitizer/../libbacktrace -I ../libbacktrace -I ../../../../gcc/libsanitizer/../include -include ../../../../gcc/libsanitizer/libbacktrace/backtrace-rename.h -g -O2 -D_GNU_SOURCE -MT sanitizer_platform_limits_posix.lo -MD -MP -MF .deps/sanitizer_platform_limits_posix.Tpo -c ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp -fPIC -DPIC -o .libs/sanitizer_platform_limits_posix.o ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp:146:10: fatal error: linux/cyclades.h: No such file or directory 146 | #include | ^~ compilation terminated. make[4]: *** [Makefile:615: sanitizer_platform_limits_posix.lo] Error 1 make[4]: Leaving directory '/export/home/tools/gcc/obj-x86_64-pc-linux-gnu/x86_64-pc-linux-gnu/libsanitizer/sanitizer_common' make[3]: *** [Makefile:531: all-recursive] Error 1 make[3]: Leaving directory '/export/home/tools/gcc/obj-x86_64-pc-linux-gnu/x86_64-pc-linux-gnu/libsanitizer' make[2]: *** [Makefile:418: all] Error 2 make[2]: Leaving directory '/export/home/tools/gcc/obj-x86_64-pc-linux-gnu/x86_64-pc-linux-gnu/libsanitizer' make[1]: *** [Makefile:18589: all-target-libsanitizer] Error 2 make[1]: Leaving directory '/export/home/tools/gcc/obj-x86_64-pc-linux-gnu' make: *** [Makefile:1002: all] Error 2
[Bug libstdc++/100690] New: ranges::iota_view::_Sentinel cannot access _M_current of _Iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100690
Bug ID: 100690
Summary: ranges::iota_view::_Sentinel cannot access _M_current
of _Iterator
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
Same access issue as PR100631:
https://godbolt.org/z/z4Ysc1cez
#include
int main() {
int x[] = {42, 42, 42};
auto r = std::views::iota(std::ranges::begin(x), std::ranges::cbegin(x) + 3);
r.end() - r.begin();
r.begin() - r.end();
}
:7:22: required from here
/opt/compiler-explorer/gcc-trunk-20210519/include/c++/12.0.0/ranges:518:22:
error: 'int* std::ranges::iota_view::_Iterator::_M_value' is
private within this context
518 | { return __x._M_value - __y._M_bound; }
| ^~~~
/opt/compiler-explorer/gcc-trunk-20210519/include/c++/12.0.0/ranges:490:15:
note: declared private here
490 | _Winc _M_value = _Winc();
| ^~~~
[Bug c++/100659] [11/12 Regression] ICE in supplement_binding_1, at cp/name-lookup.c:2702 since r11-5003-gd50310408f54e380
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100659 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jason Merrill --- Fixed for 11.2/12.
[Bug c++/100634] [11/12 Regression] ICE in convert_nontype_argument, at cp/pt.c:7653
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100634 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jason Merrill --- Fixed for 11.2/12.
[Bug c++/100634] [11/12 Regression] ICE in convert_nontype_argument, at cp/pt.c:7653
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100634 --- Comment #3 from CVS Commits --- The releases/gcc-11 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:b54e50285c716fabc3980c5383c4898018a60b28 commit r11-8444-gb54e50285c716fabc3980c5383c4898018a60b28 Author: Jason Merrill Date: Wed May 19 17:33:21 2021 -0400 c++: _Complex template parameter [PR100634] We were crashing because invalid_nontype_parm_type_p allowed _Complex template parms, but convert_nontype_argument didn't know what to do for them. Let's just disallow it, people can and should use std::complex instead. PR c++/100634 gcc/cp/ChangeLog: * pt.c (invalid_nontype_parm_type_p): Return true for COMPLEX_TYPE. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/nontype-complex1.C: New test.
[Bug c++/100659] [11/12 Regression] ICE in supplement_binding_1, at cp/name-lookup.c:2702 since r11-5003-gd50310408f54e380
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100659 --- Comment #3 from CVS Commits --- The releases/gcc-11 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:8b7212ebb80e854c08274228627ce0a3061db6b0 commit r11-8443-g8b7212ebb80e854c08274228627ce0a3061db6b0 Author: Jason Merrill Date: Wed May 19 16:40:24 2021 -0400 c++: ICE with using and enum [PR100659] Here the code for 'using enum' is confused by the combination of a using-decl and an enum that are not from 'using enum'; this CONST_DECL is from the normal unscoped enum scoping. PR c++/100659 gcc/cp/ChangeLog: * cp-tree.h (CONST_DECL_USING_P): Check for null TREE_TYPE. gcc/testsuite/ChangeLog: * g++.dg/parse/access13.C: New test.
[Bug c++/100634] [11/12 Regression] ICE in convert_nontype_argument, at cp/pt.c:7653
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100634 --- Comment #2 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:75ab8b4829dec8c70470e8225c9add964f71ed74 commit r12-933-g75ab8b4829dec8c70470e8225c9add964f71ed74 Author: Jason Merrill Date: Wed May 19 17:33:21 2021 -0400 c++: _Complex template parameter [PR100634] We were crashing because invalid_nontype_parm_type_p allowed _Complex template parms, but convert_nontype_argument didn't know what to do for them. Let's just disallow it, people can and should use std::complex instead. PR c++/100634 gcc/cp/ChangeLog: * pt.c (invalid_nontype_parm_type_p): Return true for COMPLEX_TYPE. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/nontype-complex1.C: New test.
[Bug c++/100659] [11/12 Regression] ICE in supplement_binding_1, at cp/name-lookup.c:2702 since r11-5003-gd50310408f54e380
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100659 --- Comment #2 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:fe9a6614a16b5ea7f12141c50b6b7de984390ed8 commit r12-932-gfe9a6614a16b5ea7f12141c50b6b7de984390ed8 Author: Jason Merrill Date: Wed May 19 16:40:24 2021 -0400 c++: ICE with using and enum [PR100659] Here the code for 'using enum' is confused by the combination of a using-decl and an enum that are not from 'using enum'; this CONST_DECL is from the normal unscoped enum scoping. PR c++/100659 gcc/cp/ChangeLog: * cp-tree.h (CONST_DECL_USING_P): Check for null TREE_TYPE. gcc/testsuite/ChangeLog: * g++.dg/parse/access13.C: New test.
[Bug c++/100689] New: internal compiler error: Segmentation fault when using modules and -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100689
Bug ID: 100689
Summary: internal compiler error: Segmentation fault when using
modules and -g
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ma30002000 at yahoo dot de
Target Milestone: ---
When compile file files exp.cpp and imp.cpp with the following contents:
exp.cpp --
module;
#include
export module mod;
export std::string F() { return "test"; }
---
imp.cpp --
#include
#include
#include
import mod;
constexpr void
ToHexInt(uint8_t value, char& dst) {
if (value <= 9)
dst = static_cast('0' + value);
if (value >= 0xa && value <= 0xf)
dst = static_cast('a' + (value - 0x0a));
}
template
inline DestT
ToHexString(const std::span& value) {
DestT output;
output.resize(value.size() * 2);
uint8_t i;
ToHexInt(i, output[0]);
return output;
}
int main() {
uint8_t a[2];
ToHexString(a);
}
---
with the following compiler command lines:
/usr/bin/g++-11 -g -fmodules-ts -std=gnu++2a -o exp.cpp.o -c exp.cpp
/usr/bin/g++-11 -g -fmodules-ts -std=gnu++2a -o imp.cpp.o -c imp.cpp
I get the following error on compilation of imp.cpp:
---
In file included from /usr/include/c++/11/string:38,
from exp.cpp:3,
of module mod, imported at imp.cpp:5:
/usr/include/c++/11/bits/basic_string.h:1045:9: internal compiler error:
Segmentation fault
1045 | __glibcxx_assert(__pos <= size());
| ^~~~
0xe30681 internal_error(char const*, ...)
???:0
0x9d6c83 module_state::mangle(bool)
???:0
0xf628a7 mangle_decl(tree_node*)
???:0
0x1487939 symbol_table::finalize_compilation_unit()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
---
If I do not specify "-g" the compilation concludes successfully.
[Bug jit/100688] Add support for link section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100688 --- Comment #4 from Andrew Pinski --- Hmm, now I am curious why you are using the jit framework rather than doing a normal GCC front-end; like was done for the other rust gcc front-end https://github.com/Rust-GCC/gccrs .
[Bug target/98734] ABI diagnostics emitted despite always_inline attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98734 Bill Schmidt changed: What|Removed |Added CC||wschmidt at gcc dot gnu.org --- Comment #2 from Bill Schmidt --- This warning message is being removed in GCC 12, FYI.
[Bug jit/100688] Add support for link section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100688 --- Comment #3 from Antoni --- I develop a gcc codegen for the Rust compiler and it's a feature of Rust to be able to set the link section: https://github.com/antoyo/rustc_codegen_gcc/commit/999f768526d72e19e3eafdc963dcb6af8a1afe60#diff-6bbb01450b42befd6551add5fd3f53dd6a0ebd54f6f32c20cef02246521bd490R19 One of the use cases is in the standard library: https://github.com/rust-lang/rust/blob/7e11f3a8f3c1b2683125e7def0acb68a6d684f92/library/std/src/sys/unix/args.rs#L112
[Bug c++/91859] Using destroying delete should not clobber stores to the object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91859 --- Comment #5 from Joseph C. Sible --- The real problem mentioned in comment 2 still happens as of GCC 11.1. I've narrowed it down somewhat to the optimization flags "-Og -ftree-dse -ftree-pta". Removing any one of those will make it behave again.
[Bug jit/100688] Add support for link section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100688 --- Comment #2 from Andrew Pinski --- I am curious what is the use case here?
[Bug jit/100688] Add support for link section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100688 --- Comment #1 from Antoni --- Created attachment 50847 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50847=edit Patch adding support for setting the link section
[Bug c++/100489] [10/11/12 Regression] ICE in cp/constexpr.c:3556
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100489 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug jit/100688] New: Add support for link section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100688
Bug ID: 100688
Summary: Add support for link section
Product: gcc
Version: 10.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: jit
Assignee: dmalcolm at gcc dot gnu.org
Reporter: bouanto at zoho dot com
Target Milestone: ---
Hi.
I'd like support to set the link section (i.e.
`__attribute__((section(".section")))`) in libgccjit.
A patch will follow soon.
[Bug c++/100687] New: [modules, concepts] imported concept gives different result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100687
Bug ID: 100687
Summary: [modules, concepts] imported concept gives different
result
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: webrown.cpp at gmail dot com
Target Milestone: ---
Using recent trunk [g++-HEAD (Homebrew GCC HEAD-5380e3c) 12.0.0 20210513],
compiling with significant flags -std=c++23 -fmodules-ts -c.
I have two source files, as follows:
//
export module bug_a;
template< class T >
inline constexpr bool probe = false;
//
template< class R, class C >
inline constexpr bool probe = true;
export
template< class T >
concept mbr_ptr = probe;
struct S { int f( ); };
using mf_t = decltype( ::f );
static_assert( mbr_ptr< mf_t > );
//
This bug_a module compiles successfully. In particular, the static_assert
passes.
//
export module bug_b;
import bug_a;
struct S { int f( ); };
using mf_t = decltype( ::f );
static_assert( mbr_ptr< mf_t > );
//
This bug_b module does not compile. The diagnostics are reproduced below,
including the somewhat mysterious lone apostrophe:
bug_b.cc:8:16: error: static assertion failed
8 | static_assert( mbr_ptr< mf_t > );
|^~~
bug_b.cc:8:16: note: constraints not satisfied
'
bug_a.cc:12: confused by earlier errors, bailing out
Please note that the static_assert and supporting declarations in module bug_a
are identical to those in module bug_a, yet one compiles while the other does
not.
Thus we seem to have two problems: (1) the lone apostrophe amongst the
diagnostics, and (2) the inconsistent evaluation of identical expressions.
Finally, please note that if I use a class template (instead of the variable
template) in module bug_a, both modules' static_asserts now compile without
complaint:
//
template< class T >
struct probe { static constexpr bool value = false; };
//
template< class R, class C >
struct probe { static constexpr bool value = true; };
export
template< class T >
concept
mbr_ptr = probe::value;
//
[Bug c/100619] [11 Regression] ICE on a VLA parameter with too many dimensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100619 Martin Sebor changed: What|Removed |Added Known to fail|11.1.0 | Summary|[11/12 Regression] ICE: in |[11 Regression] ICE on a |build_attr_access_from_parm |VLA parameter with too many |s, at |dimensions |c-family/c-attribs.c:5038 | |since | |r11-3303-g6450f07388f9fe57 | --- Comment #4 from Martin Sebor --- Fixed on trunk, waiting to backport.
[Bug c/100619] [11/12 Regression] ICE: in build_attr_access_from_parms, at c-family/c-attribs.c:5038 since r11-3303-g6450f07388f9fe57
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100619 --- Comment #3 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:eb2a917fa0779b689f09ac8d8c41b0456facbe62 commit r12-930-geb2a917fa0779b689f09ac8d8c41b0456facbe62 Author: Martin Sebor Date: Wed May 19 16:13:13 2021 -0600 PR c/100619 - ICE on a VLA parameter with too many dimensions gcc/c-family/ChangeLog: PR c/100619 * c-attribs.c (build_attr_access_from_parms): Handle arbitrarily many bounds. gcc/testsuite/ChangeLog: PR c/100619 * gcc.dg/pr100619.c: New test.
[Bug c++/100634] [11/12 Regression] ICE in convert_nontype_argument, at cp/pt.c:7653
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100634 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c/100619] [11/12 Regression] ICE: in build_attr_access_from_parms, at c-family/c-attribs.c:5038 since r11-3303-g6450f07388f9fe57
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100619 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #2 from Martin Sebor --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570800.html
[Bug middle-end/100684] spurious -Wnonnull with -O1 on a C++ lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100684 Martin Sebor changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Status|NEW |ASSIGNED Build||2021-05-19 0:00 Keywords||patch Target Milestone|--- |11.2 --- Comment #2 from Martin Sebor --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570801.html
[Bug testsuite/100658] Typos in dg commands and texi files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100658
--- Comment #3 from G. Steinmetz ---
> What's wrong about the $ sign?
Nothing, it's about "dollar". I was just surprised that
there was no text snippet "dollar in" in all the sources.
You can ignore this section "Additionally ...",
on x86_64-pc-linux-gnu it gives (not checked on powerpc) :
$ gcc-12-20210516 -c gcc.dg/ucnid-5.c -std=c99 -g -fdollars-in-identifiers
$ gcc-12-20210516 -c gcc.dg/ucnid-5.c -std=c99 -g -fno-dollars-in-identifiers
gcc.dg/ucnid-5.c:6:6: error: stray '$' in program
6 | int a$b(void) { return 1; }
| ^
gcc.dg/ucnid-5.c:6:7: error: expected '=', ',', ';', 'asm' or '__attribute__'
before 'b'
6 | int a$b(void) { return 1; }
| ^
gcc.dg/ucnid-5.c: In function 'main':
gcc.dg/ucnid-5.c:11:7: error: universal character \u0024 is not valid in an
identifier
11 | if (a\u0024b() != 1)
| ^
gcc.dg/ucnid-5.c:11:7: warning: implicit declaration of function 'a$b'
[-Wimplicit-function-declaration]
11 | if (a\u0024b() != 1)
| ^~~~
[Bug middle-end/99578] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
--- Comment #16 from Martin Sebor ---
It's the pointer itself that needs to be volatile to keep GCC from determining
its value. This shows the difference:
$ cat pr99578-15.c && gcc -O2 -S -Wall pr99578-15.c
void f (void)
{
void* ptr = (void *)0x7ff8ul;
__builtin_memcpy (ptr, "\x90\x90\xf\xbxen\x90", 8); // warning
}
void g (void)
{
void* volatile ptr = (void *)0x7ff8ul;
__builtin_memcpy (ptr, "\x90\x90\xf\xbxen\x90", 8); // okay
}
pr99578-15.c: In function ‘f’:
pr99578-15.c:4:3: warning: ‘__builtin_memcpy’ offset [0, 7] is out of the
bounds [0, 0] [-Warray-bounds]
4 | __builtin_memcpy (ptr, "\x90\x90\xf\xbxen\x90", 8); // warning
| ^~
Alternatively, store the address a global (modifiable) variable.
[Bug c++/100659] [11/12 Regression] ICE in supplement_binding_1, at cp/name-lookup.c:2702 since r11-5003-gd50310408f54e380
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100659 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/100205] [11/12 Regression] error: invalid use of non-static data member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100205 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Jason Merrill --- Fixed for 11.2/12.
[Bug c++/100644] [11/12 regression] Deleted move constructor prevents templated constructor from being used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100644 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jason Merrill --- Fixed for 11.2/12.
[Bug c++/100372] [11/12 Regression] ICE with variadic template template, internal compiler error: in strip_typedefs, at cp/tree.c:1544
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100372 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Jason Merrill --- Fixed for 11.2/12.
[Bug c++/100261] [11/12 Regression] ICE: tree check: expected var_decl or type_decl, have error_mark in emit_tinfo_decl, at cp/rtti.c:1643
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100261 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jason Merrill --- Fixed for 11.2/12.
[Bug c++/100367] [11/12 Regression] Internal compiler error when std::lexicographical_compare_three_way third and fourth argument are reverse iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100367 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Jason Merrill --- Fixed for 11.2/12.
[Bug c++/100367] [11/12 Regression] Internal compiler error when std::lexicographical_compare_three_way third and fourth argument are reverse iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100367 --- Comment #3 from CVS Commits --- The releases/gcc-11 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:3bdd3e45955ef94a1f2db51a2af1ded54d41f670 commit r11-8437-g3bdd3e45955ef94a1f2db51a2af1ded54d41f670 Author: Jason Merrill Date: Tue May 18 12:29:33 2021 -0400 c++: ICE with <=> fallback [PR100367] Here, when genericizing lexicographical_compare_three_way, we haven't yet walked the operands, so (a == a) still sees ADDR_EXPR , but this is after we've changed the type of a to REFERENCE_TYPE. When we try to fold (a == a) by constexpr evaluation, the constexpr code doesn't understand trying to take the address of a reference, and we end up crashing. Fixed by avoiding constexpr evaluation in genericize_spaceship, by using fold_build2 instead of build_new_op on scalar operands. Class operands should have been expanded during parsing. PR c++/100367 PR c++/96299 gcc/cp/ChangeLog: * method.c (genericize_spaceship): Use fold_build2 for scalar operands. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/spaceship-fallback1.C: New test.
[Bug c++/96299] Defaulted operator <=> implicitly deleted when a member has operator < and operator == and return type is specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96299 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:3bdd3e45955ef94a1f2db51a2af1ded54d41f670 commit r11-8437-g3bdd3e45955ef94a1f2db51a2af1ded54d41f670 Author: Jason Merrill Date: Tue May 18 12:29:33 2021 -0400 c++: ICE with <=> fallback [PR100367] Here, when genericizing lexicographical_compare_three_way, we haven't yet walked the operands, so (a == a) still sees ADDR_EXPR , but this is after we've changed the type of a to REFERENCE_TYPE. When we try to fold (a == a) by constexpr evaluation, the constexpr code doesn't understand trying to take the address of a reference, and we end up crashing. Fixed by avoiding constexpr evaluation in genericize_spaceship, by using fold_build2 instead of build_new_op on scalar operands. Class operands should have been expanded during parsing. PR c++/100367 PR c++/96299 gcc/cp/ChangeLog: * method.c (genericize_spaceship): Use fold_build2 for scalar operands. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/spaceship-fallback1.C: New test.
[Bug c++/100367] [11/12 Regression] Internal compiler error when std::lexicographical_compare_three_way third and fourth argument are reverse iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100367 --- Comment #2 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:cd67343703ef4fa61de837f4690eba70d2760825 commit r12-928-gcd67343703ef4fa61de837f4690eba70d2760825 Author: Jason Merrill Date: Tue May 18 12:29:33 2021 -0400 c++: ICE with <=> fallback [PR100367] Here, when genericizing lexicographical_compare_three_way, we haven't yet walked the operands, so (a == a) still sees ADDR_EXPR , but this is after we've changed the type of a to REFERENCE_TYPE. When we try to fold (a == a) by constexpr evaluation, the constexpr code doesn't understand trying to take the address of a reference, and we end up crashing. Fixed by avoiding constexpr evaluation in genericize_spaceship, by using fold_build2 instead of build_new_op on scalar operands. Class operands should have been expanded during parsing. PR c++/100367 PR c++/96299 gcc/cp/ChangeLog: * method.c (genericize_spaceship): Use fold_build2 for scalar operands. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/spaceship-fallback1.C: New test.
[Bug c++/96299] Defaulted operator <=> implicitly deleted when a member has operator < and operator == and return type is specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96299 --- Comment #6 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:cd67343703ef4fa61de837f4690eba70d2760825 commit r12-928-gcd67343703ef4fa61de837f4690eba70d2760825 Author: Jason Merrill Date: Tue May 18 12:29:33 2021 -0400 c++: ICE with <=> fallback [PR100367] Here, when genericizing lexicographical_compare_three_way, we haven't yet walked the operands, so (a == a) still sees ADDR_EXPR , but this is after we've changed the type of a to REFERENCE_TYPE. When we try to fold (a == a) by constexpr evaluation, the constexpr code doesn't understand trying to take the address of a reference, and we end up crashing. Fixed by avoiding constexpr evaluation in genericize_spaceship, by using fold_build2 instead of build_new_op on scalar operands. Class operands should have been expanded during parsing. PR c++/100367 PR c++/96299 gcc/cp/ChangeLog: * method.c (genericize_spaceship): Use fold_build2 for scalar operands. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/spaceship-fallback1.C: New test.
[Bug c++/93769] Slightly wrong diagnostic message for static_asserts with no message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93769 --- Comment #3 from Jonathan Wakely --- (In reply to Gennaro Prota from comment #2) > Well, I thought this would require changing a single string literal in the > compiler source code. No, there are (at least) 38 diagnostics of the same form. Changing a single one would make it inconsistent with all the others, which would IMHO be even worse than the status quo.
[Bug middle-end/99578] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 --- Comment #15 from Andrew Cooper --- (In reply to Martin Sebor from comment #1) > For now, I recommend suppressing the warning either by #pragma GCC > diagnostic or by making the pointer volatile. Trying this with the code sample from comment 14 doesn't work. Not only does the -Werror=array-bounds diagnostic remain, a second is picked up from: passing argument 1 of ‘__builtin_memcpy’ discards ‘volatile’ qualifier from pointer target type [-Werror=discarded-qualifiers]
[Bug tree-optimization/100499] Different results with -fpeel-loops -ftree-loop-vectorize options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 --- Comment #21 from Andrew Macleod --- > > > > Would this be useful? and would it solve this problem? I'm sure there are > > other details to work out related to the increased precision, but it seems > > like it might work? > > Hmm, so the issue we're facing is asking whether x * 3 is a multiple of 3 > but we have to consider that x * 3 might overflow. For '3' being > power-of-two > overflow doesn't change anything but for some C ((X * C) % S % C) != 0 > (where S is the modulo reduction applied on overflow). > > So it seems that, to be useful, this ranger expression walk would need to be > integrated with multiple_of_p itself. Or we need to restrict calls to > multiple_of_p to those C where S is a multiple of C. (but in principle > multiple_of_p is happy with a symbolic C - not sure if it is ever called with > one though) > We'll add the general expression evaluator, since I think its pretty straightforward and useful in general. And if we then add the ability to indicate an expression may overflow, then multiple_of_p can decide whether that is a check it wants to make or not, and if it is, then it can simply ask. multiple_of_p would simply be a client calling "may_overflow_p (expr)"
[Bug fortran/97046] Bad interaction between lbound/ubound, allocatable arrays and bind(C) subroutine with dimension(..) parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97046 José Rui Faustino de Sousa changed: What|Removed |Added CC||jrfsousa at gcc dot gnu.org --- Comment #6 from José Rui Faustino de Sousa --- Patch posted: https://gcc.gnu.org/pipermail/fortran/2021-May/056054.html
[Bug fortran/94331] Bind(C) corrupts array descriptors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94331 --- Comment #6 from José Rui Faustino de Sousa --- Patch posted: https://gcc.gnu.org/pipermail/fortran/2021-May/056054.html
[Bug fortran/94327] Bind(c) argument attributes are incorrectly set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94327 --- Comment #3 from José Rui Faustino de Sousa --- Patch posted: https://gcc.gnu.org/pipermail/fortran/2021-May/056054.html
[Bug fortran/93963] Select rank mishandling allocatable and pointer arguments with bind(c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93963 --- Comment #4 from José Rui Faustino de Sousa --- Patch posted: https://gcc.gnu.org/pipermail/fortran/2021-May/056054.html
[Bug fortran/93308] bind(c) subroutine changes lower bound of array argument in caller
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93308 --- Comment #4 from José Rui Faustino de Sousa --- Patch posted: https://gcc.gnu.org/pipermail/fortran/2021-May/056054.html
[Bug middle-end/99578] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 Andrew Cooper changed: What|Removed |Added CC||andrew.cooper3 at citrix dot com --- Comment #14 from Andrew Cooper --- I too have had what appears to be this bug, raised against a microkernel project. The logic is a test case involving interactions at the x86-64 lower canonical boundary, and reads like so: ... uint64_t *ptr = (void *)0x7ff8ul; memcpy(ptr, "\x90\x90\xf\xbxen\x90", 8); ... This yields: include/xtf/libc.h:36:37: error: ‘__builtin_memcpy’ offset [0, 7] is out of the bounds [0, 0] [-Werror=array-bounds] 36 | #define memcpy(d, s, n) __builtin_memcpy(d, s, n) | ^ main.c:81:5: note: in expansion of macro ‘memcpy’ 81 | memcpy(ptr, "\x90\x90\xf\xbxen\x90", 8); | ^~ It is worth pointing out that it is common for kernels to have some virtual addresses derived from compile-time constants, notably the fixmap and frametable.
[Bug libstdc++/100361] gcc-11 for msp430-elf fails to build: src/c++17/floating_to_chars.cc:107: d2fixed_full_table.h:1283:23: error: size of array ‘POW10_SPLIT_2’ exceeds maximum object size ‘32767’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100361 --- Comment #10 from Sergei Trofimovich --- Amended patch fixes msp430-elf build as well. Thank you!
[Bug pch/14940] PCH largefile test fails on various platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940 --- Comment #52 from Jonathan Wakely --- N.B. patches need to be posted to the gcc-patches mailing list for review, not here. https://gcc.gnu.org/contribute.html
[Bug middle-end/100686] New: attribute optimize ("O2") doesn't inline lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100686
Bug ID: 100686
Summary: attribute optimize ("O2") doesn't inline lambda
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
Declaring with attribute optimize ("O2") a function that makes use of a trivial
lambda function with doesn't inline the lambda unless the whole translation
unit is compiled with optimization enabled. I'm guessing this happens for the
same reason as pr100323, although here the problem seems more severe since the
lambda is defined fully in the scope of the called function.
$ cat t.C && gcc -S -Wall -fdump-tree-optimized=/dev/stdout t.C
__attribute__ ((optimize ("O2"))) int f ()
{
return [](int x){ return x; }( 1 );
}
;; Function f()operator() (_ZZ1fvENKUliE_clEi, funcdef_no=1,
decl_uid=2352, cgraph_uid=1, symbol_order=0)
int f()operator() (const struct ._anon_0 * const __closure,
int x)
{
[local count: 1073741824]:
return x_1(D);
}
;; Function f (_Z1fv, funcdef_no=0, decl_uid=2346, cgraph_uid=4,
symbol_order=3)
__attribute__((optimize ("O2")))
int f ()
{
struct ._anon_0 D.2371;
int _2;
[local count: 1073741824]:
_2 = f()operator() (, 1); [tail call]
D.2371 ={v} {CLOBBER};
return _2;
}
[Bug fortran/100683] Array initialization refuses valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100683 --- Comment #1 from José Rui Faustino de Sousa --- Patch posted: https://gcc.gnu.org/pipermail/fortran/2021-May/056053.html
[Bug c++/100596] [12 Regression] error: attribute appertains to a friend declaration that is not a definition since r12-786-g149061188c7c6ddf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100596 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Marek Polacek --- Should be fixed, sorry.
[Bug c++/100596] [12 Regression] error: attribute appertains to a friend declaration that is not a definition since r12-786-g149061188c7c6ddf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100596 --- Comment #5 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:adcb497bdba499d161d2e5e8de782bdd6f75d62c commit r12-925-gadcb497bdba499d161d2e5e8de782bdd6f75d62c Author: Marek Polacek Date: Tue May 18 16:11:16 2021 -0400 c++: Relax attribute on friend declaration checking [PR100596] It turned out that there are codebases that profusely use GNU attributes on friend declarations, so we have to dial back our checking and allow them. And for C++11 attributes let's just warn instead of giving errors. PR c++/100596 gcc/cp/ChangeLog: * cp-tree.h (any_non_type_attribute_p): Remove. * decl.c (grokdeclarator): Turn an error into a warning and only warn for standard attributes. * decl2.c (any_non_type_attribute_p): Remove. * parser.c (cp_parser_elaborated_type_specifier): Turn an error into a warning and only warn for standard attributes. (cp_parser_member_declaration): Likewise. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/friend7.C: Turn a few dg-warnings into dg-errors. Remove dg-errors for GNU attributes. * g++.dg/ext/attrib63.C: Remove dg-error. * g++.dg/cpp0x/friend8.C: New test.
[Bug middle-end/100685] New: #pragma GCC push_options ineffective for optimize options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100685
Bug ID: 100685
Summary: #pragma GCC push_options ineffective for optimize
options
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The #pragma GCC push_options in the program below should prevent the folding of
the strlen() call in g() but doesn't. This has changed in GCC 11 (GCC 10
behaves as expected). The dump shows that the optimize attribute has both
optimization options, -O1 as well as -O2. That also seems unexpected but it
has not changed between 10 and 11.
$ cat a.c && gcc -O0 -S -Wall -fdump-tree-optimized=/dev/stdout a.c
#pragma GCC optimize ("2")
int f (void)
{
const char s[] = "12";
return __builtin_strlen (s); // folded to 1 (good)
}
#pragma GCC push_options
#pragma GCC optimize ("1")
int g (void)
{
const char s[] = "1";
return __builtin_strlen (s); // also folded but shouldn't be
}
;; Function f (f, funcdef_no=0, decl_uid=1943, cgraph_uid=1, symbol_order=0)
__attribute__((optimize ("2")))
int f ()
{
[local count: 1073741824]:
return 2;
}
;; Function g (g, funcdef_no=1, decl_uid=1947, cgraph_uid=2, symbol_order=1)
__attribute__((optimize ("2", "1")))
int g ()
{
[local count: 1073741824]:
return 1;
}
[Bug fortran/96983] [11/12 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983 --- Comment #35 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #34 from Tobias Burnus --- > What's actually the status of the PR – I mean on both powerpc64*-linux-gnu, > sparc*-*-*. > > The summary states that there is an ICE – is this still the case? > I am especially interested in the sparc*-*-* status. Checking my test result logs, I find that the sparc failures are gone after 20210309. > If not, what remains to be done? > I assume that also some GCC 11 backporting is needed. AFAICS, this failure never existed on the gcc-11 branch on sparc.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #216 from dave.anglin at bell dot net --- On 2021-05-17 5:56 a.m., jvb at cyberscience dot com wrote: > With the working as, I changed gcc to use brl instructions for calls, > including > tail calls: > > --- gcc-11.1.0/gcc/config/ia64/ia64.md 2021-04-27 11:00:13.0 +0100 > +++ gcc-11.1.0-snake/gcc/config/ia64/ia64.md2021-05-13 14:49:21.0 > +0100 > @@ -4410,7 +4410,9 @@ > (const_int 0)) > (clobber (match_operand:DI 1 "register_operand" "=b,b"))] >"" > - "br.call%+.many %1 = %0" > + "@ > + br.call%+.many %1 = %0 > + brl.call%+.many %1 = %0" >[(set_attr "itanium_class" "br,scall")]) > > (define_insn "call_value_nogp" > @@ -4419,14 +4421,18 @@ > (const_int 0))) > (clobber (match_operand:DI 2 "register_operand" "=b,b"))] >"" > - "br.call%+.many %2 = %1" > + "@ > + br.call%+.many %2 = %1 > + brl.call%+.many %2 = %1" >[(set_attr "itanium_class" "br,scall")]) > > (define_insn "sibcall_nogp" >[(call (mem:DI (match_operand:DI 0 "call_operand" "?b,s")) > (const_int 0))] >"" > - "br%+.many %0" > + "@ > + br%+.many %0 > + brl%+.many %0" >[(set_attr "itanium_class" "br,scall")]) > > (define_insn "call_gp" We only should use brl when TARGET_HPUX and ia64_tune == PROCESSOR_ITANIUM2. I wouldn't worry too much about it being slightly less efficient. You can use the pattern constraint to implement this.
[Bug c++/96501] [C++11] Should warn when classes only have copy constructor defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96501 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Jonathan Wakely --- This is a dup, and there's additional discussion in the dup. *** This bug has been marked as a duplicate of bug 89700 ***
[Bug c++/87403] [Meta-bug] Issues that suggest a new warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 Bug 87403 depends on bug 96501, which changed state. Bug 96501 Summary: [C++11] Should warn when classes only have copy constructor defined https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96501 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/89700] Warn if move constructor is not generated and not deleted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89700 Jonathan Wakely changed: What|Removed |Added CC||nunoplopes at sapo dot pt --- Comment #8 from Jonathan Wakely --- *** Bug 96501 has been marked as a duplicate of this bug. ***
[Bug middle-end/100680] false positive warning for certain __builtin_memcmp() argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100680 --- Comment #3 from jbeulich at suse dot com --- (In reply to Martin Sebor from comment #2) > The warning is by design: it considers a constant non-null pointer value a > likely result of (invalid) arithmetic on a null pointer, as in the example > in pr99578 comment #1. If the warning is by design, there ought to be a way to avoid these specific instances without disabling the warning altogether. I'm also observing such bogus warnings in cases other than pointer derivation from literal numbers, possibly along the lines of what Andi has said in that other bug in comment 12. For Xen I've submitted a patch to work around the issue without disabling the warning, but it's not really pretty: https://lists.xen.org/archives/html/xen-devel/2021-05/msg01058.html I also consider Richard's comment 7 in that other bug as quite relevant. The compiler _guessing_ that offsetting from a NULL pointer is an actual issue conflicts with people intentionally doing so. Warnings based on heuristics should imo always be separately controllable, such that they can - if the heuristics prove to be wrong - be turned off, without affecting other, non-heuristic warnings. This is even more relevant for all those projects (like the Xen hypervisor) building with -Werror, resulting in false positive warnings breaking the build.
[Bug middle-end/98109] Seemingly wrong warnings from -Wnonnull when combined with -O2 -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98109 --- Comment #3 from Martin Sebor --- (In reply to James Legg from comment #2) This is a different problem from the one reported in comment 0 so I opened a new bug for it: pr100684.
[Bug middle-end/100684] spurious -Wnonnull with -O1 on a C++ lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100684 Martin Sebor changed: What|Removed |Added Known to fail||11.1.0, 12.0 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Blocks||95507 Keywords||diagnostic Last reconfirmed||2021-05-19 --- Comment #1 from Martin Sebor --- Confirmed. The front end -Wnonull has suppression logic dealing with lambdas but the middle-end -Wnonnull in tree-ssa-ccp.c doesn't have anything like that. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95507 [Bug 95507] [meta-bug] bogus/missing -Wnonnull
[Bug libstdc++/100682] Outdated manual about the debug mode using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100682
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2021-05-19
Status|UNCONFIRMED |NEW
--- Comment #1 from Jonathan Wakely ---
(In reply to frankhb1989 from comment #0)
> BTW, what is the compatibility policy here? Is it true that any
> headers could be removed in a future release of GCC without deprecation?
We probably shouldn't do that.
I suppose we could restore but with this content:
#include
namespace __gnu_debug { using std::array; using std::get; using std::swap; }
And then deprecate it.
[Bug middle-end/100684] New: spurious -Wnonnull with -O1 on a C++ lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100684
Bug ID: 100684
Summary: spurious -Wnonnull with -O1 on a C++ lambda
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
>From James Legg in comment pr98109 comment 2:
> The false positives can often be seen when converting a lambda to a function
> pointer at lower optimisation levels too. For example, in g++ 11.1.1,
> compiling:
> int main()
> {
> return static_cast([](int x){ return x; })(0);
> }
>
> with -Og -Wall -fsanitize=undefined results in:
> /tmp/a.cc: In static member function ‘static constexpr int
> main()_FUN(int)’:
> /tmp/a.cc:3:63: warning: ‘this’ pointer is null [-Wnonnull]
> 3 | return static_cast([](int x){ return x; })(0);
> | ^
> /tmp/a.cc:3:42: note: in a call to non-static member function
> ‘main()::’
> 3 | return static_cast([](int x){ return x; })(0);
> | ^
[Bug libstdc++/100361] gcc-11 for msp430-elf fails to build: src/c++17/floating_to_chars.cc:107: d2fixed_full_table.h:1283:23: error: size of array ‘POW10_SPLIT_2’ exceeds maximum object size ‘32767’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100361 --- Comment #9 from Jonathan Wakely --- Nice, thanks, Joern. That patch is OK for trunk and gcc-11 (please remember to CC the libstdc++ list when you post it to gcc-patches).
[Bug target/97205] arm: Compiler fails with an ICE for -O0 on Trunk and GCC-10 for _Generic feature.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97205 --- Comment #21 from Bernd Edlinger --- Hi Srinath, when we add new assertions to gcc we use always a gcc_checking_assert nowadays, that is also the case here. The assertion is only firing in your compiler because it is a development snapshot 10.3.1. So that is an experimemtal version. That means the release version 10.3.0 will not have an ICE with this test case, except the long-standing potential wrong code due to unaligned memory access, however most contemporary ARM chips do no longer trap on an unaligned load/store. But on the other hand, this change might affects all targets whether or not they have any issue at all. So it might trigger a completely unrelated bug in a completely different area of the compiler. That said I do not object this back-port, I just wanted to say that it fixes a non-issue in a released compiler version. And even a small risk of a regression seems to be not worth it. Regards Bernd.
[Bug fortran/100683] New: Array initialization refuses valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100683 Bug ID: 100683 Summary: Array initialization refuses valid Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gcc dot gnu.org Target Milestone: --- Created attachment 50846 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50846=edit Fortran code showing problem Hi All! Refuses valid array initialization with bogus error. Seen on: GNU Fortran (GCC) 9.3.1 20210514 GNU Fortran (GCC) 10.3.1 20210514 GNU Fortran (GCC) 11.1.1 20210514 GNU Fortran (GCC) 12.0.0 20210514 (experimental) Thank you very much. Best regards, José Rui
[Bug fortran/100662] intrinsic::ieee_arithmetic fails on aarch, powerpc architectures on FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100662
--- Comment #10 from Steve Kargl ---
On Wed, May 19, 2021 at 09:45:12AM +, ripero84 at gmail dot com wrote:
> --- Comment #9 from ripero84 at gmail dot com ---
> Steve, is this a GCC bug or a FreeBSD bug (or if it is something else, what
> side does this belong to)?
I suppose it is both. AFAIK, there is no longer an active FreeBSD
maintainer for GCC (if there were, the few non-gfortran PR/patches
I submitted would have been committed). I no longer send patches
to GCC for gfortran as I know virtually nothing about git.
> Other OSs seem to be able to compile gfortran with these modules for these
> architectures, see, e.g.,
> https://packages.ubuntu.com/focal/arm64/gfortran-10/filelist and
> https://packages.ubuntu.com/focal/ppc64el/gfortran-10/filelist). And they
> seem
> to have been able to do so since the introduction of the three Fortran IEEE
> intrinsic modules in GCC 5
> (https://packages.ubuntu.com/bionic/amd64/gfortran-5/filelist and
> https://packages.ubuntu.com/bionic/ppc64el/gfortran-5/filelist). Therefore,
> some kind of solution must exist for this - and probably has been there for
> over half a decade. (Apologies for not being able to provide a better insight
> from the Ubuntu sources.)
ubuntu is glibc. You (or something) needs to read libgfortran/configure.host,
and add the needed logic for FreeBSD to pick up an appropriate fpu-*.h
file on aarch64. The first 3 non-comment lines of that file are
# DEFAULTS
fpu_host='fpu-generic'
ieee_support='no'
which is what non-i386/amd64 FreeBSD systems likely use. It seems
fpu-generic.h provides stubs for a few functions required to build
gfortran. After gfortran is built, installation does not install
useless ieee*.mod files. Note, a standard conforming Fortran
compiler is not required to support the ieee modules.
Furhter down in the file, there is a check for fenv compatibilities,
if test "x${have_feenableexcept}" = "xyes"; then
fpu_host='fpu-glibc'
ieee_support='yes'
fi
but the name of the file seems too specific to glibc. If fenv
facilities are available, I would have thought the file would
be named fpu-fenv.h. My guess is that configure does not find
fenv on aarch64 FreeBSD and/or aarch64 FreeBSD does not support
fenv.
[Bug libstdc++/100682] New: Outdated manual about the debug mode using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100682 Bug ID: 100682 Summary: Outdated manual about the debug mode using Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: frankhb1989 at gmail dot com Target Milestone: --- As I see has been removed in GCC 11, but the doc disagree: https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode_using.html https://gcc.gnu.org/onlinedocs/gcc-11.1.0/libstdc++/manual/manual/debug_mode_using.html In table 17.2, is still at the first row. BTW, what is the compatibility policy here? Is it true that any headers could be removed in a future release of GCC without deprecation?
[Bug libstdc++/100361] gcc-11 for msp430-elf fails to build: src/c++17/floating_to_chars.cc:107: d2fixed_full_table.h:1283:23: error: size of array ‘POW10_SPLIT_2’ exceeds maximum object size ‘32767’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100361 --- Comment #8 from Jorn Wolfgang Rennecke --- Bootstrapped and regression tested on x86_64-pc-linux-gnu.
[Bug middle-end/100680] false positive warning for certain __builtin_memcmp() argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100680 Martin Sebor changed: What|Removed |Added Component|c |middle-end Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Martin Sebor --- The warning is by design: it considers a constant non-null pointer value a likely result of (invalid) arithmetic on a null pointer, as in the example in pr99578 comment #1. *** This bug has been marked as a duplicate of bug 99578 ***
[Bug middle-end/99578] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 Martin Sebor changed: What|Removed |Added CC||jbeulich at suse dot com --- Comment #13 from Martin Sebor --- *** Bug 100680 has been marked as a duplicate of this bug. ***
[Bug target/97205] arm: Compiler fails with an ICE for -O0 on Trunk and GCC-10 for _Generic feature.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97205
--- Comment #20 from SRINATH PARVATHANENI ---
(In reply to rguent...@suse.de from comment #17)
> On Mon, 23 Nov 2020, bernd.edlinger at hotmail dot de wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97205
> >
> > --- Comment #16 from Bernd Edlinger ---
> > (In reply to SRINATH PARVATHANENI from comment #15)
> > > (In reply to Bernd Edlinger from comment #14)
> > > > fixed on trunk.
> > >
> > > Thanks Bernd for fixing this on trunk, would you mind backporting this to
> > > GCC-10 as well?
> > >
> > > Thanks you.
> > >
> > > Regards,
> > > Srinath.
> >
> > Since it is a gcc_checking_assert that triggers the ICE,
> > I assumed that does not affect a release build,
> > is that correct?
>
> That is correct.
I did not understand what you meant above, please correct me if I'm wrong.
My observation:
$ arm-none-eabi-gcc bugx.c -O0 -c
during RTL pass: expand
bugx.c: In function 'fn1':
bugx.c:4:5: internal compiler error: in gen_movsi, at config/arm/arm.md:6364
4 | x b = ({
| ^
0x14ede14 gen_movsi(rtx_def*, rtx_def*)
/data/dgboter/bbs/build22--cen7x86_64/buildbot/cen7x86_64--arm-none-eabi--all-profiles/build/src/gcc/gcc/config/arm/arm.md:6364
0x92153f insn_gen_fn::operator()(rtx_def*, rtx_def*) const
/data/dgboter/bbs/build22--cen7x86_64/buildbot/cen7x86_64--arm-none-eabi--all-profiles/build/src/gcc/gcc/recog.h:317
0x92153f emit_move_insn_1(rtx_def*, rtx_def*)
/data/dgboter/bbs/build22--cen7x86_64/buildbot/cen7x86_64--arm-none-eabi--all-profiles/build/src/gcc/gcc/expr.c:3759
0x921cf4 emit_move_insn(rtx_def*, rtx_def*)
/data/dgboter/bbs/build22--cen7x86_64/buildbot/cen7x86_64--arm-none-eabi--all-profiles/build/src/gcc/gcc/expr.c:3855
0x92a6f0 store_expr(tree_node*, rtx_def*, int, bool, bool)
/data/dgboter/bbs/build22--cen7x86_64/buildbot/cen7x86_64--arm-none-eabi--all-profiles/build/src/gcc/gcc/expr.c:5931
0x92c973 expand_assignment(tree_node*, tree_node*, bool)
/data/dgboter/bbs/build22--cen7x86_64/buildbot/cen7x86_64--arm-none-eabi--all-profiles/build/src/gcc/gcc/expr.c:5516
0x7d965c expand_gimple_stmt_1
/data/dgboter/bbs/build22--cen7x86_64/buildbot/cen7x86_64--arm-none-eabi--all-profiles/build/src/gcc/gcc/cfgexpand.c:3755
0x7d965c expand_gimple_stmt
/data/dgboter/bbs/build22--cen7x86_64/buildbot/cen7x86_64--arm-none-eabi--all-profiles/build/src/gcc/gcc/cfgexpand.c:3851
0x7dbf65 expand_gimple_basic_block
/data/dgboter/bbs/build22--cen7x86_64/buildbot/cen7x86_64--arm-none-eabi--all-profiles/build/src/gcc/gcc/cfgexpand.c:5895
0x7dce7b execute
/data/dgboter/bbs/build22--cen7x86_64/buildbot/cen7x86_64--arm-none-eabi--all-profiles/build/src/gcc/gcc/cfgexpand.c:6550
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug target/100333] arm: ICE (unrecognizable insn) with CMSE nonsecure call and -march=armv8.1-m.main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100333 --- Comment #3 from Alex Coplan --- Fixed on trunk for now.
[Bug target/100333] arm: ICE (unrecognizable insn) with CMSE nonsecure call and -march=armv8.1-m.main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100333 --- Comment #2 from CVS Commits --- The master branch has been updated by Alex Coplan : https://gcc.gnu.org/g:5b953740da1976d90d974055c6d825c509c6e654 commit r12-923-g5b953740da1976d90d974055c6d825c509c6e654 Author: Alex Coplan Date: Wed May 19 15:52:45 2021 +0100 arm: Fix ICE with CMSE nonsecure calls on Armv8.1-M [PR100333] As the PR shows, we ICE shortly after expanding nonsecure calls for Armv8.1-M. For Armv8.1-M, we have TARGET_HAVE_FPCXT_CMSE. As it stands, the expander (arm.md:nonsecure_call_internal) moves the callee's address to a register (with copy_to_suggested_reg) only if !TARGET_HAVE_FPCXT_CMSE. However, looking at the pattern which the insn appears to be intended to match (thumb2.md:*nonsecure_call_reg_thumb2_fpcxt), it requires the callee's address to be in a register. This patch therefore just forces the callee's address into a register in the expander. gcc/ChangeLog: PR target/100333 * config/arm/arm.md (nonsecure_call_internal): Always ensure callee's address is in a register. gcc/testsuite/ChangeLog: PR target/100333 * gcc.target/arm/cmse/pr100333.c: New test.
[Bug target/99977] arm: ICE with __sync_bool_compare_and_swap and -mcpu=cortex-m23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99977 --- Comment #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Christophe Lyon : https://gcc.gnu.org/g:c412100235ba34ae9c133fb7a77cc52c2e93fc87 commit r11-8435-gc412100235ba34ae9c133fb7a77cc52c2e93fc87 Author: Christophe Lyon Date: Wed May 19 14:45:54 2021 + arm/testsuite: Fix testcase for PR99977 Some targets (eg arm-none-uclinuxfdpiceabi) do not support Thumb-1, and since the testcase forces -march=armv8-m.base, we need to check whether this option is actually supported. Using dg-add-options arm_arch_v8m_base ensure that we pass -mthumb as needed too. 2021-05-19 Christophe Lyon PR target/99977 gcc/testsuite/ * gcc.target/arm/pr99977.c: Require arm_arch_v8m_base.
[Bug target/99977] arm: ICE with __sync_bool_compare_and_swap and -mcpu=cortex-m23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99977 --- Comment #7 from CVS Commits --- The master branch has been updated by Christophe Lyon : https://gcc.gnu.org/g:beeb01541ae845b445837b873126a7f968b8f654 commit r12-922-gbeeb01541ae845b445837b873126a7f968b8f654 Author: Christophe Lyon Date: Wed May 19 14:45:54 2021 + arm/testsuite: Fix testcase for PR99977 Some targets (eg arm-none-uclinuxfdpiceabi) do not support Thumb-1, and since the testcase forces -march=armv8-m.base, we need to check whether this option is actually supported. Using dg-add-options arm_arch_v8m_base ensure that we pass -mthumb as needed too. 2021-05-19 Christophe Lyon PR target/99977 gcc/testsuite/ * gcc.target/arm/pr99977.c: Require arm_arch_v8m_base.
[Bug c++/100681] New: [[noreturn]] attribute can be applied to parameters of function type with strange results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100681 Bug ID: 100681 Summary: [[noreturn]] attribute can be applied to parameters of function type with strange results Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: felix.von.s at posteo dot de Target Milestone: --- Created attachment 50845 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50845=edit Sample program Attached is a code sample which G++ accepts and all other compilers I tested reject. When the `never::invoke` line is uncommented, compilation fails with a message naming the type of func as `R(Args ...) volatile`, which is an abominable function type. There doesn’t seem to be a real way to use the method. Expected behaviour: the code is rejected in both versions, just like in other compilers. Desired behaviour: the code is accepted in both versions, with the [[noreturn]] attribute applied to func as if it were a function invoked directly.
[Bug testsuite/100655] 'g++.dg/tsan/pthread_cond_clockwait.C' FAILs due to 'pthread_cond_clockwait' missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100655
--- Comment #5 from Jonathan Wakely ---
--- a/gcc/testsuite/g++.dg/tsan/pthread_cond_clockwait.C
+++ b/gcc/testsuite/g++.dg/tsan/pthread_cond_clockwait.C
@@ -4,6 +4,10 @@
#include
+// Include this to get the libstdc++ _GLIBCXX_USE_PTHREAD_COND_CLOCKWAIT
+// macro that indicates pthread_cond_clockwait is available.
+#include
+
pthread_cond_t cv;
pthread_mutex_t mtx;
@@ -23,7 +27,9 @@ int main() {
struct timespec ts;
clock_gettime(CLOCK_MONOTONIC, );
ts.tv_sec += 10;
+#ifdef _GLIBCXX_USE_PTHREAD_COND_CLOCKWAIT
pthread_cond_clockwait(, , CLOCK_MONOTONIC, );
+#endif
pthread_mutex_unlock();
pthread_join(tid, NULL);
[Bug libstdc++/100630] Unexpected implicit conversion from volatile bool& to std::filesystem::path in gcc <= 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100630 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |9.5 --- Comment #6 from Jonathan Wakely --- It's too late for 9.4 but I plan to backport it for 9.5
[Bug target/100678] [OpenACC/nvptx] 'libgomp.oacc-c-c++-common/private-atomic-1.c' FAILs (differently) in certain configurations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100678
--- Comment #2 from Thomas Schwinge ---
I ran into this in a different OpenACC context (OpenACC privatization levels),
where in testcases we're trying to use 'atomic' on 'private' variables. ...
which for nvptx offloading only works for gang-private (PTX '.shared'), but
fails for everything else, per PR83812 ("old" failure mode).
(In reply to Tom de Vries from comment #1)
> I'm not sure what you aim to achieve with the test-case.
To document the current failure mode -- a deficiency in the OpenACC/nvptx
implementation. So that there is precedence for this, and it doesn't appear
just in the upcoming OpenACC privatization levels testcases.
And then, as reported in this issue here, I found the "wrong reduction result"
problem ("new" failure mode), which seems to be another deficiency in the
OpenACC/nvptx implementation.
> My inclination would be to skip it for nvptx, which AFAIU is opposite to
> your intent when adding it. So, perhaps just remove it?
I'd rather conditionalize the nvptx offloading XFAIL appropriately for both the
"old" and "new" failure modes, and then eventually un-XFAIL, once these issues
have been addressed.
[Bug middle-end/100672] wrong code with vector shift and unary minus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100672 Richard Biener changed: What|Removed |Added Known to fail|12.0| Known to work||12.0 --- Comment #12 from Richard Biener --- Fixed on trunk sofar.
[Bug middle-end/100672] wrong code with vector shift and unary minus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100672 --- Comment #11 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:8d51039cb7c807ed84ff7df5416a1e3ba07a5e63 commit r12-913-g8d51039cb7c807ed84ff7df5416a1e3ba07a5e63 Author: Richard Biener Date: Wed May 19 13:35:07 2021 +0200 middle-end/100672 - fix bogus right shift folding This fixes the bogus use of TYPE_PRECISION on vector types from optimizing -((int)x >> 31) into (unsigned)x >> 31. 2021-05-19 Richard Biener PR middle-end/100672 * fold-const.c (fold_negate_expr_1): Use element_precision. (negate_expr_p): Likewise. * gcc.dg/torture/pr100672.c: New testcase.
[Bug c/100680] false positive warning for certain __builtin_memcmp() argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100680 Richard Biener changed: What|Removed |Added Keywords||diagnostic CC||msebor at gcc dot gnu.org --- Comment #1 from Richard Biener --- I believe this is wrong "fallback" for failing to extract a size from the pointer constant argument. It should be unknown, not zero. Martin?
[Bug c/100680] New: false positive warning for certain __builtin_memcmp() argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100680
Bug ID: 100680
Summary: false positive warning for certain __builtin_memcmp()
argument
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jbeulich at suse dot com
Target Milestone: ---
In this example
struct s {
char a[8];
int i;
long l;
};
extern char ea[8];
static char sa[8] = { 1, 2, 3, 4 };
int test(void) {
const struct s*ps = (const struct s *)0x12345678L;
if(__builtin_memcmp(ps->a, ps->a, 8))
return 0;
if(__builtin_memcmp(ps->a, ea, 8))
return 0;
if(__builtin_memcmp(ps->a, sa, 8))
return 0;
if(__builtin_memcmp(ps->a, "abcdABCD", 8))
return 0;
return 1;
}
all except, oddly enough, the first invocation cause "'__builtin_memcmp'
specified bound of 8 exceeds source size of 0 [-Wstringop-overread]". Obviously
the above example is heavily simplified from actual uses in the Xen hypervisor
sources, but clearly in (at least) OS and alike low-level development it is not
uncommon for pointers to get derived from known integer constants.
[Bug testsuite/100655] 'g++.dg/tsan/pthread_cond_clockwait.C' FAILs due to 'pthread_cond_clockwait' missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100655 --- Comment #4 from Martin Liška --- (In reply to Jonathan Wakely from comment #2) > It's not glibc-specific though, it's going to be in the next POSIX standard > and other C libraries. > > It's a bit of a hack, but you could include any libstdc++ header and then > check _GLIBCXX_USE_PTHREAD_COND_CLOCKWAIT (because libstdc++ already has > autoconf checks for it). Can you please prepare such a patch?
[Bug testsuite/100658] Typos in dg commands and texi files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100658 --- Comment #2 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:32bd0353db37af2cb023e575ed4ce8c944fd9dba commit r12-912-g32bd0353db37af2cb023e575ed4ce8c944fd9dba Author: Martin Liska Date: Wed May 19 15:25:36 2021 +0200 Fix typos. PR testsuite/100658 gcc/cp/ChangeLog: * mangle.c (write_encoding): Fix typos. gcc/jit/ChangeLog: * libgccjit.c (gcc_jit_context_new_function): Fix typos. gcc/testsuite/ChangeLog: * gcc.dg/local1.c: Fix typos. * gcc.dg/ucnid-5-utf8.c: Likewise. * gcc.dg/ucnid-5.c: Likewise.
[Bug testsuite/100658] Typos in dg commands and texi files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100658
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #1 from Martin Liška ---
I'm going to fix the typos, thanks,
> ./gcc/testsuite/gcc.dg/cpp/lexident.c:8:/* Escaped newlines, _ and $ in
> identifiers. */
> ./gcc/testsuite/gcc.target/i386/pr91298-1.c:4:/* { dg-xfail-if "No support
> for $ in identifiers" { *-*-solaris2.* && { ! gas } } } */
> ./gcc/testsuite/gcc.target/i386/pr91298-2.c:4:/* { dg-xfail-if "No support
> for $ in identifiers" { *-*-solaris2.* && { ! gas } } } */
> ./libcpp/charset.c:1131: cpp_error (pfile, CPP_DL_PEDWARN, "'$' in
> identifier or number");
> ./libcpp/lex.c:1335: cpp_error (pfile, CPP_DL_PEDWARN, "'$' in
> identifier or number");
What's wrong about the $ sign?
[Bug target/100678] [OpenACC/nvptx] 'libgomp.oacc-c-c++-common/private-atomic-1.c' FAILs (differently) in certain configurations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100678 --- Comment #1 from Tom de Vries --- (In reply to Thomas Schwinge from comment #0) > At this point, it's (a) unclear whether the PR83812 restriction indeed is > supposed to be lifted for certain modern GPU hardware/SM levels/CUDA Driver > releases, Looking at the latest ptx isa spec, 7.3, we have: ... Atomic operations may be used only with .global and .shared spaces and with generic addressing, where the address points to .global or .shared space. ... That seems pretty clear. It's also not unusual for different archs to have different failure modes. I'm not sure what you aim to achieve with the test-case. My inclination would be to skip it for nvptx, which AFAIU is opposite to your intent when adding it. So, perhaps just remove it?
[Bug c++/100675] std::string_view::find in constexpr function is not constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100675
--- Comment #1 from 康桓瑋 ---
(In reply to 康桓瑋 from comment #0)
> The following code fails in 10.1, 10.2, and 10.3:
>
> https://godbolt.org/z/soGT9o4GY
>
> #include
>
> template
> constexpr bool g() {
> std::string_view s = " ";
> s.find(" ");
> return true;
> }
>
> constexpr bool b = g(); // ok
> template concept C = g();
> static_assert(C);// error
If change constexpr to consteval then compiles:
template
consteval bool g() {
std::string_view s = " ";
s.find(" ");
return true;
}
[Bug target/100678] New: [OpenACC/nvptx] 'libgomp.oacc-c-c++-common/private-atomic-1.c' FAILs (differently) in certain configurations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100678 Bug ID: 100678 Summary: [OpenACC/nvptx] 'libgomp.oacc-c-c++-common/private-atomic-1.c' FAILs (differently) in certain configurations Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: openacc Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: tschwinge at gcc dot gnu.org CC: jules at gcc dot gnu.org, vries at gcc dot gnu.org Target Milestone: --- Target: nvptx For OpenACC/nvptx offloading, the testcase 'libgomp.oacc-c-c++-common/private-atomic-1.c' that I've just pushed as commit r12-908-g1467100fc72562a59f70cdd4e05f6c810d1fadcc "Add 'libgomp.oacc-c-c++-common/private-atomic-1.c' [PR83812]" has been expected to fail with "operation not supported on global/shared address space" (see PR83812). However, I now found that on an x86_64 GNU/Linux system, Nvidia TITAN V GPU, CUDA Driver 455.23.05, it *doesn't* fail in that way: the device kernel execution completes normally -- but it instead returns a wrong reduction result: zero. At this point, it's (a) unclear whether the PR83812 restriction indeed is supposed to be lifted for certain modern GPU hardware/SM levels/CUDA Driver releases, and (b) what is then instead going wrong so that we don't compute the expected reduction result. Assuming that (a) has been done in good faith, I can see how (b) might happen if the 'v' variable would in fact *not* be thread-private (but instead device-global, I suppose), thus all threads atomically incrementing the device-global variable concurrently, thus the '(v == -222 + 121)' expression never being true?
[Bug libstdc++/100630] Unexpected implicit conversion from volatile bool& to std::filesystem::path in gcc <= 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100630 --- Comment #5 from Romain Geissler --- Hi, Thanks for providing a fix that quickly ! I backported it in my own copy of gcc 8 and 9 and it fixed my issue on these branches as well. Cheers, Romain
[Bug fortran/96983] [11/12 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #34 from Tobias Burnus --- What's actually the status of the PR – I mean on both powerpc64*-linux-gnu, sparc*-*-*. The summary states that there is an ICE – is this still the case? I am especially interested in the sparc*-*-* status. With powerpc64le-linux-gnu, I do not see an ICE anymore but two post-compilation FAILs for which I propose: https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570732.html Does this also help for sparc*-*-* (and other powerpc64*-linux-gnu)? If not, what remains to be done? I assume that also some GCC 11 backporting is needed.
[Bug target/83812] nvptx-run: error getting kernel result: operation not supported on global/shared address space
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83812 --- Comment #4 from CVS Commits --- The master branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:1467100fc72562a59f70cdd4e05f6c810d1fadcc commit r12-908-g1467100fc72562a59f70cdd4e05f6c810d1fadcc Author: Thomas Schwinge Date: Wed May 19 11:58:49 2021 +0200 Add 'libgomp.oacc-c-c++-common/private-atomic-1.c' [PR83812] ... to at least document/test/XFAIL nvptx offloading: PR83812 "operation not supported on global/shared address space". libgomp/ PR target/83812 * testsuite/libgomp.oacc-c-c++-common/private-atomic-1.c: New.
[Bug c/100661] [11/12 Regression] ICE in omp-low.c / refs_may_alias_p_2, at tree-ssa-alias.c:2460
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100661 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- It seems it started with r6-6362-gb2b40051500c944e.
[Bug bootstrap/100654] trunk bootstrap errors with -O0 and -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100654 Martin Liška changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #3 from Martin Liška --- Closing..
[Bug bootstrap/100654] trunk bootstrap errors with -O0 and -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100654 --- Comment #2 from Manfred Schwarb --- OK, then I will not report such issues in the future and use --disable-werror per default when using non-standard flags. Thanks.
[Bug middle-end/100672] wrong code with vector shift and unary minus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100672
--- Comment #10 from Zdenek Sojka ---
(In reply to Zdenek Sojka from comment #9)
> (In reply to Richard Biener from comment #8)
> > (In reply to Zdenek Sojka from comment #7)
> > > (In reply to Richard Biener from comment #2)
> > > > Maybe sth is wrong with the testcase? clang also results in an abort.
> > > > Isn't
> > > > right-shift of negative values undefined?
> > > >
> > >
> > > Thank you for having a look.
> > >
> > > I believe the behavior is fully defined. The vectors are unsigned, and the
> > > conversion to unsigned is done by adding 2**64; this behaves the same:
> > >
> > > $ cat testcase.c
> > > typedef unsigned long long __attribute__((__vector_size__ (32))) V;
> > >
> > > V
> > > foo (V v)
> > > {
> > > return -(v >> 1);
> >
> > but this is a logical right shift, thus gives 0x7ff...e, ...
> > and negating that doesn't yield 1.
> >
>
> Shame on me. You are very right.
I did the mistake while reducing the testcase.
The original testcase had positive arguments:
$ cat testcase.c
typedef unsigned long long __attribute__((__vector_size__ (32))) V;
V
foo (V v)
{
return -(v >> 1);
}
int
main (void)
{
V v = foo ((V) { 2, 4, 6, 8 });
if (v[0] != 0x || v[1] != 0xfffe ||
v[2] != 0xfffd || v[3] != 0xfffc)
__builtin_abort ();
return 0;
}
I wanted to prevent the long 0xf... constants, but broke the testcase in he
process. Thank you for correcting me.
[Bug libstdc++/100676] Redeclaring __failed_assertion() at every point of use of __glibcxx_assert breaks Clang CUDA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100676 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2021-05-19 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Jonathan Wakely --- (In reply to J.M. from comment #0) > In every use of __glibcxx_assert the function __failed_assertion is > redeclared and btw. never defined, By design. > which might break other projects as well, How? > and then is used as an assertion in constant evaluated contexts, as it is a > non constexpr function. Right, it's only ever used when we want compilation to fail. So it's never odr-used, so no call to it is ever emitted in the generated assembly, so no definition is needed. > I wasn't able to come up with an entirely better approach so far, Which is why this "awful" construct is used. > but I > guess most of the issues, that I could think of so far, would be solved by > moving the void __failed_assertion(); declaration out of the macro. The idea was to not pollute the namespace with a declaration of a function that will never exist.
[Bug middle-end/100672] wrong code with vector shift and unary minus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100672
--- Comment #9 from Zdenek Sojka ---
(In reply to Richard Biener from comment #8)
> (In reply to Zdenek Sojka from comment #7)
> > (In reply to Richard Biener from comment #2)
> > > Maybe sth is wrong with the testcase? clang also results in an abort.
> > > Isn't
> > > right-shift of negative values undefined?
> > >
> >
> > Thank you for having a look.
> >
> > I believe the behavior is fully defined. The vectors are unsigned, and the
> > conversion to unsigned is done by adding 2**64; this behaves the same:
> >
> > $ cat testcase.c
> > typedef unsigned long long __attribute__((__vector_size__ (32))) V;
> >
> > V
> > foo (V v)
> > {
> > return -(v >> 1);
>
> but this is a logical right shift, thus gives 0x7ff...e, ...
> and negating that doesn't yield 1.
>
Shame on me. You are very right.
[Bug middle-end/100672] wrong code with vector shift and unary minus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100672
--- Comment #8 from Richard Biener ---
(In reply to Zdenek Sojka from comment #7)
> (In reply to Richard Biener from comment #2)
> > Maybe sth is wrong with the testcase? clang also results in an abort.
> > Isn't
> > right-shift of negative values undefined?
> >
>
> Thank you for having a look.
>
> I believe the behavior is fully defined. The vectors are unsigned, and the
> conversion to unsigned is done by adding 2**64; this behaves the same:
>
> $ cat testcase.c
> typedef unsigned long long __attribute__((__vector_size__ (32))) V;
>
> V
> foo (V v)
> {
> return -(v >> 1);
but this is a logical right shift, thus gives 0x7ff...e, ...
and negating that doesn't yield 1.
> }
>
> int
> main (void)
> {
> V v = foo ((V) { 0xfffe, 0xfffc,
>0xfffa, 0xfff8 });
> if (v[0] != 1 || v[1] != 2 || v[2] != 3 || v[3] != 4)
> __builtin_abort ();
> return 0;
> }
>
> Maybe clang behaves the same since the behavior was the same in the moment
> when clang was forked.
