[Bug target/105073] [meta bug]Patch pending for GCC13.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105073 Uroš Bizjak changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-03-28 Depends on||51954 Status|UNCONFIRMED |NEW Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51954 [Bug 51954] __int128_t (and long long on x86) negation can be optimized
[Bug c++/105060] [10/11] ICE with consteval function: internal compiler error: in cp_gimplify_expr, at cp/cp-gimplify.c:14879 with keep-inline-functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105060 Richard Biener changed: What|Removed |Added Known to work||11.2.1, 12.0 Keywords||ice-on-valid-code, ||needs-bisection Known to fail||10.3.1 --- Comment #1 from Richard Biener --- I cannot reproduce on the GCC 11 branch head, so maybe a fix was already backported and this bug has a duplicate. Confirmed on the GCC 10 branch head.
[Bug c++/105061] [10/11/12 Regression] [c++2a+] anonymous bitfield templated offset rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105061 Richard Biener changed: What|Removed |Added Known to fail||10.3.1 Keywords||needs-bisection Target Milestone|--- |10.4 Summary|[9/10 Regression] [c++2a+] |[10/11/12 Regression] |anonymous bitfield |[c++2a+] anonymous bitfield |templated offset rejected |templated offset rejected Known to work||9.4.1
[Bug sanitizer/84508] Load of misaligned address using _mm_load_sd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84508 --- Comment #17 from Peter Cordes --- (In reply to Andrew Pinski from comment #16) > >According to Intel ( > > https://software.intel.com/sites/landingpage/IntrinsicsGuide), there are no > > alignment requirements for _mm_load_sd, _mm_store_sd and _mm_loaddup_pd. For > > example, from _mm_load_sd: > > I disagree with saying there is no alignment requirement. > > The alignment requirement comes from the type of the argument (double > const*). [...] > Pointers themselves have an alignment requirement not just at the time of > the load/store of them. The intrinsics are badly designed to take pointer args with types other than void*, despite how they're expected to work. This is something we just need to accept. Starting with AVX-512, any new intrinsics take void*, but they haven't redefined the old ones. _mm_loadu_si128 takes a __m128i*, same as _mm_load_si128. alignof(__m128i) == 16, so _mm_loadu_si128 must not simply dereference it, that's what _mm_load_si128 does. Intel's intrinsics API requires you to do unaligned 16-byte loads by creating a misaligned pointer and passing it to a loadu intrinsic. (This in turn requires that implementations supporting these intrinsics define the behaviour of creating such a pointer without deref; in ISO C that alone would be UB.) This additional unaligned-pointer behaviour that implementations must define (at least for __m128i* and float/double*) is something I wrote about in an SO answer: https://stackoverflow.com/questions/52112605/is-reinterpret-casting-between-hardware-simd-vector-pointer-and-the-correspond _mm_loadu_ps (like _mm_load_ps) takes a float*, but its entire purpose it to not require alignment. _mm512_loadu_ps takes a void* arg, so we can infer that earlier FP load intrinsics really are intended to work on data with any alignment, not just with the alignment of a float. They're unlike a normal deref of a float* in aliasing rules, although that's separate from creating a misaligned float* in code outside the intrinsic. A hypothetical low-performance portable emulation of intrinsics that ended up dereferencing that float* arg directly would be broken for strict-aliasing as well. The requirement to define the behaviour of having a misaligned float* can be blamed on Intel in 1995 (when SSE1 was new). Later extensions like AVX _mm256_loadu_ps just followed the same pattern of taking float* until they finally used void* for intrinsics introduced with or after AVX-512. The introduction of _mm_loadu_si32 and si16 is another step in the right direction, recognizing that _mm_cvtsi32_si128( *int_ptr ) isn't strict-aliasing safe. When those were new, it might have been around the time Intel started exploring replacing ICC with the LLVM-based ICX. Anyway, the requirement to support misaligned vector and float/double pointers implies that _mm_load_ss/sd taking float*/double* doesn't imply alignof(float) or alignof(double). > So either the intrinsics definition needs to be changed to be > correct or GCC is correct. That's an option; I'd love it if all the load/store intrinsics were changed across all compilers to take void*. It's ugly and a pain to type _mm_loadu_si128( (const __m128i*)ptr ) as well as creating cognitive dissonance because alignof(__m128i) == 16. I'm not sure if it could break anything to change the intrinsics to take void* even for older ones; possibly only C++ overload resolution for insane code that defines a _mm_loadu_ps( other_type * ) and relies on float* args picking the intrinsic. If we changed just GCC, without getting buy-in from other compilers, taking void* would let people's code compile on GCC without casts from stuff like int*, when it wouldn't compile on other compilers. That could be considered a bad thing if people test their code with GCC and are surprised to get reports of failure from people using compilers that follow Intel's documentation for the intrinsic function arg types. (https://www.intel.com/content/www/us/en/docs/intrinsics-guide/index.html). It would basically be a case of being overly permissive for the feature / API that people are trying to write portable code against.
[Bug c++/105060] [10/11] ICE with consteval function: internal compiler error: in cp_gimplify_expr, at cp/cp-gimplify.c:14879 with keep-inline-functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105060 Jakub Jelinek changed: What|Removed |Added Keywords|needs-bisection | CC||jakub at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jakub Jelinek --- On the trunk this has been fixed with r12-6423-g54fa7daefe35cacf4a933947d1802318da193c01 which has been backported to 11 in r11-9499-g18abe529d092ca00903fe6a9ec5210c91d45030f So dup of PR103912 *** This bug has been marked as a duplicate of bug 103912 ***
[Bug c++/103912] ICE in a consteval function which returns a lambda which takes a "non-POD" argument and the consteval has other code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103912 Jakub Jelinek changed: What|Removed |Added CC||lutztonineubert at gmail dot com --- Comment #8 from Jakub Jelinek --- *** Bug 105060 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/105062] Suboptimal vectorization for reduction with several elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105062 Richard Biener changed: What|Removed |Added Blocks||53947 Ever confirmed|0 |1 Last reconfirmed||2022-03-28 Status|UNCONFIRMED |NEW --- Comment #1 from Richard Biener --- As the cited PR notices: "... the first loop is detected as reduction path while the second one as reduction chain." so what's missing is some "magic" during reduction detection to re-associate a reduction path to a reduction chain. The vectorizer relies on the reassoc pass to do this since re-associating during reduction analysis is a bit complicated. But since not all of the std::max are recognized as MAX_EXPR but some only after loop if-conversion that's too late for reassoc to happen. So the task here is maybe at vect_analyze_slp time try to discover some reduction paths as reduction chains or to be more forgiving during reduction discovery (but there it's more difficult because we rely on the REDUX_IDX chain to be valid even for reduction chains(?)). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug target/105068] ICE: in extract_constrain_insn, at recog.cc:2692 (insn does not satisfy its constraints: ssse3_pshufbv16qi3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105068 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Jakub Jelinek --- Fixed.
[Bug c++/105064] [10/11/12 Regression] requires crashes gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105064 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.4 Priority|P3 |P2
[Bug target/105066] GCC thinks pinsrw xmm, mem, 0 requires SSE4.1, not SSE2? _mm_loadu_si16 bounces through integer reg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105066 Richard Biener changed: What|Removed |Added Last reconfirmed||2022-03-28 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug c++/105067] ICE: in operator[], at vec.h:889
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105067 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-03-28 --- Comment #1 from Richard Biener --- > ./cc1plus -quiet t.ii -std=c++20 t.ii: In substitution of 'template requires C< > class S [with = void]': t.ii:7:7: required from here t.ii:7:7: internal compiler error: in operator[], at vec.h:889 7 | S s; | ^ 0xc063b2 vec, va_heap, vl_embed>::operator[](unsigned int) /home/rguenther/src/gcc3/gcc/vec.h:889 0xc0546a vec, va_heap, vl_ptr>::operator[](unsigned int) /home/rguenther/src/gcc3/gcc/vec.h:1495 0xc00841 get_mapped_args /home/rguenther/src/gcc3/gcc/cp/constraint.cc:2876 0xc00ffe satisfy_atom /home/rguenther/src/gcc3/gcc/cp/constraint.cc:2958 0xc014c1 satisfy_constraint_r /home/rguenther/src/gcc3/gcc/cp/constraint.cc:3028
[Bug c++/105067] [12 Regression] ICE: in operator[], at vec.h:889
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105067 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0 Priority|P3 |P1 Known to work||11.2.1 Summary|ICE: in operator[], at |[12 Regression] ICE: in |vec.h:889 |operator[], at vec.h:889
[Bug analyzer/105074] New: [12 Regression] -fanalyzer ICEs on gnutls-3.7.3: cgraph_node::get_edge(gimple*) SIGSEGV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105074
Bug ID: 105074
Summary: [12 Regression] -fanalyzer ICEs on gnutls-3.7.3:
cgraph_node::get_edge(gimple*) SIGSEGV
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Initially observed ICE when built gnutls-3.7.3 on this week's gcc. Here is the
minimal reproducer:
$ cat cert-session.c
// gcc-12.0.0 -O2 -fanalyzer -o a.o cert-session.c
void _gnutls_log(const char *);
static void _gnutls_ocsp_verify_mandatory_stapling(void) {
_gnutls_log(__func__);
}
void check_ocsp_response_gnutls_x509_cert_verify_peers(void) {
_gnutls_ocsp_verify_mandatory_stapling();
}
$ /tmp/gb/gcc/xgcc -B/tmp/gb/gcc -O2 -fanalyzer -c cert-session.c
during IPA pass: analyzer
In function ‘_gnutls_ocsp_verify_mandatory_stapling’,
inlined from ‘check_ocsp_response_gnutls_x509_cert_verify_peers’ at
cert-session.c:7:3:
cert-session.c:4:3: internal compiler error: Segmentation fault
4 | _gnutls_log(__func__);
| ^
0xdd6bc3 crash_signal
/home/slyfox/dev/git/gcc/gcc/toplev.cc:322
0x8a8120 cgraph_node::get_edge(gimple*)
/home/slyfox/dev/git/gcc/gcc/cgraph.cc:744
0x121059c ipa_ref_requires_tracking
/home/slyfox/dev/git/gcc/gcc/analyzer/region.cc:1192
0x121059c symnode_requires_tracking_p
/home/slyfox/dev/git/gcc/gcc/analyzer/region.cc:1235
0x121059c ana::decl_region::calc_tracked_p(tree_node*)
/home/slyfox/dev/git/gcc/gcc/analyzer/region.cc:1254
0x1234786 ana::decl_region::decl_region(unsigned int, ana::region const*,
tree_node*)
/home/slyfox/dev/git/gcc/gcc/analyzer/region.h:652
0x1234786 ana::region_model_manager::get_region_for_global(tree_node*)
/home/slyfox/dev/git/gcc/gcc/analyzer/region-model-manager.cc:1339
0x1216889 ana::region_model::get_lvalue_1(ana::path_var,
ana::region_model_context*) const
/home/slyfox/dev/git/gcc/gcc/analyzer/region-model.cc:2068
0x1216ad4 ana::region_model::get_lvalue(ana::path_var,
ana::region_model_context*) const
/home/slyfox/dev/git/gcc/gcc/analyzer/region-model.cc:2136
0x1216b44 ana::region_model::get_lvalue(tree_node*, ana::region_model_context*)
const
/home/slyfox/dev/git/gcc/gcc/analyzer/region-model.cc:2147
0x1216f7c ana::region_model::get_rvalue_1(ana::path_var,
ana::region_model_context*) const
/home/slyfox/dev/git/gcc/gcc/analyzer/region-model.cc:2170
0x1217997 ana::region_model::get_rvalue(ana::path_var,
ana::region_model_context*) const
/home/slyfox/dev/git/gcc/gcc/analyzer/region-model.cc:2270
0x1217a14 ana::region_model::get_rvalue(tree_node*, ana::region_model_context*)
const
/home/slyfox/dev/git/gcc/gcc/analyzer/region-model.cc:2285
0x121d3a7 ana::region_model::handle_unrecognized_call(gcall const*,
ana::region_model_context*)
/home/slyfox/dev/git/gcc/gcc/analyzer/region-model.cc:1772
0x121d81d ana::region_model::on_call_post(gcall const*, bool,
ana::region_model_context*)
/home/slyfox/dev/git/gcc/gcc/analyzer/region-model.cc:1576
0x11ef18c ana::exploded_node::on_stmt_post(gimple const*, ana::program_state*,
bool, ana::region_model_context*)
/home/slyfox/dev/git/gcc/gcc/analyzer/engine.cc:1450
0x11f56a7 ana::exploded_node::on_stmt(ana::exploded_graph&, ana::supernode
const*, gimple const*, ana::program_state*, ana::uncertainty_t*,
ana::path_context*)
/home/slyfox/dev/git/gcc/gcc/analyzer/engine.cc:1387
0x11f8dad ana::exploded_graph::process_node(ana::exploded_node*)
/home/slyfox/dev/git/gcc/gcc/analyzer/engine.cc:3756
0x11f90ad ana::exploded_graph::process_worklist()
/home/slyfox/dev/git/gcc/gcc/analyzer/engine.cc:3198
0x11fb201 ana::impl_run_checkers(ana::logger*)
/home/slyfox/dev/git/gcc/gcc/analyzer/engine.cc:5777
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ /tmp/gb/gcc/xgcc -B/tmp/gb/gcc -v |& unnix
Reading specs from /tmp/gb/gcc/specs
COLLECT_GCC=/tmp/gb/gcc/xgcc
COLLECT_LTO_WRAPPER=/tmp/gb/gcc/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/slyfox/dev/git/gcc/configure --disable-multilib
--disable-bootstrap
--with-native-system-header-dir=/<>/glibc-2.33-117-dev/include
--prefix=/tmp/gb/__td__ CFLAGS='-O1 -ggdb3' CXXFLAGS='-O1 -ggdb3' LDFLAGS='-O1
-ggdb3'
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.1 20220328 (experimental) (GCC)
[Bug debug/105070] [9/10/11/12 Regression] Missing debug info for switch statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105070
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Target Milestone|--- |9.5
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Last reconfirmed||2022-03-28
Ever confirmed|0 |1
Summary|Missing debug info for |[9/10/11/12 Regression]
|switch statement|Missing debug info for
||switch statement
Priority|P3 |P2
--- Comment #1 from Richard Biener ---
Interestingly all line number info is lost:
int foo (int x)
{
int D.1961;
int _1;
int _3;
int _4;
unsigned int _6;
_Bool _7;
long unsigned int _8;
long unsigned int _9;
_Bool _10;
:
_6 = (unsigned int) x_2(D);
_7 = _6 > 5;
if (_7 != 0)
goto ; [20.00%]
else
goto ; [80.00%]
:
_8 = 42 >> _6;
_9 = _8 & 1;
_10 = _9 != 0;
if (_10 != 0)
goto ; [60.00%]
else
goto ; [40.00%]
:
[t.c:8:12] _3 = 1;
[t.c:8:12] goto ; [INV]
and the reason is the switchlower pass run at -O0 which does
beginning to process the following SWITCH statement (t.c:4) : ---
switch (x_2(D)) [INV], case 1: [INV], case 3: [INV],
case 5: [INV]>
;; GIMPLE switch case clusters: BT:1-5
Removing basic block 6
but does not put any locations on the generated stmts.
[Bug tree-optimization/105056] [12 Regression] runtime error: load of value 3132799674, which is not a valid value for type 'ref_step_type' since r12-7795-g85b4d881327e31
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105056 --- Comment #4 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:50f9148f7a8daf1fa1608cb23595c3cca191da0f commit r12-7840-g50f9148f7a8daf1fa1608cb23595c3cca191da0f Author: Jakub Jelinek Date: Mon Mar 28 09:51:28 2022 +0200 predcom: Fix up component::component [PR105056] The recent change didn't initialize comp_step while previously we used XCNEW to allocate it. I think RS_ANY is better than RS_INTERNAL (== 0) as the default. 2022-03-28 Jakub Jelinek PR tree-optimization/105056 * tree-predcom.cc (component::component): Initialize also comp_step.
[Bug tree-optimization/105056] [12 Regression] runtime error: load of value 3132799674, which is not a valid value for type 'ref_step_type' since r12-7795-g85b4d881327e31
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105056 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed.
[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 105056, which changed state. Bug 105056 Summary: [12 Regression] runtime error: load of value 3132799674, which is not a valid value for type 'ref_step_type' since r12-7795-g85b4d881327e31 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105056 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/105071] [9 Regression] Incorrect code with -Os and complex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105071 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-03-28 --- Comment #1 from Richard Biener --- Confirmed.
[Bug target/105075] New: [nvptx] Generate sad insn (sum of absolute differences)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105075 Bug ID: 105075 Summary: [nvptx] Generate sad insn (sum of absolute differences) Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- ptx has sad ((sum of absolute differences)) insn, which is currently not modeled in the .md file.
[Bug analyzer/105074] [12 Regression] -fanalyzer ICEs on gnutls-3.7.3: cgraph_node::get_edge(gimple*) SIGSEGV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105074 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0
[Bug tree-optimization/105062] Suboptimal vectorization for reduction with several elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105062
--- Comment #2 from Marc Glisse ---
(In reply to Richard Biener from comment #1)
> But since not all of the std::max are recognized as
> MAX_EXPR but some only after loop if-conversion
Ah, I hadn't noticed. I tried replacing std::max with a simpler by-value
version so we get MAX_EXPR already in early inline, but that didn't help.
Actually, it made things worse:
#include
#include
#include
#include
#include
#include
int my_max(int a, int b){ return (a> vec;
vec.reserve(n);
std::random_device rd;
std::default_random_engine re(rd());
std::uniform_int_distribution rand_int;
std::uniform_real_distribution rand_dbl;
for(int i=0;i(vec[i]),std::get<1>(vec[i])));
volatile int noopt0 = sup;
}
#else
{
int sup = 0;
for(int i=0;i(vec[i])),std::get<1>(vec[i]));
volatile int noopt1 = sup;
}
#endif
auto finish = std::chrono::system_clock::now();
std::cout << std::chrono::duration_cast(finish -
start).count() << '\n';
}
Now reassoc1 turns the fast code into the slow code before the vectorizer can
detect the reduction chain :-(
[Bug middle-end/105076] New: [OpenMP] Weak/template functions: split-off offload-region functions should also be weak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105076
Bug ID: 105076
Summary: [OpenMP] Weak/template functions: split-off
offload-region functions should also be weak
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization, openmp
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
When using something like
template
void foo(T var)
{
#pragma omp target ...
...
}
the function 'foo' is weak – but its associated offload function isn't.
Result: While at the end only one 'foo' function remains, there will be as many
offload function as 'foo'-using translation units.
Expected: Also the split off target-regions should be a weak symbol.
NOTE: Requires a consistent naming of the offload functions, but I think that's
already guaranteed by create_omp_child_function_name (invoked from
create_omp_child_function_name).
Existing testcase:
'test_map' in libgomp/testsuite/libgomp.c++/target-same-name-2.C
of PR104285 / r12-7776-g1002a7ace11
(checks only for link/run-time errors and not for how many offload functions
remain)
[Bug target/105075] [nvptx] Generate sad insn (sum of absolute differences)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105075 --- Comment #1 from Tom de Vries --- Created attachment 52693 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52693&action=edit Demonstrator patch This patch adds: - modeling of insn sad.u32 in the .md file - peephole2 to generate it (which is incomplete, it needs some safety-checks related to using unique intermediate regs) - extra instance of peephole2 pass (otherwise, the peephole is not triggered) - extra instance of fast_rtl_dce pass (otherwise, unused intermediate insn are not cleaned up) So for the usad_2 in the test-case, we have without the patch: ... cvt.u64.u32 %r32, %r28; cvt.u64.u32 %r33, %r29; sub.u64 %r34, %r32, %r33; abs.s64 %r35, %r34; cvt.u32.u64 %r36, %r35; add.u32 %value, %r36, %r30; ... and with: ... sad.u32 %value, %r28, %r29, %r30; ...
[Bug target/105075] [nvptx] Generate sad insn (sum of absolute differences)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105075 --- Comment #2 from Tom de Vries --- AFAIU, at gimple level support is limited to vectors, so that doesn't help to generate the insn for the simple, scalar case. It would be nice if combine could generate it and we wouldn't have to use a peephole, but AFAIU the pattern is too complex for that. I wonder if reformulating using a conditional could help there (ptx isa describes semantics using "c + ((a
[Bug target/105066] GCC thinks pinsrw xmm, mem, 0 requires SSE4.1, not SSE2? _mm_loadu_si16 bounces through integer reg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105066 --- Comment #3 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:e4352a0fee49441a32d12e8d8b98c425cfed4a86 commit r12-7841-ge4352a0fee49441a32d12e8d8b98c425cfed4a86 Author: liuhongt Date: Mon Mar 28 11:12:37 2022 +0800 Fix typo in vec_setv8hi_0. pinsrw is available for both reg and mem operand under sse2. pextrw requires sse4.1 for mem operands. The patch change attr "isa" for pinsrw mem alternative from sse4_noavx to noavx, will enable below optimization. -movzwl (%rdi), %eax pxor%xmm1, %xmm1 -pinsrw $0, %eax, %xmm1 +pinsrw $0, (%rdi), %xmm1 movdqa %xmm1, %xmm0 gcc/ChangeLog: PR target/105066 * config/i386/sse.md (vec_set_0): Change attr "isa" of alternative 4 from sse4_noavx to noavx. gcc/testsuite/ChangeLog: * gcc.target/i386/pr105066.c: New test.
[Bug target/105066] GCC thinks pinsrw xmm, mem, 0 requires SSE4.1, not SSE2? _mm_loadu_si16 bounces through integer reg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105066 --- Comment #4 from Hongtao.liu --- Fixed in GCC12.
[Bug tree-optimization/105062] Suboptimal vectorization for reduction with several elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105062
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #3 from Richard Biener ---
Confirmed. C testcase:
int my_max(int a, int b){ return (a
[Bug target/105075] [nvptx] Generate sad insn (sum of absolute differences)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105075 Tom de Vries changed: What|Removed |Added Attachment #52693|0 |1 is obsolete|| --- Comment #3 from Tom de Vries --- Created attachment 52694 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52694&action=edit Demonstrator patch v2 Forgot to add test-case.
[Bug c++/105077] New: The std::bad_array_new_length is not thrown for some new array scenarios.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105077
Bug ID: 105077
Summary: The std::bad_array_new_length is not thrown for some
new array scenarios.
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: chumarshal at foxmail dot com
Target Milestone: ---
The std::bad_array_new_length is not thrown for the following three scenarios.
These scenarios do not follow C++ spec:"std::bad_array_new_length is the type
of the object thrown as exceptions by the new-expressions to report invalid
array lengths if array length is negative."
case1 using g++ -O0
==
#include
#include
int main()
{
try
{
int negative = -1;
new char[negative];
}
catch(const std::bad_array_new_length &e)
{
}
return 0;
}
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
case2 using g++ -O0
==
#include
#include
struct s_char
{
char ch;
};
int main()
{
try
{
int negative = -1;
new s_char[negative];
}
catch(const std::bad_array_new_length &e)
{
}
return 0;
}
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
case3 using g++ -O0
==
#include
#include
struct s_char_with_new
{
char ch;
void *operator new[] (std::size_t sz)
{
abort();
}
};
int main()
{
try
{
int negative = -1;
new char[negative];
}
catch(const std::bad_array_new_length &e)
{
}
return 0;
}
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
[Bug c++/99934] bad_array_new_length thrown when non-throwing allocation function would have been used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99934 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-03-28 Status|UNCONFIRMED |NEW
[Bug tree-optimization/105078] New: Maybe wrong *** buffer overflow detected ***: terminated with -D_FORTIFY_SOURCE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105078
Bug ID: 105078
Summary: Maybe wrong *** buffer overflow detected ***:
terminated with -D_FORTIFY_SOURCE
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: fab...@ritter-vogt.de, siddhesh at gcc dot gnu.org
Target Milestone: ---
It's what was slightly mentioned here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104964#c6
Thanks to Fabian for the reduced test-case:
$ cat qt.C
#include
#include
#include
struct QArrayData {
int size;
ptrdiff_t offset; // in bytes from beginning of header
void *data() {
return reinterpret_cast(this) + offset;
}
static QArrayData *allocate(size_t size, size_t alignment) {
size_t headerSize = sizeof(QArrayData);
headerSize += (alignment - alignof(QArrayData));
QArrayData *header = static_cast(::malloc(headerSize + size));
header->size = size;
header->offset = headerSize;
return header;
}
};
template
struct QTypedArrayData : QArrayData {
T *data() { return static_cast(QArrayData::data()); }
class AlignmentDummy { QArrayData header; T data; };
static QTypedArrayData *allocate(size_t size) {
return static_cast(QArrayData::allocate(size, alignof(AlignmentDummy)));
}
};
int main()
{
int size = 256;
auto *data = QTypedArrayData::allocate(size);
return readlink("asdf", data->data(), data->size - 1);
}
$ g++ qt.C -D_FORTIFY_SOURCE=2 -O2 && ./a.out
In file included from /usr/include/features.h:490,
from
/home/marxin/bin/gcc/include/c++/12.0.1/x86_64-pc-linux-gnu/bits/os_defines.h:39,
from
/home/marxin/bin/gcc/include/c++/12.0.1/x86_64-pc-linux-gnu/bits/c++config.h:655,
from /home/marxin/bin/gcc/include/c++/12.0.1/cstdlib:41,
from qt.C:1:
In function ‘ssize_t readlink(const char*, char*, size_t)’,
inlined from ‘int main()’ at qt.C:37:24:
/usr/include/bits/unistd.h:119:10: warning: ‘ssize_t __readlink_alias(const
char*, char*, size_t)’ writing 255 bytes into a region of size 0 overflows the
destination [-Wstringop-overflow=]
119 | return __glibc_fortify (readlink, __len, sizeof (char),
| ^~~
qt.C: In function ‘int main()’:
qt.C:24:8: note: at offset 16 into destination object
‘QTypedArrayData::’ of size 16
24 | struct QTypedArrayData : QArrayData {
|^~~
/usr/include/bits/unistd.h:104:16: note: in a call to function ‘ssize_t
__readlink_alias(const char*, char*, size_t)’ declared with attribute ‘access
(write_only, 2, 3)’
104 | extern ssize_t __REDIRECT_NTH (__readlink_alias,
|^~
In function ‘ssize_t readlink(const char*, char*, size_t)’,
inlined from ‘int main()’ at qt.C:37:24:
/usr/include/bits/unistd.h:119:10: warning: ‘ssize_t __readlink_chk(const
char*, char*, size_t, size_t)’ writing 255 bytes into a region of size 0
overflows the destination [-Wstringop-overflow=]
119 | return __glibc_fortify (readlink, __len, sizeof (char),
| ^~~
qt.C: In function ‘int main()’:
qt.C:24:8: note: at offset 16 into destination object
‘QTypedArrayData::’ of size 16
24 | struct QTypedArrayData : QArrayData {
|^~~
In file included from /usr/include/unistd.h:1214,
from qt.C:3:
/usr/include/bits/unistd.h:100:16: note: in a call to function ‘ssize_t
__readlink_chk(const char*, char*, size_t, size_t)’ declared with attribute
‘access (write_only, 2, 3)’
100 | extern ssize_t __readlink_chk (const char *__restrict __path,
|^~
In function ‘ssize_t readlink(const char*, char*, size_t)’,
inlined from ‘int main()’ at qt.C:37:24:
/usr/include/bits/unistd.h:119:10: warning: call to ‘__readlink_chk_warn’
declared with attribute warning: readlink called with bigger length than size
of destination buffer [-Wattribute-warning]
119 | return __glibc_fortify (readlink, __len, sizeof (char),
| ^~~
*** buffer overflow detected ***: terminated
Aborted (core dumped)
[Bug c++/105077] The std::bad_array_new_length is not thrown for some new array scenarios.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105077 --- Comment #1 from Jonathan Wakely --- Looks like a dup of PR 85795
[Bug tree-optimization/102892] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102892
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
Resolution|FIXED |---
Status|RESOLVED|REOPENED
--- Comment #8 from Eric Botcazou ---
The test fails (to link) on SPARC though, here's the .optimized dump at -O3:
;; Function main (main, funcdef_no=0, decl_uid=1488, cgraph_uid=1,
symbol_order=1) (executed once)
Removing basic block 8
Removing basic block 9
Removing basic block 10
Removing basic block 11
int main ()
{
unsigned int ivtmp.8;
long int a;
long int _1;
void * _2;
unsigned int _17;
[local count: 44232128]:
if (a_9(D) != 1)
goto ; [89.00%]
else
goto ; [11.00%]
[local count: 715863673]:
# ivtmp.8_23 = PHI
bar ();
_2 = (void *) ivtmp.8_23;
_1 = MEM[(long int *)_2];
if (_1 == 1)
goto ; [20.24%]
else
goto ; [79.76%]
[local count: 144890806]:
foo ();
[local count: 715863674]:
ivtmp.8_24 = ivtmp.8_23 + 4;
if (_17 != ivtmp.8_24)
goto ; [66.67%]
else
goto ; [33.33%]
[local count: 238597362]:
ivtmp.8_7 = (unsigned int) &b;
_17 = ivtmp.8_7 + 8;
goto ; [100.00%]
[local count: 44232131]:
return 0;
}
[Bug c++/85795] bad_alloc thrown from allocation function when bad_array_length is expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85795
--- Comment #2 from Jonathan Wakely ---
Erroneous expressions include negative ones, as in PR 105077:
#include
#include
int main()
{
try
{
int negative = -1;
new char[negative];
}
catch(const std::bad_array_new_length &e)
{
}
return 0;
}
This throws bad_alloc instead of bad_array_new_length.
PR 99934 is another example where we should not call the allocation function,
but the FE should return a nullptr instead of throwing.
[Bug c++/105077] The std::bad_array_new_length is not thrown for some new array scenarios.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105077 Jonathan Wakely changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Jonathan Wakely --- I've added the first example there. The other two examples are exactly the same scenario. *** This bug has been marked as a duplicate of bug 85795 ***
[Bug c++/85795] bad_alloc thrown from allocation function when bad_array_length is expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85795 Jonathan Wakely changed: What|Removed |Added CC||chumarshal at foxmail dot com --- Comment #3 from Jonathan Wakely --- *** Bug 105077 has been marked as a duplicate of this bug. ***
[Bug target/105079] New: _mm_storeu_si16 inefficiently uses pextrw to an integer reg (without SSE4.1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105079
Bug ID: 105079
Summary: _mm_storeu_si16 inefficiently uses pextrw to an
integer reg (without SSE4.1)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: peter at cordes dot ca
Target Milestone: ---
Target: x86_64-*-*, i?86-*-*
With PR105066 fixed, we do _mm_loadu_si16 with pinsrw from memory, because
that's available with just SSE2. (And the cause wasn't tuning choices, it was
a typo in what insns GCC thought were available.) Related: PR105072 re:
folding such 16-bit loads into memory source operands for PMOVZX/SXBQ.
But the famously non-orthogonal SSE2 only includes pextrw $imm, %xmm, reg. Not
reg/mem until SSE4.1 (with a longer opcode for no apparent reason, instead of
just allowing mem addressing modes for the existing one. But same mnemonic so
the assembler takes care of it. https://www.felixcloutier.com/x86/pextrw)
So we do need to care about tuning for _mm_storeu_si16(p, v) without the option
of PEXTRW to memory. Currently we do this, which is obviously bad:
pextrw $0, %xmm0, %eax # 2 uops
movw%ax, (%rdi)
we should be doing this
movd%xmm0, %eax # 1 uop
mov %ax, (%rdi)
https://godbolt.org/z/Ee3Ez174M
This is especially true if we don't need the integer value zero-extended into
EAX.
If we *did* also want the value zero-extended in an integer register, the extra
uop in PEXTRW (in addition to the port 0 uop like MOVD) is a port-5 shuffle to
extract an arbitrary 16-bit element, vs. a separate integer movzwl %cx, %eax
could run on any integer ALU port. (Including port 6 on HSW/SKL, which doesn't
compete with any vector ALUs).
Mov-elimination for movzwl doesn't work on any current CPUs, only movzbl on
Intel, and movl / movq on both Intel and AMD. So currently there's no benefit
to picking a different register like %ecx, instead of just using movzwl %ax,
%eax
When we both store and use the integer value:
int store16_and_use(void *p, __m128i v){
_mm_storeu_si16( p, v );
return 123 + *(unsigned short*)p;
}
https://godbolt.org/z/zq6TMo1oE current trunk GCC does this, which is not bad:
# -O3 with or without -msse4.1
pextrw $0, %xmm0, %eax
movw%ax, (%rdi)
addl$123, %eax
ret
Clang13 uses MOVD + MOVZX like I was suggesting, even though it costs more code
size. That's not necessarily better
movd%xmm0, %eax
movw%ax, (%rdi)
movzwl %ax, %eax
addl$123, %eax
retq
In this case it's not obviously wrong to use PEXTRW to an integer reg, but it's
also fine to do it clang's way. So however that corner case shakes out in the
process of fixing the main bug (using movd / movw without SSE4.1 when we don't
reload) is fine.
If SSE4.1 is available, the no-reload case should probably use PEXTRW to memory
instead of movd + movw. On some CPUs, the ALU op that's part of PEXTRW has
more choice of ALU port than xmm->gp_int operations.
[Bug target/105066] GCC thinks pinsrw xmm, mem, 0 requires SSE4.1, not SSE2? _mm_loadu_si16 bounces through integer reg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105066 --- Comment #5 from Peter Cordes --- > pextrw requires sse4.1 for mem operands. You're right! I didn't double-check the asm manual for PEXTRW when writing up the initial report, and had never realized that PINSRW wasn't symmetric with it. I was really surprised to see that in https://www.felixcloutier.com/x86/pextrw So we do need to care about tuning for _mm_storeu_si16(p, v) without SSE4.1 (without the option of PEXTRW to memory). PEXTRW to an integer register is obviously bad; we should be doing movd %xmm0, %eax mov %ax, (%rdi) instead of an inefficient pextrw $0, %xmm0, %eax ; movw-store Reported as PR105079, since the cause of the load missed-opt was GCC thinking the instruction wasn't available, rather than a wrong tuning choice like this is.
[Bug target/105069] [12 regression] sh-elf internal compiler errors and test failures with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105069
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
The ICE started with the PR92860 change.
sh_option_optimization_table has:
static const struct default_options sh_option_optimization_table[] =
{
{ OPT_LEVELS_SIZE, OPT_mdiv_, SH_DIV_STR_FOR_SIZE, 1 },
{ OPT_LEVELS_0_ONLY, OPT_mdiv_, "", 1 },
{ OPT_LEVELS_ALL, OPT__param_simultaneous_prefetches_, NULL, 2 },
{ OPT_LEVELS_NONE, 0, NULL, 0 }
};
and so wants to change sh_div_str for -Os or -O0.
But I think SH doesn't support target attribute.
Does sh_override_options_after_change need to do something, or is target
attribute handling now required for backends that do want to change some Target
options based on optimization levels?
[Bug debug/105070] [9/10/11/12 Regression] Missing debug info for switch statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105070 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:bc86a86a4f2c057bc0e0be94dcbb8c128ae7f717 commit r12-7843-gbc86a86a4f2c057bc0e0be94dcbb8c128ae7f717 Author: Richard Biener Date: Mon Mar 28 10:07:53 2022 +0200 tree-optimization/105070 - annotate bit cluster tests with locations The following makes sure to annotate the tests generated by switch lowering bit-clustering with locations which otherwise can be completely lost even at -O0. 2022-03-28 Richard Biener PR tree-optimization/105070 * tree-switch-conversion.h (bit_test_cluster::hoist_edge_and_branch_if_true): Add location argument. * tree-switch-conversion.cc (bit_test_cluster::hoist_edge_and_branch_if_true): Annotate cond with location. (bit_test_cluster::emit): Annotate all generated expressions with location.
[Bug target/105069] [12 regression] sh-elf internal compiler errors and test failures with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105069 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 --- Comment #3 from Jakub Jelinek --- SH isn't primary nor secondary, so P4.
[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 #9 from HaoChen Gui --- Escaped for 'atemp' doesn't be set with Fortran source code, while it's set with C source code. 'auto_var_in_fn_p + pt_solution_includes' works for Fortran code. But if the function is a head of the loop in Fortran, it's still unsafe for multithreaded.
[Bug c++/105077] The std::bad_array_new_length is not thrown for some new array scenarios.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105077
--- Comment #3 from marshal ---
(In reply to Jonathan Wakely from comment #2)
> I've added the first example there. The other two examples are exactly the
> same scenario.
>
> *** This bug has been marked as a duplicate of bug 85795 ***
But why "new int[negative];" throws std::bad_array_new_length as following
case?
I think "new int[negative]" and "new char[negative]" should both throw
std::bad_array_new_length when "int negative = -1;".
new int[negative]
==
#include
#include
int main()
{
int negative = -1;
new int[negative];
return 0;
}
terminate called after throwing an instance of 'std::bad_array_new_length'
what(): std::bad_array_new_length
[Bug target/105075] [nvptx] Generate sad insn (sum of absolute differences)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105075 Thomas Schwinge changed: What|Removed |Added CC||rguenth at gcc dot gnu.org, ||tschwinge at gcc dot gnu.org Last reconfirmed||2022-03-28 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #4 from Thomas Schwinge --- (In reply to Tom de Vries from comment #0) > ptx has sad ((sum of absolute differences)) insn, which is currently not > modeled in the .md file. I also had noticed this, a while ago (but no opportunity to work on it properly). I had found GCC/RTL 'ssad', 'usad', and 'gcc/tree.def:SAD_EXPR', but not verified their applicability. (In reply to Tom de Vries from comment #2) > AFAIU, at gimple level support is limited to vectors, so that doesn't help > to generate the insn for the simple, scalar case. > > It would be nice if combine could generate it and we wouldn't have to use a > peephole, but AFAIU the pattern is too complex for that. > > I wonder if reformulating using a conditional could help there (ptx isa > describes semantics using "c + ((a Also, I wonder if defining a stepping-stone intermediate pattern could help > combine.
[Bug c++/105061] [10/11/12 Regression] [c++2a+] anonymous bitfield templated offset rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105061
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
CC||jakub at gcc dot gnu.org,
||jason at gcc dot gnu.org
Keywords|needs-bisection |
Priority|P3 |P2
Last reconfirmed||2022-03-28
--- Comment #2 from Jakub Jelinek ---
Started with r10-3735-gcb57504a550158913258e5be8ddb991376475efb
P0683R1 was done already r8-3526-g603be0224edf653c1e38229e1d32ed449ffd23bd
template
struct A { T : V, u : U; };
template
struct B { unsigned : V, u : U; };
typedef unsigned uns;
template
struct C { uns : V, u : U; };
[Bug debug/105070] [9/10/11 Regression] Missing debug info for switch statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105070 Richard Biener changed: What|Removed |Added Summary|[9/10/11/12 Regression] |[9/10/11 Regression] |Missing debug info for |Missing debug info for |switch statement|switch statement Known to work||12.0 --- Comment #3 from Richard Biener --- Fixed on trunk sofar.
[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 #10 from rguenther at suse dot de --- On Mon, 28 Mar 2022, guihaoc at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105030 > > --- Comment #9 from HaoChen Gui --- > Escaped for 'atemp' doesn't be set with Fortran source code, while it's set > with C source code. 'auto_var_in_fn_p + pt_solution_includes' works for > Fortran > code. But if the function is a head of the loop in Fortran, it's still unsafe > for multithreaded. The fortran standard requires you to annotate the parameter with POINTER to make it escaped (or to make it threaded). But still the only way for a thread (but not a coroutine for example!) to access stack from another thread is to make a pointer to an object on the stack escape to it.
[Bug c++/105061] [10/11/12 Regression] [c++2a+] anonymous bitfield templated offset rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105061 Jakub Jelinek changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Just a wild guess, should cp_parser_template_introduction temporarily clear parser->colon_corrects_to_scope_p (perhaps only if member_p)?
[Bug target/105075] [nvptx] Generate sad insn (sum of absolute differences)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105075
--- Comment #5 from Richard Biener ---
@cindex @code{ssad@var{m}} instruction pattern
@item @samp{ssad@var{m}}
@cindex @code{usad@var{m}} instruction pattern
@item @samp{usad@var{m}}
Compute the sum of absolute differences of two signed/unsigned elements.
Operand 1 and operand 2 are of the same mode. Their absolute difference, which
is of a wider mode, is computed and added to operand 3. Operand 3 is of a mode
equal or wider than the mode of the absolute difference. The result is placed
in operand 0, which is of the same mode as operand 3.
That cruically "misses" a detail for the vector case where the sum will
also sum across (unspecified!) lanes when operand 3 is wider than the
absolute difference and has a lower number of lanes than the input vectors.
The unspecified part makes it a hart fit for pattern matching (unrolled)
code when actual output lanes are used and they are not being reduced to
a single scalar in the end.
For scalar instruction matching the patterns should be usable.
Note the SAD_EXPR on GENERIC has the same issue when vectors types are
used - the exact semantics are unspecified.
The same is true for DOT_PROD_EXPR and WIDEN_SUM_EXPR and a bunch of others.
These days we'd go for matching them to direct internal function calls
using the {u,s}sad optabs and I don't see any reason to not allow scalar
modes for them. I'd rather get rid of all the tree codes we have for
vectorizer reduction patterns in favor of those so if you can avoid
introducing new ones or adding more uses of existing ones that would be nice.
[Bug c/105080] New: Bugus -Wformat-truncation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105080
Bug ID: 105080
Summary: Bugus -Wformat-truncation
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: marcandre.lureau at gmail dot com
Target Milestone: ---
With Fedora gcc-12.0.1-0.12.fc36.x86_64
gcc (GCC) 12.0.1 20220308 (Red Hat 12.0.1-0)
test.c:
#include
void main(void)
{
char foo[3];
int i;
for (i = 0; i < 16; i++) {
snprintf(foo, sizeof(foo), "%d", i);
}
}
$ gcc -Wformat-truncation test.c
test.c: In function ‘main’:
test.c:9:45: warning: ‘%d’ directive output may be truncated writing between 1
and 11 bytes into a region of size 3 [-Wformat-truncation=]
9 | snprintf(foo, sizeof(foo), "%d", i);
| ^~
test.c:9:44: note: directive argument in the range [-2147483647, 15]
9 | snprintf(foo, sizeof(foo), "%d", i);
|^~~~
test.c:9:17: note: ‘snprintf’ output between 2 and 12 bytes into a destination
of size 3
9 | snprintf(foo, sizeof(foo), "%d", i);
| ^~~
The computed range seems incorrect. There are similar variants of this bug that
have been found while compiling QEMU
(https://patchew.org/QEMU/20220328084717.367993-1-marcandre.lur...@redhat.com/)
[Bug target/105014] [nvptx] FAIL: gcc.dg/pr97459-1.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105014 --- Comment #6 from Tom de Vries --- Reproducer filed at https://github.com/vries/nvidia-bugs/tree/master/shift-and PR filed at nvidia ( https://developer.nvidia.com/nvidia_bug/3585290 ).
[Bug tree-optimization/105078] Maybe wrong *** buffer overflow detected ***: terminated with -D_FORTIFY_SOURCE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105078
--- Comment #1 from Siddhesh Poyarekar ---
With gcc12:
Computing maximum subobject size for _11:
Visiting use-def links for _11
Visiting use-def links for _10
Computing maximum object size for header_12:
Visiting use-def links for header_12
header_12: maximum object size 272
_10: maximum subobject size 16
_11: maximum subobject size 0
Simplified
_2 = __builtin_object_size (_11, 1);
to 0
gimple_simplified to if (0 != 0)
gimple_simplified to _4 = 0;
int main ()
{
struct QArrayData * header;
long unsigned int _2;
int _3;
bool _4;
int _5;
long int iftmp.1_6;
long int iftmp.2_7;
long int iftmp.2_8;
long int iftmp.1_9;
struct QArrayData * _10;
void * _11;
[local count: 1073741824]:
header_12 = malloc (272);
header_12->size = 256;
header_12->offset = 16;
_10 = &MEM[(struct QTypedArrayData *)header_12].D.4557;
_11 = _10 + 16;
_2 = __builtin_object_size (_11, 1);
_4 = 0;
_5 = __builtin_constant_p (_4);
if (_5 != 0)
goto ; [50.00%]
else
goto ; [50.00%]
...
with gcc11:
;; Function main (main, funcdef_no=54, decl_uid=4523, cgraph_uid=48,
symbol_order=47) (executed once)
Computing maximum subobject size for _11:
Visiting use-def links for _11
Visiting use-def links for header_12
_11: maximum subobject size 256
header_12: maximum subobject size 272
Simplified
_2 = __builtin_object_size (_11, 1);
to 256
gimple_simplified to if (0 != 0)
gimple_simplified to if (1 != 0)
gimple_simplified to _4 = 1;
int main ()
{
struct QArrayData * header;
long unsigned int _2;
int _3;
bool _4;
int _5;
long int iftmp.1_6;
long int iftmp.2_7;
long int iftmp.2_8;
long int iftmp.1_9;
void * _11;
[local count: 1073741823]:
header_12 = malloc (272);
header_12->size = 256;
header_12->offset = 16;
_11 = &MEM [(void *)header_12 + 16B];
_2 = __builtin_object_size (_11, 1);
_4 = 1;
_5 = __builtin_constant_p (_4);
if (_5 != 0)
goto ; [50.00%]
else
goto ; [50.00%]
...
The
&MEM [(void *)header_12 + 16B]
vs
_10 = &MEM[(struct QTypedArrayData *)header_12].D.4557;
_11 = _10 + 16;
appears to be the difference, where the gcc11 version allows the full size
(272) to be seen while the cast to QTypedArrayData in the latter allows only
the sizeof (QTypedArrayData) to be seen as subobject size.
[Bug c++/105077] The std::bad_array_new_length is not thrown for some new array scenarios.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105077 --- Comment #4 from Jonathan Wakely --- (In reply to marshal from comment #3) > But why "new int[negative];" throws std::bad_array_new_length as following > case? Because that case requires size_t(-1) * sizeof(int) and the compiler detects that it's out of range. It fails to detect that size_t(-1) is already incorrect. > I think "new int[negative]" and "new char[negative]" should both throw > std::bad_array_new_length when "int negative = -1;". Yes, it's a bug.
[Bug gcov-profile/105063] [GCOV] Ability to map .gcda paths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105063 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2022-03-28 --- Comment #1 from Martin Liška --- Can you please provide a self-contained test-case that shows your problem?
[Bug target/105069] [12 regression] sh-elf internal compiler errors and test failures with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105069 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-03-28 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #4 from Martin Liška --- Lemme take a look.
[Bug tree-optimization/105078] Maybe wrong *** buffer overflow detected ***: terminated with -D_FORTIFY_SOURCE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105078 --- Comment #2 from Martin Liška --- > appears to be the difference, where the gcc11 version allows the full size > (272) to be seen while the cast to QTypedArrayData in the latter allows only > the sizeof (QTypedArrayData) to be seen as subobject size. Started with r12-2270-gdddb6ffdc5c25264.
[Bug c/105080] Bugus -Wformat-truncation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105080
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords||diagnostic
Ever confirmed|0 |1
Last reconfirmed||2022-03-28
--- Comment #1 from Richard Biener ---
Confirmed. The issue is that at -O0 we do not use SCEV and thus range analysis
is limited, just using i < 16.
static unsigned int
printf_strlen_execute (function *fun, bool warn_only)
{
strlen_optimize = !warn_only;
calculate_dominance_info (CDI_DOMINATORS);
bool use_scev = optimize > 0 && flag_printf_return_value;
if (use_scev)
{
loop_optimizer_init (LOOPS_NORMAL);
scev_initialize ();
}
at -O0 we call this when warn_format_overflow > 0 || warn_format_trunc > 0 so
to improve we could maybe do || warn_only above. That would fix the bogus
diagnostic.
[Bug c/105080] Bugus -Wformat-truncation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105080
Richard Biener changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
--- Comment #2 from Richard Biener ---
(In reply to Richard Biener from comment #1)
> Confirmed. The issue is that at -O0 we do not use SCEV and thus range
> analysis is limited, just using i < 16.
>
> static unsigned int
> printf_strlen_execute (function *fun, bool warn_only)
> {
> strlen_optimize = !warn_only;
>
> calculate_dominance_info (CDI_DOMINATORS);
>
> bool use_scev = optimize > 0 && flag_printf_return_value;
> if (use_scev)
> {
> loop_optimizer_init (LOOPS_NORMAL);
> scev_initialize ();
> }
>
> at -O0 we call this when warn_format_overflow > 0 || warn_format_trunc > 0 so
> to improve we could maybe do || warn_only above. That would fix the bogus
> diagnostic.
Or rather always do this, even the late pass as otherwise I see a bogus
diagnostic with -fno-printf-return-value even when optimizing:
> ./cc1 -quiet t.c -Wall -O -fno-printf-return-value
t.c:1:6: warning: return type of 'main' is not 'int' [-Wmain]
1 | void main(void)
| ^~~~
t.c: In function 'main':
t.c:7:55: warning: '%d' directive output may be truncated writing between 1 and
11 bytes into a region of size 3 [-Wformat-truncation=]
7 | __builtin_snprintf(foo, sizeof(foo), "%d", i);
| ^~
t.c:7:54: note: directive argument in the range [-2147483647, 2147483647]
7 | __builtin_snprintf(foo, sizeof(foo), "%d", i);
| ^~~~
t.c:7:17: note: '__builtin_snprintf' output between 2 and 12 bytes into a
destination of size 3
7 | __builtin_snprintf(foo, sizeof(foo), "%d", i);
| ^
[Bug c++/105067] [12 Regression] ICE: in operator[], at vec.h:889 since r12-7631-g9413bb55185b9e88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105067 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||ppalka at gcc dot gnu.org Summary|[12 Regression] ICE: in |[12 Regression] ICE: in |operator[], at vec.h:889|operator[], at vec.h:889 ||since ||r12-7631-g9413bb55185b9e88 --- Comment #2 from Martin Liška --- Started with r12-7631-g9413bb55185b9e88.
[Bug middle-end/105071] [9 Regression] Incorrect code with -Os and complex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105071 Martin Liška changed: What|Removed |Added Keywords|needs-bisection | CC||jamborm at gcc dot gnu.org, ||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Fixed on master with r10-3311-gff6686d2e5f797d6, if I add -fno-ipa-sra for the revision, it's still correct.
[Bug analyzer/105074] [12 Regression] -fanalyzer ICEs on gnutls-3.7.3: cgraph_node::get_edge(gimple*) SIGSEGV since r12-7809-g5f6197d7c197f9d2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105074 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 Summary|[12 Regression] -fanalyzer |[12 Regression] -fanalyzer |ICEs on gnutls-3.7.3: |ICEs on gnutls-3.7.3: |cgraph_node::get_edge(gimpl |cgraph_node::get_edge(gimpl |e*) SIGSEGV |e*) SIGSEGV since ||r12-7809-g5f6197d7c197f9d2 Last reconfirmed||2022-03-28 Status|UNCONFIRMED |NEW --- Comment #1 from Martin Liška --- Started with r12-7809-g5f6197d7c197f9d2.
[Bug tree-optimization/104450] [11 Regression] ICE: verify_flow_info failed: BB 2 cannot throw but has an EH edge with -O -fnon-call-exceptions -fsanitize=thread -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104450 Martin Liška changed: What|Removed |Added Keywords|needs-bisection | CC||marxin at gcc dot gnu.org --- Comment #5 from Martin Liška --- Btw. started with r11-1645-ga8d8caca0cbfde03.
[Bug c++/101054] Compiler inconsistently gives error when constexpr class function is called from lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101054 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Keywords|needs-bisection | CC||marxin at gcc dot gnu.org Last reconfirmed||2022-03-28 Status|UNCONFIRMED |NEW --- Comment #2 from Martin Liška --- Fixed with r11-88-g733195e367d84914.
[Bug tree-optimization/105078] Maybe wrong *** buffer overflow detected ***: terminated with -D_FORTIFY_SOURCE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105078
--- Comment #3 from Jakub Jelinek ---
This changed with r12-2270-gdddb6ffdc5c25264dd75ad82dad8e48a0718d2d9
Before that commit it has been the forwprop2 pass that changed
_6 = &MEM[(struct QTypedArrayData *)header_8].D.2415;
_7 = _6 + 16;
to
_7 = &MEM [(void *)header_8 + 16B];
and that was done before objsz2 pass, but now objsz is done before fwprop2
(intentionally).
The D.2415 there is the artificial base object.
I'd say the C++ derived class case is similar to:
struct S { int size; __PTRDIFF_TYPE__ offset; };
struct T { struct S base; };
__SIZE_TYPE__ foo (struct T *p) { return __builtin_object_size ((char *)
&p->base + sizeof (struct S), 1); }
__SIZE_TYPE__ bar (struct T *p) { return __builtin_object_size ((char *) p +
sizeof (struct S), 1); }
We've been since forever returning 0 from foo and all ones from bar, because in
the first case we are crossing subobject boundary.
I guess what would work is add char payload[]; to QArrayData and base the
pointer on address of that (+ offset - offsetof(QArrayData, payload)).
[Bug libstdc++/105081] New: Make std::random_device throw std::system_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105081 Bug ID: 105081 Summary: Make std::random_device throw std::system_error Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- Unsupported constructor tokens could throw a std::system_error with std::invalid_argument instead of just std::runtime_error. That would match what libc++ does. This shouldn't break any existing code, because a handler for std::runtime_error will still catch a std::system_error exception.
[Bug libstdc++/105081] Make std::random_device throw std::system_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105081 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |13.0
[Bug fortran/102043] [9/10/11/12 Regression] Wrong array types used for negative stride accesses, gfortran.dg/vector_subscript_1.f90 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043 --- Comment #37 from Richard Biener --- (In reply to rguent...@suse.de from comment #36) > On Sun, 27 Mar 2022, mikael at gcc dot gnu.org wrote: > > > For gcc-12, is there a way to add a middle-end workaround using annotations > > on > > descriptor types (a lang flag or something) ? > > I will think of what options we have to work around this in the > middle-end (maybe with help of the frontend during gimplification). So the difficult issue is that the intended effect of the ARRAY_REF is to apply a negative offset to its base. That's something fundamentally not supported for any handled component reference, especially when it is a non-constant negative offset. An access is currently constrained to [offset, offset + max_size] where max_size can be unknown (we use a special value of -1 for that). In particular 'offset' cannot be unknown, but when we split the ultimate base object we do support a constant negative offset from the real base object. So we consider a get_base_address() base plus [0, 0 + unknown] to be a valid conservative answer - but for the fortran ARRAY_REF indexing it would not be! Now - actual miscompilations of course require more specific setups, the ones cited here take advantage of knowing the size of the underlying object and together with the offset >= 0 constraint constraining the variable index to exactly the last element of the array. We already have -funconstrained-commons to catch a similar case (but with trailing arrays here). On the middle-end side it's hard to tell whether the actual array reference is from a "safe" one (not via an array descriptor and not with negative stride), so truly fixing it there with lowering the ARRAY_REF to pointer arithmetic would be a mass-rewrite of even safe accesses. Another effect besides the wrong constant propagation would be disambiguation of accesses. Like if we had integer, dimension (10) :: a do i = 1, 10 reshape(a, (/10:1:-1/))(i) = a(i) end do (sorry for my likely invalid fortran, but you get the idea), then the middle-end would disambiguate all a(i) besides a(10) against the store. To sum up, I don't see a good way to workaround this in the middle-end (without a really big hammer that would do more harm than good). I also do not see a way to teach the middle-end negative offsetting ARRAY_REFs, even if you'd call them differently. The issue itself is long latent so we probably have to live with GCC 12 exposing slightly more cases of it in the real world (I have yet to see one there).
[Bug fortran/102043] [9/10/11/12 Regression] Wrong array types used for negative stride accesses, gfortran.dg/vector_subscript_1.f90 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043 --- Comment #38 from Tobias Burnus --- (In reply to Thomas Koenig from comment #15) > One possibility would be to extend the patch Sandra posted at > https://gcc.gnu.org/pipermail/fortran/2021-January/055563.html > to scalarization. As mentioned by Thomas, a re-based patch is https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584716.html (I did not quickly see whether Mikael's patch c, attachment 51974) is completely orthogonal, goes in the same direction or a different one.) Mikael Morin wrote in (comment #35) > I have tried to fix this PR using pointer arithmetic too. > But there are so many places in the frontend where we expect to have an > array type when dereferencing a descriptor pointer Do you see a special issue here or not? In that area, I realized when working on my OpenMP deep-mapping patch that there were issues related to coarrays and CLASS, in particular: * 'select type' always adds 'attr.pointer' which both permits wrong code (e.g. deallocate, pointer assignment), but also sets the GFC_ARRAY_POINTER - but fixing it then caused issues with coarrays. (GFC_TYPE_ARRAY_AKIND also does not distinguish allocatable/pointer for assumed rank, but that should be only/mostly a problem for my OpenMP patch.) I have a continuously growing to-do list, but still: is there something I can do here?
[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 #8 from Jakub Jelinek --- Created attachment 52695 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52695&action=edit gcc12-pr104985.patch As I can't reproduce, just an untested patch, which will not keep around addresses of regno_reg_rtx array elements, but the regnos. Yet another option would be to make where.m a rtx and save there the REGs.
[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 #9 from Richard Biener --- (In reply to Jakub Jelinek from comment #8) > Created attachment 52695 [details] > gcc12-pr104985.patch > > As I can't reproduce, just an untested patch, which will not keep around > addresses of regno_reg_rtx array elements, but the regnos. > Yet another option would be to make where.m a rtx and save there the REGs. I think that's a good cleanup! Martin - does this fix the issue?
[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 #10 from Jakub Jelinek --- Created attachment 52696 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52696&action=edit gcc12-pr104985-2.patch A variant patch, also untested, but much smaller. Yet another way would be to change do_SUBST_MODE into SUBST_MODE and just pass the rtx instead of rtx *.
[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 #11 from Jakub Jelinek --- Created attachment 52697 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52697&action=edit gcc12-pr104985-3.patch And 3rd untested version, keep SUBST_MODE users as they are, but change SUBST_MODE implementation and UNDO_MODE users.
[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 #12 from Jakub Jelinek --- I think once gen_reg_rtx is called, we no longer overwrite regno_reg_rtx[regno] but just modify it in place to change mode (except that we throw it away at the end of RTL passes for each function), so I think all 3 patches should be safe.
[Bug c++/105067] [12 Regression] ICE: in operator[], at vec.h:889 since r12-7631-g9413bb55185b9e88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105067 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug tree-optimization/105080] [12 Regression] Bugus -Wformat-truncation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105080 Richard Biener changed: What|Removed |Added Known to work||11.2.1 Summary|Bugus -Wformat-truncation |[12 Regression] Bugus ||-Wformat-truncation Component|c |tree-optimization Target Milestone|--- |12.0 --- Comment #3 from Richard Biener --- GCC 11 doesn't warn.
[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 Martin Liška changed: What|Removed |Added Status|WAITING |NEW --- Comment #13 from Martin Liška --- I can confirm all the patches handle the crash. Thanks for it.
[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 Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
[Bug tree-optimization/105080] [12 Regression] Bugus -Wformat-truncation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105080 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #4 from Richard Biener --- Testgin the fix.
[Bug target/105075] [nvptx] Generate sad insn (sum of absolute differences)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105075 --- Comment #6 from Tom de Vries --- Created attachment 52698 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52698&action=edit Demonstrator patch with stepping stone patterns for combine (In reply to Tom de Vries from comment #2) > Also, I wonder if defining a stepping-stone intermediate pattern could help > combine. Well, that approach seems to work.
[Bug libgomp/105042] [libgomp, GOMP_NVPTX_JIT=-O0] Openacc testsuite failures when X runs on nvidia driver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105042 Tom de Vries changed: What|Removed |Added Severity|normal |enhancement --- Comment #8 from Tom de Vries --- With the conversation shifted to better error messages, re-classifying as enhancement.
[Bug target/105075] [nvptx] Generate sad insn (sum of absolute differences)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105075 --- Comment #7 from rguenther at suse dot de --- On Mon, 28 Mar 2022, vries at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105075 > > --- Comment #6 from Tom de Vries --- > Created attachment 52698 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52698&action=edit > Demonstrator patch with stepping stone patterns for combine > > (In reply to Tom de Vries from comment #2) > > Also, I wonder if defining a stepping-stone intermediate pattern could help > > combine. > > Well, that approach seems to work. Another possibility is to do this on GIMPLE where we detect widen multiplication and friends (tree-ssa-math-opts.cc:pass_optimize_widening_mul).
[Bug target/104868] [12 Regression] powerpc: Compiling libgfortran with -flto failing with GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104868 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #11 from Jakub Jelinek --- Assuming this is fixed, if not, please reopen.
[Bug c++/105064] [10/11/12 Regression] requires crashes gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105064 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug middle-end/105082] New: [OpenMP] [RFC] Add warning like LLVM's "declaration marked as declare target after first use, it may lead to incorrect results [-Wopenmp-target]" ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105082
Bug ID: 105082
Summary: [OpenMP] [RFC] Add warning like LLVM's "declaration
marked as declare target after first use, it may lead
to incorrect results [-Wopenmp-target]" ?
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: diagnostic, openmp
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
According to https://github.com/SOLLVE/sollve_vv/issues/506 , LLVM has the
following '-Wopenmp-target' warning.
RFC: Add a similar warning to warn_omp_declare_target_after_first_use ?
(
https://github.com/llvm/llvm-project/commit/729e242a7972f4802f982a4b4dabb964aa299675
)
warning: declaration marked as declare target after first use, it may lead to
incorrect results [-Wopenmp-target]
#pragma omp declare target link(a,b,c,i)
for code like:
int a[N], b[N], c[N];
int i = 0;
void update() {
for (i = 0; i < N; i++) {
a[i] += 1;
b[i] += 2;
c[i] += 3;
}
}
#pragma omp declare target
#pragma omp declare target link(a,b,c,i)
#pragma omp declare target to(update)
#pragma omp end declare target
[Bug middle-end/105083] New: scev_initialize should check for loop prerequesites
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105083 Bug ID: 105083 Summary: scev_initialize should check for loop prerequesites Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- The SCEV code has prerequesites like looking at preheader edges or requiring recorded exists but it does not verify presence of those in scev_initialize (). It could also provide safe operation without those.
[Bug middle-end/105083] scev_initialize should check for loop prerequesites
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105083 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2022-03-28 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #1 from Richard Biener --- I will see to better document this for GCC 13.
[Bug c++/104503] [12 regression][modules] bits/shared_ptr_base.h: error: must ‘#include ’ before using ‘typeid’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104503 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- The FE requires that std::type_info definition is seen before it can handle typeid, so bet the module code needs to take it into account.
[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 --- Comment #9 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:07be8f8da4c6840a1fd6b2229b147e50cc6f03dc commit r12-7848-g07be8f8da4c6840a1fd6b2229b147e50cc6f03dc Author: Jason Merrill Date: Fri Mar 25 11:26:06 2022 -0400 c++: ICE with alias in pack expansion [PR103769] This was breaking because when we stripped the 't' typedef in s...> to be s, the TYPE_MAIN_VARIANT of "Args..." was still "t...", because type pack expansions are treated as types. Fixed by using the right function to copy a "type". PR c++/99445 PR c++/103769 gcc/cp/ChangeLog: * tree.cc (strip_typedefs): Use build_distinct_type_copy. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/variadic-alias5.C: New test.
[Bug c++/99445] [11 Regression] ICE in hashtab_chk_error, at hash-table.c:137 since r11-7011-g6e0a231a4aa2407b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99445 --- Comment #12 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:07be8f8da4c6840a1fd6b2229b147e50cc6f03dc commit r12-7848-g07be8f8da4c6840a1fd6b2229b147e50cc6f03dc Author: Jason Merrill Date: Fri Mar 25 11:26:06 2022 -0400 c++: ICE with alias in pack expansion [PR103769] This was breaking because when we stripped the 't' typedef in s...> to be s, the TYPE_MAIN_VARIANT of "Args..." was still "t...", because type pack expansions are treated as types. Fixed by using the right function to copy a "type". PR c++/99445 PR c++/103769 gcc/cp/ChangeLog: * tree.cc (strip_typedefs): Use build_distinct_type_copy. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/variadic-alias5.C: New test.
[Bug c++/104847] [11/12 Regression] ICE in write_unqualified_name, at cp/mangle.cc:1406
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104847
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:71e1db540c01a13b01fae054c92878a79252b471
commit r12-7849-g71e1db540c01a13b01fae054c92878a79252b471
Author: Jason Merrill
Date: Sat Mar 26 20:10:19 2022 -0400
c++: mangling union{1} in template [PR104847]
My implementation of union non-type template arguments in r11-2016 broke
braced casts of union type, because they are still in syntactic
(undigested)
form.
PR c++/104847
gcc/cp/ChangeLog:
* mangle.cc (write_expression): Don't write a union designator when
undigested.
gcc/testsuite/ChangeLog:
* g++.dg/abi/mangle-union1.C: New test.
[Bug c++/102045] [11/12 regression] constructor is not being instantiated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102045 --- Comment #6 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:72bdfcb848327020f62f72405d72cf85650666e1 commit r12-7850-g72bdfcb848327020f62f72405d72cf85650666e1 Author: Jason Merrill Date: Sat Mar 26 20:38:54 2022 -0400 c++: missing aggregate base ctor [PR102045] When make_base_init_ok changes a call to a complete constructor into a call to a base constructor, we were never marking the base ctor as used, so it didn't get emitted. PR c++/102045 gcc/cp/ChangeLog: * call.cc (make_base_init_ok): Call make_used. gcc/testsuite/ChangeLog: * g++.dg/cpp1z/aggr-base12.C: New test.
[Bug c++/103943] [11/12 Regression] ICE building qualified name inside class with variadic CTAD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103943 --- Comment #3 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:8bc5cdaafa2e729f9209684dc30aa0acb72d2580 commit r12-7851-g8bc5cdaafa2e729f9209684dc30aa0acb72d2580 Author: Jason Merrill Date: Sat Mar 26 22:05:53 2022 -0400 c++: CTAD and member function references [PR103943] More quirks of rewriting member references to dependent references for CTAD. A reference to a member of dependent scope is definitely dependent. And since r11-7044, tsubst_baselink builds a SCOPE_REF, so tsubst_qualified_id should just use it. PR c++/103943 gcc/cp/ChangeLog: * pt.cc (tsubst_qualified_id): Handle getting SCOPE_REF from tsubst_baselink. (instantiation_dependent_scope_ref_p): Check dependent_scope_p. gcc/testsuite/ChangeLog: * g++.dg/cpp1z/class-deduction109.C: New test.
[Bug c++/103968] [11/12 Regression] ICE and segfault when instantiating template with lvalue ref argument and nested template type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103968 --- Comment #2 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:c7361eb36fa50307c9f7cfca36c9f58ce24f8f54 commit r12-7852-gc7361eb36fa50307c9f7cfca36c9f58ce24f8f54 Author: Jason Merrill Date: Sun Mar 27 00:28:30 2022 -0400 c++: member alias declaration [PR103968] Here, we were wrongly thinking that (const Options&)Widget::c_options is not value-dependent because neither the type nor the (value of) c_options are dependent, but since we're binding it to a reference we also need to consider that it has a value-dependent address. PR c++/103968 gcc/cp/ChangeLog: * pt.cc (value_dependent_expression_p): Check has_value_dependent_address for conversion to reference. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/alias-decl-mem1.C: New test.
[Bug c++/102123] [11/12 Regression] Internal Compiler Error occurs during template deduction in use with templates as template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102123 --- Comment #4 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:b854ce130ebbfdf2f882ef08538746030513b44b commit r12-7853-gb854ce130ebbfdf2f882ef08538746030513b44b Author: Jason Merrill Date: Sat Mar 26 23:54:22 2022 -0400 c++: CTAD and member alias template [PR102123] When building a deduction guide from the Test constructor, we need to rewrite the use of _dummy into a dependent reference, i.e. Test::template _dummy. We were using SCOPE_REF for both type and non-type templates; we need to use UNBOUND_CLASS_TEMPLATE for type templates. PR c++/102123 gcc/cp/ChangeLog: * pt.cc (tsubst_copy): Use make_unbound_class_template for rewriting a type template reference. gcc/testsuite/ChangeLog: * g++.dg/cpp1z/class-deduction110.C: New test.
[Bug c++/103291] [11/12 Regression] #pragma gcc visibility is lost for external decls declared inside a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103291 --- Comment #5 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:8796eb27e24bd3340ebd393e96a94b91d09407e9 commit r12-7854-g8796eb27e24bd3340ebd393e96a94b91d09407e9 Author: Jason Merrill Date: Sun Mar 27 09:44:59 2022 -0400 c++: visibility of local extern [PR103291] When setting up the hidden namespace-scope decl for a local extern, we also need to set its visibility. PR c++/103291 gcc/cp/ChangeLog: * name-lookup.cc (push_local_extern_decl_alias): Call determine_visibility. gcc/testsuite/ChangeLog: * g++.dg/ext/visibility/visibility-local-extern1.C: New test.
[Bug c++/102071] [10/11/12 Regression] crash when combining -faligned-new=N with array cookie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102071 --- Comment #5 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:19b87a06482756739087283cd8b884cb3de693f9 commit r12-7855-g19b87a06482756739087283cd8b884cb3de693f9 Author: Jason Merrill Date: Sun Mar 27 12:36:13 2022 -0400 c++: low -faligned-new [PR102071] This test ICEd after the constexpr new patch (r10-3661) because alloc_call had a NOP_EXPR around it; fixed by moving the NOP_EXPR to alloc_expr. And the PR pointed out that the size_t cookie might need more alignment, so I fix that as well. PR c++/102071 gcc/cp/ChangeLog: * init.cc (build_new_1): Include cookie in alignment. Omit constexpr wrapper from alloc_call. gcc/testsuite/ChangeLog: * g++.dg/cpp1z/aligned-new9.C: New test.
[Bug target/105068] ICE: in extract_constrain_insn, at recog.cc:2692 (insn does not satisfy its constraints: ssse3_pshufbv16qi3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105068 --- Comment #3 from CVS Commits --- The releases/gcc-11 branch has been updated by H.J. Lu : https://gcc.gnu.org/g:a374915186ecab108c983a84b6afcede680100a4 commit r11-9701-ga374915186ecab108c983a84b6afcede680100a4 Author: H.J. Lu Date: Sun Mar 27 11:07:39 2022 -0700 x86: Use Yw constraint on *ssse3_pshufbv8qi3 Since AVX512VL and AVX512BW are required for AVX512 VPSHUFB, replace the "Yv" register constraint with the "Yw" register constraint. gcc/ PR target/105068 * config/i386/sse.md (*ssse3_pshufbv8qi3): Replace "Yv" with "Yw". (cherry picked from commit 08e69332881f8d28ce8b559ffba1900ae5c0d5ee)
[Bug analyzer/104308] no location info provided for [-Wanalyzer-use-of-uninitialized-value] warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104308
--- Comment #6 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:875342766d42988fa2f8eb7d34ef562ba69e340a
commit r12-7856-g875342766d42988fa2f8eb7d34ef562ba69e340a
Author: David Malcolm
Date: Mon Mar 28 09:43:07 2022 -0400
gimple-fold: fix location of loads for memory ops [PR104308]
PR analyzer/104308 reports that when -Wanalyzer-use-of-uninitialized-value
complains about certain memmove operations where the source is
uninitialized, the diagnostic uses UNKNOWN_LOCATION:
In function 'main':
cc1: warning: use of uninitialized value '*(short unsigned int *)&s + 1'
[CWE-457] [-Wanalyzer-use-of-uninitialized-value]
'main': event 1
|
|pr104308.c:5:8:
|5 | char s[5]; /* { dg-message "region created on stack here" }
*/
| |^
| ||
| |(1) region created on stack here
|
'main': event 2
|
|cc1:
| (2): use of uninitialized value '*(short unsigned int *)&s + 1' here
|
The issue is that gimple_fold_builtin_memory_op converts a memmove to:
_3 = MEM [(char * {ref-all})_1];
MEM [(char * {ref-all})&s] = _3;
but only sets the location of the 2nd stmt, not the 1st.
Fixed thusly, giving:
pr104308.c: In function 'main':
pr104308.c:6:3: warning: use of uninitialized value '*(short unsigned int
*)&s + 1' [CWE-457] [-Wanalyzer-use-of-uninitialized-value]
6 | memmove(s, s + 1, 2); /* { dg-warning "use of uninitialized
value" } */
| ^~~~
'main': events 1-2
|
|5 | char s[5]; /* { dg-message "region created on stack here" }
*/
| |^
| ||
| |(1) region created on stack here
|6 | memmove(s, s + 1, 2); /* { dg-warning "use of uninitialized
value" } */
| |
| | |
| | (2) use of uninitialized value '*(short unsigned int *)&s +
1' here
|
One side-effect of this change is a change in part of the output of
gcc.dg/uninit-40.c from:
uninit-40.c:47:3: warning: â*(long unsigned int *)(&u[1][0][0])â is
used uninitialized [-Wuninitialized]
47 | __builtin_memcpy (&v[1], &u[1], sizeof (V));
| ^~~
uninit-40.c:45:5: note: â*(long unsigned int *)(&u[1][0][0])â was
declared here
45 | V u[2], v[2];
| ^
to:
uninit-40.c:47:3: warning: âuâ is used uninitialized
[-Wuninitialized]
47 | __builtin_memcpy (&v[1], &u[1], sizeof (V));
| ^~~
uninit-40.c:45:5: note: âuâ declared here
45 | V u[2], v[2];
| ^
What's happening is that pass "early_uninit"(29)'s call to
maybe_warn_operand is guarded by this condition:
1051else if (gimple_assign_load_p (stmt)
1052 && gimple_has_location (stmt))
Before the patch, the stmt:
_3 = MEM [(char * {ref-all})&u + 8B];
has no location, and so early_uninit skips this operand at line
1052 above. Later, pass "uninit"(217) tests the var_decl "u$8", and
emits a warning for it.
With the patch, the stmt has a location, and so early_uninit emits a
warning for "u" and sets a NW_UNINIT warning suppression at that
location. Later, pass "uninit"(217)'s test of "u$8" is rejected
due to that per-location suppression of uninit warnings, from the
earlier warning.
gcc/ChangeLog:
PR analyzer/104308
* gimple-fold.cc (gimple_fold_builtin_memory_op): When optimizing
to loads then stores, set the location of the new load stmt.
gcc/testsuite/ChangeLog:
PR analyzer/104308
* gcc.dg/analyzer/pr104308.c: New test.
* gcc.dg/uninit-40.c (foo): Update expression in expected message.
Signed-off-by: David Malcolm
[Bug analyzer/104308] no location info provided for [-Wanalyzer-use-of-uninitialized-value] warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104308 David Malcolm changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #7 from David Malcolm --- Should be fixed by the above patch.
[Bug analyzer/105074] [12 Regression] -fanalyzer ICEs on gnutls-3.7.3: cgraph_node::get_edge(gimple*) SIGSEGV since r12-7809-g5f6197d7c197f9d2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105074 David Malcolm changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #2 from David Malcolm --- Thanks for filing this bug report; happens at -O2 and above. Working on a fix now.
