[Bug c++/102156] [9/10/11/12 Regression] `cannot call constructor` error during member access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102156
Jason Merrill changed:
What|Removed |Added
Resolution|--- |INVALID
CC||jason at gcc dot gnu.org
Status|NEW |RESOLVED
--- Comment #3 from Jason Merrill ---
Why do you think that DR147 doesn't apply to this testcase? We see B::B<, look
up B in B, and DR147 says we find the constructor.
The rule mentioned in PR11764, that lookup in a nested-name-specifier only
considers types and namespaces, doesn't apply here because the name B isn't
followed directly by ::. The current draft even has an example to illustrate
this:
template struct B : A {};
namespace N {
template void B();
int f() {
return B<0>::n; // error: N::B<0> is not a type
}
}
EDG also rejects this testcase.
[Bug target/105271] [12 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105271 Kewen Lin changed: What|Removed |Added Summary|ICE in extract_insn, at |[12 Regression] ICE in |recog.cc:2791 (error: |extract_insn, at |unrecognizable insn)|recog.cc:2791 (error: ||unrecognizable insn) --- Comment #2 from Kewen Lin --- GCC11's behavior: /opt/at15.0/bin//gcc test.c -mvsx -mcpu=power7 test.c: In function ‘test3’: test.c:7:5: note: builtin ‘__builtin_vec_neg’ requires builtin ‘__builtin_altivec_neg_v2di’ 7 | return vec_neg (x); | ^~ In file included from test.c:2: test.c:7:12: error: ‘__builtin_altivec_neg_v2di’ requires the ‘-mpower8-vector’ option 7 | return vec_neg (x); |^~~
[Bug c++/102804] [9/10/11/12 Regression] template matching fails w/ false ambiguity on ternary expressions with enums class defined with unsigned typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102804 --- Comment #8 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:e580f81d22d61153564959f08d9a6d3bcc7fd386 commit r12-8173-ge580f81d22d61153564959f08d9a6d3bcc7fd386 Author: Jason Merrill Date: Thu Apr 14 17:49:47 2022 -0400 c++: unsigned int32_t enum promotion [PR102804] There's been an extension for a long time to allow applying 'unsigned' to an int typedef, but that was confusing the integer promotion code. Fixed by forgetting about the typedef in that case. I'm going to make this an unconditional pedwarn in stage 1. PR c++/102804 gcc/cp/ChangeLog: * decl.cc (grokdeclarator): Drop typedef used with 'unsigned'. gcc/testsuite/ChangeLog: * g++.dg/ext/unsigned-typedef1.C: New test.
[Bug c++/105280] New: g++ does not raise sign-comapre in static_assert under some conditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105280
Bug ID: 105280
Summary: g++ does not raise sign-comapre in static_assert under
some conditions
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: cfy1990 at gmail dot com
Target Milestone: ---
g++ does not raise sign-compare warnings in static_assert((-1 >= 1u) &&
T1::v, "");
Code link: https://godbolt.org/z/4GjT9f5oz
Compile arguments: -O2 -std=c++11 -Wall -Wextra -Wconversion -Wsign-conversion
-Wunused-result -Wsign-compare -Wlogical-not-parentheses -Wdouble-promotion
Code:
template
struct T1;
template<>
struct T1{
const static bool v=true;
};
template
void foo(__attribute__((unused)) T v){
// should generate warning, but not in g++
// clang works fine
static_assert((-1 >= 1u) && T1::v, "");
// codes works fine in gcc and clang
static_assert((-1 >= 1u) && T1::v, ""); // sign-compare warning
static_assert((-1 >= 1u), ""); // sign-compare warning
constexpr bool b = (-1 >= 1u) && T1::v; // sign-compare warning
static_assert(b, "");
static_assert((!3 > -1) && T1::v, ""); // logical-not-parentheses
warning
static_assert((1.0f*3.0 > 0) && T1::v, ""); // double-promotion warning
}
void bar(){
static_assert((-1 >= 1u) && T1::v, ""); // sign-compare
warning
foo(2u);
}
[Bug c++/102987] [9/10/11/12 Regression] Segfault when error or warning should trigger with combination.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102987 --- Comment #4 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:6364a39907bd68624a30df0c8e380c40d2a646c4 commit r12-8172-g6364a39907bd68624a30df0c8e380c40d2a646c4 Author: Jason Merrill Date: Thu Apr 14 17:35:35 2022 -0400 c++: using in diagnostics [PR102987] The expression pretty-printing code crashed on a location wrapper with no type, and didn't know what to do with a USING_DECL. PR c++/102987 gcc/cp/ChangeLog: * error.cc (dump_expr): Handle USING_DECL. [VIEW_CONVERT_EXPR]: Just look through location wrapper. gcc/testsuite/ChangeLog: * g++.dg/diagnostic/using1.C: New test.
[Bug analyzer/105264] -Wanalyzer-use-of-uninitialized-value gets confused about var + i v.s. [i]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105264 --- Comment #8 from David Malcolm --- The above patch hopefully fixes the false positive you're seeing, but as noted, there are some deeper issues that it doesn't fix; keeping this bug open.
[Bug analyzer/105264] -Wanalyzer-use-of-uninitialized-value gets confused about var + i v.s. [i]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105264 --- Comment #7 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:a358e4b60815b41e27f3508014ceb592f86b9b45 commit r12-8169-ga358e4b60815b41e27f3508014ceb592f86b9b45 Author: David Malcolm Date: Thu Apr 14 09:52:00 2022 -0400 analyzer: fix escaping of pointer arithmetic [PR105264] PR analyzer/105264 reports that the analyzer can fail to treat (PTR + IDX) and PTR[IDX] as referring to the same memory under some situations. There are various ways in which this can happen when IDX is a symbolic value, due to having several ways in which such memory regions can be referred to symbolically. I attempted to fix this by being smarter when folding svalues and regions, but this fix seems too fiddly to attempt in stage 4. Instead, this less ambitious patch fixes a false positive from -Wanalyzer-use-of-uninitialized-value by making the analyzer's escape analysis smarter, so that it treats *PTR as escaping when (PTR + OFFSET) is passed to an external function, and thus it treats *PTR as possibly-initialized (the "passing [IDX]" case was already working). gcc/analyzer/ChangeLog: PR analyzer/105264 * region-model-reachability.cc (reachable_regions::handle_parm): Use maybe_get_deref_base_region rather than just region_svalue, to handle pointer arithmetic also. * svalue.cc (svalue::maybe_get_deref_base_region): New. * svalue.h (svalue::maybe_get_deref_base_region): New decl. gcc/testsuite/ChangeLog: PR analyzer/105264 * gcc.dg/analyzer/torture/symbolic-10.c: New test. Signed-off-by: David Malcolm
[Bug jit/105279] New: Using libgccjit produces a null pointer access in GCC's tree-optimization code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105279
Bug ID: 105279
Summary: Using libgccjit produces a null pointer access in
GCC's tree-optimization code
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: jit
Assignee: dmalcolm at gcc dot gnu.org
Reporter: m...@nieper-wisskirchen.de
Target Milestone: ---
Created attachment 52812
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52812=edit
libgccjit reproducer file
Compiling and running the attached libgccjit reproducer file produces a null
pointer access in GCC's tree-optimization path. The error goes away if I
comment out the call to gcc_jit_block_add_assignment on line 1181 or if I
replace the pointer to the function there ("address_of_program") with a null
pointer in the form of gcc_jit_context_new_rvalue_from_ptr (ctxt_0x6fe3ff0,
ptr_to_union_value__struct_processorunion_value_, NULL).
The error also goes away if I replace both occurrences of "-O3" in reproducer.c
with "-O1" or lower.
$ gcc -lgccjit reproducer.c && valgrind ./a.out
==979255== Memcheck, a memory error detector
==979255== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==979255== Using Valgrind-3.17.0 and LibVEX; rerun with -h for copyright info
==979255== Command: ./a.out
==979255==
==979255== Invalid read of size 8
==979255==at 0x5D85753: operator_minus::op1_range(irange&, tree_node*,
irange const&, irange const&, tree_code) const (range-op.cc:1460)
==979255==by 0x5CAAC75: gori_compute::compute_operand1_range(irange&,
gimple*, irange const&, tree_node*, fur_source&) (gimple-range-gori.cc:1024)
==979255==by 0x5CAACD9: gori_compute::compute_operand1_range(irange&,
gimple*, irange const&, tree_node*, fur_source&) (gimple-range-gori.cc:1077)
==979255==by 0x5CAC775: gori_compute::outgoing_edge_range_p(irange&,
edge_def*, tree_node*, range_query&) (gimple-range-gori.cc:1271)
==979255==by 0x5CA0FDC: ranger_cache::range_on_edge(irange&, edge_def*,
tree_node*) [clone .part.0] (gimple-range-cache.cc:1083)
==979255==by 0x5C9DFE1: gimple_ranger::range_on_edge(irange&, edge_def*,
tree_node*) (gimple-range.cc:245)
==979255==by 0x52DB39E: range_query::value_on_edge(edge_def*, tree_node*)
(value-query.cc:107)
==979255==by 0x52BDDE7: rvrp_folder::value_on_edge(edge_def*, tree_node*)
(tree-vrp.cc:4281)
==979255==by 0x51D419C:
substitute_and_fold_engine::propagate_into_phi_args(basic_block_def*)
(tree-ssa-propagate.cc:742)
==979255==by 0x51D4CD7:
substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
(tree-ssa-propagate.cc:942)
==979255==by 0x5C70125: dom_walker::walk(basic_block_def*) (domwalk.cc:309)
==979255==by 0x51D3B6E:
substitute_and_fold_engine::substitute_and_fold(basic_block_def*)
(tree-ssa-propagate.cc:987)
==979255== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==979255==
==979255==
==979255== Process terminating with default action of signal 11 (SIGSEGV)
==979255== Access not within mapped region at address 0x0
==979255==at 0x5D85753: operator_minus::op1_range(irange&, tree_node*,
irange const&, irange const&, tree_code) const (range-op.cc:1460)
==979255==by 0x5CAAC75: gori_compute::compute_operand1_range(irange&,
gimple*, irange const&, tree_node*, fur_source&) (gimple-range-gori.cc:1024)
==979255==by 0x5CAACD9: gori_compute::compute_operand1_range(irange&,
gimple*, irange const&, tree_node*, fur_source&) (gimple-range-gori.cc:1077)
==979255==by 0x5CAC775: gori_compute::outgoing_edge_range_p(irange&,
edge_def*, tree_node*, range_query&) (gimple-range-gori.cc:1271)
==979255==by 0x5CA0FDC: ranger_cache::range_on_edge(irange&, edge_def*,
tree_node*) [clone .part.0] (gimple-range-cache.cc:1083)
==979255==by 0x5C9DFE1: gimple_ranger::range_on_edge(irange&, edge_def*,
tree_node*) (gimple-range.cc:245)
==979255==by 0x52DB39E: range_query::value_on_edge(edge_def*, tree_node*)
(value-query.cc:107)
==979255==by 0x52BDDE7: rvrp_folder::value_on_edge(edge_def*, tree_node*)
(tree-vrp.cc:4281)
==979255==by 0x51D419C:
substitute_and_fold_engine::propagate_into_phi_args(basic_block_def*)
(tree-ssa-propagate.cc:742)
==979255==by 0x51D4CD7:
substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
(tree-ssa-propagate.cc:942)
==979255==by 0x5C70125: dom_walker::walk(basic_block_def*) (domwalk.cc:309)
==979255==by 0x51D3B6E:
substitute_and_fold_engine::substitute_and_fold(basic_block_def*)
(tree-ssa-propagate.cc:987)
==979255== If you believe this happened as a result of a stack
==979255== overflow in your program's main thread (unlikely but
==979255== possible), you can try to increase the size of the
==979255== main thread stack using the --main-stacksize= flag.
==979255== The main thread stack size used in this run was 67108864.
==979255==
==979255== HEAP SUMMARY:
[Bug c++/102987] [9/10/11/12 Regression] Segfault when error or warning should trigger with combination.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102987 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/104646] [9/10/11 Regression] ICE in cx_check_missing_mem_inits, at cp/constexpr.cc:845
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104646 Jason Merrill changed: What|Removed |Added Summary|[9/10/11/12 Regression] ICE |[9/10/11 Regression] ICE in |in |cx_check_missing_mem_inits, |cx_check_missing_mem_inits, |at cp/constexpr.cc:845 |at cp/constexpr.cc:845 | Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/104646] [9/10/11/12 Regression] ICE in cx_check_missing_mem_inits, at cp/constexpr.cc:845
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104646 --- Comment #3 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:c5de3444c4798758cdd800eca144480b4a8ef299 commit r12-8167-gc5de3444c4798758cdd800eca144480b4a8ef299 Author: Jason Merrill Date: Thu Apr 14 15:34:14 2022 -0400 c++: constexpr trivial -fno-elide-ctors [PR104646] The constexpr constructor checking code got confused by the expansion of a trivial copy constructor; we don't need to do that checking for defaulted ctors, anyway. PR c++/104646 gcc/cp/ChangeLog: * constexpr.cc (maybe_save_constexpr_fundef): Don't do extra checks for defaulted ctors. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/constexpr-fno-elide-ctors1.C: New test.
[Bug analyzer/105273] -Wanalyzer-use-of-uninitialized-value warns on "missing" default for switch when callers can be statically determined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105273 --- Comment #4 from David Malcolm --- Thanks for filing this bug. IIRC in the initial GCC 10 release of the analyzer, it didn't directly explore within static functions, and instead only explored them via callsites. I tweaked the policy for this in commit r11-7029-g8a2750086d57d1. There's definitely room for improvement here, possibly with a heuristic for switch statements, or due to fixing how the analyzer handles call summaries.
[Bug analyzer/105264] -Wanalyzer-use-of-uninitialized-value gets confused about var + i v.s. [i]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105264 --- Comment #6 from David Malcolm --- There are some fiddly issues where the analyzer fails to figure out that ptr + i and [i] refer to the same memory, for certain symbolic values of i. I'm testing a partial fix for GCC 12, which at least seems to fix the -Wanalyzer-use-of-uninitialized-value false positives identified in the reproducer. That said, I think for a deeper fix it's probably best to wait until GCC 13.
[Bug target/104853] [RISC-V] -march=rv64g not including extension Zifencei
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104853 John Doe changed: What|Removed |Added CC||bau2wux4sh at pkv73 dot anonbox.ne ||t --- Comment #14 from John Doe --- Shouldn't it also be necessary to re-generate the existing configurations files (e.g. gcc/config/riscv/t-elf-multilib) with the modified multilib-generator script? Maybe it also makes sense to add _zicsr / _zifence multilib targets to those for MULTILIB_REUSE while at it?
[Bug c++/105256] [9/10/11/12 Regression] ICE compiling firefox-99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256 --- Comment #25 from Chris Clayton --- I went ahead and patched gcc-11-0220409 and with the resultant compiler have had two successful builds of firefox-99. I then reverted to the unpatched gcc and a build of firefox-99 failed with the same ICE that I reported in comment 1.
[Bug c++/105278] no warning for precise literals compared with floats
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105278 --- Comment #4 from David Binderman --- (In reply to Eric Gallager from comment #3) > (In reply to David Binderman from comment #2) > > (In reply to Eric Gallager from comment #1) > > > -Wfloat-equal gets you a warning, as does -Wdouble-promotion: > > > > Thanks for that. This looks like another case where an obscure flag > > really ought to be in -Wall or at least -Wextra. > > > > I'll be adding it into my local compiler. > > Which one of them specifically do you want as part of -Wall or -Wextra? > Because the latter is listed explicitly in some documentation somewhere as > an example of a flag that would be bad to include in -Wall or -Wextra. Sorry, I should have been more clear -Wfloat-equal. I haven't looked into the pros and cons of -Wdouble-promotion. If you've got some spare time to pin down "some documentation somewhere", then that would be appreciated.
[Bug c++/87404] Implement -Wenum-compare and -Wenum-compare-switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87404 --- Comment #10 from Ævar Arnfjörð Bjarmason --- Thanks, just clarifying. I saw this one was in the C++ component unlike the other one. On Thu, Apr 14, 2022, 19:57 egallager at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87404 > > --- Comment #9 from Eric Gallager --- > (In reply to Ævar Arnfjörð Bjarmason from comment #8) > > Eric: I filed bug 87983. I think it makes sense to mark it as a duplicate > > only if this one covers both C and C++, right now the "component" for > this > > one is C++. > > > > As bug 87983 notes in passing C does not have first-class enums, so > > implementing this will presumably be a bit harder than C++, and . > > My understanding was that this bug would cover both C and C++, as I'm > pretty > sure I've seen this clang warning in plain-C code before, too (and there's > no > component for the code shared by the C family of languages, which is where > I'd > assume this would be implemented) > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug c++/105278] no warning for precise literals compared with floats
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105278 --- Comment #3 from Eric Gallager --- (In reply to David Binderman from comment #2) > (In reply to Eric Gallager from comment #1) > > -Wfloat-equal gets you a warning, as does -Wdouble-promotion: > > Thanks for that. This looks like another case where an obscure flag > really ought to be in -Wall or at least -Wextra. > > I'll be adding it into my local compiler. Which one of them specifically do you want as part of -Wall or -Wextra? Because the latter is listed explicitly in some documentation somewhere as an example of a flag that would be bad to include in -Wall or -Wextra.
[Bug libstdc++/101527] The implementation of std::common_iterator and std::counted_iterator's operator== seems to be wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101527 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |12.0 Last reconfirmed||2022-04-14 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
[Bug c++/82980] [9/10/11 Regression] template keyword should not be required for captured decl of the "base" type since r6-6866-gff2faafcf689b6c2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82980 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Summary|[9/10/11/12 Regression] |[9/10/11 Regression] |template keyword should not |template keyword should not |be required for captured|be required for captured |decl of the "base" type |decl of the "base" type |since |since |r6-6866-gff2faafcf689b6c2 |r6-6866-gff2faafcf689b6c2 Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/82980] [9/10/11/12 Regression] template keyword should not be required for captured decl of the "base" type since r6-6866-gff2faafcf689b6c2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82980 --- Comment #4 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:74b2e20222cf4fb24b90561ddb6f0989738bb722 commit r12-8165-g74b2e20222cf4fb24b90561ddb6f0989738bb722 Author: Jason Merrill Date: Thu Apr 14 08:16:45 2022 -0400 c++: lambda and the current instantiation [PR82980] When a captured variable is type-dependent, we've expressed the type of the capture field and proxy with a decltype variant. But if the type is "the current instantiation", we need to be able to see that so that we can do lookup inside it just like we could with the captured variable itself. I also tried looking through lambda capture in cp_parser_postfix_dot_deref_expression, but this way seems cleaner. I plan to treat more types as deducible in stage 1. I considered also using this in do_auto_deduction, but think that would be wrong: [temp.dep.expr] says an id-expression is type-dependent if it is "associated by name lookup with a variable declared with a type that contains a placeholder type where the initializer is type-dependent". That doesn't clearly exclude deducing a dependent type from the initializer, but it seems like a barrier, and other implementations agree. PR c++/82980 gcc/cp/ChangeLog: * lambda.cc (type_deducible_expression_p): New. (lambda_capture_field_type): Check it. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/lambda/lambda-current-inst1.C: New test.
[Bug c++/105278] no warning for precise literals compared with floats
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105278 --- Comment #2 from David Binderman --- (In reply to Eric Gallager from comment #1) > -Wfloat-equal gets you a warning, as does -Wdouble-promotion: Thanks for that. This looks like another case where an obscure flag really ought to be in -Wall or at least -Wextra. I'll be adding it into my local compiler.
[Bug c++/87404] Implement -Wenum-compare and -Wenum-compare-switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87404 --- Comment #9 from Eric Gallager --- (In reply to Ævar Arnfjörð Bjarmason from comment #8) > Eric: I filed bug 87983. I think it makes sense to mark it as a duplicate > only if this one covers both C and C++, right now the "component" for this > one is C++. > > As bug 87983 notes in passing C does not have first-class enums, so > implementing this will presumably be a bit harder than C++, and . My understanding was that this bug would cover both C and C++, as I'm pretty sure I've seen this clang warning in plain-C code before, too (and there's no component for the code shared by the C family of languages, which is where I'd assume this would be implemented)
[Bug c++/105278] no warning for precise literals compared with floats
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105278 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Keywords||diagnostic --- Comment #1 from Eric Gallager --- -Wfloat-equal gets you a warning, as does -Wdouble-promotion: $ /usr/local/bin/gcc -c -g -O2 -Wall -Wextra -pedantic -Wconversion -Wfloat-equal -Wdouble-promotion 105278.c 105278.c: In function 'f': 105278.c:5:15: warning: comparing floating-point with '==' or '!=' is unsafe [-Wfloat-equal] 5 | if (a == 0.1234) | ^~ 105278.c:5:15: warning: implicit conversion from 'float' to 'double' to match other operand of binary expression [-Wdouble-promotion] $
[Bug debug/105089] CTF for a defined extern variable is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105089 --- Comment #7 from CVS Commits --- The master branch has been updated by Indu Bhagat : https://gcc.gnu.org/g:d634c5d7c78c6ec0fa39d96984460475564519c8 commit r12-8164-gd634c5d7c78c6ec0fa39d96984460475564519c8 Author: Indu Bhagat Date: Thu Apr 14 10:02:45 2022 -0700 Refactor and update CTF testcases [PR105089] This commit splits the ctf-array-2.c into ctf-array-5.c and ctf-variables.c with the following responsibilities: [1] ctf-array-2.c: Test CTF generation for unsized arrays. [2] ctf-array-5.c: Test CTF generation for unsized but initialized array. [3] ctf-variables-3.c: Test CTF generation for extern variable with defining decl. Earlier all three tests above were being done in ctf-array-2.c. The checks around [3] were very loose in the original version of ctf-array-2.c in that the testcase was only checking that the types are as expected. The compiler was emitting two CTF variable records as follows: Variables: _CTF_NEWSTR -> 5: const const char [0] (size 0x0) -> 4: const char [0] (size 0x0) _CTF_NEWSTR -> 8: const const char [8] (size 0x8) -> 7: const char [8] (size 0x8) This is incorrect behaviour as it creates ambiguity. The testcase ctf-variables-3.c now has added checks that only one CTF variable record is expected. 2022-04-14 Indu Bhagat gcc/testsuite/ChangeLog: PR debug/105089 * gcc.dg/debug/ctf/ctf-array-2.c: Refactor testcase. Move some checks ... * gcc.dg/debug/ctf/ctf-array-5.c: ... to here. * gcc.dg/debug/ctf/ctf-variables-3.c: ... and here. Add additional checks for one CTF variable and one CTF object info record.
[Bug debug/105089] CTF for a defined extern variable is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105089 --- Comment #6 from CVS Commits --- The master branch has been updated by Indu Bhagat : https://gcc.gnu.org/g:d0b00e74bf59c73b79471bbe9de19373b8661e20 commit r12-8163-gd0b00e74bf59c73b79471bbe9de19373b8661e20 Author: Indu Bhagat Date: Thu Apr 14 10:01:22 2022 -0700 CTF for extern variable fix [PR105089] The CTF format cannot differentiate between a non-defining extern variable declaration vs. a defining variable declaration (unlike DWARF). So, the correct behaviour wrt the compiler generating CTF for such extern variables (i.e., when both the defining and non-defining decl are present in the same CU) is to simply emit the CTF variable correspoding to the defining declaration. To carry out the above, following changes are introduced via the patch: 1. The CTF container (ctfc.h) now keeps track of the non-defining declarations (by noting the DWARF attribute DW_AT_specification) in a new ctfc_ignore_vars hashtable. Such book-keeping is necessary because the CTF container should not rely on the order of DWARF DIEs presented to it at generation time. 2. At the time of ctf_add_variable (), the DW_AT_specification DIE if present is added in the ctfc_ignore_vars hashtable. The CTF variable generation for the defining declaration continues as normal. 3. If the ctf_add_variable () is asked to generate CTF variable for a DIE present in the ctfc_ignore_vars, it skips generating CTF for it. 4. Recall that CTF variables are pre-processed before emission. Till now, the only pre-processing that was being done was to sort them in order of their names. Now an additional step is added: If the CTF variable which corresponds to the non-defining declaration is indeed present in the ctfc_vars hashtable (because the corresponding DWARF DIE was encountered first by the CTF generation engine), skip that CTF variable from output. An important side effect of such a workflow above is that CTF for the C type of the non-defining decl will remain in the CTF dictionary (and will be emitted in the output section as well). This type can be pruned by the link-time de-duplicator as usual, if deemed unused. 2022-04-14 Indu Bhagat gcc/ChangeLog: PR debug/105089 * ctfc.cc (ctf_dvd_ignore_insert): New function. (ctf_dvd_ignore_lookup): Likewise. (ctf_add_variable): Keep track of non-defining decl DIEs. (new_ctf_container): Initialize the new hash-table. (ctfc_delete_container): Empty hash-table. * ctfc.h (struct ctf_container): Add new hash-table. (ctf_dvd_ignore_lookup): New declaration. (ctf_add_variable): Add additional argument. * ctfout.cc (ctf_dvd_preprocess_cb): Skip adding CTF variable record for non-defining decl for which a defining decl exists in the same TU. (ctf_preprocess): Defer updating the number of global objts until here. (output_ctf_header): Use ctfc_vars_list_count as some CTF variables may not make it to the final output. (output_ctf_vars): Likewise. * dwarf2ctf.cc (gen_ctf_variable): Skip generating CTF variable if this is known to be a non-defining decl DIE.
[Bug c++/105268] type/value mismatch when using variadic concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105268 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug analyzer/105273] -Wanalyzer-use-of-uninitialized-value warns on "missing" default for switch when callers can be statically determined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105273 Eric Gallager changed: What|Removed |Added Keywords||diagnostic CC||egallager at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=61864 --- Comment #3 from Eric Gallager --- For more discussion of how "default" branches of switch statements affect diagnostics, see also bug 61864 (although that's just for regular diagnostics, and predates the analyzer)
[Bug libstdc++/84568] libstdc++-v3 configure checks for atomic operations fail on riscv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84568 --- Comment #12 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:3fc22eedb033cbff1bf5a70c6a032d3c5ce2d867 commit r12-8161-g3fc22eedb033cbff1bf5a70c6a032d3c5ce2d867 Author: Palmer Dabbelt Date: Thu Apr 14 17:22:58 2022 +0100 libstdc++: Default to mutex-based atomics on RISC-V The RISC-V port requires libatomic to be linked in order to resolve various atomic functions, which results in builds that have "--with-libstdcxx-lock-policy=auto" defaulting to mutex-based locks. Changing this to direct atomics breaks the ABI, this forces the auto detection mutex-based atomics on RISC-V in order to avoid a silent ABI break for users. See Bug 84568 for more discussion. In the long run there may be a way to get the higher-performance atomics without an ABI flag day, but that's going to be a much more complicated operation. We don't even have support for the inline atomics yet, but given that some folks have been discussing hacks to make these libatomic routines appear implicitly it seems prudent to just turn off the automatic detection for RISC-V. libstdc++-v3/ChangeLog: * acinclude.m4 (GLIBCXX_ENABLE_LOCK_POLICY): Force auto to mutex for RISC-V. * configure: Regenerate.
[Bug target/89125] Misoptimization of converting sin(x) and cos(x) into sincos(x,,)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89125 --- Comment #16 from kargl at gcc dot gnu.org --- Can someone please commit the patch?
[Bug target/105251] static assert sizeof(decltype(_together)) <= hardware_constructive_interference_size fails with gcc12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105251 --- Comment #11 from Khem Raj --- yes thanks. I have done so https://jira.mongodb.org/browse/SERVER-65664
[Bug target/105251] static assert sizeof(decltype(_together)) <= hardware_constructive_interference_size fails with gcc12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105251 --- Comment #10 from Andrew Pinski --- No. The issue is the two constants and cache line size are different. Basically the whole code should not say cache line aligned but rather use them based on what they mean. Report the issue to the mongodb folks and have them fix their broken code. They are using the constants in the wrong manner.
[Bug c++/55077] implement and enable by default -Wliteral-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55077 --- Comment #9 from David Binderman --- -Wfloat-conversion does the deed: any chance of getting it someplace useful like -Wall or -Wextra anytime soon ? I will put it into my local compiler.
[Bug target/105251] static assert sizeof(decltype(_together)) <= hardware_constructive_interference_size fails with gcc12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105251
--- Comment #9 from Khem Raj ---
how does something like this look ?
#include
#include
#include
#include
#ifdef __cpp_lib_hardware_interference_size
using std::hardware_constructive_interference_size;
using std::hardware_destructive_interference_size;
#else
// 64 bytes on x86-64 │ L1_CACHE_BYTES │ L1_CACHE_SHIFT │
__cacheline_aligned │ ...
constexpr std::size_t hardware_constructive_interference_size = 64;
constexpr std::size_t hardware_destructive_interference_size = 64;
#endif
class NetworkCounter {
private:
template
struct alignas(alignment) WithAlignment : T {
using T::T;
};
template
using WithAlignmentAtLeast = WithAlignment;
// These two counters are always incremented at the same time, so
// we place them on the same cache line.
template
using CacheAligned = WithAlignmentAtLeast;
struct Together {
long long logicalBytesIn{0};
long long requests{0};
};
CacheAligned _together{};
static_assert(sizeof(decltype(_together)) <=
hardware_destructive_interference_size,
"cache line spill");
};
[Bug target/105251] static assert sizeof(decltype(_together)) <= hardware_constructive_interference_size fails with gcc12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105251 --- Comment #8 from Khem Raj --- So in this case if I change static_assert(sizeof(decltype(_together)) <= hardware_constructive_interference_size, "cache line spill"); to static_assert(sizeof(decltype(_together)) <= hardware_destructive_interference_size, "cache line spill"); should set it right
[Bug c++/105256] [9/10/11/12 Regression] ICE compiling firefox-99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256 --- Comment #24 from Chris Clayton --- I see the patch is for gcc-12. As I said in comment, I don't get the ICE with the latest gcc-12 snapshot, but is it worth me applying the patch to gcc-11 (with which I do get the ICE) and testing a build with that?
[Bug c++/105278] New: no warning for precise literals compared with floats
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105278
Bug ID: 105278
Summary: no warning for precise literals compared with floats
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this C++ code:
extern void g( int);
void f( float a)
{
if (a == 0.1234)
g( 1);
}
recent gcc trunk has nothing to say:
$ /home/dcb/gcc/results/bin/gcc -c -g -O2 -Wall -Wextra -pedantic apr14b.cc
$
Here is clang finding the problem:
$ /home/dcb/llvm/results/bin/clang -c -g -O2 -Wall apr14b.cc
apr14b.cc:6:8: warning: floating-point comparison is always false; constant
cannot be represented exactly in type 'float' [-Wliteral-range]
if (a == 0.1234)
~ ^ ~~~
1 warning generated.
Interestingly, if float is replaced by double, the warning goes away.
[Bug c++/105277] New: Pointer to member UB in constant expression is not checked.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105277
Bug ID: 105277
Summary: Pointer to member UB in constant expression is not
checked.
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: malorubi at outlook dot com
Target Milestone: ---
The standard says
[expr.mptr.oper] bullet 4 https://eel.is/c++draft/expr#mptr.oper-4
...
If the dynamic type of E1 does not contain the member to which E2 refers, the
behavior is undefined.
...
This is currently not checked, it is possible to invoke a function pointer
using an expression of invalid dynamic type in a constant expression, without
such call being diagnosed as UB.
Example on compiler explorer: https://godbolt.org/z/s4G8ovs7n
Example verbatim:
=== BEGIN EXAMPLE
struct Base {};
struct Derived1 : Base
{
int x;
constexpr int fn() const
{ return 0; }
};
struct Derived2 : Base
{
int x;
constexpr int fn() const
{ return 1; }
};
inline void test()
{
using common_fn = int (Base::*)() const;
constexpr Derived1 instance1 {};
constexpr Derived2 instance2 {};
constexpr auto ptr1 = (common_fn) ::fn;
constexpr auto ptr2 = (common_fn) ::fn;
static_assert ((instance1.*ptr1)() == 0);
static_assert ((instance2.*ptr2)() == 1);
static_assert ((instance1.*ptr2) () == 1); // ?
static_assert ((instance2.*ptr1) () == 0); // ?
}
=== END EXAMPLE
[Bug c++/105256] [9/10/11/12 Regression] ICE compiling firefox-99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256 --- Comment #23 from Jakub Jelinek --- Created attachment 52811 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52811=edit gcc12-pr105256.patch Untested patch to do that.
[Bug c++/105256] [9/10/11/12 Regression] ICE compiling firefox-99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256
--- Comment #22 from Jakub Jelinek ---
So, wonder if for a CONSTRUCTOR containing elements which are CONSTRUCTORs with
CONSTRUCTOR_PLACEHOLDER_BOUNDARY set we shouldn't move the
CONSTRUCTOR_PLACEHOLDER_BOUNDARY flag to the outer CONSTRUCTOR (if not set
there already).
The reason why the flag was introduced was to catch e.g. those
X x { 1, bar (X{2}).n }; etc. cases where the X{2} contains an unrelated
PLACEHOLDER_EXPR to the outer one.
But when we have directly nested CONSTRUCTORs, we can replace_placeholders all
of those PLACEHOLDER_EXPRs from in there, the object will be simply some member
of the var or TARGET_EXPR slot etc.
[Bug c/105276] New: [12 Regression] executed once loop not optimized anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105276
Bug ID: 105276
Summary: [12 Regression] executed once loop not optimized
anymore
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
bool foo(unsigned i) {
bool result = true;
while (i) {
i = i % 3;
i = i - (i==2 ? 2 : i ? 1 : 0);
result = !result;
}
return result;
}
--
compiled with g++ 11.2 and -O2 it produces:
-
foo(unsigned int):
testedi, edi
seteal
ret
With current trunk and -02 lots of instructions are generated, the loop is
still present, about 30 instructions are produced.
Also, when compiled with -Os trunk produces loopless assembly:
--
foo(unsigned int):
mov dl, 1
testedi, edi
je .L1
xor edx, edx
.L1:
mov eax, edx
ret
---
Whereas using -Os and g++ 11.2 it uses one less register:
--
foo(unsigned int):
mov al, 1
testedi, edi
je .L4
xor eax, eax
.L4:
ret
[Bug analyzer/105264] -Wanalyzer-use-of-uninitialized-value gets confused about var + i v.s. [i]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105264 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2022-04-14 --- Comment #5 from David Malcolm --- (In reply to Ævar Arnfjörð Bjarmason from comment #2) > I think I can do one better. Here's a stand-alone reproducible test case > without any headers except standard headers, I've expanded the gcc -E > version of that too, but presumably you won't need it. Thanks - I'm poking at -fanalyzer on both attachments now. FWIW, the -E version can sometimes be very helpful, for the case where we have different headers (e.g. glibc sometimes adds attributes to decls, which can affect things)
[Bug c++/105256] [9/10/11/12 Regression] ICE compiling firefox-99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256 --- Comment #21 from Jakub Jelinek --- Ah, we have: case TARGET_EXPR: if (TARGET_EXPR_INITIAL (stmt) && TREE_CODE (TARGET_EXPR_INITIAL (stmt)) == CONSTRUCTOR && CONSTRUCTOR_PLACEHOLDER_BOUNDARY (TARGET_EXPR_INITIAL (stmt))) TARGET_EXPR_NO_ELIDE (stmt) = 1; break; but that doesn't trigger in this case because the TARGET_EXPR's CONSTRUCTOR is not CONSTRUCTOR_PLACEHOLDER_BOUNDARY, instead it is a CONSTRUCTOR that contains a CONSTRUCTOR_PLACEHOLDER_BOUNDARY CONSTRUCTOR as one of its elements.
[Bug c++/105256] [9/10/11/12 Regression] ICE compiling firefox-99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256
--- Comment #20 from Marek Polacek ---
(In reply to Jakub Jelinek from comment #16)
> Don't both of those tests have UB (sure, we shouldn't ICE), using
> uninitialized non-static data member?
NSDMIs are parsed at the end of the class, but I think I should have switched
the order of the initialization:
struct S {
struct Prefs {
struct P {
int i = 42;
int j = i;
} p;
void Load();
};
};
void S::Prefs::Load() {
*this = {};
};
but your test is good too.
[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|ASSIGNED|WAITING URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2022-April/5 ||93245.html --- Comment #10 from David Malcolm --- Followup patch posted; waiting on review: https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593245.html
[Bug c++/105256] [9/10/11/12 Regression] ICE compiling firefox-99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256
--- Comment #19 from Jakub Jelinek ---
The TARGET_EXPR is elided in gimplify_modify_expr_rhs:
case TARGET_EXPR:
{
/* If we are initializing something from a TARGET_EXPR, strip the
TARGET_EXPR and initialize it directly, if possible. This can't
be done if the initializer is void, since that implies that the
temporary is set in some non-trivial way.
??? What about code that pulls out the temp and uses it
elsewhere? I think that such code never uses the TARGET_EXPR as
an initializer. If I'm wrong, we'll die because the temp won't
have any RTL. In that case, I guess we'll need to replace
references somehow. */
tree init = TARGET_EXPR_INITIAL (*from_p);
if (init
&& (TREE_CODE (*expr_p) != MODIFY_EXPR
|| !TARGET_EXPR_NO_ELIDE (*from_p))
&& !VOID_TYPE_P (TREE_TYPE (init)))
{
*from_p = init;
ret = GS_OK;
changed = true;
}
}
break;
Though, can the TARGET_EXPR be elided if there are PLACEHOLDER_EXPRs in it?
If not, something should probably set TARGET_EXPR_NO_ELIDE somewhere.
If yes, perhaps we need to replace_placeholders perhaps through a language hook
at the
above point. But it is unclear to what it should be replaced...
[Bug plugins/105171] gcc/toplev.c: `local_tick` can overflow and become -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105171 --- Comment #22 from Jakub Jelinek --- That doesn't look right, get_random_seed (true) can return 0 even if it uses a random seed which just happens to be 0.
[Bug c++/105256] [9/10/11/12 Regression] ICE compiling firefox-99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256
--- Comment #18 from Jakub Jelinek ---
The rationale for introduction of CONSTRUCTOR_PLACEHOLDER_BOUNDARY was given in
the
https://gcc.gnu.org/legacy-ml/gcc-patches/2018-03/threads.html#00681
thread, not all PLACEHOLDER_EXPRs nested in an expression should be replaced by
the same object, if there are e.g. nested TARGET_EXPRs with PLACEHOLDER_EXPRs
in their initializers, those nested PLACEHOLDER_EXPRs should be replaced by the
TARGET_EXPR's slot rather than the outermost expression.
Before the r8-7334-g570f86f94eca76fbf, the PLACEHOLDER_EXPR was replaced from
build_over_call, but that has removed. The expectation was that we'd always
have some object (var being constructed, TARGET_EXPR slot, etc. and we'd
replace_placeholders when gimplifying INIT_EXPR for it).
But on:
int bar (int &);
struct S {
struct T {
struct U {
int i = bar (i);
} u;
};
};
void
foo (S::T *p)
{
*p = {};
};
cp_gimplify_init_expr is never called, gimplify_target_expr neither, because we
ICE earlier than that.
While we have there a TARGET_EXPR when we start gimplification:
*NON_LVALUE_EXPR = *(struct T &) _EXPR )->i)}}>, seems something has elided it.
[Bug analyzer/105252] [12 Regression] ICE: in cmp_cst, at analyzer/svalue.cc:309 with -O -fanalyzer -fnon-call-exceptions since r12-1931-ge61ffa201403e381
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105252 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from David Malcolm --- Should be fixed by the above patch.
[Bug target/105275] New: 525.x264_r and 538.imagick_r regressed on x86_64 at -O2 with PGO after r12-7319-g90d693bdc9d718
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105275 Bug ID: 105275 Summary: 525.x264_r and 538.imagick_r regressed on x86_64 at -O2 with PGO after r12-7319-g90d693bdc9d718 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jamborm at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Target Milestone: --- I can see x86_64 regressions of 525.x264_r and 538.imagick_r when built with plain -O2 (so generic march/mtune) and profile guided optimization (PGO), compared to GCC 11. The performance drop of 525.x264_r is about 11% on znver3 and 10% on Intel cascadelake. The performance drop of 538.imagick_r is about 6.4% on znver3. FWIW, I bisected both to commit r12-7319-g90d693bdc9d718: commit 90d693bdc9d71841f51d68826ffa5bd685d7f0bc Author: Richard Biener Date: Fri Feb 18 14:32:14 2022 +0100 target/99881 - x86 vector cost of CTOR from integer regs This uses the now passed SLP node to the vectorizer costing hook to adjust vector construction costs for the cost of moving an integer component from a GPR to a vector register when that's required for building a vector from components. A cruical difference here is whether the component is loaded from memory or extracted from a vector register as in those cases no intermediate GPR is involved. The pr99881.c testcase can be Un-XFAILed with this patch, the pr91446.c testcase now produces scalar code which looks superior to me so I've adjusted it as well. 2022-02-18 Richard Biener PR tree-optimization/104582 PR target/99881 * config/i386/i386.cc (ix86_vector_costs::add_stmt_cost): Cost GPR to vector register moves for integer vector construction. With PGo+LTO, the 538.imagick_r regression on znver3 is small (less than 3%), the 525.x264_r ones are smaller but visible (9.4% and 7.1% on the two machines).
[Bug analyzer/105252] [12 Regression] ICE: in cmp_cst, at analyzer/svalue.cc:309 with -O -fanalyzer -fnon-call-exceptions since r12-1931-ge61ffa201403e381
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105252 --- Comment #3 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:b209a349268d245f7a318861112df47bea15b89d commit r12-8159-gb209a349268d245f7a318861112df47bea15b89d Author: David Malcolm Date: Wed Apr 13 12:02:07 2022 -0400 analyzer: fix ICE comparing VECTOR_CSTs [PR105252] gcc/analyzer/ChangeLog: PR analyzer/105252 * svalue.cc (cmp_cst): When comparing VECTOR_CSTs, compare the types of the encoded elements before calling cmp_cst on them. gcc/testsuite/ChangeLog: PR analyzer/105252 * gcc.dg/analyzer/pr105252.c: New test. Signed-off-by: David Malcolm
[Bug plugins/105171] gcc/toplev.c: `local_tick` can overflow and become -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105171 --- Comment #21 from Jason A. Donenfeld --- FYI, Linux is working around this shortcoming with the trick in this commit: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c40160f2998c897231f8454bf797558d30a20375
[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #28 from Richard Biener --- I'm testing a patch along comment #4 after discussing on IRC with Segher.
[Bug c++/105256] [9/10/11/12 Regression] ICE compiling firefox-99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256 --- Comment #17 from Chris Clayton --- Created attachment 52810 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52810=edit Compiler commands Finally got them by running running "ps ax" in a while true loop, grepping the output for the file name and writing any matches to a file. There must be an easier way!
[Bug target/105247] [11 Regression] IA64: ICE on sqlite-3.38.2: in decompose, at rtl.h:2288 since r11-5271-g4866b2f5db117f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105247 Jakub Jelinek changed: What|Removed |Added Summary|[11/12 Regression] IA64:|[11 Regression] IA64: ICE |ICE on sqlite-3.38.2: in|on sqlite-3.38.2: in |decompose, at rtl.h:2288|decompose, at rtl.h:2288 |since |since |r11-5271-g4866b2f5db117f|r11-5271-g4866b2f5db117f --- Comment #6 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug target/105247] [11/12 Regression] IA64: ICE on sqlite-3.38.2: in decompose, at rtl.h:2288 since r11-5271-g4866b2f5db117f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105247 --- Comment #5 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:ba2f60499dd4a3bc1bb4e99fa12dda3bc1548519 commit r12-8158-gba2f60499dd4a3bc1bb4e99fa12dda3bc1548519 Author: Jakub Jelinek Date: Thu Apr 14 13:47:34 2022 +0200 simplify-rtx: Don't assume shift count has the same mode as the shift [PR105247] The following testcase ICEs on ia64. It is UB at runtime, but we shouldn't ICE on it... The problem is that on ia64, the shift count (last operand of ASHIFT etc.) is promoted to DImode (using zero-extension), while most other targets use much narrower modes (say QImode). If we try to simplify a shift and the shift count is CONST_INT or other VOIDmode integer constant which isn't properly sign extended for the first operand's mode (in the testcase the shift count is 0xfff8U and it is a SImode shift), then we ICE during wide_int wop1 = pop1; in the first hunk, INTVAL == 0xfff8U is not valid for SImode. I think in theory we could run into this even on other targets, say if they use SImode or HImode shift counts for e.g. QImode shifts. I hope word size is the upper bound of what a reasonable target should use, using e.g. multiple registers for the shift count is insane, so the following patch if op1 has VOIDmode and int_mode is narrower than word uses word_mode for extraction of the value. 2022-04-14 Jakub Jelinek PR target/105247 * simplify-rtx.cc (simplify_const_binary_operation): For shifts or rotates by VOIDmode constant integer shift count use word_mode for the operand if int_mode is narrower than word. * gcc.c-torture/compile/pr105247.c: New test.
[Bug libgomp/105274] New: [libgomp][nvptx] Provide means to set the stack size on the device side (+ improve doc)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105274 Bug ID: 105274 Summary: [libgomp][nvptx] Provide means to set the stack size on the device side (+ improve doc) Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: documentation, openmp Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: jakub at gcc dot gnu.org, vries at gcc dot gnu.org Target Milestone: --- Currently, for offloading code, nvptx has (A) for SIMT -msoft-stack-reserve-local= (default: 128) Undocumented in .texi. From .opt: msoft-stack-reserve-local= Target Joined RejectNegative UInteger Var(nvptx_softstack_size) Init(128) Specify size of .local memory used for stack when the exact amount is not known. (For -msoft-stack, see: https://gcc.gnu.org/onlinedocs/gcc/Nvidia-PTX-Options.html#index-msoft-stack ) (B) For non-SIMT, there is (fixed + undocumented): nvptx_stacks_size() in libgomp/plugin/plugin-nvptx.c (always returns 128*1024) I know that for some (program, compiler) combinations, setting OMP_DEV_STACKSIZE to some higher value is required. (Was required to get a program running with the xlf compiler with nvptx offload.) Thus, it seems as if making it settable in GCC is also highly desirable – plus actually document everything. Regarding OMP_DEV_... itself, see also the by-device-env-support patch https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588728.html
[Bug analyzer/105273] -Wanalyzer-use-of-uninitialized-value warns on "missing" default for switch when callers can be statically determined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105273 --- Comment #2 from Ævar Arnfjörð Bjarmason --- ...To finish the report (Bugzilla's eager submitting threw me for a loop) the issue is that while the analyzer is right in the *general* case about a "switch" with a missing "default" being something that *could* be fed any arbitrary value, in this case all of the possible values can be determined at a compile-time. Which is all this bug report is suggesting as an initial report, that it would be nice to have that narrow case handled. END OF NARROW REPORT More generally though (and perhaps I should submit another report for this) it's a really useful feature of GCC (and clang) that with C they put a bit of trust in the programmer with -Wswitch (which is enabled under -Wall). Because even though there are cases where the programmer is wrong and exhaustively enumerating the enum labels isn't sufficient, in the general case being able to avoid "default" cases in favor of exhaustively listing the labels avoids a *lot* of subtle bugs in larger codebases. That's because the values being thrown around to "switch" on are validated already by [insert magic here], but whenever *new* values are added it's really important to not miss 1/N switch statements that new labels need to be added to. In the testcase for this bug the compiler has enough visibility to determine this to be true without the "[insert magic here]", but in cases where that's not true it seems to me that those users -fanalyzer would be encouraged to add "default" cases just to appease the compiler, and thus get worse warnings from -Wswitch. I may be missing something obvious, but it would be nice to have some way out of that where you can have your cake & eat it too. I.e. only have -fanalyze complain about this class of issue where -Wswitch would complain, and have the current behavior in GCC 12.0 hidden behind some opt-in sub-flag of -Wanalyzer-use-of-uninitialized-value. Anyway, just my 0.02. Thanks a lot for -fanalyze, I've been trying it out on the git codebase and it's uncovered a lot of genuine issues already. I'm just filing some bugs for the long tail where the analyzer seemed to be wrong/lacking. Thanks!
[Bug c++/84964] [9/10/11/12 Regression] ICE in expand_call, at calls.c:4540
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84964 Roger Sayle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #24 from Roger Sayle --- This should now be fixed on mainline.
[Bug middle-end/104885] ICE in compiling new test case g++.dg/other/pr84964.C after r12-7607-ga717376e99fb33
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104885 Roger Sayle changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |12.0 Status|ASSIGNED|RESOLVED --- Comment #3 from Roger Sayle --- This should now be fixed on mainline.
[Bug tree-optimization/104010] [12 regression] short loop no longer vectorized with Neon after r12-3362
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104010 Richard Biener changed: What|Removed |Added Keywords||patch --- Comment #14 from Richard Biener --- Patch posted for review.
[Bug tree-optimization/104010] [12 regression] short loop no longer vectorized with Neon after r12-3362
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104010 Richard Biener changed: What|Removed |Added Attachment #52798|0 |1 is obsolete|| --- Comment #13 from Richard Biener --- Created attachment 52809 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52809=edit patch
[Bug analyzer/105273] -Wanalyzer-use-of-uninitialized-value warns on "missing" default for switch when callers can be statically determined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105273 --- Comment #1 from Ævar Arnfjörð Bjarmason --- Created attachment 52808 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52808=edit test case without an enum A slightly amended test case, showing that the enum isn't per-se the issue (same with constant ints).
[Bug analyzer/105273] New: -Wanalyzer-use-of-uninitialized-value warns on "missing" default for switch when callers can be statically determined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105273
Bug ID: 105273
Summary: -Wanalyzer-use-of-uninitialized-value warns on
"missing" default for switch when callers can be
statically determined
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: avarab at gmail dot com
Target Milestone: ---
Created attachment 52807
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52807=edit
test case with an enum
With GCC 12.0 built from c1ff207af66 (ppc: testsuite: skip pr60203 on no
ldbl128, 2022-04-12) I get a warning on the attached test case:
gcc -fanalyzer analyze.c
analyze.c: In function ‘vreportf’:
analyze.c:28:17: warning: use of uninitialized value ‘pfx’ [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
28 | snprintf(buf, sizeof(buf), "%s", pfx);
| ^
‘vreportf’: events 1-6
|
| 13 | const char *pfx;
| | ^~~
| | |
| | (1) region created on stack here
| 14 |
| 15 | switch (kind) {
| | ~~
| | |
| | (2) following ‘default:’ branch...
|..
| 25 | if (kind == USAGE_BUG)
| |~
| ||
| |(3) ...to here
| |(4) following ‘false’ branch (when ‘kind != 1’)...
|..
| 28 | snprintf(buf, sizeof(buf), "%s", pfx);
| | ~
| | |
| | (5) ...to here
| | (6) use of uninitialized value ‘pfx’ here
|
[Bug target/105162] [AArch64] outline-atomics drops dmb ish barrier on __sync builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105162 Wilco changed: What|Removed |Added CC||wilco at gcc dot gnu.org --- Comment #7 from Wilco --- (In reply to Sebastian Pop from comment #5) > Created attachment 52762 [details] > patch > > The attached patch fixes the issue for __sync builtins by adding the missing > barrier to -march=armv8-a+nolse path in the outline-atomics functions. > > The patch also changes the behavior of __atomic builtins for > -moutline-atomics -march=armv8-a+nolse to be the same as for > -march=armv8-a+lse. So what is your reasoning for adding the barrier to __atomic as well? Only __sync needs the extra full barrier, but __atomic does not.
[Bug libstdc++/105269] missing some library feature test macros in c++20 and c++23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105269 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from Jonathan Wakely --- Fixed, thanks for the report.
[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231 --- Comment #27 from rguenther at suse dot de --- On Thu, 14 Apr 2022, segher at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231 > > --- Comment #26 from Segher Boessenkool --- > (In reply to Richard Biener from comment #25) > > (In reply to Segher Boessenkool from comment #24) > > > Wrt keeping REG_EQUAL notes... If you want to keep them you need to make > > > sure > > > they still are valid. GCC keeps those on i3, it is much too hard in > > > general > > > to > > > validate other such notes. > > > > It seems to be that the REG_EQUAL notes of the SET dests in the final > > instruction we combine into, so 24 for > > > > Trying 78, 17 -> 24: > > > > are better always valid even after the combination - at least when they > > are not refering to pseudos set by insns combined (78, 17 here) and always > > when the REG_EQUAL is constant. When there are multiple sets in the final > > insn (24) then which note ends up where is determined by the SET dests. > > In the *resulting* final insn. And some of those notes may have to be moved > to i2 -- when there are multiple sets in the *resulting* insn, and it is > split. > > > For this particular case preserving _constant_ REG_EQUAL notes would be > > important. And for this case only handling single-set would be good enough. > > You can *never* require REG_EQUAL notes for correctness. It is always correct > to delete REG_EQUAL notes. They exist to make optimisation easier, and for > nothing else. > > > Of course if i3 is not always '24' (in this case) then we have to find > > a better place to preserve these than distribute_notes. > > Or fix the bug: that which requires REG_EQUAL notes to not be deleted. This > is a problem whether or not we hide the problem here (by making things > optimised better). Then the bug is in combine itself - it places a REG_EH_REGION note but fails to split the basic-block after the affected instruction. Or it even considers placing it on the not last instruction. Maybe there's already the constraint that combine never combines an insns with a REG_EH_REGION note (aka a possibly throwing insn) with another but only combines not throwing insns into a throwing one. Then the correct action is to always place the REG_EH_REGION note on the last insn, or if that cannot throw, throw it away. If we somehow created an intermediate throwing/trapping insn we should then reject the combination. Richard.
[Bug libstdc++/105269] missing some library feature test macros in c++20 and c++23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105269 --- Comment #1 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:d2f8208e9add01fe10ee56307cc79631b9995f74 commit r12-8154-gd2f8208e9add01fe10ee56307cc79631b9995f74 Author: Jonathan Wakely Date: Thu Apr 14 10:28:03 2022 +0100 libstdc++: Fix missing and incorrect feature test macros [PR105269] libstdc++-v3/ChangeLog: PR libstdc++/105269 * include/bits/stl_vector.h (__cpp_lib_constexpr_vector): Define. * include/c_compatibility/stdatomic.h (__cpp_lib_stdatomic_h): Define. * include/std/optional (__cpp_lib_optional): Define new value for C++23. (__cpp_lib_monadic_optional): Remove. * include/std/version (__cpp_lib_constexpr_vector): Define. (__cpp_lib_stdatomic_h): Define. (__cpp_lib_optional): Define new value for C++23. (__cpp_lib_monadic_optional): Remove. * testsuite/20_util/optional/monadic/and_then.cc: Adjust. * testsuite/20_util/optional/requirements.cc: Adjust for C++23. * testsuite/20_util/optional/version.cc: Likewise. * testsuite/23_containers/vector/cons/constexpr.cc: Check feature test macro. * testsuite/29_atomics/headers/stdatomic.h/c_compat.cc: Likewise. * testsuite/20_util/optional/monadic/version.cc: Removed. * testsuite/23_containers/vector/requirements/version.cc: New test. * testsuite/29_atomics/headers/stdatomic.h/version.cc: New test.
[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231 --- Comment #26 from Segher Boessenkool --- (In reply to Richard Biener from comment #25) > (In reply to Segher Boessenkool from comment #24) > > Wrt keeping REG_EQUAL notes... If you want to keep them you need to make > > sure > > they still are valid. GCC keeps those on i3, it is much too hard in general > > to > > validate other such notes. > > It seems to be that the REG_EQUAL notes of the SET dests in the final > instruction we combine into, so 24 for > > Trying 78, 17 -> 24: > > are better always valid even after the combination - at least when they > are not refering to pseudos set by insns combined (78, 17 here) and always > when the REG_EQUAL is constant. When there are multiple sets in the final > insn (24) then which note ends up where is determined by the SET dests. In the *resulting* final insn. And some of those notes may have to be moved to i2 -- when there are multiple sets in the *resulting* insn, and it is split. > For this particular case preserving _constant_ REG_EQUAL notes would be > important. And for this case only handling single-set would be good enough. You can *never* require REG_EQUAL notes for correctness. It is always correct to delete REG_EQUAL notes. They exist to make optimisation easier, and for nothing else. > Of course if i3 is not always '24' (in this case) then we have to find > a better place to preserve these than distribute_notes. Or fix the bug: that which requires REG_EQUAL notes to not be deleted. This is a problem whether or not we hide the problem here (by making things optimised better).
[Bug c++/105256] [9/10/11/12 Regression] ICE compiling firefox-99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256
--- Comment #16 from Jakub Jelinek ---
Don't both of those tests have UB (sure, we shouldn't ICE), using uninitialized
non-static data member?
Perhaps:
int
bar (int &)
{
return 1;
}
struct S {
struct T {
struct U {
int i = bar (i);
} p;
void foo ();
};
};
void
S::T::foo ()
{
*this = {};
};
is better?
[Bug target/105034] [10/11/12 regression]Suboptimal codegen for min/max with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105034 --- Comment #5 from Roger Sayle --- The latest CSiBE results on x86_64-pc-linux-gnu: With -Os the total size is 3696263, and with -Os -mno-stv the total size is 3966887, i.e. 624 bytes larger. The worst regression from -mno-stv is teem-1.6.0-src/src/nrrd/parseNrrd which 402 bytes larger, and the best improvement from -mno-stv is linux-2.4.23-pre3-testplatform/net/ipv4/route which is 134 bytes smaller. So I think this is a fine tuning problem. cmp/cmov is much shorter than a pmax or a pmin, so SImode MAX/MIN should have negative gain with -Os. Likewise for const0_rtx.
[Bug libstdc++/105269] missing some library feature test macros in c++20 and c++23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105269 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Last reconfirmed||2022-04-14 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Target Milestone|--- |12.0
[Bug gcov-profile/105238] Regression: using -fprofile-dir: gcno files not ccache cachable anymore / gcovr report broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105238 --- Comment #4 from Esger Abbink --- We use Ubuntu 20.04 currently for our jenkins images. With gcc built from master with patch using -fprofile-prefix-map works as expected: with a main.cpp in /home/esger/src/application/coverage_test/dir1/source compiling with: cd /home/esger/src/application/coverage_test/dir1/source/ && g++-11 --coverage -fprofile-prefix-map=/home/esger/src/application/coverage_test/dir1=dir2 -c /home/esger/src/application/coverage_test/dir1/source/main.cpp cd /home/esger/src/application/coverage_test/dir1/source/ && g++-11 --coverage -fprofile-prefix-map=/home/esger/src/application/coverage_test/dir1=dir2 main.o -o ../bin/a.out results in a main.gcno in the source directory, and after running ./dir1/bin/a.out from /home/esger/src/application/coverage_test there is a main.gcda (non-mangled) in dir2/source. Note that I was not able to produce a meaningful coverage report even for the simplest/first case of the four above with gcc 11. I think gcovr might not yet support newer formats used? So I can't currently verify if with -fprofile-prefix-map the coverage report is ok, but I would assume so. (Still, I don't quite understand why behavior that was working is now broken/changed and needs a new option? ie. why is -fprofile-dir mangling the name, and -fprofile-prefix-map not? and 9.4 behavior with -fprofile-dir still seems broken when explicitly specifying the default?) If I perform a small experiment more closely resembling what cmake + ccache do: cd /home/esger/src/application/coverage_test/dir1/source/ && CCACHE_BASEDIR=/home/esger/src/application/coverage_test/dir1 ccache /usr/bin/g++-11 --coverage -fprofile-prefix-map=/home/esger/src/application/coverage_test/dir1=. -fdebug-prefix-map=/home/esger/src/application/coverage_test/dir1=. -c /home/esger/src/application/coverage_test/dir1/source/main.cpp cd /home/esger/src/application/coverage_test/dir1/source/ && CCACHE_BASEDIR=/home/esger/src/application/coverage_test/dir1 ccache /usr/bin/g++-11 --coverage -fprofile-prefix-map=/home/esger/src/application/coverage_test/dir1=. -fdebug-prefix-map=/home/esger/src/application/coverage_test/dir1=. main.o -o ../bin/a.out and then from /home/esger/src/application/coverage_test/dir2 run ../dir1/bin/a.out (to simulate a run with a binary built from cached .o and .gcno run from a different directory) again the gcda is created in the dir2/source directory with a non-mangled name. yey :) I can also see the source file paths in the gcno are relative: main.gcno:note:magic `gcno':version `B20 ' main.gcno:stamp 625107654 main.gcno:checksum 0 main.gcno:cwd: /home/esger/src/application/coverage_test/dir1/source main.gcno: 0100: 83:FUNCTION ident=1482908279, lineno_checksum=0x2c72f060, cfg_checksum=0xc0bbb23e, `_GLOBAL__sub_I__Z5funcAi' ./source/main.cpp:21:1-21:1, artificial main.gcno:0141: 4:BLOCKS 4 blocks main.gcno:0143: 12:ARCS 1 arcs main.gcno:0143: 20:ARCS 2 arcs main.gcno:0143: 12:ARCS 1 arcs main.gcno:0145: 42:LINES main.gcno:0145: 42:LINES ... So with a patched gcc11, dropping -fprofile-dir and using -fprofile-prefix-map instead, gcda creation seems ok. The gcno files seem to contain relative paths to the source file too. However, the gcno file also still contains the compilation CWD which interferes with caching it and re-using it for different build dirs. Is there any way to get rid of that? And of course I still need to verify such created gcda files will actually result in a proper coverage report. Applying the patch to 9.4 or 10.3 as vit9696 did should allow me to test that. Will try that tomorrow if I have time.
[Bug target/105034] [10/11/12 regression]Suboptimal codegen for min/max with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105034
--- Comment #4 from Richard Biener ---
Example that we don't transform but could:
typedef int v4si __attribute__((vector_size(16)));
#define min(a,b) ((a)<(b)?(a):(b))
v4si foo (v4si a, v4si b)
{
a[0] = min (a[0], b[0]);
return a;
}
here the scalar code is
movd%xmm0, %edx
movd%xmm1, %eax
cmpl%edx, %eax
cmovg %edx, %eax
pinsrd $0, %eax, %xmm0
where we could use sth like
movq %xmm0, %xmm2
minpd %xmm2, %xmm1
a testcase variant could return the scalar minimum. For both cases it's
likely a win even for -Os.
[Bug target/105034] [10/11/12 regression]Suboptimal codegen for min/max with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105034 Roger Sayle changed: What|Removed |Added CC||roger at nextmovesoftware dot com --- Comment #3 from Roger Sayle --- Hi Hongtao, Note that -mstv is a net win on the code size benchmark CSiBE, so gating the entire pass on optimize_size is not an ideal solution. Instead the gain function needs to choose which chains to transform based on optimize_size aware costs.
[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231 --- Comment #25 from Richard Biener --- (In reply to Segher Boessenkool from comment #24) > Wrt keeping REG_EQUAL notes... If you want to keep them you need to make > sure > they still are valid. GCC keeps those on i3, it is much too hard in general > to > validate other such notes. It seems to be that the REG_EQUAL notes of the SET dests in the final instruction we combine into, so 24 for Trying 78, 17 -> 24: are better always valid even after the combination - at least when they are not refering to pseudos set by insns combined (78, 17 here) and always when the REG_EQUAL is constant. When there are multiple sets in the final insn (24) then which note ends up where is determined by the SET dests. For this particular case preserving _constant_ REG_EQUAL notes would be important. And for this case only handling single-set would be good enough. Of course if i3 is not always '24' (in this case) then we have to find a better place to preserve these than distribute_notes.
[Bug fortran/105272] Using entry inside module contained subroutines changes subroutine's scope in DWARF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105272 Richard Biener changed: What|Removed |Added Last reconfirmed||2022-04-14 Status|UNCONFIRMED |NEW Keywords||wrong-debug Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Likely the DECL_CONTEXTs of the entry forwarder functions are not set up correctly so it should be simple to fix (copy from the entered function).
[Bug analyzer/105264] -Wanalyzer-use-of-uninitialized-value gets confused about var + i v.s. [i]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105264 --- Comment #4 from Ævar Arnfjörð Bjarmason --- Created attachment 52806 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52806=edit testcase-full.c (gcc -E of testcase.c) The gcc -E version of testcase.c, probably useless since it only uses headers from glibc, but just in case...
[Bug analyzer/105264] -Wanalyzer-use-of-uninitialized-value gets confused about var + i v.s. [i]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105264 Ævar Arnfjörð Bjarmason changed: What|Removed |Added CC||avarab at gmail dot com --- Comment #3 from Ævar Arnfjörð Bjarmason --- Created attachment 52805 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52805=edit testcase.c A stand-alone testcase of builtin/merge-file.c from git.git
[Bug analyzer/105264] -Wanalyzer-use-of-uninitialized-value gets confused about var + i v.s. [i]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105264 --- Comment #2 from Ævar Arnfjörð Bjarmason --- I think I can do one better. Here's a stand-alone reproducible test case without any headers except standard headers, I've expanded the gcc -E version of that too, but presumably you won't need it. It's screaming bloddy murder about various other things, since I did a rather bad hatchet job of copy/pasting various structs I needed from local headers into the testcase, and deleted some code I could do away with, but as noted in the now-added comment in the code: 1. "mmfs + i" to "[i]" makes it go away, so if it's a loop-iterator problem wouldn't that apply to both? 2. I tried copying the relevant function into the file and that makes it go away too, so some cross-file analysis limitation? Will follow-up and attach both the testcase & the gcc -E version, tested with: gcc -o testcase -fanalyzer testcase.c
[Bug c++/87404] Implement -Wenum-compare and -Wenum-compare-switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87404 --- Comment #8 from Ævar Arnfjörð Bjarmason --- Eric: I filed bug 87983. I think it makes sense to mark it as a duplicate only if this one covers both C and C++, right now the "component" for this one is C++. As bug 87983 notes in passing C does not have first-class enums, so implementing this will presumably be a bit harder than C++, and .
[Bug fortran/105272] New: Using entry inside module contained subroutines changes subroutine's scope in DWARF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105272 Bug ID: 105272 Summary: Using entry inside module contained subroutines changes subroutine's scope in DWARF Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: nils-christian.kempke at intel dot com Target Milestone: --- When compiling a subroutine inside a module like $ cat f_no_entry.f90 module a contains subroutine b print *, "b" end subroutine b end module a program prog print *, "hi" end program prog $ gfortran -O0 -g ./f.f90 $ gfortran --version GNU Fortran (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0 ... the DWARF emitted shows that the DW_TAG_subprogram for subroutine b is a child of the DW_TAG_module for a. This seems reasonable and puts b into the scope of a: $ objdump --dwarf=info ./a.out ... <1>: Abbrev Number: 8 (DW_TAG_module) DW_AT_name: a DW_AT_decl_file : 1 DW_AT_decl_line : 1 <2>: Abbrev Number: 9 (DW_TAG_subprogram) DW_AT_external: 1 DW_AT_name: b DW_AT_decl_file : 1 DW_AT_decl_line : 3 DW_AT_linkage_name: (indirect string, offset: 0x0): __a_MOD_b DW_AT_low_pc : 0x1179 DW_AT_high_pc : 0x73 DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa) DW_AT_GNU_all_tail_call_sites: 1 <2>: Abbrev Number: 0 <1>: Abbrev Number: 0 Changing this example seemingly just a bit by adding an alternative entry point to b via the 'entry' moves the subroutine (and the entry point) out of the module and puts them into the scope of the whole compile unit TAG: $ cat f_entry.f90 module a contains subroutine b entry bbb print *, "b" end subroutine b end module a program prog print *, "hi" end program prog $ gfortran -O0 -g ./f_entry.f90 $ objdump --dwarf=info ./a.out ... <1>: Abbrev Number: 8 (DW_TAG_module) DW_AT_name: a DW_AT_decl_file : 1 DW_AT_decl_line : 1 DW_AT_sibling : <0xd1> <2>: Abbrev Number: 9 (DW_TAG_subprogram) DW_AT_name: (indirect string, offset: 0xa): master.0.b DW_AT_decl_file : 1 DW_AT_decl_line : 7 DW_AT_low_pc : 0x1199 DW_AT_high_pc : 0x8c DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa) DW_AT_GNU_all_tail_call_sites: 1 <3>: Abbrev Number: 10 (DW_TAG_formal_parameter) DW_AT_name: (indirect string, offset: 0x57): __entry DW_AT_type: <0xd8> DW_AT_artificial : 1 DW_AT_location: 3 byte block: 91 d8 7b (DW_OP_fbreg: -552) <3>: Abbrev Number: 0 <2>: Abbrev Number: 0 ... <1>: Abbrev Number: 4 (DW_TAG_base_type) DW_AT_byte_size : 8 DW_AT_encoding: 5(signed) DW_AT_name: (indirect string, offset: 0x27): integer(kind=8) <1>: Abbrev Number: 11 (DW_TAG_subprogram) DW_AT_external: 1 DW_AT_name: bbb DW_AT_decl_file : 1 DW_AT_decl_line : 4 DW_AT_linkage_name: (indirect string, offset: 0x142): __a_MOD_bbb DW_AT_low_pc : 0x1189 DW_AT_high_pc : 0x10 DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa) DW_AT_GNU_all_tail_call_sites: 1 <1>: Abbrev Number: 11 (DW_TAG_subprogram) DW_AT_external: 1 DW_AT_name: b DW_AT_decl_file : 1 DW_AT_decl_line : 3 DW_AT_linkage_name: (indirect string, offset: 0x0): __a_MOD_b <103> DW_AT_low_pc : 0x1179 <10b> DW_AT_high_pc : 0x10 <113> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa) <115> DW_AT_GNU_all_tail_call_sites: 1 <1><115>: Abbrev Number: 0 This behavior seems odd. I stumbled upon this when trying to access the entry point bbb in gdb via a::bbb (as bbb is in the module's scope) which I could not. There is a likely related issue about gfortran not emitting a DW_TAG_entry_point for entry points https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37134.
[Bug target/105271] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105271 Kewen Lin changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org Target|powerpc-e300c3-linux-gnu|powerpc*-linux-gnu Last reconfirmed||2022-04-14 Ever confirmed|0 |1 CC||linkw at gcc dot gnu.org --- Comment #1 from Kewen Lin --- It can be reproduce even without cross build, and it's related to commit r12-7925. Unlike the other vector integer mode, V2DImode on vec_neg (__builtin_altivec_neg_v2di) is special, it requires the pattern negv2di and it's further expanded into vzero and subv2di, the latter has the condition guard "VECTOR_UNIT_P8_VECTOR_P (V2DImode)", so it's wrong to move it out from P8 vector stanza. The fix can be to move it back to be under power8-vector stanza.
[Bug testsuite/105267] [12 regression] gcc.target/powerpc/pr56605.c fails after r12-8128-g6b7cc7294770ec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105267 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0
[Bug c++/105265] [9/10/11 Regression] temporary object not destructed causing memory leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105265 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug testsuite/105266] new test case gcc.dg/pr105250.c fails with excess errors in r12-8134-g4e892de6774f86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105266 --- Comment #2 from Richard Biener --- yes please
