[Bug c++/100109] [8/9/10/11 Regression] ICE: unexpected expression 'E' of kind template_parm_index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100109 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 c++/91706] [8/9/10/11 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in equate_type_number_to_die, at dwarf2out.c:5782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91706 --- Comment #7 from Jason Merrill --- Created attachment 50632 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50632=edit near fix This seemed like a fix, but it breaks the modules/merge-8 testcase, and debugging that is being slow.
[Bug libstdc++/95983] `std::counted_iterator>>` fails to satisfy `std::input_or_output_iterator`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95983 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Patrick Palka --- P2259R1 (wg21.link/p2259r1) fixes this issue and similar ones. Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568272.html
[Bug c/51971] unclear/unverified restrictions on attribute((const|pure))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51971
--- Comment #5 from David Stone ---
After compiling this code
```
struct s {
s();
};
s::s() {}
s g() {
return s();
}
```
with `-O3 -Wsuggest-attribute=pure -Wsuggest-attribute=const`
I get the output
```
: In function 's g()':
:7:3: warning: function might be candidate for attribute 'const'
[-Wsuggest-attribute=const]
7 | s g() {
| ^
Compiler returned: 0
```
[Bug fortran/100149] Seg fault passing to CHARACTER(*), DIMENSION(*), INTENT(IN), OPTIONAL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100149 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- Update 11 when it is available. I get % gfcx -o z -O a.f90 % ./z Zone_t Zone_t Zone_t
[Bug target/100108] [10/11 Regression] powerpc: recognize 32-bit CPU as POWER9 with -misel option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100108 --- Comment #7 from Rin Okuyama --- Thank you for discussion. The proposed patch works fine for me (except for missing ``;'' at the end of the line).
[Bug d/98584] Many D tests FAIL with SIGBUS in read_encoded_value_with_base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98584
--- Comment #2 from Iain Buclaw ---
Running all D torture tests on sparc-sun-solaris2.11 with the RUNTESTFLAGS
--target_board=unix\{,-m64\}", I don't see any failures that arise in any f the
supported tests now.
---
=== gdc Summary for unix ===
# of expected passes1520
# of unsupported tests 300
=== gdc Summary for unix/-m64 ===
# of expected passes1520
# of unsupported tests 300
=== gdc Summary ===
# of expected passes3040
# of unsupported tests 600
---
A variant of this patch can be backported to the gcc-10 branch as well if it is
useful.
[Bug d/98584] Many D tests FAIL with SIGBUS in read_encoded_value_with_base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98584 --- Comment #1 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:30b11d8d1be9c683f1517472c47a3cb69df02c4f commit r11-8254-g30b11d8d1be9c683f1517472c47a3cb69df02c4f Author: Iain Buclaw Date: Tue Apr 20 02:09:51 2021 +0200 libphobos: Fix SIGBUS in read_encoded_value_with_base on sparc-sun-solaris (PR98584) Instead of unsafe pointer dereferencing, use memcpy() to read encoded values from memory. The function `read_encoded_value' has been updated to accept a ref parameter, this simplifies handling of the pointer to memory needing to be read. libphobos/ChangeLog: PR d/98584 * libdruntime/gcc/deh.d (scanLSDA): Update calls to read_uleb128 and read_encoded_value. (actionTableLookup): Update calls to read_sleb128 and read_encoded_value_with_base. * libdruntime/gcc/unwind/pe.d (read_uleb128): Update signature. (read_sleb128): Update signature. (read_unaligned): New function. (read_encoded_value_with_base): Update signature. Call read_unaligned instead of unsafe pointer dereferencing. (read_encoded_value): Update signature.
[Bug fortran/100149] New: Seg fault passing to CHARACTER(*), DIMENSION(*), INTENT(IN), OPTIONAL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100149 Bug ID: 100149 Summary: Seg fault passing to CHARACTER(*), DIMENSION(*), INTENT(IN), OPTIONAL Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: brtnfld at hdfgroup dot org Target Milestone: --- Created attachment 50631 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50631=edit The program has two lines of doing that same thing, the lines are marked which fail. The attached program fails with: Program received signal SIGSEGV, Segmentation fault. 0x143c783f in __memmove_sse2_unaligned_erms () from /lib64/libc.so.6 The program worked with 10.1.0 (and 9.3.1, 7.5.0) and fails with 10.2.0
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 97536, which changed state. Bug 97536 Summary: [concepts] parser segfault for concept defined in function template https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97536 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/97536] [concepts] parser segfault for concept defined in function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97536 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Marek Polacek --- Fixed in GCC 11.
[Bug c++/97536] [concepts] parser segfault for concept defined in function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97536
--- Comment #3 from CVS Commits ---
The master branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:29d8838c5ecaf70ce552fea7639ec1f34adb2e04
commit r11-8252-g29d8838c5ecaf70ce552fea7639ec1f34adb2e04
Author: Marek Polacek
Date: Mon Apr 19 16:21:46 2021 -0400
c++: ICE with concept defined in function [PR97536]
This is an ICE-on-invalid, but I keep seeing it when reducing code so
I'd like to fix it. We crash on
template void forward() {
concept C = true;
}
which breaks two requirements:
[temp.concept]/1: A concept is a template ...
[temp.concept]/3: A concept-definition shall inhabit a namespace scope.
This patch adds a test that exercises broken code and fixes the ICE
by checking that a concept-definition is defined at namespace scope.
gcc/cp/ChangeLog:
PR c++/97536
* decl.c (grokvardecl): Given an error when a concept is not
defined
at namespace scope.
gcc/testsuite/ChangeLog:
PR c++/97536
* g++.dg/concepts/diagnostic16.C: New test.
[Bug libstdc++/98678] 30_threads/future/members/poll.cc execution test FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98678 seurer at gcc dot gnu.org changed: What|Removed |Added CC||seurer at gcc dot gnu.org Target|i386-pc-solaris2.11,|i386-pc-solaris2.11, |x86_64-pc-solaris2.11, |x86_64-pc-solaris2.11, |arm-none-linux-gnueabi, |arm-none-linux-gnueabi, |hppa-unknown-linux-gnu, |hppa-unknown-linux-gnu, |x86_64-pc-linux-gnu |x86_64-pc-linux-gnu, ||powerpc64-linux-gnu --- Comment #2 from seurer at gcc dot gnu.org --- FYI I am seeing this every so often on powerpc64 BE on an older power 7 machine, too.
[Bug d/98457] [d] writef!"%s" doesn't work with MonoTime / SysTick
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98457 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Iain Buclaw --- ICE has been fixed. The library related errors are more to do with the version of the D compiler in tree, rather than an issue with gdc itself.
[Bug d/98457] [d] writef!"%s" doesn't work with MonoTime / SysTick
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98457 --- Comment #5 from CVS Commits --- The releases/gcc-9 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:fda5b17a89e5066e19371ea138253bbb9cad262a commit r9-9364-gfda5b17a89e5066e19371ea138253bbb9cad262a Author: Iain Buclaw Date: Mon Apr 19 18:45:32 2021 +0200 d: Fix ICE in when formating a string with '%' or '`' characters (PR98457) The percentage character was being confused for a format specifier in pp_format(), whilst the backtick character was confused for the beginning of a quoted string in expand_d_format(). Both are now properly escaped to avoid the ICE. gcc/d/ChangeLog: PR d/98457 * d-diagnostic.cc (expand_d_format): Handle escaped backticks. (escape_d_format): New funtion. (verror): Call escape_d_format on prefixing strings. (vdeprecation): Likewise. gcc/testsuite/ChangeLog: PR d/98457 * gdc.dg/pr98457.d: New test. (cherry picked from commit dc7d1c74ffb1cc85e67984632f581d526c783770)
[Bug d/98457] [d] writef!"%s" doesn't work with MonoTime / SysTick
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98457 --- Comment #4 from CVS Commits --- The releases/gcc-10 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:19fc127321c7fe3962bd8b6c0064b224ab14aec7 commit r10-9718-g19fc127321c7fe3962bd8b6c0064b224ab14aec7 Author: Iain Buclaw Date: Mon Apr 19 18:45:32 2021 +0200 d: Fix ICE in when formating a string with '%' or '`' characters (PR98457) The percentage character was being confused for a format specifier in pp_format(), whilst the backtick character was confused for the beginning of a quoted string in expand_d_format(). Both are now properly escaped to avoid the ICE. gcc/d/ChangeLog: PR d/98457 * d-diagnostic.cc (expand_d_format): Handle escaped backticks. (escape_d_format): New funtion. (verror): Call escape_d_format on prefixing strings. (vdeprecation): Likewise. gcc/testsuite/ChangeLog: PR d/98457 * gdc.dg/pr98457.d: New test. (cherry picked from commit dc7d1c74ffb1cc85e67984632f581d526c783770)
[Bug tree-optimization/100081] [11 Regression] Compile time hog in irange since r11-4135-ge864d395b4e862ce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100081 --- Comment #13 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:329d2f0df7d6d22c87ab3338b94caef68139cd58 commit r11-8251-g329d2f0df7d6d22c87ab3338b94caef68139cd58 Author: Andrew MacLeod Date: Fri Apr 16 17:08:51 2021 -0400 tree-optimization/100081 - Limit depth of logical expression windback. Limit how many logical expressions GORI will look back through when evaluating outgoing edge range. PR tree-optimization/100081 * gimple-range-cache.h (ranger_cache): Inherit from gori_compute rather than gori_compute_cache. * gimple-range-gori.cc (is_gimple_logical_p): Move to top of file. (range_def_chain::m_logical_depth): New member. (range_def_chain::range_def_chain): Initialize m_logical_depth. (range_def_chain::get_def_chain): Don't build defchains through more than LOGICAL_LIMIT logical expressions. * params.opt (param_ranger_logical_depth): New.
[Bug middle-end/99797] accessing uninitialized automatic variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99797 --- Comment #11 from Martin Uecker --- (In reply to Ivan Sorokin from comment #10) ... > > is a bug if this choice is unreasonable and does not serve its users well. > > Do you have some specific proposal in mind? > > Currently a user has these 5 options: > 1. Using -O0 suppressing optimizations. > 2. Using -fno-tree-ccp suppressing this specific optimization. Optimizations are important, so this is not really an option. > 3. Using -Wall and relying on warnings. It is not clear to me that this fully addresses the problem. GCC does not warn about all possible accesses to uninitialized variables. > 4. (in theory) Using static analyzer -fanalyzer. It doesn't detect this error >at the moment, but I believe can be taught detecting this. This may be helpful. > 5. Using dynamic analyzer like valgrind. This is too expensive for production and also only useful for limited testing. > It seems that you find existing options insufficient and want another one. I want the optimizer to assume that uninitialized variables have an unknown but fixed value. Then one could still optimize almost as well *and* get analyzable and more benign behavior even when uninitialized variables are accessed. Optimizers already know how to deal with variables of unknown content, so this should be fairly easy to implement (maybe I will try). I would also like something such as -fsanitize=undefined which detects for uninitialized variables at run-time. Best, Martin
[Bug c++/100127] [coroutines] internal compiler error compiling promise with custom awaiter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100127
--- Comment #2 from Riccardo Brugo ---
(In reply to Iain Sandoe from comment #1)
> I think that this issue is already fixed in the released 10.3 branch and in
> master (will shortly become GCC11). Please could you try one of those?
>
> $ ./gcc-10/gcc-10/bin/g++ -std=c++20 -fcoroutines pr100127.C -S -save-temps
> pr100127.C: In function ‘future create_future()’:
> pr100127.C:54:8: error: the coroutine promise type
> ‘std::__n4861::__coroutine_traits_impl::promise_type’ {aka
> ‘future::promise_type’} declares both ‘return_value’ and ‘return_void’
>54 | future create_future()
> |^
> pr100127.C:49:14: note: ‘return_void’ declared here
>49 | void return_void() {}
> | ^~~
> pr100127.C:31:14: note: ‘return_value’ declared here
>31 | void return_value(value_type val) {
> | ^~~~
>
> ===
>
> $ ./gcc-master/gcc-11-0-1/bin/g++ -std=c++20 -fcoroutines pr100127.C -S
> -save-temps
> pr100127.C: In function ‘future create_future()’:
> pr100127.C:54:8: error: the coroutine promise type
> ‘std::__n4861::__coroutine_traits_impl::promise_type’ {aka
> ‘future::promise_type’} declares both ‘return_value’ and ‘return_void’
>54 | future create_future()
> |^
> pr100127.C:49:14: note: ‘return_void’ declared here
>49 | void return_void() {}
> | ^~~
> pr100127.C:31:14: note: ‘return_value’ declared here
>31 | void return_value(value_type val) {
> | ^~~~
Removing the `return_void` member function will trigger a compilation error in
trunk (https://godbolt.org/z/7vfT89KEx) and a segmentation fault in 10.3
(https://godbolt.org/z/7b37sPbfo)
[Bug fortran/100136] [11 Regression] ICE, regression, using flag -fcheck=pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100136 --- Comment #2 from anlauf at gcc dot gnu.org --- We do not properly handle the VALUE attribute. Reduced testcase: program p implicit none class(*), allocatable :: d call add_class (d) contains subroutine add_class (d) class(*), value :: d end subroutine end program
[Bug debug/100148] [10/11 Regression] -fcompare-debug failure (length) with -O2 -fno-dce -fno-tree-dce -fno-tree-dominator-opts -fno-tree-sink
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100148 --- Comment #2 from Jakub Jelinek --- I bet it goes wrong during cprop1, at least fwprop1 dumps with --param min-nondebug-insn-uid=1 look good to me and cprop1 contains -rescanning insn with uid = 10033. -GLOBAL CONST-PROP: Replacing reg 82 in jump_insn 10033 with constant (const_int 0 [0]) -Purged edges from bb 8 -deleting insn with uid = 10033. -GLOBAL CONST-PROP: Replacing reg 82 in insn 10029 with constant (const_int 0 [0]) -CPROP of foo, 14 basic blocks, 592 bytes needed, 0 local const props, 0 local copy props, 2 global const props, 0 global copy props +CPROP of foo, 14 basic blocks, 592 bytes needed, 0 local const props, 0 local copy props, 0 global const props, 0 global copy props as the first major difference.
[Bug d/98494] libphobos: std.process Config.stderrPassThrough missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98494 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Iain Buclaw --- Added to phobos.
[Bug d/98457] [d] writef!"%s" doesn't work with MonoTime / SysTick
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98457 --- Comment #3 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:dc7d1c74ffb1cc85e67984632f581d526c783770 commit r11-8250-gdc7d1c74ffb1cc85e67984632f581d526c783770 Author: Iain Buclaw Date: Mon Apr 19 18:45:32 2021 +0200 d: Fix ICE in when formating a string with '%' or '`' characters (PR98457) The percentage character was being confused for a format specifier in pp_format(), whilst the backtick character was confused for the beginning of a quoted string in expand_d_format(). Both are now properly escaped to avoid the ICE. gcc/d/ChangeLog: PR d/98457 * d-diagnostic.cc (expand_d_format): Handle escaped backticks. (escape_d_format): New funtion. (verror): Call escape_d_format on prefixing strings. (vdeprecation): Likewise. gcc/testsuite/ChangeLog: PR d/98457 * gdc.dg/pr98457.d: New test.
[Bug d/98494] libphobos: std.process Config.stderrPassThrough missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98494 --- Comment #1 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:e19c6389966216af5925d2917a206cedc40540e8 commit r11-8249-ge19c6389966216af5925d2917a206cedc40540e8 Author: Iain Buclaw Date: Mon Apr 19 13:51:02 2021 +0200 libphobos: Merge upstream druntime 89f870b7, phobos e6907ff3e Phobos changes: - Synchronize C bindings with the latest port fixes in upstream druntime. - Add Config.stderrPassThrough to std.process (PR98494). Reviewed-on: https://github.com/dlang/druntime/pull/3448 https://github.com/dlang/phobos/pull/7984 libphobos/ChangeLog: PR d/98494 * libdruntime/MERGE: Merge upstream druntime 89f870b7. * src/MERGE: Merge upstream phobos e6907ff3e.
[Bug d/98058] libphobos: Support building on *-*-darwin*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98058 --- Comment #1 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:6eae7549b8a350b92435be904efed195bd190bae commit r11-8248-g6eae7549b8a350b92435be904efed195bd190bae Author: Iain Buclaw Date: Mon Apr 19 14:48:32 2021 +0200 libphobos: Add Thread/Fiber support code for Darwin (PR98058) libphobos/ChangeLog: PR d/98058 * configure: Regenerate. * libdruntime/Makefile.am (DRUNTIME_DSOURCES_DARWIN): Add core/sys/darwin/config.d * libdruntime/Makefile.in: Regenerate. * libdruntime/config/powerpc/switchcontext.S: Implement fiber_switchContext for __MACH__. * libdruntime/config/x86/switchcontext.S: Likewise. * libdruntime/core/sys/darwin/config.d: New file. * libdruntime/core/thread/fiber.d (Fiber.getThis): Mark noinline. (UnsafeFiberMigration): Define for OSX/X86 and OSX/X86_64. * libdruntime/core/thread/osthread.d (callWithStackShell): Add inline assembler implementation for X86, X86_64, PPC, and PPC64. * libdruntime/core/thread/threadbase.d (ThreadBase.getThis): Mark noinline. * libdruntime/gcc/deh.d (FuncTable): Remove definition. * m4/druntime/os.m4 (DRUNTIME_OS_MINFO_BRACKETING): Check for right bracket symbol on darwin* targets. * testsuite/libphobos.thread/fiber_guard_page.d: Update test to support ucontext-based Fibers.
[Bug d/99794] libphobos: Support building on *-*mingw*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99794 --- Comment #1 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:b66e72b43e1e8f402dc958ce3cca35f7c273340d commit r11-8247-gb66e72b43e1e8f402dc958ce3cca35f7c273340d Author: Iain Buclaw Date: Mon Apr 19 14:36:14 2021 +0200 libphobos: Add D runtime support code for MinGW (PR99794) libphobos/ChangeLog: PR d/99794 * libdruntime/Makefile.am (DRUNTIME_SOURCES_CONFIGURED): Add config/mingw/msvc.c on DRUNTIME_OS_MINGW. * libdruntime/Makefile.in: Regenerate. * libdruntime/config/mingw/msvc.c: New file. * libdruntime/config/mingw/switchcontext.S (fiber_switchContext): Fix function definition. * libdruntime/gcc/deh.d (__gdc_personality_seh0): Fix call to _GCC_specific_handler. * libdruntime/gcc/gthread.d (__gthread_once_t): Fix definition. * libdruntime/gcc/unwind/generic.d (_GCC_specific_handler): Fix declaration. * libdruntime/rt/dmain2.d (rt_loadLibrary): Remove function. (rt_loadLibraryW): Remove function. (initLibrary): Remove function. (rt_unloadLibrary): Remove function.
[Bug d/99691] OpenBSD support for GDC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99691 --- Comment #4 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:d86e60855f05a0e493f8362c12bfd40d5432d337 commit r11-8246-gd86e60855f05a0e493f8362c12bfd40d5432d337 Author: Iain Buclaw Date: Mon Apr 19 14:23:00 2021 +0200 libphobos: Add section support code for OpenBSD (PR99691) libphobos/ChangeLog: PR d/99691 * configure: Regenerate. * libdruntime/config/common/threadasm.S: Add __OpenBSD__. * libdruntime/gcc/backtrace.d: Import core.sys.openbsd.dlfcn on OpenBSD platforms. * libdruntime/gcc/sections/elf.d (SharedElf): Define on OpenBSD. (linkMapForHandle): Implement for OpenBSD. (exeLinkMap): Remove. (getDependencies): Adjust dlpi_addr on OpenBSD. (handleForName): Implement for OpenBSD. (IterateManually): Define on OpenBSD. * libdruntime/gcc/sections/package.d (SectionsElf): Define on OpenBSD. * m4/druntime/libraries.m4 (DRUNTIME_LIBRARIES_ATOMIC): Test for enable_libatomic. (DRUNTIME_LIBRARIES_BACKTRACE): Test for enable_libbacktrace.
[Bug debug/100148] [10/11 Regression] -fcompare-debug failure (length) with -O2 -fno-dce -fno-tree-dce -fno-tree-dominator-opts -fno-tree-sink
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100148 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Target Milestone|--- |10.4 Last reconfirmed||2021-04-19 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r10-7268-g529ea7d9596b26ba103578eeab448e9862a2d2c5
[Bug target/100067] Unexpected warning for -mcpu=neoverse-n1 when configured with --with-fpu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100067 --- Comment #7 from CVS Commits --- The master branch has been updated by Richard Earnshaw : https://gcc.gnu.org/g:3bffc4b37e85c7f6092dfb0fbe4067d268e97b46 commit r11-8245-g3bffc4b37e85c7f6092dfb0fbe4067d268e97b46 Author: Richard Earnshaw Date: Mon Apr 19 16:56:31 2021 +0100 arm: partial revert of r11-8168 [PR100067] This is a partial revert of r11-8168. The overall purpose of the commit is retained (to fix a bogus warning when -mfpu= is used in combination with eg -mcpu=neoverse-v1), but it removes the hunk that changed the subsequent feature bits for features of a simd/fp unit that cannot be described by -mfpu. While I still think that is the correct direction of travel, it's somewhat disruptive and not appropriate for late stage4. I'll revisit for gcc-12. gcc: PR target/100067 * config/arm/arm.c (arm_configure_build_target): Do not strip extended FPU/SIMD feature bits from the target ISA when -mfpu is specified (partial revert of r11-8168).
[Bug tree-optimization/100137] [10/11 Regression] -Warray-bounds false positive on varying offset plus negative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100137 --- Comment #4 from Moritz Beutel --- Interesting. I had figured that the test case could probably be reduced further, but I didn't try because the bug appeared so brittle. Slightly changing seemingly unrelated details made it vanish: - // line 10: if ( _size != 0 && _data == nullptr ) throw 42; // bug //if ( _size != 0 && _data == nullptr ) throw 42; // no bug // line 23: size_t string_length( char const * ptr, size_t max = (size_t) -1 ) // bug size_t string_length( char const * ptr, size_t max = (size_t) -2 ) // no bug // line 26: while ( len < max && ptr[len] ) // bug while ( ptr[len] ) // no bug - Link for experimentation: https://gcc.godbolt.org/z/af8P7v64T
[Bug debug/100148] New: [10/11 Regression] -fcompare-debug failure (length) with -O2 -fno-dce -fno-tree-dce -fno-tree-dominator-opts -fno-tree-sink
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100148 Bug ID: 100148 Summary: [10/11 Regression] -fcompare-debug failure (length) with -O2 -fno-dce -fno-tree-dce -fno-tree-dominator-opts -fno-tree-sink Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz CC: aoliva at gcc dot gnu.org Target Milestone: --- Host: x86_64-pc-linux-gnu Created attachment 50630 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50630=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -O2 -fno-dce -fno-tree-dce -fno-tree-dominator-opts -fno-tree-sink -fcompare-debug testcase.C x86_64-pc-linux-gnu-gcc: error: testcase.C: '-fcompare-debug' failure (length) $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r11-8244-20210419132718-g714bdc31b69-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/11.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r11-8244-20210419132718-g714bdc31b69-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.0.1 20210419 (experimental) (GCC)
[Bug tree-optimization/100137] [10/11 Regression] -Warray-bounds false positive on varying offset plus negative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100137
Martin Sebor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
--- Comment #3 from Martin Sebor ---
The warning bug was introduced in r262893 (GCC 10). A trivial test case is:
$ cat a.c && gcc -O2 -S -Wall a.c
int f (long i)
{
const char *p = "123";
p += i;
return p[-1];
}
a.c: In function ‘f’:
a.c:5:11: warning: array subscript -1 is outside array bounds of ‘char[4]’
[-Warray-bounds]
5 | return p[-1];
| ~^~~~
This same thing is handled correctly elsewhere (e.h., -Wstringop_overflow) so
the ideal fix is to replace the warning code with the new pointer_query class.
[Bug tree-optimization/100137] [10/11 Regression] -Warray-bounds false positive on varying offset plus negative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100137
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
Ever confirmed|0 |1
Known to work||10.2.0
Component|c++ |tree-optimization
Status|UNCONFIRMED |NEW
Summary|-Werror=array-bounds false |[10/11 Regression]
|positive:"subscript -1 is |-Warray-bounds false
|outside array bounds" |positive on varying offset
||plus negative
Last reconfirmed||2021-04-19
Known to fail||10.3.0, 11.0
--- Comment #2 from Martin Sebor ---
Confirmed. The bug is caused by -Warray-bounds ignoring varying offsets
instead of setting the offset range to that of the referenced object.
Bisection points to g:e7fd3b783238d034018443e43a58ff87908b4db6 but that just
exposed the underlying bug in the warning. The test case triggers the false
positive in 10.3.0 and 11.0 but not in 10.2.0 or prior.
int main ()
{
...
[local count: 114863531]:
# len_11 = PHI <18446744073709551615(3), len_23(4)>
s ={v} {CLOBBER};
s.first_ =
iftmp.0_13 = + len_11; <<< len_11:
VR_VARYING, iftmp.0_13 taken to point to
s.last_ = iftmp.0_13;
_15 = len_11 != 0;
MEM[(char &)iftmp.0_13 + 18446744073709551615] = 50; <<< iftmp.0_13[-1] =
'2'; <<< -Warray-bounds
hello ={v} {CLOBBER};
s ={v} {CLOBBER};
return 0;
}
[Bug target/99555] [OpenMP/nvptx] Execution-time hang for simple nested OpenMP 'target'/'parallel'/'task' constructs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99555
--- Comment #9 from Tom de Vries ---
(In reply to Tom de Vries from comment #8)
> This fixes the hang:
This is a less intrusive solution, and is easier to transplant into
gomp_team_barrier_wait_cancel_end:
...
diff --git a/libgomp/config/nvptx/bar.c b/libgomp/config/nvptx/bar.c
index c5c2fa8829b..cb7b299c6a8 100644
--- a/libgomp/config/nvptx/bar.c
+++ b/libgomp/config/nvptx/bar.c
@@ -91,6 +91,9 @@ gomp_team_barrier_wait_end (gomp_barrier_t *bar,
gomp_barrier_state_t state)
{
gomp_barrier_handle_tasks (state);
state &= ~BAR_WAS_LAST;
+ if (team->task_count != 0)
+ __builtin_abort ();
+ bar->total = 1;
}
else
{
@@ -157,6 +160,9 @@ gomp_team_barrier_wait_cancel_end (gomp_barrier_t *bar,
{
gomp_barrier_handle_tasks (state);
state &= ~BAR_WAS_LAST;
+ if (team->task_count != 0)
+ __builtin_abort ();
+ bar->total = 1;
}
else
{
...
[Bug d/98457] [d] writef!"%s" doesn't work with MonoTime / SysTick
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98457
--- Comment #2 from Iain Buclaw ---
Reduced test:
---
void main() { writef!"%s"; }
---
Any error that deals with a symbol that has a formatting string in it will
trigger a segmentation fault.
[Bug target/100108] [10/11 Regression] powerpc: recognize 32-bit CPU as POWER9 with -misel option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100108 --- Comment #6 from Jakub Jelinek --- LGTM.
[Bug target/100108] [10/11 Regression] powerpc: recognize 32-bit CPU as POWER9 with -misel option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100108 Segher Boessenkool changed: What|Removed |Added Target|powerpc--netbsd |powerpc Last reconfirmed||2021-04-19 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/100108] [10/11 Regression] powerpc: recognize 32-bit CPU as POWER9 with -misel option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100108 --- Comment #5 from Segher Boessenkool --- Created attachment 50629 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50629=edit Proposed simpler patch A simpler patch. I'll commit this later today (if no one stops me).
[Bug target/100108] [10/11 Regression] powerpc: recognize 32-bit CPU as POWER9 with -misel option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100108 --- Comment #4 from Segher Boessenkool --- (In reply to Andrew Pinski from comment #1) > e500 support had been moved to the powerpcspe target; so assuming power9 for > -misel is correct. > > e500mc support is still there though. There never *was* separate e500 support in GCC!
[Bug target/100108] [10/11 Regression] powerpc: recognize 32-bit CPU as POWER9 with -misel option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100108
Jakub Jelinek changed:
What|Removed |Added
CC||dje at gcc dot gnu.org,
||jakub at gcc dot gnu.org,
||segher at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
Indeed, several rs6000-cpus.def entries have MASK_ISEL:
RS6000_CPU ("8540", PROCESSOR_PPC8540, MASK_STRICT_ALIGN | MASK_ISEL)
RS6000_CPU ("8548", PROCESSOR_PPC8548, MASK_STRICT_ALIGN | MASK_ISEL)
RS6000_CPU ("e500mc", PROCESSOR_PPCE500MC, MASK_PPC_GFXOPT | MASK_ISEL)
RS6000_CPU ("e500mc64", PROCESSOR_PPCE500MC64,
MASK_POWERPC64 | MASK_PPC_GFXOPT | MASK_ISEL)
RS6000_CPU ("e5500", PROCESSOR_PPCE5500,
MASK_POWERPC64 | MASK_PPC_GFXOPT | MASK_ISEL)
RS6000_CPU ("e6500", PROCESSOR_PPCE6500, POWERPC_7400_MASK | MASK_POWERPC64
| MASK_MFCRF | MASK_ISEL)
So perhaps we should consider MASK_ISEL as power9 thing only for flags which
include power7-ish or later ISAs?
--- rs6000.c.jj42021-04-09 10:18:15.582266372 +0200
+++ rs6000.c2021-04-19 16:30:07.033208577 +0200
@@ -5766,6 +5766,9 @@ rs6000_machine_from_flags (void)
/* Disable the flags that should never influence the .machine selection. */
flags &= ~(OPTION_MASK_PPC_GFXOPT | OPTION_MASK_PPC_GPOPT);
+ if ((flags & (ISA_3_1_MASKS_SERVER
+ & ~(ISA_2_5_MASKS_SERVER | MASK_ISEL))) == 0)
+flags &= ~MASK_ISEL;
if ((flags & (ISA_3_1_MASKS_SERVER & ~ISA_3_0_MASKS_SERVER)) != 0)
return "power10";
[Bug c++/92031] [9 Regression] Incorrect "taking address of r-value" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92031 Chip Kerchner changed: What|Removed |Added CC||chip.kerchner at ibm dot com --- Comment #5 from Chip Kerchner --- Please backport this fix into 9.4 or 9.5.
[Bug libstdc++/90943] Visiting inherited variants no longer works in 9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90943 --- Comment #7 from Jonathan Wakely --- Implemented downstream: https://gitlab.com/jonathan-wakely/gcc/-/commit/484308ad163862632ae7e710c5d909be385450aa
[Bug tree-optimization/100081] [11 Regression] Compile time hog in irange since r11-4135-ge864d395b4e862ce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100081 --- Comment #12 from Andrew Macleod --- (In reply to Richard Biener from comment #10) > (In reply to Andrew Macleod from comment #8) > > OMG. Don't bother reducing. I can see the problem. > > > > EVRP is fine, but when wrestrict runs, its quite late, and the CFG has > > > > [local count: 28382607]: > > <...> > > _571 = _61 >= _593; > > _3583 = _724 + _3992; > > _2220 = _831 <= _3583; > > _47 = _571 | _2220; > > _2935 = _376 * 2; > > _3966 = _725 + _2935; > > _3024 = _61 >= _3966; > > _4219 = _3992 * 2; > > _4218 = _725 + _4219; > > _1836 = _831 <= _4218; > > _3080 = _1836 | _3024; > > <...> > > _5348 = _5347 & _32080; > > _5349 = _5348 & _32151; > > _5350 = _5349 & _32176; > > _5351 = _5350 & _32488; > > _5352 = _5351 & _33691; > > _5353 = _5352 & _33762; > > _5354 = _5353 & _34753; > > _35662 = _5354 & _34824; > > if (_35662 != 0) > > goto ; [90.00%] > > else > > goto ; [10.00%] > > > > Its a 7200 stmt basic block, made up of calculations and 2614 ORs and 1480 > > ANDs. > > > > A request is made for a range which can be exported from this block, and > > ranger is dutifully trying everything it can to process those blocks. > > > > Each AND/OR is a logical expression which evaluates a TRUE and FALSE range > > for each operands, so it calculates up to 4 ranges for each pair of > > operands. I knew this could get out of hand in pathological cases, so we > > introduced a logical cache to help resolve this and avoid extra work. Its > > actually making this one worse I think. > > Hmm, still the overall work should be linear to produce ranges for all > of the SSA defs in this BB, no? As heuristic you might want to avoid > producing ranges for single-use defs, like those that are just used in > another & or | combination? Wrestrict should only be interested in > ranges for the "tails" of this &| tree (for example _61 in _61 >= _3966). > Since the direction is bottom up, it is no longer linear. This has probably never been explain very well. lets make up a simple example: if (x > 2 && x < 10 || x == 15) for unsigned x turns into: _1 = x_8(D) + 4294967293; _2 = _1 <= 6; _3 = x_8(D) == 15; _4 = _2 | _3; if (_4 != 0) goto ; [INV] else goto ; [INV] and we can calculate the following ranges (note none of them are calculated in advance, only if asked/required) : 2->3 (T) _4 : bool [1, 1] 2->3 (T) x_8(D) : unsigned int [3, 9][15, 15] 2->5 (F) _1 : unsigned int [7, +INF] 2->5 (F) _2 : bool [0, 0] 2->5 (F) _3 : bool [0, 0] 2->5 (F) _4 : bool [0, 0] 2->5 (F) x_8(D) : unsigned int [0, 2][10, 14][16, +INF] When a client asks for the range of x_8 on the true edge, we have to solve [1,1] = _4 != 0, which in turn feeds back to the def of _4 as: [1,1] = _2 | _3 There are 3 possible ways this branch can be taken.. a) _2 = [1, 1], _3 = [1, 1] b) _2 = [0, 0], _3 = [1, 1] c) _2 = [1, 1], _3 = [0, 0] In order to calculate a precise range for x_8, we need to calculate the range of x_8 for both possible values of _2 and _3 and combine them.. I wont trace the actual calculation for each one, but it boils down to _2 = [0, 0] produces x_8 = ~[3, 9] _2 = [1, 1] produces x_8 = [3, 9] _3 = [0, 0] produces x_8 = ~[15, 15] _3 = [1, 1] produces x_8 = [15, 15] Then we combine them with the 2 possible combinations, and produce the final range of unsigned int [3, 9][15, 15]. Once upon a time I tried to "simplify" this a couple of different ways, but in more complex situations, it inevitably fails to produce the correct range.. so instead, we simply do the calculations exactly as the statement requires and combine them. The logical OR spawned 4 requests for the range of x_8.. so when these logical expressions feed each other, we get the exponential growth of computations. The logical cache was suppose to resolve this by caching the true and false values of x_8 for _2 and _3 eliminating the need to recalculate them. More complex cases with many ssa_names feeding through a boolean condition cause it to not function well. As for single use-use defs.. There is nothing special about them. We never produce ranges for anything that is not used an an outgoing edge calculation, regardless of how many uses there are. Those are tagged and we simply use their global value. Furthermore, we never produce ranges for anything that isn't either explicitly requested, or used in a calculation that affects an explicit request. In this case for instance, I forget the name that restrict asked for, but lets say it was _3992. we start at the bottom of the block and work back to the definition of _3992. During the evaluation, we go through many single-use cases which we will need the ranges for as they feed the condition at the bottom and may therefore affect the outcome. Anything above _3992's def is never evaluated. Up until now, I haven't really throttled anything..
[Bug libstdc++/94080] -mabi=ieeelongdouble and -mfloat128 cause libstc++ header breakage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94080 --- Comment #4 from Bill Schmidt --- Thanks, Jonathan!
[Bug target/100075] [9/10 Regression] unneeded sign extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100075 --- Comment #5 from CVS Commits --- The master branch has been updated by Christophe Lyon : https://gcc.gnu.org/g:714bdc31b69688ae2eaeb9807a48e0f101fecf4e commit r11-8244-g714bdc31b69688ae2eaeb9807a48e0f101fecf4e Author: Christophe Lyon Date: Mon Apr 19 13:24:31 2021 + aarch64: Fix up 2 other combine opt regressions vs. GCC8 [PR100075] The testcase is endianness dependent and works only on little-endian. 2021-04-19 Christophe Lyon PR target/100075 gcc/testsuite/ * gcc.target/aarch64/pr100075.c: Add aarch64_little_endian effective target.
[Bug c++/99936] [modules] FAIL: g++.dg/modules/xtreme-header* on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99936 Dominique d'Humieres changed: What|Removed |Added CC||nathan at gcc dot gnu.org Blocks||99227 Ever confirmed|0 |1 Summary|FAIL: |[modules] FAIL: |g++.dg/modules/xtreme-heade |g++.dg/modules/xtreme-heade |r* on Darwin|r* on Darwin Last reconfirmed||2021-04-19 Status|UNCONFIRMED |NEW --- Comment #1 from Dominique d'Humieres --- See also https://gcc.gnu.org/pipermail/gcc-testresults/2021-April/682945.html and friends. It would be nice to have this PR fixed for GCC 11.1! Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99227 [Bug 99227] [meta] [modules] Bugs relating to header-units of STL header files
[Bug preprocessor/100142] [11 Regression] ICE in linemap_position_for_loc_and_offset, at libcpp/line-map.c:1004 since r11-8150-g4acb3af3669db4ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100142 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed.
[Bug preprocessor/100142] [11 Regression] ICE in linemap_position_for_loc_and_offset, at libcpp/line-map.c:1004 since r11-8150-g4acb3af3669db4ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100142 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:2f422b550ff6351d312e6c81a00b488d9280bfff commit r11-8243-g2f422b550ff6351d312e6c81a00b488d9280bfff Author: Richard Biener Date: Mon Apr 19 10:07:35 2021 +0200 preprocessor/100142 - revert unwanted change in last commit This reverts a s/column_offset/column/ change in the fix for PR99446. 2021-04-19 Richard Biener PR preprocessor/100142 libcpp/ * line-map.c (linemap_position_for_loc_and_offset): Revert unintended s/column_offset/column/ change. gcc/testsuite/ * gcc.dg/pr100142.c: New testcase. * g++.dg/diagnostic/pr72803.C: Revert last change.
[Bug fortran/100110] Parameterized Derived Types, problems with global variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100110 --- Comment #2 from Paul Thomas --- Created attachment 50628 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50628=edit Fix for the PR As I thought, the fix is trivial. Paul
[Bug c++/99805] [9 Regression] filesystem::path::parent_path got a wrong path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99805 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from Jonathan Wakely --- And 9.4 too.
[Bug c++/99805] [9 Regression] filesystem::path::parent_path got a wrong path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99805 --- Comment #10 from CVS Commits --- The releases/gcc-9 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:056563557e5e6e00d467760744c5b8e8525a06ac commit r9-9362-g056563557e5e6e00d467760744c5b8e8525a06ac Author: Jonathan Wakely Date: Wed Apr 7 16:05:42 2021 +0100 libstdc++: Fix filesystem::path construction from COW string [PR 99805] Calling the non-const data() member on a COW string makes it "leaked", possibly resulting in reallocating the string to ensure a unique owner. The path::_M_split_cmpts() member parses its _M_pathname string using string_view objects and then calls _M_pathname.data() to find the offset of each string_view from the start of the string. However because _M_pathname is non-const that will cause a COW string to reallocate if it happens to be shared with another string object. This results in the offsets calculated for each component being wrong (i.e. undefined) because the string views no longer refer to substrings of the _M_pathname member. The fix is to use the parse.offset(c) member which gets the offset safely. The bug only happens for the path(string_type&&) constructor and only for COW strings. When constructed from an lvalue string the string's contents are copied rather than just incrementing the refcount, so there's no reallocation when calling the non-const data() member. The testsuite changes check the lvalue case anyway, because we should probably change the deep copying to just be a refcount increment (by adding a path(const string_type&) constructor or an overload for __effective_range(const string_type&), for COW strings only). libstdc++-v3/ChangeLog: PR libstdc++/99805 * src/c++17/fs_path.cc (path::_M_split_cmpts): Do not call non-const member on _M_pathname, to avoid copy-on-write. * testsuite/27_io/filesystem/path/decompose/parent_path.cc: Check construction from strings that might be shared. (cherry picked from commit e06d3f5dd7d0c6b4a20fe813e6ee5addd097f560)
[Bug libstdc++/100146] __cpp_lib_to_chars not defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100146 --- Comment #6 from Jonathan Wakely --- I suppose this would be OK: #if _GLIBCXX_HAVE_USELOCALE # define __cpp_lib_to_chars 201611L #endif
[Bug libstdc++/100146] __cpp_lib_to_chars not defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100146 --- Comment #5 from Jonathan Wakely --- It's std::from_chars which incorrectly allocates. It uses strtod which requires a null-terminated string.
[Bug target/99555] [OpenMP/nvptx] Execution-time hang for simple nested OpenMP 'target'/'parallel'/'task' constructs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99555
--- Comment #8 from Tom de Vries ---
This fixes the hang:
...
@@ -91,14 +129,16 @@ gomp_team_barrier_wait_end (gomp_barrier_t *bar,
gomp_barrier_state_t state)
{
gomp_barrier_handle_tasks (state);
state &= ~BAR_WAS_LAST;
+ gen = __atomic_load_n (>generation, MEMMODEL_ACQUIRE);
+ if (gen == state + BAR_INCR)
+ return;
}
else
{
...
I'm not yet sure about the implementation, but the idea is to detect that
gomp_team_barrier_done was called during gomp_barrier_handle_tasks, and then
bail out.
[Bug target/84547] Suboptimal code for int128 masked shifts (ARM64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84547 --- Comment #2 from Richard Earnshaw --- (In reply to Andrew Pinski from comment #1) > Yes int128 (or rather double wide register) shifts are not optimized that > well. They are not used by many people even. I wonder if there is a way to > use vector instructions to do them. Even if there were (and I'm not aware of any), moving values into and out of the vector unit can be expensive so this would likely be a very poor solution.
[Bug libstdc++/100146] __cpp_lib_to_chars not defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100146 --- Comment #4 from Jakub Jelinek --- The uselocale thing could be handled by defining the macros only if _GLIBCXX_HAVE_USELOCALE. Does any implementation actually handle it without memory allocations? I mean, even sprintf can fail with ENOMEM if it needs to allocate memory and looking at glibc __printf_fp_l, there are paths in which it calls malloc as opposed to e.g. alloca.
[Bug middle-end/100144] [OpenMP] Data race with "omp parallel master taskloop ... shared(scalar)"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100144 --- Comment #1 from Jakub Jelinek --- This looks just like a bogus assumption in the testcase. The taskloop directive says that the iterations are split into some tasks. As neither num_tasks nor graintsize clauses are specified, it is implementation defined into how many tasks it is split. But even when those would be specified, there is still no guarantee that the master thread will execute any of those explicit threads, it can easily happen that while the master thread creates the tasks other threads pick those tasks already and there is no task left for the master thread. The test should better use if (i == 0) num_threads = omp_get_num_threads(); then it has a guarantee that it will be executed exactly once.
[Bug target/99555] [OpenMP/nvptx] Execution-time hang for simple nested OpenMP 'target'/'parallel'/'task' constructs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99555
--- Comment #7 from Tom de Vries ---
Created attachment 50627
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50627=edit
debug patch
A bit more analysis.
I'm working with this example, with an actual task to be able to perform a
check afterwards:
...
#include
int i = 1;
int
main (void)
{
#pragma omp target map(tofrom:i)
#pragma omp parallel num_threads(2)
#pragma omp task
{
__atomic_add_fetch (, 1, __ATOMIC_SEQ_CST);
}
assert (i == 3);
return 0;
}
...
And I've forced the plugin to launch with two omp-threads to limit the
dimensions to the minimium:
...
(cuda-gdb) info cuda kernels
Kernel Parent Dev Grid Status SMs Mask GridDim BlockDim Invocation
* 0 - 01 Active 0x0010 (1,1,1) (32,2,1) main$_omp_fn()
...
Furthermore I've made specific instances for the bar.sync team barrier, to get
more meaningful backtraces. So the lifetimes of the two omp-threads look like
this.
THREAD 0:
...
#0 0x00b73aa8 in bar_sync_thread_0 ()
#1 0x00b74a80 in bar_sync_n ()
#2 0x00b72598 in bar_sync_1 ()
#3 0x00b760b8 in gomp_team_barrier_wake ()
#4 0x00b5bc38 in GOMP_task ()
#5 0x00b36a58 in main$_omp_fn () # $1
#6 0x00a7e618 in GOMP_parallel ()
#7 0x00b377a0 in main$_omp_fn$0$impl ()
#8 0x00b3c700 in gomp_nvptx_main ()
#9 0x00b39420 in main$_omp_fn<<<(1,1,1),(32,2,1)>>> ()
#0 0x00b380e8 in main$_omp_fn () # $2
#1 0x00b95178 in gomp_barrier_handle_tasks ()
#2 0x00b76e38 in gomp_team_barrier_wait_end ()
#3 0x00b77dd8 in gomp_team_barrier_wait_final ()
#4 0x00b2a1b8 in gomp_team_end ()
#5 0x00b318d8 in GOMP_parallel_end ()
#6 0x00a7e620 in GOMP_parallel ()
#7 0x00b377a0 in main$_omp_fn$0$impl ()
#8 0x00b3c700 in gomp_nvptx_main ()
#9 0x00b39420 in main$_omp_fn<<<(1,1,1),(32,2,1)>>> ()
#0 0x00b380e8 in main$_omp_fn () # $2
#1 0x00b95178 in gomp_barrier_handle_tasks ()
#2 0x00b76e38 in gomp_team_barrier_wait_end ()
#3 0x00b77dd8 in gomp_team_barrier_wait_final ()
#4 0x00b2a1b8 in gomp_team_end ()
#5 0x00b318d8 in GOMP_parallel_end ()
#6 0x00a7e620 in GOMP_parallel ()
#7 0x00b377a0 in main$_omp_fn$0$impl ()
#8 0x00b3c700 in gomp_nvptx_main ()
#9 0x00b39420 in main$_omp_fn<<<(1,1,1),(32,2,1)>>> ()
#0 0x00b73aa8 in bar_sync_thread_0 ()
#1 0x00b74a80 in bar_sync_n ()
#2 0x00b72598 in bar_sync_1 ()
#3 0x00b760b8 in gomp_team_barrier_wake ()
#4 0x00b94c98 in gomp_barrier_handle_tasks ()
#5 0x00b76e38 in gomp_team_barrier_wait_end ()
#6 0x00b77dd8 in gomp_team_barrier_wait_final ()
#7 0x00b2a1b8 in gomp_team_end ()
#8 0x00b318d8 in GOMP_parallel_end ()
#9 0x00a7e620 in GOMP_parallel ()
#10 0x00b377a0 in main$_omp_fn$0$impl ()
#11 0x00b3c700 in gomp_nvptx_main ()
#12 0x00b39420 in main$_omp_fn<<<(1,1,1),(32,2,1)>>> ()
#0 0x00b73aa8 in bar_sync_thread_0 ()
#1 0x00b74a80 in bar_sync_n ()
#2 0x00b719b8 in bar_sync_3 ()
#3 0x00b76f50 in gomp_team_barrier_wait_end ()
#4 0x00b77dd8 in gomp_team_barrier_wait_final ()
#5 0x00b2a1b8 in gomp_team_end ()
#6 0x00b318d8 in GOMP_parallel_end ()
#7 0x00a7e620 in GOMP_parallel ()
#8 0x00b377a0 in main$_omp_fn$0$impl ()
#9 0x00b3c700 in gomp_nvptx_main ()
#10 0x00b39420 in main$_omp_fn<<<(1,1,1),(32,2,1)>>> ()
^C
#0 0x00b73da8 in bar_sync_thread_0 ()
#1 0x00b74a80 in bar_sync_n ()
#2 0x00b719b8 in bar_sync_3 ()
#3 0x00b76f50 in gomp_team_barrier_wait_end ()
#4 0x00b77dd8 in gomp_team_barrier_wait_final ()
#5 0x00b2a1b8 in gomp_team_end ()
#6 0x00b318d8 in GOMP_parallel_end ()
#7 0x00a7e620 in GOMP_parallel ()
#8 0x00b377a0 in main$_omp_fn$0$impl ()
#9 0x00b3c700 in gomp_nvptx_main ()
#10 0x00b39420 in main$_omp_fn<<<(1,1,1),(32,2,1)>>> ()
...
THREAD 1:
...
#0 0x00b70ae8 in bar_sync_thread_1 ()
#1 0x00b74b80 in bar_sync_n ()
#2 0x00b72598 in bar_sync_1 ()
#3 0x00b760b8 in gomp_team_barrier_wake ()
#4 0x00b5bc38 in GOMP_task ()
#5 0x00b36a58 in main$_omp_fn () # $1
#6 0x00b3cbb8 in gomp_nvptx_main ()
#7 0x00b39420 in main$_omp_fn<<<(1,1,1),(32,2,1)>>> ()
#0 0x00b70ae8 in bar_sync_thread_1 ()
#1 0x00b74b80 in bar_sync_n ()
#2 0x00b719b8 in bar_sync_3 ()
#3 0x00b76f50 in gomp_team_barrier_wait_end ()
#4 0x00b77dd8 in gomp_team_barrier_wait_final ()
#5 0x00b3cd50 in gomp_nvptx_main ()
#6 0x00b39420 in main$_omp_fn<<<(1,1,1),(32,2,1)>>> ()
^C
#0 0x00b3ca30 in gomp_nvptx_main ()
#1
[Bug middle-end/99797] accessing uninitialized automatic variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99797
Ivan Sorokin changed:
What|Removed |Added
CC||vanyacpp at gmail dot com
--- Comment #10 from Ivan Sorokin ---
(Disclaimer: I'm not a GCC developer, I'm just a random guy who reads bugzilla
and
tried making some simple changes to GCC a few times)
(In reply to Martin Uecker from comment #9)
> The behavior of GCC is dangerous as the example in comment #1 show. You can
> not reason at all about the generated code.
My reasoning normally boils down to this: As the program invokes UB therefore
the exact behavior depends on the compiler, the compiler version, the OS and
other factors.
I would like to note that the optimization performed by compiler are not
designed to break user's code. They were designed to optimize some typical
redundancies in programs. It just happened that their combination breaks
unpredictably the code invoking UB.
Normally it is difficult/impossible not to break the code invoking UB
without regressing some optimizations.
Also optimizations performed by compiler change over time, so the exact
result of the breakage inevitably depends on the specific compiler
version.
In theory GCC already has an option that limits the effects of UB: -O0. I
believe this is the only forward-compatible option for that. If we want to
be more precise we can disable only -fno-tree-ccp, but these fine-grained
optimization options changes from one compiler version to another.
> The "optimize based on the assumption that UB can not happen" philosophy
> amplifies even minor programming errors into something dangerous.
Unfortunately this is easier said than done. I far as I know all major
compilers do optimization based on UB. Consider this:
const int PI = 3;
int tau()
{
return 2 * PI; // can this be folded into 6?
}
GCC folds 2 * PI into 6 even with -O0. This optimization is based on UB.
Because in some other function one can write:
void evil()
{
const_cast(PI) = 4;
}
As some usages of PI can be folded and some can be not. The ones that were
folded would see PI = 3, the ones that were not folded would see PI = 4.
One can argue that the constant folding is fundamentally an optimization
based on UB. I believe few optimizations will be left, if we disable all
that rely on UB.
> This, of course, also applies to other UB (in varying degrees). For signed
> overflow we have -fsanitize=signed-integer-overflow which can help detect and
> mitigate such errors, e.g. by trapping at run-time. And also this is allowed
> by UB.
> In case of UB the choice of what to do lies with the compiler, but I think it
> is a bug if this choice is unreasonable and does not serve its users well.
Do you have some specific proposal in mind?
Currently a user has these 5 options:
1. Using -O0 suppressing optimizations.
2. Using -fno-tree-ccp suppressing this specific optimization.
3. Using -Wall and relying on warnings.
4. (in theory) Using static analyzer -fanalyzer. It doesn't detect this error
at the moment, but I believe can be taught detecting this.
5. Using dynamic analyzer like valgrind.
It seems that you find existing options insufficient and want another one.
[Bug c/97880] [8/9/10 Regression] [OpenACC] ICE in emit_library_call_value_1, at calls.c:5298
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97880 Tobias Burnus changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #7 from Tobias Burnus --- FIXED on GCC 11 (mainline) and GCC 10. (Cf. related also PR98088, fixed for the same branches.) I do not intent to backport it to GCC 8 or 9. Hence, close as FIXED Thanks for this and the other reports!
[Bug fortran/100110] Parameterized Derived Types, problems with global variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100110 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org Last reconfirmed||2021-04-19 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Paul Thomas --- Hi Xiao, Thank you for this report. I admit that the implementation of PDTs in gfortran is broken. I didn't realise quite how broken it is:-( Making 'obj' allocatable and allocating it produces the expected result. I had planned that once gcc-11 is released, I would turn my attention to PDTs. This one, I suspect, is such a low hanging fruit, that I will give it attention now. Best regards Paul
[Bug libstdc++/99876] std::filesystem::absolute is inefficient
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99876 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|redi at gcc dot gnu.org|unassigned at gcc dot gnu.org
[Bug libstdc++/67572] std::atomic, std::mutex and others are trivially copyable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67572 Jonathan Wakely changed: What|Removed |Added Assignee|redi at gcc dot gnu.org|unassigned at gcc dot gnu.org Status|ASSIGNED|NEW
[Bug libstdc++/65762] --with-default-libstdcxx-abi=c++11 is silently ignored when --disable-libstdcxx-dual-abi is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65762 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|redi at gcc dot gnu.org|unassigned at gcc dot gnu.org
[Bug libstdc++/96279] build failure: floating_from_chars.cc:310:22: error: '__builtin_isinf_sign' is not a member of 'std'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96279 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|redi at gcc dot gnu.org|unassigned at gcc dot gnu.org
[Bug libstdc++/90542] Build with --enable-libstdcxx-debug fails on Solaris due to symbol conflicts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90542 Jonathan Wakely changed: What|Removed |Added Assignee|redi at gcc dot gnu.org|unassigned at gcc dot gnu.org Status|ASSIGNED|NEW
[Bug libstdc++/90745] [9/10/11 Regression] std::tuple::operator= parameter causes error outside immediate context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90745 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|redi at gcc dot gnu.org|unassigned at gcc dot gnu.org
[Bug libstdc++/66146] call_once not C++11-compliant on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146 Jonathan Wakely changed: What|Removed |Added Assignee|redi at gcc dot gnu.org|unassigned at gcc dot gnu.org Status|ASSIGNED|NEW
[Bug libstdc++/93421] futex.cc use of futex syscall is not time64-compatible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93421 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|redi at gcc dot gnu.org|unassigned at gcc dot gnu.org
[Bug libstdc++/52389] Allocation/deallocation across DLL boundary in std::locale
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52389 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|redi at gcc dot gnu.org|unassigned at gcc dot gnu.org
[Bug libstdc++/97841] [C++17] is_invocable handling of incomplete return type is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97841 Jonathan Wakely changed: What|Removed |Added Assignee|redi at gcc dot gnu.org|unassigned at gcc dot gnu.org Status|ASSIGNED|NEW
[Bug libstdc++/67791] [8/9/10 Regression] Crash using std::thread and iostream with dynamic loading of a shared library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67791 Jonathan Wakely changed: What|Removed |Added Assignee|redi at gcc dot gnu.org|unassigned at gcc dot gnu.org Status|ASSIGNED|NEW
[Bug libstdc++/96161] istream::ignore sets eofbit too soon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96161 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|redi at gcc dot gnu.org|unassigned at gcc dot gnu.org
[Bug libstdc++/66742] abort on sorting list with custom allocator that is not stateless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66742 Jonathan Wakely changed: What|Removed |Added Assignee|redi at gcc dot gnu.org|unassigned at gcc dot gnu.org Status|ASSIGNED|NEW
[Bug libstdc++/95983] `std::counted_iterator>>` fails to satisfy `std::input_or_output_iterator`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95983 Jonathan Wakely changed: What|Removed |Added Assignee|redi at gcc dot gnu.org|unassigned at gcc dot gnu.org Status|ASSIGNED|NEW
[Bug libstdc++/90415] [9 Regression] std::is_copy_constructible> is incomplete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90415 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|redi at gcc dot gnu.org|unassigned at gcc dot gnu.org
[Bug libstdc++/99871] #includes inside push visibility scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99871 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|redi at gcc dot gnu.org|unassigned at gcc dot gnu.org
[Bug libstdc++/70472] is_copy_constructible>>::value is true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70472 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|redi at gcc dot gnu.org|unassigned at gcc dot gnu.org
[Bug libstdc++/97944] 30_threads/jthread/95989.cc fails randomly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97944 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|redi at gcc dot gnu.org|unassigned at gcc dot gnu.org
[Bug libstdc++/70560] Review configure checks for _GLIBCXX_ATOMIC_BUILTINS and atomicity_dir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70560 Jonathan Wakely changed: What|Removed |Added Assignee|redi at gcc dot gnu.org|unassigned at gcc dot gnu.org Status|ASSIGNED|NEW
[Bug libstdc++/85828] std::shuffle tries to swap element with itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85828 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|redi at gcc dot gnu.org|unassigned at gcc dot gnu.org
[Bug target/24012] [8/9/10/11 regression] #define _POSIX_C_SOURCE breaks #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24012 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|redi at gcc dot gnu.org|unassigned at gcc dot gnu.org
[Bug libstdc++/88125] Erroneous duplicate "basic_stringbuf" symbol entry in libstdc++ gnu.ver file.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88125 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|redi at gcc dot gnu.org|unassigned at gcc dot gnu.org
[Bug libstdc++/57272] node-based containers don't use allocator's pointer type internally
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57272 Jonathan Wakely changed: What|Removed |Added Assignee|redi at gcc dot gnu.org|unassigned at gcc dot gnu.org Status|ASSIGNED|NEW
[Bug libstdc++/81380] basic_stringbuf::seekpos doesn't fail when trying to reposition a null sequence
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81380 Jonathan Wakely changed: What|Removed |Added Assignee|redi at gcc dot gnu.org|unassigned at gcc dot gnu.org Status|ASSIGNED|NEW
[Bug libstdc++/95048] [9/10/11 Regression] wstring-constructor of std::filesystem::path throws for non-ASCII characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95048 Jonathan Wakely changed: What|Removed |Added Assignee|redi at gcc dot gnu.org|unassigned at gcc dot gnu.org Status|ASSIGNED|NEW
[Bug libstdc++/96657] [8/9/10 Regression] libsupc++.a missing required functions from src/c++98/atomicity.cc when atomic builtins are not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96657 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|redi at gcc dot gnu.org|unassigned at gcc dot gnu.org
[Bug libstdc++/68792] Review doxygen output and don't install useless things
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68792 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|redi at gcc dot gnu.org|unassigned at gcc dot gnu.org
[Bug libstdc++/94749] std::istream::ignore discards too many characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94749 Jonathan Wakely changed: What|Removed |Added Assignee|redi at gcc dot gnu.org|unassigned at gcc dot gnu.org Status|ASSIGNED|NEW
[Bug libstdc++/71367] std::time_get does not implement 'r' or 'p'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71367 Jonathan Wakely changed: What|Removed |Added Assignee|redi at gcc dot gnu.org|unassigned at gcc dot gnu.org Status|ASSIGNED|NEW
[Bug libstdc++/58909] C++11's condition variables fail with static linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909 Jonathan Wakely changed: What|Removed |Added Assignee|redi at gcc dot gnu.org|unassigned at gcc dot gnu.org Status|ASSIGNED|NEW
[Bug libstdc++/93770] std::tuple::operator< sometimes does needless extra work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93770 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|redi at gcc dot gnu.org|unassigned at gcc dot gnu.org
[Bug libstdc++/58876] No non-virtual-dtor warning in std::unique_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58876 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|redi at gcc dot gnu.org|unassigned at gcc dot gnu.org
[Bug libstdc++/93456] No overflow check in __atomic_futex_unsigned_base::_M_futex_wait_until
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93456 Jonathan Wakely changed: What|Removed |Added Assignee|redi at gcc dot gnu.org|unassigned at gcc dot gnu.org Status|ASSIGNED|NEW
[Bug libstdc++/87308] pretty printer for std::any fails with: Python Exception Unknown manager function in std::any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87308 Jonathan Wakely changed: What|Removed |Added Assignee|redi at gcc dot gnu.org|unassigned at gcc dot gnu.org Status|ASSIGNED|NEW
[Bug libstdc++/51749] Including pollutes global namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51749 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|redi at gcc dot gnu.org|unassigned at gcc dot gnu.org
[Bug libstdc++/83906] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906 Jonathan Wakely changed: What|Removed |Added Assignee|redi at gcc dot gnu.org|unassigned at gcc dot gnu.org Status|ASSIGNED|NEW
[Bug libstdc++/91371] std::bind and bind_front don't work with function with call convention
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91371 Jonathan Wakely changed: What|Removed |Added Assignee|redi at gcc dot gnu.org|unassigned at gcc dot gnu.org Status|ASSIGNED|NEW
[Bug libstdc++/70692] No warning when std::function binds a reference to a temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70692 Jonathan Wakely changed: What|Removed |Added Assignee|redi at gcc dot gnu.org|unassigned at gcc dot gnu.org Status|ASSIGNED|NEW
[Bug libstdc++/80676] [DR 2995] basic_stringbuf does not use initial capacity of SSO string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80676 Jonathan Wakely changed: What|Removed |Added Assignee|redi at gcc dot gnu.org|unassigned at gcc dot gnu.org Status|ASSIGNED|NEW
