[Bug c++/105040] snfit-2.4.0 fails to build because of /usr/include/c++/7/ostream:682:5: error: no type named 'type' in 'struct std::enable_if&>'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105040 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- The code is invalid. The simple fix is todo: stringstream message; message << "ERROR Salt2ExtinctionLaw::Read unknown version " << version; cerr << message.str() << endl;
[Bug c++/105040] snfit-2.4.0 fails to build because of /usr/include/c++/7/ostream:682:5: error: no type named 'type' in 'struct std::enable_if&>'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105040 --- Comment #1 from Andrew Pinski --- https://stackoverflow.com/questions/70791879/im-getting-a-type-error-while-building-snfit-2-4-2
[Bug c++/105040] New: snfit-2.4.0 fails to build because of /usr/include/c++/7/ostream:682:5: error: no type named 'type' in 'struct std::enable_if&>'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105040
Bug ID: 105040
Summary: snfit-2.4.0 fails to build because of
/usr/include/c++/7/ostream:682:5: error: no type named
'type' in 'struct std::enable_if&>'
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gautam_bhuyan282 at hotmail dot com
Target Milestone: ---
When I am trying to build a supernova light curve fitter known as salt2.4 which
comes as the source code snfit-2.4.0, it fails every time after I run "make".
The error due to which the build fails is reported as:
salt2extinction.cc: In member function 'void
Salt2ExtinctionLaw::Read(std::istream&)':
salt2extinction.cc:132:10: error: no match for 'operator<<' (operand types are
'std::ostream {aka std::basic_ostream}' and 'std::stringstream {aka
std::__cxx11::basic_stringstream}')
cerr << message << endl;
~^~
salt2extinction.cc:132:10: note: candidate: operator<<(int, int)
salt2extinction.cc:132:10: note: no known conversion for argument 2 from
'std::stringstream {aka std::__cxx11::basic_stringstream}' to 'int'
In file included from /usr/include/c++/7/iostream:39:0,
from salt2extinction.cc:1:
/usr/include/c++/7/ostream:108:7: note: candidate: std::basic_ostream<_CharT,
_Traits>::__ostream_type& std::basic_ostream<_CharT,
_Traits>::operator<<(std::basic_ostream<_CharT, _Traits>::__ostream_type&
(*)(std::basic_ostream<_CharT, _Traits>::__ostream_type&)) [with _CharT = char;
_Traits = std::char_traits; std::basic_ostream<_CharT,
_Traits>::__ostream_type = std::basic_ostream]
operator<<(__ostream_type& (*__pf)(__ostream_type&))
^~~~
/usr/include/c++/7/ostream:108:7: note: no known conversion for argument 1
from 'std::stringstream {aka std::__cxx11::basic_stringstream}' to
'std::basic_ostream::__ostream_type&
(*)(std::basic_ostream::__ostream_type&) {aka std::basic_ostream&
(*)(std::basic_ostream&)}'
/usr/include/c++/7/ostream:117:7: note: candidate: std::basic_ostream<_CharT,
_Traits>::__ostream_type& std::basic_ostream<_CharT,
_Traits>::operator<<(std::basic_ostream<_CharT, _Traits>::__ios_type&
(*)(std::basic_ostream<_CharT, _Traits>::__ios_type&)) [with _CharT = char;
_Traits = std::char_traits; std::basic_ostream<_CharT,
_Traits>::__ostream_type = std::basic_ostream; std::basic_ostream<_CharT,
_Traits>::__ios_type = std::basic_ios]
operator<<(__ios_type& (*__pf)(__ios_type&))
^~~~
/usr/include/c++/7/ostream:117:7: note: no known conversion for argument 1
from 'std::stringstream {aka std::__cxx11::basic_stringstream}' to
'std::basic_ostream::__ios_type&
(*)(std::basic_ostream::__ios_type&) {aka std::basic_ios&
(*)(std::basic_ios&)}'
/usr/include/c++/7/ostream:127:7: note: candidate: std::basic_ostream<_CharT,
_Traits>::__ostream_type& std::basic_ostream<_CharT,
_Traits>::operator<<(std::ios_base& (*)(std::ios_base&)) [with _CharT = char;
_Traits = std::char_traits; std::basic_ostream<_CharT,
_Traits>::__ostream_type = std::basic_ostream]
operator<<(ios_base& (*__pf) (ios_base&))
^~~~
/usr/include/c++/7/ostream:127:7: note: no known conversion for argument 1
from 'std::stringstream {aka std::__cxx11::basic_stringstream}' to
'std::ios_base& (*)(std::ios_base&)'
/usr/include/c++/7/ostream:166:7: note: candidate: std::basic_ostream<_CharT,
_Traits>::__ostream_type& std::basic_ostream<_CharT, _Traits>::operator<<(long
int) [with _CharT = char; _Traits = std::char_traits;
std::basic_ostream<_CharT, _Traits>::__ostream_type = std::basic_ostream]
operator<<(long __n)
^~~~
/usr/include/c++/7/ostream:166:7: note: no known conversion for argument 1
from 'std::stringstream {aka std::__cxx11::basic_stringstream}' to 'long
int'
/usr/include/c++/7/ostream:170:7: note: candidate: std::basic_ostream<_CharT,
_Traits>::__ostream_type& std::basic_ostream<_CharT, _Traits>::operator<<(long
unsigned int) [with _CharT = char; _Traits = std::char_traits;
std::basic_ostream<_CharT, _Traits>::__ostream_type = std::basic_ostream]
operator<<(unsigned long __n)
^~~~
/usr/include/c++/7/ostream:170:7: note: no known conversion for argument 1
from 'std::stringstream {aka std::__cxx11::basic_stringstream}' to 'long
unsigned int'
/usr/include/c++/7/ostream:174:7: note: candidate: std::basic_ostream<_CharT,
_Traits>::__ostream_type& std::basic_ostream<_CharT, _Traits>::operator<<(bool)
[with _CharT = char; _Traits = std::char_traits;
std::basic_ostream<_CharT, _Traits>::__ostream_type = std::basic_ostream]
operator<<(bool __n)
^~~~
/usr/include/c++/7/ostream:174:7: note: no known conversion for argument 1
from 'std::stringstream {aka std::__cxx11::basic_stringstream}' to 'bool'
In file included from /usr/include/c++/7/ostream:693:0,
[Bug target/104984] Use hard-fp for libgcc single-floating-point routines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104984 Den changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Den --- (In reply to jos...@codesourcery.com from comment #2) > See libgcc/config/rs6000/t-e500v1-fp Thank you, Joseph. That's exactly what I was looking for. As for the mips/mipsel single-float targets - it is not rational to make some global changes like to use double float precisions emulately for all of them (though, for r5900 it's worth it). Sure, there should be a functions to exclude from being hardwarely operated.
[Bug tree-optimization/105030] store motion if-change flag causes if-conversion optimization can't be taken.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105030
--- Comment #3 from HaoChen Gui ---
(In reply to Richard Biener from comment #2)
> That occured to me as well - I think the answer is maybe. In principle
> foo() could launch a thread and make the 'atemp' available to it. As long
> as foo() outlives thread termination that should be all well-defined and so
> we'd have to take this possibility into account.
>
> There's currently no code ruling this out and doing that is likely difficult.
> So maybe the answer is to add -fallow-store-data-races={local,all}, map
> -fallow-store-data-races to -fallow-store-data-races=all and make
> -fallow-store-data-races=local the default?
For the local automatic variables(not global, not static), they should be
stored on one's own thread stack. I think they can't be accessed by other
threads. Other threads should create their own instance for the local automatic
variables. So 'atemp' is thread safe in the example code? Could you please
explain why it's unsafe when foo outlives thread termination? Thanks a lot.
diff --git a/gcc/tree-ssa-loop-im.cc b/gcc/tree-ssa-loop-im.cc
index 6d9316eed1f..e2b6b927351 100644
--- a/gcc/tree-ssa-loop-im.cc
+++ b/gcc/tree-ssa-loop-im.cc
@@ -2219,7 +2219,10 @@ execute_sm (class loop *loop, im_mem_ref *ref,
bool always_stored = ref_always_accessed_p (loop, ref, true);
if (maybe_mt
&& (bb_in_transaction (loop_preheader_edge (loop)->src)
- || (! flag_store_data_races && ! always_stored)))
+ || (! flag_store_data_races && ! always_stored
+ && (!auto_var_in_fn_p (ref->mem.ref, current_function_decl)
+ || TREE_THIS_VOLATILE (ref->mem.ref)
+ || TREE_STATIC (ref->mem.ref)
multi_threaded_model_p = true;
Could we use above conditions to exclude local auto variables from
multi-threaded safe considerations?
[Bug c++/102598] [modules] ICE in pp_string, at pretty-print.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102598 --- Comment #2 from Johel Ernesto Guerrero Peña --- Another test case: https://godbolt.org/z/Gsfx56GM9.
[Bug debug/104564] '-fcompare-debug' failure w/ -std=c++20 -O1 -fharden-conditional-branches -fopenacc -gno-statement-frontiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104564 Alexandre Oliva changed: What|Removed |Added Last reconfirmed||2022-03-24 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Alexandre Oliva --- Created attachment 52677 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52677=edit Candidate patch Mine. Looks like it's the copied identifiers that get -fcompare-debug to fail. We don't need them, and without them, the failure is gone.
[Bug target/104967] ICE: Segmentation fault (in find_instance)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104967 Kewen Lin changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Kewen Lin --- Should be fixed on trunk.
[Bug target/105002] [12 regression] gcc.target/powerpc/float128-minmax-3.c fails starting with r12-7687-g3a7ba8fd0cda38
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105002 --- Comment #5 from Kewen Lin --- Patch was just posted at https://gcc.gnu.org/pipermail/gcc-patches/2022-March/592204.html.
[Bug target/104967] ICE: Segmentation fault (in find_instance)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104967 --- Comment #3 from CVS Commits --- The master branch has been updated by Kewen Lin : https://gcc.gnu.org/g:497bde3ab92b2c292f78672db341bbb7cc1bcf1f commit r12-7792-g497bde3ab92b2c292f78672db341bbb7cc1bcf1f Author: Kewen Lin Date: Wed Mar 23 20:46:06 2022 -0500 rs6000: Skip overload instances with NULL fntype [PR104967] For some overload built-in function instance, if it requires a data type which isn't defined on the target, its fntype would be initialized as NULL. This patch is to consider this possibility in function find_instance, as shown in PR104967. PR target/104967 gcc/ChangeLog: * config/rs6000/rs6000-c.cc (find_instance): Skip instances with null function types.
[Bug demangler/105039] New: rust demangler stack overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105039 Bug ID: 105039 Summary: rust demangler stack overflow Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: demangler Assignee: unassigned at gcc dot gnu.org Reporter: amodra at gmail dot com Target Milestone: --- >From https://sourceware.org/bugzilla/show_bug.cgi?id=28995 c++filt _RYAaca_NRYAaBa_a AddressSanitizer:DEADLYSIGNAL = ==4145846==ERROR: AddressSanitizer: stack-overflow on address 0x7ffd205e8ff8 (pc 0x021dfea9 bp 0x005f sp 0x7ffd205e9000 T0) #0 0x21dfea9 in peek /home/alan/src/binutils-gdb/libiberty/rust-demangle.c:90 #1 0x21dfd8c in eat /home/alan/src/binutils-gdb/libiberty/rust-demangle.c:99:7 #2 0x21e1bb4 in parse_integer_62 /home/alan/src/binutils-gdb/libiberty/rust-demangle.c:125:7 #3 0x21e2019 in demangle_const /home/alan/src/binutils-gdb/libiberty/rust-demangle.c:1153:17 #4 0x21e20a7 in demangle_const /home/alan/src/binutils-gdb/libiberty/rust-demangle.c:1158:11 and lots more at 1158:11. This is with libiberty sources from gcc commit 4cebae0924248b.
[Bug target/105010] [12 regression] GCC 12 after 20220227 fails to build on powerpc64-freebsd with Error: invalid mfcr mask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105010 --- Comment #13 from Piotr Kubaj --- Is it possible there's an underlying bug in GCC and it only works on Linux because the default for Linux for 32-bits is POWER7?
[Bug middle-end/104975] ICE in execute, at gimple-harden-conditionals.cc:577 and returns_twice and pure attributes on the same function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104975 Alexandre Oliva changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Alexandre Oliva --- Created attachment 52676 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52676=edit Candidate patch Mine. I'm testing this fix.
[Bug target/105010] [12 regression] GCC 12 after 20220227 fails to build on powerpc64-freebsd with Error: invalid mfcr mask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105010 --- Comment #12 from Segher Boessenkool --- What I still cannot figure out is how you get TARGET_MFCRF with your configuration and command line, so, ISA 2.01 . This is -m32 so *should* default to -mcpu=7450. But apparently it uses the PROCESSOR_DEFAULT64 for -m32 as well? How can that ever work?
[Bug c++/100687] [modules, concepts] imported concept gives different result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100687
--- Comment #2 from Johel Ernesto Guerrero Peña ---
Another use case (Clang: https://godbolt.org/z/hTPsPbEhe) (GCC:
https://godbolt.org/z/96MqTvrKv):
`mod.cpp`:
```C++
export module mod;
export template
inline constexpr bool is_same_v = false;
export template
inline constexpr bool is_same_v = true;
```
`test.cpp`:
```C++
import mod;
static_assert(is_same_v);
int main() {
}
```
Output:
```
test.cpp:2:15: error: static assertion failed
2 | static_assert(is_same_v);
| ^~~
```
[Bug analyzer/104979] False positive from -Wanalyzer-malloc-leak with cast within boxed pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104979 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from David Malcolm --- Should be fixed by the above commit.
[Bug analyzer/104979] False positive from -Wanalyzer-malloc-leak with cast within boxed pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104979 --- Comment #1 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:4cebae0924248beb2077894c6dc725c306fc0a69 commit r12-7790-g4cebae0924248beb2077894c6dc725c306fc0a69 Author: David Malcolm Date: Wed Mar 23 17:40:29 2022 -0400 analyzer: fix accessing wrong stack frame on interprocedural return [PR104979] PR analyzer/104979 reports a leak false positive when handling an interprocedural return to a caller: LHS = CALL(ARGS); where the LHS is a certain non-trivial compound expression. The root cause is that parts of the LHS were being erroneously evaluated with respect to the stack frame of the called function, rather than tha of the caller. When LHS contained a local variable within the caller as part of certain nested expressions, this local variable was looked for within the called frame, rather than that of the caller. This lookup in the wrong stack frame led to the local variable being treated as uninitialized, and thus the write to LHS was considered as writing to a garbage location, leading to the return value being lost, and thus being considered as a leak. The region_model code uses the analyzer's path_var class to try to extend the tree type with stack depth information. Based on the above, I think that the path_var class is fundamentally broken, but it's used in a few other places in the analyzer, so I don't want to rip it out until the next stage 1. In the meantime, this patch reworks how region_model::pop_frame works so that the destination region for an interprocedural return value is computed after the frame is popped, so that the region_model has the stack frame for the *caller* at that point. Doing so fixes the issue. I attempted a more ambitious fix which moved the storing of the return svalue into the destination region from region_model::pop_region into region_model::update_for_return_gcall, with pop_frame returning the return svalue. Unfortunately, this regressed g++.dg/analyzer/pr93212.C, which returns a pointer into a stale frame. unbind_region_and_descendents and poison_any_pointers_to_descendents are only set up to poison regions with bindings into the stale frame, not individual svalues, and updating that became more invasive than I'm comfortable with in stage 4. The patch also adds assertions to verify that we have the correct function when looking up locals/SSA names in a stack frame. There doesn't seem to be a general-purpose way to get at the function of an SSA name, so the assertions go from SSA name to def-stmt to basic_block, and from there use the analyzer's supergraph to get the function from the basic_block. If there's a simpler way to do this, please let me know. gcc/analyzer/ChangeLog: PR analyzer/104979 * engine.cc (impl_run_checkers): Create the engine after the supergraph, and pass the supergraph to the engine. * region-model.cc (region_model::get_lvalue_1): Pass ctxt to frame_region::get_region_for_local. (region_model::update_for_return_gcall): Pass the lvalue for the result to pop_frame as a tree, rather than as a region. (region_model::pop_frame): Update for above change, determining the destination region after the frame is popped and thus with respect to the caller frame rather than the called frame. Likewise, set the value of the region to the return value after the frame is popped. (engine::engine): Add supergraph pointer. (selftest::test_stack_frames): Set the DECL_CONTECT of PARM_DECLs. (selftest::test_get_representative_path_var): Likewise. (selftest::test_state_merging): Likewise. * region-model.h (region_model::pop_frame): Convert first param from a const region * to a tree. (engine::engine): Add param "sg". (engine::m_sg): New field. * region.cc: Include "analyzer/sm.h" and "analyzer/program-state.h". (frame_region::get_region_for_local): Add "ctxt" param. Add assertions that VAR_DECLs are locals, and that expr is for the correct function. * region.h (frame_region::get_region_for_local): Add "ctxt" param. gcc/testsuite/ChangeLog: PR analyzer/104979 * gcc.dg/analyzer/boxed-malloc-1-29.c: Deleted test, moving the now fixed test_29 to... * gcc.dg/analyzer/boxed-malloc-1.c: ...here. * gcc.dg/analyzer/stale-frame-1.c: Add test coverage. Signed-off-by: David Malcolm
[Bug target/105010] [12 regression] GCC 12 after 20220227 fails to build on powerpc64-freebsd with Error: invalid mfcr mask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105010
--- Comment #11 from Piotr Kubaj ---
Unfortunately, this fails with the original issue:
/wrkdirs/usr/ports/lang/gcc12-devel/work/.build/./gcc/xgcc
-B/wrkdirs/usr/ports/lang/gcc12-devel/work/.build/./gcc/
-B/usr/local/powerpc64-portbld-freebsd13.1/bin/
-B/usr/local/powerpc64-portbld-freebsd13.1/lib/ -isystem
/usr/local/powerpc64-portbld-freebsd13.1/include -isystem
/usr/local/powerpc64-portbld-freebsd13.1/sys-include -fno-checking -g -O2
-pipe -DLIBICONV_PLUG -fstack-protector-strong -fno-strict-aliasing -m32 -fPIC
-mstrict-align -msecure-plt -O2 -g -O2 -pipe -DLIBICONV_PLUG
-fstack-protector-strong -fno-strict-aliasing -DIN_GCC -fPIC -W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -pthread
-mno-minimal-toc -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC
-pthread -mno-minimal-toc -I. -I. -I../../.././gcc
-I/wrkdirs/usr/ports/lang/gcc12-devel/work/gcc-12-20220320/libgcc
-I/wrkdirs/usr/ports/lang/gcc12-devel/work/gcc-12-20220320/libgcc/.
-I/wrkdirs/usr/ports/lang/gcc12-devel/work/gcc-12-20220320/libgcc/../gcc
-I/wrkdirs/usr/ports/lang/gcc12-devel/work/gcc-12-20220320/libgcc/../include
-DHAVE_CC_TLS -o _mulsc3.o -MT _mulsc3.o -MD -MP -MF _mulsc3.dep -DL_mulsc3
-c /wrkdirs/usr/ports/lang/gcc12-devel/work/gcc-12-20220320/libgcc/libgcc2.c
-fvisibility=hidden -DHIDE_EXPORTS
{standard input}: Assembler messages:
{standard input}:140: Error: invalid mfcr mask
{standard input}:147: Error: unrecognized opcode: `fcfid'
{standard input}:166: Error: invalid mfcr mask
{standard input}:175: Error: unrecognized opcode: `fcfid'
{standard input}:326: Error: invalid mfcr mask
{standard input}:337: Error: unrecognized opcode: `fcfid'
{standard input}:356: Error: invalid mfcr mask
{standard input}:365: Error: unrecognized opcode: `fcfid'
[Bug sanitizer/105029] sanitizer_internal_defs.h:254:72: error: size of array ‘assertion_failed__1135’ is negative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105029 --- Comment #3 from Eyal Rozenberg --- (In reply to Andrew Pinski from comment #2) > You could backport the fix if you want. I'd like to trouble you for a little more guidance, so that I can apply the fix to 6.5.0. Now, I understand the fix does two things: 1. Change the conditions under which a size-and-type check is performed 2. Change the structure of __sanitizer_ipc_perm for various platforms. However, this is difficult to back-port when I don't understand what the actual problem was. The layout, and types, of the __sanitizer_ipc_perm structure is different in 6.5.0 and in 9.3.0, so that it's not clear what fields to change, into what, and for what platforms/combination of flags. The CHECK_SIZE_AND_TYPE - I can use the same condition as in the patched version, but - are they the appropriate ones for 6.5.0? Help out a poor developer who's trying to maintain compatibility of his library with older systems/compilers.
[Bug c++/104620] FAIL: g++.dg/cpp23/consteval-if2.C -std=gnu++20 (test for errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104620 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Target Milestone|--- |12.0 CC||ppalka at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug rtl-optimization/104985] [12 Regression] ICE: SIGSEGV in undo_to_marker / adjust_reg_mode with -Os -frounding-math since r12-4767-g81342e95827f77
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104985 --- Comment #6 from Jakub Jelinek --- Still can't reproduce.
[Bug fortran/105038] New: Improve error message for recursive type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105038 Bug ID: 105038 Summary: Improve error message for recursive type Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: vivekrao4 at yahoo dot com Target Milestone: --- For the code module m implicit none type :: t integer :: i type(t) :: x end type t end module m gfortran says recursive_type.f90:5:15: 5 |type(t) :: x | 1 Error: Component at (1) must have the POINTER attribute but the code compiles if x has either the POINTER or ALLOCATABLE attribute, and the error message should reflect this.
[Bug middle-end/105028] [11/12 Regression] gcc.dg/long_branch.c compilation time increases by 10x on BE system after r11-5648
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105028 --- Comment #5 from seurer at gcc dot gnu.org --- Thanks, that patch really improved things!
[Bug c++/103337] rejects-valid brace elision inside designated initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103337 --- Comment #5 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:2cd0c9a5310420e1039be5e514a818b6d381d89f commit r12-7789-g2cd0c9a5310420e1039be5e514a818b6d381d89f Author: Jason Merrill Date: Wed Mar 23 13:22:25 2022 -0400 c++: tweak PR103337 fix Patrick suggested a way to implement the designated-init handling without (temporarily) modifying the CONSTRUCTOR being reshaped. PR c++/103337 gcc/cp/ChangeLog: * decl.cc (reshape_single_init): New. (reshape_init_class): Use it.
[Bug middle-end/105032] Compiling inline ASM x86 causing GCC stuck in an endless loop with 100% CPU usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105032 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #8 from H.J. Lu --- (In reply to Jakub Jelinek from comment #7) > Anyway, with the "b" etc. constraints (which is a good idea to use on x86 > when it has single register constraints for those but can't be used on other > arches which do not have such constraints) you just trigger slightly > different path in the RA, but the problem remains roughly the same, you > force use of 6 registers as input plus one memory address and esp is a stack > pointer and ebp could be a frame pointer and it is a question if you don't > need another register for the address of the memory input. Since it is very unreliable, the inlined syscall with asm statement has been removed from glibc.
[Bug target/105010] [12 regression] GCC 12 after 20220227 fails to build on powerpc64-freebsd with Error: invalid mfcr mask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105010 Segher Boessenkool changed: What|Removed |Added Attachment #52670|0 |1 is obsolete|| Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org --- Comment #10 from Segher Boessenkool --- Created attachment 52675 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52675=edit proposed patch v2 Bah. Try this one :-)
[Bug c++/104620] FAIL: g++.dg/cpp23/consteval-if2.C -std=gnu++20 (test for errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104620 --- Comment #2 from Marek Polacek --- FAIL: g++.dg/cpp23/consteval-if2.C -std=gnu++20 (test for errors, line 80) FAIL: g++.dg/cpp23/consteval-if2.C -std=gnu++20 (test for errors, line 84) After r12-7264-gc19f317a78c0e4 these two errors only show up with -fchecking=2.
[Bug target/104831] RISCV libatomic LR.aq/SC.rl pair insufficient for SEQ_CST
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104831
--- Comment #9 from Patrick O'Neill ---
Adding this comment to summarize why LR.aq/SC.rl doesn't appear to be
an issue.
The re-orderings shown in the previous litmus tests are allowed by the
C++/GCC definition of SEQ_CST. My reasoning in prior comments are
incorrect and should be disregarded.
The ISA manual table A.6 recommends the LR.aqrl/SC.rl pairing for
SEQ_CST because of A.6's SEQ_CST store mapping. When the SEQ_CST store
is implemented as:
fence rw,w + sw
There needs to be ordering enforced to prevent the store from being
reordered into the middle of the LR/SC pairing [1][2].
GCC has a different mapping for SEQ_CST store:
fence iorw,ow + amoswap.rl
This prevents the reordering as seen in the example [2], so we can
safely use LR.aq/SC.rl pairings [3].
Relevant litmus tests:
[1] CDSChecker Litmus test - seq_cst W-RMW
#include
#include
#include
#include
#include "model-assert.h"
/*
* This shows that the c memory model enforces
* SEQ_CST W->(RMW) ordering
*/
std::atomic_int x;
std::atomic_int y;
int resx, resy;
static void a(void *obj)
{
x.store(1, std::memory_order_seq_cst);
resy = y.fetch_add(1, std::memory_order_seq_cst);
}
static void b(void *obj)
{
y.store(42, std::memory_order_seq_cst);
resx = x.load(std::memory_order_seq_cst);
}
int user_main(int argc, char **argv)
{
thrd_t t1, t2;
atomic_init(, 0);
atomic_init(, 0);
printf("Main thread: creating 2 threads\n");
thrd_create(, (thrd_start_t), NULL);
thrd_create(, (thrd_start_t), NULL);
thrd_join(t1);
thrd_join(t2);
printf("x: %d\n", resy);
printf("y: %d\n", resx);
MODEL_ASSERT(!(resy == 0 && resx == 0));
printf("Main thread is finished\n");
return 0;
}
[2] Herd7 Write-RMW litmus test - ISA Manual A.6 Mapping
RISCV W-RMW
(*
Table A.6 Seq_cst store along with LR.aq/SC.rl is insufficient for a
seq_cst store, seq_cst RMW mapping.
*)
{
0:x7=A; 0:x8=B;
1:x7=A; 1:x8=B;
}
P0 | P1 ;
ori x1,x0,1 | ori x1,x0,1 ;
fence rw,w | fence rw,rw ;
sw x1,0(x8) | sw x1,0(x7) ;
lr.w.aq x3,0(x7)| fence rw,rw ;
sc.w.rl x1,x1,0(x7) | lw x2,0(x8) ;
exists
(0:x3=0 /\ 1:x2=0)
[3] Herd7 Write-RMW litmus test - GCC Mapping
RISCV W-RMW
(*
GCC's current mapping for seq_cst store along with LR.aq/SC.rl is
sufficient for a seq_cst store, seq_cst RMW mapping.
*)
{
0:x7=A; 0:x8=B;
1:x7=A; 1:x8=B;
}
P0 | P1 ;
ori x1,x0,1 | ori x1,x0,1 ;
fence rw,w | fence rw,rw ;
amoswap.w.aq x0,x1,0(x8) | sw x1,0(x7) ;
lr.w.aq x3,0(x7) | fence rw,rw ;
sc.w.rl x1,x1,0(x7) | lw x2,0(x8) ;
~exists (0:x3=0 /\ 1:x2=0)
[Bug c++/92067] __is_constructible(incomplete_type) should make the program ill-formed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92067 --- Comment #6 from Jonathan Wakely --- (In reply to Jason Merrill from comment #4) > Do other standard library implementations depend on the compiler to diagnose > this? I don't think they enforce it at all (it's IFNDR).
[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 Bug 63426 depends on bug 104999, which changed state. Bug 104999 Summary: [12 Regression] runtime error: pointer index expression with base 0x0cf67720 overflowed to 0xea627728 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104999 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/104999] [12 Regression] runtime error: pointer index expression with base 0x00000cf67720 overflowed to 0xffffffffea627728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104999 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from anlauf at gcc dot gnu.org --- Should be FIXED.
[Bug c++/104620] FAIL: g++.dg/cpp23/consteval-if2.C -std=gnu++20 (test for errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104620 Marek Polacek changed: What|Removed |Added Host|hppa*-*-linux* | CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2022-03-23 Status|UNCONFIRMED |NEW Target|hppa*-*-linux* | Build|hppa*-*-linux* | --- Comment #1 from Marek Polacek --- I see it on x86_64 too. Confirmed.
[Bug fortran/105037] New: gfortran emits incorrect debug information if compiled with -finit-real=snan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105037 Bug ID: 105037 Summary: gfortran emits incorrect debug information if compiled with -finit-real=snan Product: gcc Version: 10.3.0 Status: UNCONFIRMED Keywords: wrong-debug Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: christian.friedl at gmx dot at Target Milestone: --- I have the following small example, let's call it example.F SUBROUTINE TEST(N1,N2,O2) IMPLICIT DOUBLE PRECISION (A-H,O-Z) COMMON /ABC/ EMP2,ITRLE,ITER,IREST DIMENSION O2(1) IF(IREST.EQ.0) THEN CALL WO2(1,N1,N2,O2) ENRGOLD=EMP2 ITER=0 END IF ITRLE=0 RETURN END I compile this and dissassemble it afterwards gfortran -c -ggdb -O0 example.F objdump -S example.o This is how the disassembly looks ... : SUBROUTINE TEST(N1,N2,O2) 0: 55 push %rbp 1: 48 89 e5mov%rsp,%rbp 4: 48 83 ec 30 sub$0x30,%rsp 8: 48 89 7d e8 mov%rdi,-0x18(%rbp) c: 48 89 75 e0 mov%rsi,-0x20(%rbp) 10: 48 89 55 d8 mov%rdx,-0x28(%rbp) 14: 8b 05 00 00 00 00 mov0x0(%rip),%eax# 1a IMPLICIT DOUBLE PRECISION (A-H,O-Z) COMMON /ABC/ EMP2,ITRLE,ITER,IREST DIMENSION O2(1) IF(IREST.EQ.0) THEN 1a: 85 c0 test %eax,%eax 1c: 75 32 jne50 ... I can also compile with -finit-real=snan gfortran -c -ggdb -O0 -finit-real=snan example.F objdump -S example.o In this case the disassembly looks like this ... : SUBROUTINE TEST(N1,N2,O2) 0: 55 push %rbp 1: 48 89 e5mov%rsp,%rbp 4: 48 83 ec 30 sub$0x30,%rsp 8: 48 89 7d e8 mov%rdi,-0x18(%rbp) c: 48 89 75 e0 mov%rsi,-0x20(%rbp) 10: 48 89 55 d8 mov%rdx,-0x28(%rbp) IMPLICIT DOUBLE PRECISION (A-H,O-Z) COMMON /ABC/ EMP2,ITRLE,ITER,IREST DIMENSION O2(1) IF(IREST.EQ.0) THEN CALL WO2(1,N1,N2,O2) ENRGOLD=EMP2 14: f2 0f 10 05 00 00 00movsd 0x0(%rip),%xmm0# 1c 1b: 00 1c: f2 0f 11 45 f8 movsd %xmm0,-0x8(%rbp) SUBROUTINE TEST(N1,N2,O2) 21: 8b 05 00 00 00 00 mov0x0(%rip),%eax# 27 IF(IREST.EQ.0) THEN 27: 85 c0 test %eax,%eax 29: 75 32 jne5d ... I have extracted this small testcase from a much bigger subroutine. When debugging a floating-point exception in the original subroutine the gdb debugger would be upset and yield /build/gdb-ktlO15/gdb-9.2/gdb/utils.c:690: internal-error: virtual memory exhausted. I am working on Ubuntu 20.04 LTS with gfortran version 4:9.3.0-1ubuntu2 on amd64.
[Bug rtl-optimization/105023] new test case g++.dg/other/pr104989.C ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105023 --- Comment #6 from Segher Boessenkool --- BLKmode is *not* valid for registers. reg:BLK at one time was a special marker for invalid asm operands, apparently. :BLK is for mem, and for parallel as well in some cases, but not for reg.
[Bug target/105010] [12 regression] GCC 12 after 20220227 fails to build on powerpc64-freebsd with Error: invalid mfcr mask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105010
--- Comment #9 from Piotr Kubaj ---
Now libgcc fails to configure.
>From config.log:
configure:3789: checking for suffix of object files
configure:3811: /wrkdirs/usr/ports/lang/gcc12-devel/work/.build/./gcc/xgcc
-B/wrkdirs/usr/ports/lang/gcc12-devel/work/.build/./gcc/
-B/usr/local/powerpc64-portbld-freebsd13.1/bin/
-B/usr/local/powerpc64-portbld-freebsd13.1/lib/ -isystem
/usr/local/powerpc64-portbld-freebsd13.1/include -isystem
/usr/local/powerpc64-portbld-freebsd13.1/sys-include -fno-checking -m32 -fPIC
-mstrict-align -msecure-plt -c -g -O2 -pipe -DLIBICONV_PLUG
-fstack-protector-strong -fno-strict-
aliasing conftest.c >&5
{standard input}: Assembler messages:
{standard input}:2: Error: junk at end of line, first unrecognized character is
`,'
[Bug tree-optimization/104475] [12 Regression] Wstringop-overflow + atomics incorrect warning on dynamic object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104475 --- Comment #10 from Aldy Hernandez --- (In reply to Richard Biener from comment #9) > I think threading unlikely paths is never worth it and usually NULL pointer > checks are statically predicted. > > I guess one idea would be to scale BB cost based on entry_BB->count vs. > BB->count so we more quickly run into the threading size limit for unlikely > executed blocks? Likewise since we first evaluate all threading > opportunities in a function (do we?) we should sort them so we first thread > the "best" one and use a global threading limit instead one applied to each > individual path (so we'd just stop threading once we hit the limit). Yes, we first queue all threading opportunities and then reorganize the blocks at the end. > > Can we, for GCC 12, at least stop threading !maybe_hot_edge_p()? Eventually > we can produce sth like a maybe_hot_threading_path_p () taking into account > the whole path. Sure, sounds reasonable, especially since as we get the last holdout converted to the new model (DOM threading), we'll have even more threading opportunities which could use some pruning. The whole cost model, as well as profiling, etc, was beyond the scope of my work this year. I'm curious if Jeff had any long term plans for this?
[Bug c++/105006] [12 Regression] ice: tree check: expected function_decl, have using_decl in maybe_push_used_methods, at cp/class.cc:1325
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105006 --- Comment #4 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:e8cd3edc0fc6c02a732dcecf519c22d835e5f422 commit r12-7788-ge8cd3edc0fc6c02a732dcecf519c22d835e5f422 Author: Jason Merrill Date: Wed Mar 23 12:22:20 2022 -0400 c++: tweak PR105006 fix Checking dependent_type_p avoids needing to walk the overloads in cases where it would not be possible to find a dependent using. PR c++/105006 gcc/cp/ChangeLog: * name-lookup.cc (lookup_using_decl): Check that scope is a dependent type before looking for dependent using.
[Bug tree-optimization/104987] [12 Regression] Recent change causing vrp13.c regressions on several targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104987 --- Comment #5 from Jakub Jelinek --- And it is unclear to me how it could get the sign of the multiplication wrong, it is a normal SImode mul which multiplies the values of SImode r6 and r7 registers. As it isn't hipart multiply or something similar, it doesn't care about sign, it should be the same. Or are you getting a different assembly?
[Bug tree-optimization/104987] [12 Regression] Recent change causing vrp13.c regressions on several targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104987
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek ---
If I use --param=logical-op-non-short-circuit=0 -O2 on x86_64-linux, I get
exactly the same -fdump-tree-optimized-alias dump as on v850-elf and the
testcase passes and the optimized dump looks sane.
I admit I don't have v850-elf binutils nor sim around, but the assembly I get
is:
_foo_mult:
.LFB0:
prepare {r31}, 0
movea -20,r0,r10
cmp r10,r6
blt .L2
cmp -9,r6
blt .L14
cmp 10,r6
bgt .L7
cmp 1,r7
bgt .L4
addi 10,r7,r10
cmp 8,r10
bh .L2
.L12:
mov r6,r10
mul r7,r10,r0
dispose 0 {r31}, r31
...
.L2:
jarl _abort, r31
When this is called, r6 is 10 and r7 is -2, so I think none of the conditional
jumps should branch away,
because r6 >= -20, r6 >= -9, r6 <= 10, r7 <= 1 and so it will do r10 = r7 + 10
(thus set r10 to 8) and r10 <= 8U,
so I think it should fall through into .L12 and multiply + return.
[Bug c++/92067] __is_constructible(incomplete_type) should make the program ill-formed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92067 --- Comment #5 from Jason Merrill --- Created attachment 52674 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52674=edit patch Like so.
[Bug c++/92067] __is_constructible(incomplete_type) should make the program ill-formed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92067 --- Comment #4 from Jason Merrill --- (In reply to Jason Merrill from comment #3) > Hmm? but the standard says that a precondition for std::is_constructible is > the type being complete, and we enforce that with a static_assert (since > PR71579). Why would it be a problem for the builtin to enforce it as well? ...having tried it, one reason not to is that it makes the diagnostic worse: instead of one understandable error from the static_assert, we also get the compiler error, and then another one from trying to access ::value in the class we failed to instantiate. Do other standard library implementations depend on the compiler to diagnose this?
[Bug target/104271] [12 Regression] 538.imagick_r run-time at -Ofast -march=native regressed by 26% on Intel Cascade Lake server CPU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104271 --- Comment #5 from Martin Jambor --- (In reply to Richard Biener from comment #4) > Does this still happen after the last fiddling? Unfortunately yes, the run-time is still 27% worse than when compiled with the commit previous to the one identified in the bug summary (I tried with e6a3991ea15).
[Bug rtl-optimization/105023] new test case g++.dg/other/pr104989.C ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105023
--- Comment #5 from Jakub Jelinek ---
BLKmode is valid mode for larger aggregate arguments and return values.
As documented:
"The return value is usually either a @code{reg} RTX for the hard
register in which to pass the argument, or zero to pass the argument
on the stack.
The value of the expression can also be a @code{parallel} RTX@. This is
used when an argument is passed in multiple locations. The mode of the
@code{parallel} should be the mode of the entire argument. The
@code{parallel} holds any number of @code{expr_list} pairs; each one
describes where part of the argument is passed. In each
@code{expr_list} the first operand must be a @code{reg} RTX for the hard
register in which to pass this part of the argument, and the mode of the
register RTX indicates how large this part of the argument is. The
second operand of the @code{expr_list} is a @code{const_int} which gives
the offset in bytes into the entire argument of where this part starts.
As a special exception the first @code{expr_list} in the @code{parallel}
RTX may have a first operand of zero. This indicates that the entire
argument is also stored on the stack.
The last time this hook is called, it is called with @code{MODE ==
VOIDmode}, and its result is passed to the @code{call} or @code{call_value}
pattern as operands 2 and 3 respectively."
If the whole argument is to be passed on the stack, the hook should just return
NULL_RTX. In case the psABI says for such structures (say the one with short :
2048 bitfield) should be partially passed in registers, still (reg:BLK 3 3)
seems to be a wrong answer, it could use (parallel:BLK [(reg:DI 3 3) (reg:DI 4
4) (reg:DI 5 5) (reg:DI 6 6)]) to indicate passing say first 256 bits in
registers and the rest on the stack.
[Bug fortran/103560] [12 Regression] Error: Nonexistent include directory './', stat on mingw does not work with "./"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103560 Tobias Burnus changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Tobias Burnus --- FIXED on mainline (GCC 12). Thanks for the report and draft patch - and sorry for the belated fix. Thanks Richi for pinging.
[Bug fortran/103560] [12 Regression] Error: Nonexistent include directory './', stat on mingw does not work with "./"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103560 --- Comment #8 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:5e33fea21957c97d63e3738be6056ae2a94e3284 commit r12-7787-g5e33fea21957c97d63e3738be6056ae2a94e3284 Author: Tobias Burnus Date: Wed Mar 23 16:54:12 2022 +0100 Fortran: Fix directory stat check for '.' [PR103560] MinGW does not like a call to 'stat' for './' via gfc_do_check_include_dir. Solution: Only append '/' when concatenating the path with the filename. gcc/fortran/ChangeLog: PR fortran/103560 * scanner.cc (add_path_to_list): Don't append '/' to the save include path. (open_included_file): Use '/' in concatenating path + file name. * module.cc (gzopen_included_file_1): Likewise. gcc/testsuite/ChangeLog: PR fortran/103560 * gfortran.dg/include_14.f90: Update dg-warning. * gfortran.dg/include_17.f90: Likewise. * gfortran.dg/include_18.f90: Likewise. * gfortran.dg/include_6.f90: Update dg-*.
[Bug target/105023] new test case g++.dg/other/pr104989.C ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105023 --- Comment #4 from Segher Boessenkool --- It never even executes rs6000_function_arg for that testcase. What are you doing differently? ... Oh, C++. Duh. It happens because we do return gen_rtx_REG (mode, gregno); which is perfectly valid: garbage in, garbage out. This is arg.mode, a function parameter here. Make the caller do some validation? BLKmode is not a valid mode to pass to function_arg.
[Bug target/105019] [nvptx] malias in libgomp results in "Internal error: reference to deleted section"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105019
--- Comment #6 from Tom de Vries ---
(In reply to Tom de Vries from comment #4)
> OK, I think this is the pattern:
> ...
> $ cat gcc/testsuite/gcc.target/nvptx/alias-5.c
FTR, same thing if I use static functions:
...
static void __attribute__((noinline))
__f ()
{
v = 1;
}
static void f () __attribute__ ((alias ("__f")));
static void
g (void)
{
f ();
}
...
[Bug tree-optimization/104970] [12 Regression] ICE in execute_todo, at passes.cc:2133 since r12-6480-gea19c8f33a3a8d2b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104970
--- Comment #10 from Martin Sebor ---
The purpose of the internal_p flag documented in the attr_access class is more
general than to tell a VLA-like argument from an ordinary array/pointer form
("Set for an attribute added internally rather than by an explicit
declaration") so tying the two together would be fragile. I expect using
internal_p directly as Siddhesh suggests will probably work now but I would
recommend using the vla_bounds() member function instead in case things change
in the future.
[Bug middle-end/104285] openmp offload linker issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104285 Tobias Burnus changed: What|Removed |Added Resolution|--- |FIXED CC||burnus at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #3 from Tobias Burnus --- FIXED on mainline (GCC 12). Thanks for the report. It additionally fixes an 'omp declare target link(var)' issue, exposed by omptests's t-same-name-definitions (which now passes). However, test-case writing revealed yet another issue (also related to the link clause), now tracked at PR105015.
[Bug middle-end/104986] [12 Regression] bogus writing 1 byte into a region of size 0 with -fwrapv and -O2 -fpeel-loops since r12-4698-gf6d012338bf87f42
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104986 --- Comment #8 from Richard Biener --- (In reply to Andrew Macleod from comment #5) > Looking at the strlen1 output, it only ever asks ranger about 6 names: > > 334 range_of_expr(_36) at stmt _52 = iftmp.1_17 + _36; > TRUE : (334) range_of_expr (_36) sizetype [3, 5] > maybe_invalidate called for *_52 = _60; > maybe_invalidate returns 1 > 342 range_of_expr(_69) at stmt _71 = iftmp.1_7 + _69; > TRUE : (342) range_of_expr (_69) sizetype [3, 5] > maybe_invalidate called for *_71 = _72; > maybe_invalidate returns 1 > 348 range_of_expr(_6) at stmt _31 = iftmp.1_76 + _6; > TRUE : (348) range_of_expr (_6) sizetype [2, 4] > maybe_invalidate called for *_31 = _32; > maybe_invalidate returns 1 > 367 range_of_expr(_37) at stmt _39 = iftmp.1_76 + _37; > TRUE : (367) range_of_expr (_37) sizetype [1, 3] > maybe_invalidate called for *_39 = _40; > statement may clobber object _31 0 bytes in size > > maybe_invalidate returns 1 > 375 range_of_expr(_45) at stmt _47 = iftmp.1_76 + _45; > TRUE : (375) range_of_expr (_45) sizetype [0, 2] > maybe_invalidate called for *_47 = _48; > statement may clobber object _39 0 bytes in size > maybe_invalidate returns 1 > 383 range_of_expr(_53) at stmt _55 = iftmp.1_76 + _53; > TRUE : (383) range_of_expr (_53) sizetype [1, 1] So maybe strlen can invoke ranger on GIMPLE_CONDs to mark unreachable code on the fly? IIRC domwalk has some ability to skip not executable edges so if the walk makes sure to properly initialize that for outgoing edges it might work in that it would refrain from optimizing/diagnosing in unreachable regions. > Is there a reason it runs before vrp2? Likely historical or the idea that VRP can do something with its results, like propagate constants (but there's now a CCP pass after it).
[Bug middle-end/104986] [12 Regression] bogus writing 1 byte into a region of size 0 with -fwrapv and -O2 -fpeel-loops since r12-4698-gf6d012338bf87f42
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104986 --- Comment #7 from Andrew Macleod --- and I forgot to show to dom3 output which did the transformation: j.c.195t.dom3:Match-and-simplified (sizetype) nb_66 to 18446744073709551615 j.c.195t.dom3:Optimizing statement _2 = (sizetype) nb_66; j.c.195t.dom3: Replaced 'nb_66' with constant '-1' j.c.195t.dom3: nb_66 = -1; but for whatever reason it could not reduce nb_58 to anything better than [-1, 0] nb_58 = prephitmp_30 + -5; Intersecting int [-1, 0] and int [-1, 4] to int [-1, 0]
[Bug target/102125] (ARM Cortex-M3 and newer) missed optimization. memcpy not needed operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102125
--- Comment #11 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:d9792f8d227cdd409c2b082ef0685b47ccfaa334
commit r12-7786-gd9792f8d227cdd409c2b082ef0685b47ccfaa334
Author: Richard Biener
Date: Wed Mar 23 14:53:49 2022 +0100
target/102125 - alternative memcpy folding improvement
The following extends the heuristical memcpy folding path with the
ability to use misaligned accesses on strict-alignment targets just
like the size-based path does. That avoids regressing the following
testcase on arm
uint64_t bar64(const uint8_t *rData1)
{
uint64_t buffer;
memcpy(, rData1, sizeof(buffer));
return buffer;
}
when r12-3482-g5f6a6c91d7c592 is reverted.
2022-03-23 Richard Biener
PR target/102125
* gimple-fold.cc (gimple_fold_builtin_memory_op): Allow the
use of movmisalign when either the source or destination
decl is properly aligned.
[Bug middle-end/105028] [11/12 Regression] gcc.dg/long_branch.c compilation time increases by 10x on BE system after r11-5648
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105028 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:1daa198aafd72925ca8dd8616385f523ff180d4a commit r12-7785-g1daa198aafd72925ca8dd8616385f523ff180d4a Author: Richard Biener Date: Wed Mar 23 12:21:32 2022 +0100 rtl-optimization/105028 - fix compile-time hog in form_threads_from_copies form_threads_from_copies processes a sorted array of copies, skipping those with the same thread and conflicting threads and merging the first non-conflicting ones. After that it terminates the loop and gathers the remaining elements of the array, skipping same thread copies, re-starting the process. For a large number of copies this gathering of the rest takes considerable time and it also appears pointless. The following simply continues processing the array which should be equivalent as far as I can see. This takes form_threads_from_copies off the profile radar from previously taking ~50% of the compile-time. 2022-03-23 Richard Biener PR rtl-optimization/105028 * ira-color.cc (form_threads_from_copies): Remove unnecessary copying of the sorted_copies tail.
[Bug target/105010] [12 regression] GCC 12 after 20220227 fails to build on powerpc64-freebsd with Error: invalid mfcr mask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105010 --- Comment #8 from Piotr Kubaj --- Testing. FYI, on 12-20220227, .machine power4 is used.
[Bug middle-end/104986] [12 Regression] bogus writing 1 byte into a region of size 0 with -fwrapv and -O2 -fpeel-loops since r12-4698-gf6d012338bf87f42
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104986 --- Comment #6 from Aldy Hernandez --- (In reply to Aldy Hernandez from comment #4) > (In reply to Richard Biener from comment #3) > > This is peeling leaving us with unreachable code we warn on and somehow > > while figuring prephitmp_30 + -6 is -1 we don't figure nb_58 is zero on > > the path to bb9. > > > > I think I've seen this backward-forward dependency issue with ranger before > > in another missed optimization PR. > > This is not ranger, but the legacy conditional folding in vr-values. It's > the test_for_singularity() code that turns x<=0 where x is [0,6] into x!=0. Ooops, sorry I totally missed Richi's comment on prephitmp. I see Andrew answered though :).
[Bug middle-end/104986] [12 Regression] bogus writing 1 byte into a region of size 0 with -fwrapv and -O2 -fpeel-loops since r12-4698-gf6d012338bf87f42
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104986 --- Comment #5 from Andrew Macleod --- (In reply to Richard Biener from comment #3) > This is peeling leaving us with unreachable code we warn on and somehow > while figuring prephitmp_30 + -6 is -1 we don't figure nb_58 is zero on > the path to bb9. > > I think I've seen this backward-forward dependency issue with ranger before > in another missed optimization PR. (In reply to Richard Biener from comment #3) > This is peeling leaving us with unreachable code we warn on and somehow > while figuring prephitmp_30 + -6 is -1 we don't figure nb_58 is zero on > the path to bb9. > > I think I've seen this backward-forward dependency issue with ranger before > in another missed optimization PR. DOM3 is the pass which converted prephitmp_30 + -6 to -1, and left nb_58 as is. Ranger appears to see it just fine. Looking at VRP2, Folding statement: nb_68 = prephitmp_30 + -5; Queued stmt for removal. Folds to: 0 <...> Folding statement: if (nb_68 != 0) gimple_simplified to if (0 != 0) Folded into: if (0 != 0) strlen runs just before vrp2, and if I put a VRP pass immediately before strlen1, then the warning goes away. Looking at the strlen1 output, it only ever asks ranger about 6 names: 334 range_of_expr(_36) at stmt _52 = iftmp.1_17 + _36; TRUE : (334) range_of_expr (_36) sizetype [3, 5] maybe_invalidate called for *_52 = _60; maybe_invalidate returns 1 342 range_of_expr(_69) at stmt _71 = iftmp.1_7 + _69; TRUE : (342) range_of_expr (_69) sizetype [3, 5] maybe_invalidate called for *_71 = _72; maybe_invalidate returns 1 348 range_of_expr(_6) at stmt _31 = iftmp.1_76 + _6; TRUE : (348) range_of_expr (_6) sizetype [2, 4] maybe_invalidate called for *_31 = _32; maybe_invalidate returns 1 367 range_of_expr(_37) at stmt _39 = iftmp.1_76 + _37; TRUE : (367) range_of_expr (_37) sizetype [1, 3] maybe_invalidate called for *_39 = _40; statement may clobber object _31 0 bytes in size maybe_invalidate returns 1 375 range_of_expr(_45) at stmt _47 = iftmp.1_76 + _45; TRUE : (375) range_of_expr (_45) sizetype [0, 2] maybe_invalidate called for *_47 = _48; statement may clobber object _39 0 bytes in size maybe_invalidate returns 1 383 range_of_expr(_53) at stmt _55 = iftmp.1_76 + _53; TRUE : (383) range_of_expr (_53) sizetype [1, 1] Is there a reason it runs before vrp2?
[Bug middle-end/104986] [12 Regression] bogus writing 1 byte into a region of size 0 with -fwrapv and -O2 -fpeel-loops since r12-4698-gf6d012338bf87f42
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104986 --- Comment #4 from Aldy Hernandez --- (In reply to Richard Biener from comment #3) > This is peeling leaving us with unreachable code we warn on and somehow > while figuring prephitmp_30 + -6 is -1 we don't figure nb_58 is zero on > the path to bb9. > > I think I've seen this backward-forward dependency issue with ranger before > in another missed optimization PR. This is not ranger, but the legacy conditional folding in vr-values. It's the test_for_singularity() code that turns x<=0 where x is [0,6] into x!=0.
[Bug c/105013] Valgrind reports accessing uninitialized memory when -O2 option is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105013 Martin Liška changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #5 from Martin Liška --- Good, then let's close it as invalid.
[Bug c/105013] Valgrind reports accessing uninitialized memory when -O2 option is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105013 --- Comment #4 from James Allwright --- I have re-run with the suggested options --track-origins=yes and -s : $ valgrind --track-origins=yes -s ./bug ==16956== Memcheck, a memory error detector ==16956== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==16956== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==16956== Command: ./bug ==16956== out = command = ==16956== Conditional jump or move depends on uninitialised value(s) ==16956==at 0x1092DB: example_func (bug.c:37) ==16956==by 0x1090D3: main (bug.c:44) ==16956== Uninitialised value was created by a stack allocation ==16956==at 0x109280: example_func (bug.c:26) ==16956== ==16956== ==16956== HEAP SUMMARY: ==16956== in use at exit: 0 bytes in 0 blocks ==16956== total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated ==16956== ==16956== All heap blocks were freed -- no leaks are possible ==16956== ==16956== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) ==16956== ==16956== 1 errors in context 1 of 1: ==16956== Conditional jump or move depends on uninitialised value(s) ==16956==at 0x1092DB: example_func (bug.c:37) ==16956==by 0x1090D3: main (bug.c:44) ==16956== Uninitialised value was created by a stack allocation ==16956==at 0x109280: example_func (bug.c:26) ==16956== ==16956== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) When I run with --expensive-definedness-checks=yes, no problems are reported: $ valgrind --expensive-definedness-checks=yes ./bug ==16924== Memcheck, a memory error detector ==16924== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==16924== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==16924== Command: ./bug ==16924== out = command = ==16924== ==16924== HEAP SUMMARY: ==16924== in use at exit: 0 bytes in 0 blocks ==16924== total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated ==16924== ==16924== All heap blocks were freed -- no leaks are possible ==16924== ==16924== For lists of detected and suppressed errors, rerun with: -s ==16924== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
[Bug rtl-optimization/104985] [12 Regression] ICE: SIGSEGV in undo_to_marker / adjust_reg_mode with -Os -frounding-math since r12-4767-g81342e95827f77
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104985 --- Comment #5 from Martin Liška --- Created attachment 52673 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52673=edit auto-host.h
[Bug rtl-optimization/104985] [12 Regression] ICE: SIGSEGV in undo_to_marker / adjust_reg_mode with -Os -frounding-math since r12-4767-g81342e95827f77
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104985 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- I can't reproduce it either. Can you perhaps attach auto-host.h with which you can reproduce it?
[Bug target/102772] [12 regression] g++.dg/torture/pr80334.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772 --- Comment #20 from Jakub Jelinek --- Note, for ntpoff the listed instructions are: movl %gs:0,%eax leal x@ntpoff(%eax),%eax rather than addl. But certainly this one was never meant to be taken pedantically as that instruction sequence only, it is completely intentional that the %gs:0 load can be far away (used by multiple TLS LE or IE accesses), and even tls.pdf mentions some other instructions: movl %gs:0,%eax movl x@ntpoff(%eax),%eax and movl %gs:x@ntpoff,%eax are all mentioned.
[Bug rtl-optimization/104985] [12 Regression] ICE: SIGSEGV in undo_to_marker / adjust_reg_mode with -Os -frounding-math since r12-4767-g81342e95827f77
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104985 --- Comment #3 from Martin Liška --- No, it's still there and you will likely need cross GAS to reproduce it: ~/Programming/gcc/configure --enable-languages=c,c++ --prefix=/home/marxin/bin/gcc --disable-multilib --enable-host-shared --disable-libsanitizer --enable-valgrind-annotations --disable-bootstrap --target=mips64el-unknown-linux-gnuabi64 --with-as=/home/marxin/Programming/binutils/objdir/gas/as-new --enable-checking=yes,rtl,df,extra
[Bug target/102772] [12 regression] g++.dg/torture/pr80334.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772 --- Comment #19 from Jakub Jelinek --- If it is the linker, you can always objdump -dr the binary to see what is in there after linking. s@ntpoff in my understanding is a relocation that should supply at link time the offset from the TLS base and at least on the GCC side it can appear anywhere where 32-bit immediate appears in an instruction (or in data section too), not necessarily in addl imm, %eax instruction. Perhaps also try to have 2 different functions, one with movl%gs:0, %eax addl$s@ntpoff, %eax ret and another with pushl %ebx movl%gs:0, %ebx addl$s@ntpoff, %ebx popl%ebx ret and see what they do at runtime (if they both print the same address in each thread or not).
[Bug c++/103769] [11/12 Regression] checking ICE in hashtab_chk_error with alias template and pack expansion after r11-7931
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103769 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug tree-optimization/101636] [11 Regression] ICE: verify_gimple failed (error: conversion of register to a different size in 'view_convert_expr')
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101636 Richard Biener changed: What|Removed |Added Known to work||11.2.1 Status|ASSIGNED|RESOLVED Known to fail||11.2.0 Resolution|--- |FIXED --- Comment #19 from Richard Biener --- Fixed.
[Bug tree-optimization/104782] [12 regression] ICE: verify_gimple failed in slp (non-trivial conversion in ‘ssa_name’) with -msve-vector-bits=128 since r12-7359-g6e80c4f1ad9046b0a7c105660cc7b3dcae0fdb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104782 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:893cb28a22f86281ca9ce1e045da7b8840ceb121 commit r11-9689-g893cb28a22f86281ca9ce1e045da7b8840ceb121 Author: Richard Biener Date: Wed Feb 23 11:15:38 2022 +0100 tree-optimization/101636 - CTOR vectorization ICE The following fixes an ICE when vectorizing the defs of a CTOR results in a different vector type than expected. That can happen with AARCH64 SVE and a fixed vector length as noted in r10-5979 and on x86 with AVX512 mask CTORs and trying to re-vectorize using SSE as shown in this bug. The fix is simply to reject the vectorization when it didn't produce the desired type. 2022-02-23 Richard Biener PR tree-optimization/101636 PR tree-optimization/104782 * tree-vect-slp.c (vect_slp_analyze_operations): Make sure the CTOR is vectorized with an expected type. * c-c++-common/torture/pr101636.c: Likewise. * gcc.dg/vect/pr104782.c: New testcase.
[Bug tree-optimization/101636] [11 Regression] ICE: verify_gimple failed (error: conversion of register to a different size in 'view_convert_expr')
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101636 --- Comment #18 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:893cb28a22f86281ca9ce1e045da7b8840ceb121 commit r11-9689-g893cb28a22f86281ca9ce1e045da7b8840ceb121 Author: Richard Biener Date: Wed Feb 23 11:15:38 2022 +0100 tree-optimization/101636 - CTOR vectorization ICE The following fixes an ICE when vectorizing the defs of a CTOR results in a different vector type than expected. That can happen with AARCH64 SVE and a fixed vector length as noted in r10-5979 and on x86 with AVX512 mask CTORs and trying to re-vectorize using SSE as shown in this bug. The fix is simply to reject the vectorization when it didn't produce the desired type. 2022-02-23 Richard Biener PR tree-optimization/101636 PR tree-optimization/104782 * tree-vect-slp.c (vect_slp_analyze_operations): Make sure the CTOR is vectorized with an expected type. * c-c++-common/torture/pr101636.c: Likewise. * gcc.dg/vect/pr104782.c: New testcase.
[Bug tree-optimization/104931] [9/10/11 Regression] wrong-code with number_of_iterations_lt_to_ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104931 --- Comment #11 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:d1f4dfd409dedf4d00ca7be001cf757d0d6e82f4 commit r11-9688-gd1f4dfd409dedf4d00ca7be001cf757d0d6e82f4 Author: Richard Biener Date: Wed Mar 16 14:53:06 2022 +0100 tree-optimization/104931 - mitigate niter analysis issue The following backports a pointer associating pattern from trunk that mitigates an issue with number_of_iterations_lt_to_ne in which context we fail to fold a comparison but succeed in folding a related subtraction. In the failure mode this results in a loop wrongly assumed looping with a bogus number of iterations, resulting in crashing of the premake application on start. With the backported simplification we are able to fold the comparison and correctly compute the loop as not iterating. I have failed to create a standalone testcase. I belive part of the issue is still latent but I have failed to nail down the issue exactly. Still I believe the backporting of the mitigation patch is the most sensible and safe thing at this point. 2022-03-16 Richard Biener PR tree-optimization/104931 * match.pd ((ptr) (x p+ y) p+ z -> (ptr) (x p+ (y + z))): New GENERIC simplification.
[Bug target/102772] [12 regression] g++.dg/torture/pr80334.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772
--- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #17 from Jakub Jelinek ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #16)
>> I've wrapped that in a small test programming, calling foo both from the
>> initial thread and a new one: in all cases, the return value from foo
>> was 32-byte aligned as expected.
>
> Perhaps the problem only shows when the PT_TLS size is not a multiple of the
> alignment? Or depends on other PT_TLS segments in shared libraries in the
> same
> process. The pointer2.f90 testcase will link against libgomp which uses TLS
> as
> well.
> So perhaps try:
> struct __attribute__((aligned (16))) S { char buf[0x24]; };
> __thread struct S s;
> __attribute__((noipa)) S *foo (void) { return }
> int
> main ()
> {
> #pragma omp parallel
> __builtin_printf ("%p\n", foo ());
> return 0;
> }
> ?
I've compiled that with g++ -m32 -O2 -fopenmp. Initially, when foo was
just
movl%gs:0, %eax
addl$s@ntpoff, %eax
ret
this worked reliably, emitting a 16-byte aligned address 48 times
(matching the number of cores).
However, when I changed the assembler output to
pushl %ebx
movl%gs:0, %ebx
addl$s@ntpoff, %ebx
popl%ebx
ret
and relinked, the resulting addresses were just 4-byte aligned, exactly
one of them even being 0.
That might again suggest the Solaris ld/ld.so.1 took the TLS spec
literally (provided I've not created that mess myself: IIUC, %ebx is
callee-saved).
[Bug middle-end/105028] [11/12 Regression] gcc.dg/long_branch.c compilation time increases by 10x on BE system after r11-5648
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105028 --- Comment #3 from seurer at gcc dot gnu.org --- Thanks for looking at this. It has been bugging me at a low level for months.
[Bug middle-end/105032] Compiling inline ASM x86 causing GCC stuck in an endless loop with 100% CPU usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105032
--- Comment #7 from Jakub Jelinek ---
Consider e.g.
void bar (int *);
int
foo (int *a, int *b, int *c, int *d)
{
for (int i = 0; i < 1024; i++)
a[i] = a[i] * b[i] + (c[i] - d[i]);
bar (a);
return 42;
}
with -m32 -O3 -mavx -mstackrealign.
It needs to dynamically realign the stack because user asked for it (so that it
can use 256-bit aligned stack slots and callers don't guarantee that
alignment), so it needs a frame pointer (%ebp), stack pointer (%esp) and DRAP
(%ecx in this case). Especially if you e.g. also use VLAs or alloca in the
function.
%ebp based addressing is for the automatic vars in the function in its stack
frame, stack pointer can be variable offset from it used for outgoing arguments
to function calls and push/pop or for alloca/VLAs and DRAP is used to access
function arguments which aren't at fixed offset from the frame pointer either.
Anyway, with the "b" etc. constraints (which is a good idea to use on x86 when
it has single register constraints for those but can't be used on other arches
which do not have such constraints) you just trigger slightly different path in
the RA, but the problem remains roughly the same, you force use of 6 registers
as input plus one memory address and esp is a stack pointer and ebp could be a
frame pointer and it is a question if you don't need another register for the
address of the memory input.
A way to free one input would be to store 2 arguments into an array and use the
whole array as one memory input and only inside of the inline asm load it into
the right registers.
[Bug c++/92067] __is_constructible(incomplete_type) should make the program ill-formed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92067 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/105035] [11/12 Regression] tree check: expected field_decl, have identifier_node in operand_equal_p, at fold-const.c:3335 since r11-5181-g0862d007b564eca8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105035
--- Comment #7 from Patrick Palka ---
(In reply to Patrick Palka from comment #6)
> (In reply to Jakub Jelinek from comment #3)
> > Another option is to make sure we don't call
> > warn_duplicated_cond_add_or_warn
> > when processing_template_decl or say when value_dependent_expression_p or
> > similar, and instead call it during template instantiation in pt.cc after
> > finish_if_stmt_cond call there.
>
> I noticed the warning already gives up on conditions that have
> TREE_SIDE_EFFECTS set, so I suppose it makes sense to do the same for
> type-dependent expressions since we can't know if they have side effects
> until instantiation time.
However, doing the check at instantiation time for dependent conditions might
be problematic since two different dependent conditions could instantiate to
the same non-dependent condition, and I don't think we'd want to issue a
-Wduplicated-cond warning in this case. For example,
template
void f() {
if (T() == 5)
...
else if (U() == 5)
...
}
I'm not sure issuing a warning at instantiation time for f() would be
appropriate. We'd might have to compare the dependent conditions even at
instantiation time, provided that the instantiated condition doesn't have
TREE_SIDE_EFFECTS set... Seems quite messy to get right.
[Bug c++/92067] __is_constructible(incomplete_type) should make the program ill-formed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92067 --- Comment #3 from Jason Merrill --- (In reply to Jonathan Wakely from comment #2) > We need to be careful about this in SFINAE contexts. It can't be a hard > error, because it's extremely common for constructors to be constrained with > std::is_constructible, and for overload resolution to consider constructors > for incomplete types. Hmm? but the standard says that a precondition for std::is_constructible is the type being complete, and we enforce that with a static_assert (since PR71579). Why would it be a problem for the builtin to enforce it as well? I'm also not sure why it's a problem that the builtin doesn't enforce it, for the same reason. But I guess it might as well for consistency.
[Bug c++/96645] [9/10/11/12 Regression] [CWG2335] std::variant default constructor and unparsed DMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645 --- Comment #20 from Jason Merrill --- Created attachment 52672 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52672=edit patch to make it an error for __is_constructible Thus.
[Bug middle-end/105032] Compiling inline ASM x86 causing GCC stuck in an endless loop with 100% CPU usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105032 --- Comment #6 from Ammar Faizi --- (In reply to Jakub Jelinek from comment #4) > If this is a macro that users should use in arbitrary user code, there is > another problem, if something is vectorized in the function, either using > AVX or later or -mstackrealign is used, another register is needed for the > stack realignment (DRAP register). I don't really understand about stack realignment part. So I have a question, what is another register here? Is it %ebp? If we have %ebp as a stack frame pointer, can't the compiler just use it for the realignment? I am not sure what the DRAP register really means. Googled about it, but doesn't show anything relevant.
[Bug analyzer/105017] [12 Regression] gcc/analyzer/sm-taint.cc:631:21: warning: private field 'm_mem_space' is not used [-Wunused-private-field]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105017 --- Comment #4 from Martin Liška --- (In reply to David Malcolm from comment #3) > I'm assuming that this was a clang warning, and that this is fixed by the > above commit; please reopen if it's still affected. Thanks, it fixed the clang warning!
[Bug middle-end/105032] Compiling inline ASM x86 causing GCC stuck in an endless loop with 100% CPU usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105032
--- Comment #5 from Ammar Faizi ---
(In reply to Jakub Jelinek from comment #3)
> This has been hanging or ICEing on and off since forever.
> E.g. even r105000 ICEs, r20 works, r21 ICEs, r10-5912 works, r11-1
> hangs, so does current trunk.
> The first revision after r10-5912 to start hanging was
> r10-6326-gbcf3fa7cf5a3d024b507.
> Note, without optimizations, the inline asm is on or beyond the border what
> can be handled, it uses 6 of the 8 GPRs the arch has, the further two are
> the stack pointer and when not optimizing or if frame pointer is for
> whatever reason needed frame pointer. The asm also has a memory input. So,
> it fully depends on optimization (which isn't done with -O0 generally) that
> the address of the
> _arg6 variable can be expressed as offset(%esp) or offset(%ebp). If it is
> not (and -O0 asks for no optimizations), then there are no registers left
> how to describe the input.
Interestingly, changing the my_syscall6() macro to this one works nicely.
#define my_syscall6(num, arg1, arg2, arg3, arg4, arg5, arg6)\
({ \
long _eax = (long)(num); \
long _arg6 = (long)(arg6); /* Always in memory */ \
__asm__ volatile ( \
"pushl %[_arg6]\n\t" \
"pushl %%ebp\n\t" \
"movl 4(%%esp),%%ebp\n\t" \
"int$0x80\n\t" \
"popl %%ebp\n\t" \
"addl $4,%%esp\n\t" \
: "+a"(_eax)/* %eax */ \
: "b"(arg1),/* %ebx */ \
"c"(arg2),/* %ecx */ \
"d"(arg3),/* %edx */ \
"S"(arg4),/* %esi */ \
"D"(arg5),/* %edi */ \
[_arg6]"m"(_arg6) /* memory */\
: "memory", "cc"\
); \
_eax; \
})
Link: https://godbolt.org/z/hdsffvr1d
What could possibly be wrong here?
I am not sure what is the behavior difference between this macro with the
previously posted?
[Bug debug/105036] New: Missing variables when debugging due to overlapping ranges after unrolling, instruction scheduling, and inlining at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105036
Bug ID: 105036
Summary: Missing variables when debugging due to overlapping
ranges after unrolling, instruction scheduling, and
inlining at -O3
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: assaiante at diag dot uniroma1.it
Target Milestone: ---
In this minimized C example, variables i and j that index the two nested loops
are missing when putting a breakpoint on the statement in the inner loop and
executing it for the very first time. Then, they become visible when executing
it at iteration (0,1) and still are when about to exit the outer loop, as
expected with unrolling.
This behavior appears to be caused by i and j’s DWARF location info, for the
(0,0) iteration only, overlapping with DWARF location info for the inlined
function foo. We observe the issue at -O3 with the root cause likely being
schedule-insns2, combined with the effects of inlining foo and loop unrolling.
We also noted that if we shorten the loop counts in the example, for instance
to have i stopping at 3 and j at 4, the issue is no longer present.
Please find below a detailed analysis for -O3 on x64 and a quick assessment on
past gcc versions where the issue is sometimes not present.
$ cat a.c
volatile int a;
int b;
unsigned c[35];
int d;
void foo() {
b = 3;
for (; b >= -10; b = b - 4) {
d++;
}
}
int main() {
int i, j;
foo();
i = 0;
for (; i < 5; i++) {
j = 0;
for (; j < 7; j++)
a = c[i * 5 + j];
}
}
GCC and GDB version (GCC commit id: 500d3f0a302):
$ gcc --version
gcc (GCC) 12.0.0 20211227 (experimental)
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gdb --version
GNU gdb (GDB) 11.2
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
GDB trace:
$ gcc -O3 -g a.c -o opt
$ gdb -q opt
Reading symbols from opt...
(gdb) b 18
Breakpoint 1 at 0x4003b6: /home/stepping/50/reduce/a.c:18. (2 locations)
(gdb) r
Starting program: /home/stepping/50/reduce/opt
Breakpoint 1, foo () at test.c:18
18a = c[i * 5 + j];
(gdb) info locals
No locals.
(gdb) n
Breakpoint 1, main () at test.c:18
18a = c[i * 5 + j];
(gdb) info locals
i = 0
j = 1
(gdb) n
15for (; i < 5; i++) {
(gdb) info locals
i = 5
j = 7
GDB trace with instruction stepping:
$ gdb -q opt
Reading symbols from opt...
(gdb) b 18
Breakpoint 1 at 0x4003b6: /home/stepping/50/reduce/a.c:18. (2 locations)
(gdb) r
Starting program: /home/stepping/50/reduce/opt
Breakpoint 1, foo () at test.c:18
18a = c[i * 5 + j];
(gdb) info loc
No locals.
(gdb) si
0x004003bd in main () at test.c:18
18a = c[i * 5 + j];
(gdb) info loc
i = 0
j = 0
(gdb) si
Breakpoint 1, main () at test.c:18
18a = c[i * 5 + j];
(gdb) info loc
i = 0
j = 1
We can see how in the source-level stepping GDB trace, when the breakpoint at
line 18 is hit for the first time, variables i and j are not available due to
the location overlap. Instead, when stepping through instructions, we see the
correct value of i and j from the second instruction associated with the first
execution of line 18 (since the first one is the only one overlapping).
ASM at -O3 (shortened):
004003a0 :
4003a0: 8b 05 da 0c 20 00 mov0x200cda(%rip),%eax#
601080
4003a6: 8b 15 e8 0c 20 00 mov0x200ce8(%rip),%edx#
601094
4003ac: c7 05 56 0d 20 00 f3movl $0xfff3,0x200d56(%rip)
# 60110c
4003b3: ff ff ff
4003b6: 83 05 a3 0c 20 00 04addl $0x4,0x200ca3(%rip)#
601060
4003bd: 89 05 4d 0d 20 00 mov%eax,0x200d4d(%rip)#
601110
4003c3: 8b 05 bb 0c 20 00 mov0x200cbb(%rip),%eax#
601084
[ . . . ]
400519: 8b 05 c9 0b 20 00 mov0x200bc9(%rip),%eax#
6010e8
40051f: 89 05 eb 0b 20 00 mov%eax,0x200beb(%rip)#
601110
400525: 31 c0 xor%eax,%eax
400527: c3 retq
400528: 0f 1f 84 00 00 00 00nopl 0x0(%rax,%rax,1)
40052f: 00
>From the ASM we see that function foo is inlined within the function main and
all the loops are fully unrolled.
DWARF info at -O3:
0x00a0: DW_TAG_subprogram
DW_AT_external (true)
DW_AT_name ("main")
DW_AT_decl_file ("/home/stepping/50/reduce/a.c")
[Bug c/65891] [9/10/11/12 Regression] -Wlogical-op now warns about logical ‘and’ of equal expressions even when different types/sizeofs are involved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65891 James Legg changed: What|Removed |Added CC||jlegg at feralinteractive dot com --- Comment #7 from James Legg --- (In reply to Kai Tietz from comment #3) > For C++ delayed folding this issue won't be warned anymore, as for it sizeof > isn't folded early. With -fsanitize=integer-divide-by-zero, the spurious warning is still issued in C++.
[Bug rtl-optimization/104985] [12 Regression] ICE: SIGSEGV in undo_to_marker / adjust_reg_mode with -Os -frounding-math since r12-4767-g81342e95827f77
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104985 Richard Biener changed: What|Removed |Added Status|NEW |WAITING --- Comment #2 from Richard Biener --- I can't reproduce this, maybe it's fixed?
[Bug c++/105035] [11/12 Regression] tree check: expected field_decl, have identifier_node in operand_equal_p, at fold-const.c:3335 since r11-5181-g0862d007b564eca8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105035 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment #6 from Patrick Palka --- (In reply to Jakub Jelinek from comment #3) > Another option is to make sure we don't call warn_duplicated_cond_add_or_warn > when processing_template_decl or say when value_dependent_expression_p or > similar, and instead call it during template instantiation in pt.cc after > finish_if_stmt_cond call there. I noticed the warning already gives up on conditions that have TREE_SIDE_EFFECTS set, so I suppose it makes sense to do the same for type-dependent expressions since we can't know if they have side effects until instantiation time. And I wonder if warn_duplicated_cond_add_or_warn should be using cp_tree_equal instead operand_equal_p? IIUC the latter doesn't handle C++-specific tree codes.
[Bug c++/104996] [10/11/12 Regression] Overload resolution over rvalue/const lvalue array reference parameters for an init. list argument incorrectly picks the const lvalue ref. overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104996 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug middle-end/104986] [12 Regression] bogus writing 1 byte into a region of size 0 with -fwrapv and -O2 -fpeel-loops since r12-4698-gf6d012338bf87f42
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104986 Richard Biener changed: What|Removed |Added Keywords||missed-optimization --- Comment #3 from Richard Biener --- This is peeling leaving us with unreachable code we warn on and somehow while figuring prephitmp_30 + -6 is -1 we don't figure nb_58 is zero on the path to bb9. I think I've seen this backward-forward dependency issue with ranger before in another missed optimization PR.
[Bug c++/105006] [12 Regression] ice: tree check: expected function_decl, have using_decl in maybe_push_used_methods, at cp/class.cc:1325
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105006 --- Comment #3 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:a3f78748fab6b24e3d4a8b319afd3f8afa17248f commit r12-7784-ga3f78748fab6b24e3d4a8b319afd3f8afa17248f Author: Jason Merrill Date: Tue Mar 22 11:17:26 2022 -0400 c++: using from enclosing class template [PR105006] Here, DECL_DEPENDENT_P was false for the second using because Row is "the current instantiation", so lookup succeeds. But since Row itself has a dependent using-decl for operator(), the set of functions imported by the second using is dependent, so we should set the flag. PR c++/105006 gcc/cp/ChangeLog: * name-lookup.cc (lookup_using_decl): Set DECL_DEPENDENT_P if lookup finds a dependent using. gcc/testsuite/ChangeLog: * g++.dg/template/using30.C: New test.
[Bug target/105019] [nvptx] malias in libgomp results in "Internal error: reference to deleted section"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105019
--- Comment #5 from Tom de Vries ---
Creating a CUDA example is hampered by the fact that there's no symbol alias
support, AFAICT.
I'd like to write something like:
...
__device__ void __foo ()
{
printf ("__foo\n");
}
__device__ void foo () __attribute__((alias ("__foo")));
__device__ void bar ()
{
foo ();
}
__global__ void hello_world ()
{
bar ();
}
...
(and then comment out bar to reproduce the problem), but all attempts to get
this compiled and executed end up in various errors.
Of course we can resort to hand-edited ptx, or adding .alias directives in asm
statements, but that's likely to produce an 'unsupported' response by nvidia
when filed as bug report.
[Bug target/104894] [11/12 Regression] ICE with -fno-plt -mcpu=power10 on PowerPC64 LE Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104894 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/105035] [11/12 Regression] tree check: expected field_decl, have identifier_node in operand_equal_p, at fold-const.c:3335 since r11-5181-g0862d007b564eca8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105035 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Created attachment 52671 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52671=edit gcc12-pr105035.patch Untested fix.
[Bug tree-optimization/104475] [12 Regression] Wstringop-overflow + atomics incorrect warning on dynamic object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104475 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #9 from Richard Biener --- I think threading unlikely paths is never worth it and usually NULL pointer checks are statically predicted. I guess one idea would be to scale BB cost based on entry_BB->count vs. BB->count so we more quickly run into the threading size limit for unlikely executed blocks? Likewise since we first evaluate all threading opportunities in a function (do we?) we should sort them so we first thread the "best" one and use a global threading limit instead one applied to each individual path (so we'd just stop threading once we hit the limit). Can we, for GCC 12, at least stop threading !maybe_hot_edge_p()? Eventually we can produce sth like a maybe_hot_threading_path_p () taking into account the whole path.
[Bug analyzer/105017] [12 Regression] gcc/analyzer/sm-taint.cc:631:21: warning: private field 'm_mem_space' is not used [-Wunused-private-field]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105017 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- I'm assuming that this was a clang warning, and that this is fixed by the above commit; please reopen if it's still affected.
[Bug analyzer/104997] [12 Regression] ICE in add_note, at analyzer/diagnostic-manager.cc:946 since r12-7677-g7fd6e36ea9aa8575
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104997 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from David Malcolm --- Should be fixed by the above commit.
[Bug target/105010] [12 regression] GCC 12 after 20220227 fails to build on powerpc64-freebsd with Error: invalid mfcr mask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105010 --- Comment #7 from Segher Boessenkool --- Created attachment 52670 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52670=edit proposed patch Does this help? The 7450 (which is what freebsd64 defaults to) indeed does not support these instructions, and it isn't clear to me why we generate them at all anyway, but this patch makes us more conservative here still.
[Bug analyzer/105017] [12 Regression] gcc/analyzer/sm-taint.cc:631:21: warning: private field 'm_mem_space' is not used [-Wunused-private-field]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105017 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:e6a3991ea15c0b14117b5693d77e15fd0477ce51 commit r12-7783-ge6a3991ea15c0b14117b5693d77e15fd0477ce51 Author: David Malcolm Date: Wed Mar 23 08:37:06 2022 -0400 analyzer: use tainted_allocation_size::m_mem_space [PR105017] gcc/analyzer/ChangeLog: PR analyzer/105017 * sm-taint.cc (taint_diagnostic::subclass_equal_p): Check m_has_bounds as well as m_arg. (tainted_allocation_size::subclass_equal_p): Chain up to base class implementation. Also check m_mem_space. (tainted_allocation_size::emit): Add note showing stack-based vs heap-based allocations. gcc/testsuite/ChangeLog: PR analyzer/105017 * gcc.dg/analyzer/taint-alloc-1.c: Add expected messages relating to heap vs stack. Signed-off-by: David Malcolm
[Bug target/104271] [12 Regression] 538.imagick_r run-time at -Ofast -march=native regressed by 26% on Intel Cascade Lake server CPU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104271 Richard Biener changed: What|Removed |Added Status|NEW |WAITING --- Comment #4 from Richard Biener --- Does this still happen after the last fiddling?
[Bug c++/105035] [11/12 Regression] tree check: expected field_decl, have identifier_node in operand_equal_p, at fold-const.c:3335 since r11-5181-g0862d007b564eca8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105035 --- Comment #4 from rguenther at suse dot de --- On Wed, 23 Mar 2022, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105035 > > Jakub Jelinek changed: > >What|Removed |Added > > CC||jakub at gcc dot gnu.org, >||mpolacek at gcc dot gnu.org > > --- Comment #3 from Jakub Jelinek --- > I think because operand_equal_p already has code to deal with the C++ special > trees and because it is such a low level API, changing it seems to be better. Agreed.
[Bug analyzer/104997] [12 Regression] ICE in add_note, at analyzer/diagnostic-manager.cc:946 since r12-7677-g7fd6e36ea9aa8575
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104997 --- Comment #3 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:160b095fc9ded4eaa2bf4d49bd97319f4aabff0a commit r12-7782-g160b095fc9ded4eaa2bf4d49bd97319f4aabff0a Author: David Malcolm Date: Wed Mar 23 08:32:17 2022 -0400 analyzer: fix ICE adding note to disabled diagnostic [PR104997] gcc/analyzer/ChangeLog: PR analyzer/104997 * diagnostic-manager.cc (diagnostic_manager::add_diagnostic): Convert return type from "void" to "bool", reporting success vs failure to caller, for both overloads. * diagnostic-manager.h (diagnostic_manager::add_diagnostic): Likewise. * engine.cc (impl_region_model_context::warn): Propagate return value from diagnostic_manager::add_diagnostic. gcc/testsuite/ChangeLog: PR analyzer/104997 * gcc.dg/analyzer/write-to-string-literal-4-disabled.c: New test, adapted from write-to-string-literal-4.c. Signed-off-by: David Malcolm
[Bug c++/105035] [11/12 Regression] tree check: expected field_decl, have identifier_node in operand_equal_p, at fold-const.c:3335 since r11-5181-g0862d007b564eca8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105035 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- The C++ FE when parsing templates (processing_template_decl is true) produces a lot of trees the middle-end doesn't like. If they aren't type or value dependent, usually (but not always) the trees are such that they can be handed over to the generic code even when parsing templates. The -Wduplicated-cond warning implemented in PR64249 seems to do: condition = finish_if_stmt_cond (condition, statement); if (warn_duplicated_cond) warn_duplicated_cond_add_or_warn (token->location, condition, ); only in the parser regardless of processing_template_decl. So, the options are either to make sure at least operand_equal_p can cope even with those trees and apparently operand_equal_p already has such spots in it, e.g.: /* Similar, if either does not have a type (like a template id), they aren't equal. */ if (!TREE_TYPE (arg0) || !TREE_TYPE (arg1)) return false; So, in this particular case, we'd punt if either field0 or field1 is not a FIELD_DECL (this is in !OP_SAME (1) guarded code). Another option is to make sure we don't call warn_duplicated_cond_add_or_warn when processing_template_decl or say when value_dependent_expression_p or similar, and instead call it during template instantiation in pt.cc after finish_if_stmt_cond call there. I think because operand_equal_p already has code to deal with the C++ special trees and because it is such a low level API, changing it seems to be better.
[Bug tree-optimization/104162] [12 Regression] Missed CSE after lowering of [ptr_1 + CST]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104162 Richard Biener changed: What|Removed |Added Target Milestone|12.0|13.0 Priority|P3 |P2
[Bug rtl-optimization/103775] [12 Regression] Assembler messages: Warning: unpredictable transfer with writeback -- `ldrb w0,[x0,16]!'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103775 Richard Biener changed: What|Removed |Added Priority|P3 |P1
