[Bug tree-optimization/97744] [11 regression] 32 bit floating point result errors after r11-4637
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97744 Kewen Lin changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org Last reconfirmed||2020-11-07 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #3 from Kewen Lin --- (In reply to seurer from comment #2) > This particular test has been problematic before. For example, see pr83497. > Previously the change in output was from some floating point operations > being reordered causing a minute rounding change but it was actually OK. > > By adding -fno-associative-math or removing -ffast-math it will work. We > are probably just going to go with that. Thanks for the information! I'll have a look at it.
[Bug tree-optimization/97744] [11 regression] 32 bit floating point result errors after r11-4637
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97744 --- Comment #2 from seurer at gcc dot gnu.org --- This particular test has been problematic before. For example, see pr83497. Previously the change in output was from some floating point operations being reordered causing a minute rounding change but it was actually OK. By adding -fno-associative-math or removing -ffast-math it will work. We are probably just going to go with that.
[Bug tree-optimization/97223] Failure to optimize comparison of char arithmetic to single comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97223 --- Comment #3 from Eugene Rozenfeld --- The proposed patch was committed to the trunk by Jeff Law.
[Bug tree-optimization/97108] Wmaybe-uninitialized false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97108 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2020-11-06 --- Comment #1 from Jeffrey A. Law --- So the key to this testcase is the merge points. After some slight simplifications to the test we have the following key blocks: ;; basic block 2, loop depth 0, count 1073741823 (estimated locally), maybe hot ;;prev block 0, next block 3, flags: (NEW, VISITED) ;;pred: ENTRY [always] count:1073741823 (estimated locally) (FALLTHRU,EXECUTABLE) if (flags_8(D) == 0) goto ; [50.00%] else goto ; [50.00%] ;;succ: 5 [50.0% (guessed)] count:536870912 (estimated locally) (TRUE_VALUE,EXECUTABLE) ;;3 [50.0% (guessed)] count:536870912 (estimated locally) (FALSE_VALUE,EXECUTABLE) ;; basic block 3, loop depth 0, count 536870912 (estimated locally), maybe hot ;;prev block 2, next block 4, flags: (NEW, VISITED) ;;pred: 2 [50.0% (guessed)] count:536870912 (estimated locally) (FALSE_VALUE,EXECUTABLE) if (flags_8(D) != -1) goto ; [32.00%] else goto ; [68.00%] ;;succ: 5 [32.0% (guessed)] count:171798688 (estimated locally) (TRUE_VALUE,EXECUTABLE) ;;4 [68.0% (guessed)] count:365072224 (estimated locally) (FALSE_VALUE,EXECUTABLE) [ ... ] ;; basic block 5, loop depth 0, count 708669600 (estimated locally), maybe hot ;;prev block 4, next block 6, flags: (NEW, VISITED) ;;pred: 2 [50.0% (guessed)] count:536870912 (estimated locally) (TRUE_VALUE,EXECUTABLE) ;;3 [32.0% (guessed)] count:171798688 (estimated locally) (TRUE_VALUE,EXECUTABLE) # orig_err_26 = PHI if (in_12(D) != 0) goto ; [33.00%] else goto ; [67.00%] ;;succ: 6 [33.0% (guessed)] count:233860967 (estimated locally) (TRUE_VALUE,EXECUTABLE) ;;7 [67.0% (guessed)] count:474808633 (estimated locally) (FALSE_VALUE,EXECUTABLE) ;; basic block 6, loop depth 0, count 233860966 (estimated locally), maybe hot ;;prev block 5, next block 7, flags: (NEW, VISITED) ;;pred: 5 [33.0% (guessed)] count:233860967 (estimated locally) (TRUE_VALUE,EXECUTABLE) _close (in_12(D)); ;;succ: 7 [always] count:233860966 (estimated locally) (FALLTHRU,EXECUTABLE) ;; basic block 7, loop depth 0, count 708669601 (estimated locally), maybe hot ;;prev block 6, next block 8, flags: (NEW, VISITED) ;;pred: 6 [always] count:233860966 (estimated locally) (FALLTHRU,EXECUTABLE) ;;5 [67.0% (guessed)] count:474808633 (estimated locally) (FALSE_VALUE,EXECUTABLE) if (out_14(D) != 1) goto ; [48.88%] else goto ; [51.12%] ;;succ: 8 [48.9% (guessed)] count:346397699 (estimated locally) (TRUE_VALUE,EXECUTABLE) ;;9 [51.1% (guessed)] count:362271902 (estimated locally) (FALSE_VALUE,EXECUTABLE) Of particular note is that because BB2 and BB3 both reach BB5 we don't really have any useful information about FLAGS.The threader does know how to look through a join point like that, but it then runs into another at BB7 at which point it gives up. The backwards threader probably could be made to detect this case though. I'm pretty sure we're not raising queries for COND_EXPRs on the RHS of a statement, just for GIMPLE_COND statements. So this block: ;; basic block 9, loop depth 0, count 708669601 (estimated locally), maybe hot ;;prev block 8, next block 10, flags: (NEW, VISITED) ;;pred: 8 [always] count:346397698 (estimated locally) (FALLTHRU,EXECUTABLE) ;;7 [51.1% (guessed)] count:362271902 (estimated locally) (FALSE_VALUE,EXECUTABLE) _2 = orig_err_26 != 2; _1 = flags_8(D) == 0; _3 = _2 & _1; if (_3 != 0) goto ; [33.00%] else goto ; [67.00%] We don't raise a query for flags_8. The backwards threader also doesn't know how to imply a range from anything other than assignments. So the conditionals involving flags_8 aren't helpful. This is something we're going to want to tackle with ranger integration into the backwards threader. SO think we keep this as an open BZ until that's addressed.
[Bug c++/97749] New: ICE: Segmentation Fault on C++20 NTTP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97749
Bug ID: 97749
Summary: ICE: Segmentation Fault on C++20 NTTP
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: janpmoeller at gmx dot de
Target Milestone: ---
The following code results in an ICE when compiled with gcc-10.2 or the latest
trunk:
/
#include
#include
template
struct fixed_string
{
char buf[N + 1]{};
constexpr fixed_string(char const* s) { std::copy_n(s, N, buf); }
constexpr operator char const *() const { return buf; }
constexpr operator std::string_view() const { return buf; }
};
template
fixed_string(char const (&)[N]) -> fixed_string;
template
struct foo;
template
struct bar;
template
struct bar>
{};
int main()
{
bar> foobar;
}
/
This is the output:
#
:22:24: internal compiler error: Segmentation fault
22 | struct bar>
|^~~
0x1be3959 internal_error(char const*, ...)
???:0
0x6ad485 resolve_args(vec*, int)
???:0
0x89f9af do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
???:0
0x8bf5ac lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
???:0
0x91439d finish_template_type(tree_node*, tree_node*, int)
???:0
0x87a2ac c_parse_file()
???:0
0x9f0f52 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c/97748] New: Preincrement of _Complex gives bogus warning = "value computed is not used"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97748
Bug ID: 97748
Summary: Preincrement of _Complex gives bogus warning = "value
computed is not used"
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: antiquarktv at gmail dot com
Target Milestone: ---
The following code, when compiled with -Wall, gives the warning "value computed
is not used". The value is in fact used, thus the warning is bogus.
#include
#include
int main()
{
double _Complex x = 2.0 + I * 2.0;
++x;
printf("%f,%f\n", creal(x), cimag(x));
}
Output:
gcc -Wall test.c
test.c: In function ‘main’:
test.c:7:2: warning: value computed is not used [-Wunused-value]
7 | ++x;
| ^~~
[Bug libgcc/96948] _Unwind_GetIP() and _Unwind_GetIPInfo() empty in _Unwind_Backtrace() with SEH on mingw64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96948 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #6 from Jeffrey A. Law --- Should be fixed on trunk now.
[Bug target/91489] misplaced stack pointer when __ms_hook_prologue__ attribute is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91489 Jeffrey A. Law changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED CC||law at redhat dot com --- Comment #6 from Jeffrey A. Law --- Should be fixed on trunk now
[Bug target/91489] misplaced stack pointer when __ms_hook_prologue__ attribute is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91489 --- Comment #5 from CVS Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:659ba632e440280e8d61e1ae870e917765db5ae5 commit r11-4806-g659ba632e440280e8d61e1ae870e917765db5ae5 Author: Jeff Law Date: Fri Nov 6 17:38:00 2020 -0500 Fix stack pointer handling in ms_hook_prologue functions for i386 target. gcc/ PR target/91489 * config/i386/i386.md (simple_return): Also check for ms_hook_prologue function attribute. * config/i386/i386.c (ix86_can_use_return_insn_p): Also check for ms_hook_prologue function attribute. * config/i386/i386-protos.h (ix86_function_ms_hook_prologue): Declare. gcc/testsuite PR target/91489 * gcc.target/i386/ms_hook_prologue.c: Expand testcase to reproduce PR target/91489 issue.
[Bug tree-optimization/91789] Value ranges determined from comparisons not used transitively
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91789 --- Comment #5 from Andrew Macleod --- Ranger made it in, but relations have not been implemented for this release. GCC 12 for sure!
[Bug other/89863] [meta-bug] Issues in gcc that other static analyzers (cppcheck, clang-static-analyzer, PVS-studio) find that gcc misses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863 Bug 89863 depends on bug 66469, which changed state. Bug 66469 Summary: config/rl78/rl78.c:679: possible bad array index ? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66469 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug other/89863] [meta-bug] Issues in gcc that other static analyzers (cppcheck, clang-static-analyzer, PVS-studio) find that gcc misses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863 Bug 89863 depends on bug 50355, which changed state. Bug 50355 Summary: Comparison is always true in alpha config code https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50355 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug target/66469] config/rl78/rl78.c:679: possible bad array index ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66469 Eric Gallager changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #4 from Eric Gallager --- (In reply to David Binderman from comment #3) > (In reply to Eric Gallager from comment #2) > > (In reply to Eric Gallager from comment #1) > > > I can't seem to find the mentioned code in the source file any longer... > > > > WAITING for David to reconfirm > > $ fgrep call_used_regs trunk.git/gcc/config/rl78/rl78.c > $ > > Another one gone away. Closed, then.
[Bug target/50355] Comparison is always true in alpha config code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50355 Eric Gallager changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #4 from Eric Gallager --- (In reply to David Binderman from comment #3) > $ fgrep INTVAL /home/dcb/gcc/trunk.git/gcc/config/alpha/alpha.c | fgrep 8 > && INTVAL (XEXP (x, 1)) == -8) > mod_f = memmodel_from_int (INTVAL (operands[8])); > (INTVAL (x) & 0x) - 2 * (INTVAL (x) & 0x8000)); > (INTVAL (x) == 8 ? "b" > fprintf (file, HOST_WIDE_INT_PRINT_DEC, INTVAL (x) / 8); > > So some nine years later, the code doesn't seem to exist anymore. ok, closing as FIXED then
[Bug other/89863] [meta-bug] Issues in gcc that other static analyzers (cppcheck, clang-static-analyzer, PVS-studio) find that gcc misses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863 Bug 89863 depends on bug 71327, which changed state. Bug 71327 Summary: libiberty/cplus-dem.c:2702]: (style) Redundant condition https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71327 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug other/71327] libiberty/cplus-dem.c:2702]: (style) Redundant condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71327 Eric Gallager changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #4 from Eric Gallager --- (In reply to David Binderman from comment #3) > (In reply to Eric Gallager from comment #2) > > WAITING for David to reconfirm > > $ fgrep scan trunk.git/libiberty/cplus-dem.c > $ > > Another one gone away, this time in four years. Thus, closing.
[Bug target/96933] rs6000: inefficient code for char/short vec CTOR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96933 --- Comment #13 from CVS Commits --- The master branch has been updated by Segher Boessenkool : https://gcc.gnu.org/g:e5502ae72f784470019de5850017ad0c87ffacef commit r11-4805-ge5502ae72f784470019de5850017ad0c87ffacef Author: Segher Boessenkool Date: Fri Nov 6 12:50:35 2020 + rs6000: Fix TARGET_POWERPC64 vs. TARGET_64BIT confusion I gave Ke Wen bad advice, luckily David corrected me: it is true that we cannot use TARGET_POWERPC64 on many 32-bit OSes, since either the kernel or userland does not save the top half of the 64-bit integer registers, but we do not have to care about that in separate patterns or related code. The flag is automatically not enabled by default on targets that do not handle this correctly. This patch fixes it. Segher 2020-11-06 Segher Boessenkool PR target/96933 * config/rs6000/rs6000.c (rs6000_expand_vector_init): Use TARGET_POWERPC64 instead of TARGET_64BIT.
[Bug target/97734] GCC using branches when a conditional move would be better
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97734 --- Comment #3 from Rafael Avila de Espindola --- I just realized I made a mistake when producing the reduced testcase. The argument x should have been an uint32_t. Unfortunately, with that fix gcc always produces a branch. ICC still produces a cmov: https://gcc.godbolt.org/z/zszrPK I would be very happy with a __builtin_branchless_select.
[Bug target/66469] config/rl78/rl78.c:679: possible bad array index ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66469 --- Comment #3 from David Binderman --- (In reply to Eric Gallager from comment #2) > (In reply to Eric Gallager from comment #1) > > I can't seem to find the mentioned code in the source file any longer... > > WAITING for David to reconfirm $ fgrep call_used_regs trunk.git/gcc/config/rl78/rl78.c $ Another one gone away.
[Bug bootstrap/58427] xgcc target compilation depends on installed libgcc_s.so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58427 Eric Gallager changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-11-06 Status|UNCONFIRMED |WAITING CC||egallager at gcc dot gnu.org --- Comment #3 from Eric Gallager --- (In reply to Eric Gallager from comment #2) > (In reply to Rose Garcia from comment #1) > > related binutils bugreport: > > https://sourceware.org/bugzilla/show_bug.cgi?id=12549#c18 > > That binutils issue has been fixed; is there anything left for GCC to do? WAITING on a reply
[Bug other/71327] libiberty/cplus-dem.c:2702]: (style) Redundant condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71327 --- Comment #3 from David Binderman --- (In reply to Eric Gallager from comment #2) > WAITING for David to reconfirm $ fgrep scan trunk.git/libiberty/cplus-dem.c $ Another one gone away, this time in four years.
[Bug target/50355] Comparison is always true in alpha config code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50355 --- Comment #3 from David Binderman --- $ fgrep INTVAL /home/dcb/gcc/trunk.git/gcc/config/alpha/alpha.c | fgrep 8 && INTVAL (XEXP (x, 1)) == -8) mod_f = memmodel_from_int (INTVAL (operands[8])); (INTVAL (x) & 0x) - 2 * (INTVAL (x) & 0x8000)); (INTVAL (x) == 8 ? "b" fprintf (file, HOST_WIDE_INT_PRINT_DEC, INTVAL (x) / 8); So some nine years later, the code doesn't seem to exist anymore.
[Bug target/66469] config/rl78/rl78.c:679: possible bad array index ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66469 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 CC||egallager at gcc dot gnu.org Last reconfirmed||2020-11-06 --- Comment #2 from Eric Gallager --- (In reply to Eric Gallager from comment #1) > I can't seem to find the mentioned code in the source file any longer... WAITING for David to reconfirm
[Bug other/71327] libiberty/cplus-dem.c:2702]: (style) Redundant condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71327 Eric Gallager changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Last reconfirmed||2020-11-06 CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- (In reply to Eric Gallager from comment #1) > (In reply to David Binderman from comment #0) > > libiberty/cplus-dem.c:2702]: (style) Redundant condition: If 'EXPR == '_'', > > the comparison 'EXPR' is always true. > > > > Source code is > > > > while (*scan && *scan == '_') > > > > Suggest new code > > > > while (*scan == '_') > > I can't seem to find the mentioned code in the original source file any > longer... WAITING for David to reconfirm
[Bug target/50355] Comparison is always true in alpha config code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50355 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Last reconfirmed||2020-11-06 --- Comment #2 from Eric Gallager --- (In reply to Eric Gallager from comment #1) > I can't seem to find the code in question in the source file any longer... WAITING for David to reconfirm
[Bug c++/81660] Add -Wexceptions warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81660 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Marek Polacek --- Done in GCC 11.
[Bug c++/81660] Add -Wexceptions warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81660 --- Comment #4 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:43d3b7bc073df27800218b685e6d7dd78dd31905 commit r11-4803-g43d3b7bc073df27800218b685e6d7dd78dd31905 Author: Marek Polacek Date: Thu Nov 5 21:46:06 2020 -0500 c++: Small tweak to can_convert_eh [PR81660] While messing with check_handlers_1, I spotted this bug report which complains that we don't warn about the case when we have two duplicated handlers of type int. can_convert_eh implements [except.handle] and that says: A handler is a match for an exception object of type E if - The handler is of type cv T or cv T& and E and T are the same type (ignoring the top-level cv-qualifiers), or [...] but we don't implement this bullet properly for non-class types. The fix therefore seems pretty obvious. Also change the return type to bool when we're only returning yes/no. gcc/cp/ChangeLog: PR c++/81660 * except.c (can_convert_eh): Change the return type to bool. If the type TO and FROM are the same, return true. gcc/testsuite/ChangeLog: PR c++/81660 * g++.dg/warn/Wexceptions3.C: New test. * g++.dg/eh/pr42859.C: Add dg-warning. * g++.dg/torture/pr81659.C: Likewise.
[Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417 --- Comment #21 from Jim Wilson --- I submitted my testcase as 97747 so it will get more attention.
[Bug rtl-optimization/97747] New: missed combine opt with logical ops after zero extended load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97747
Bug ID: 97747
Summary: missed combine opt with logical ops after zero
extended load
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: wilson at gcc dot gnu.org
Target Milestone: ---
Consider this testcase
struct
{
unsigned int a : 1;
unsigned int b : 1;
unsigned int c : 1;
unsigned int d : 1;
unsigned int pad1 : 28;
} s;
void
sub (void)
{
s.a = 1;
s.c = 1;
}
Compiling with -O2 -S for ARM I get
sub:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
movwr2, #:lower16:.LANCHOR0
movtr2, #:upper16:.LANCHOR0
ldrbr3, [r2]@ zero_extendqisi2
bic r3, r3, #5
orr r3, r3, #5
strbr3, [r2]
bx lr
The bic bit-clear instruction is obviously unnecessary.
In the combine dump file I see that we have
(insn 9 7 11 2 (set (reg:SI 120)
(and:SI (reg:SI 119 [ MEM [(struct *)] ])
(const_int -6 [0xfffa]))) "tmp.c":13:7 90
{*arm_andsi3_insn}
(expr_list:REG_DEAD (reg:SI 119 [ MEM [(struct
*)] ])
(nil)))
(insn 11 9 13 2 (set (reg:SI 122)
(ior:SI (reg:SI 120)
(const_int 5 [0x5]))) "tmp.c":13:7 106 {*iorsi3_insn}
(expr_list:REG_DEAD (reg:SI 120)
(nil)))
And the combiner does:
Trying 9 -> 11:
9: r120:SI=r119:SI&0xfffa
REG_DEAD r119:SI
11: r122:SI=r120:SI|0x5
REG_DEAD r120:SI
Failed to match this instruction:
(set (reg:SI 122)
(ior:SI (and:SI (reg:SI 119 [ MEM [(struct *)] ])
(const_int 250 [0xfa]))
(const_int 5 [0x5])))
The problem here is that the ARM port generated a zero_extend for the load
byte, so combine knows that r120 has only 8 nonzero bits, it modified the -6 to
250 and then fails to notice that the and operation can be folded away because
in SImode the operation is no longer redundant with the modified constant.
On targets that do not generate the zero_extend, the and -6 operation gets
optimized away in combine. For instance, with the current RISC-V port I get
sub:
lui a4,%hi(s)
lbu a5,%lo(s)(a4)
ori a5,a5,5
sb a5,%lo(s)(a4)
ret
This likely fails on any target where movqi generates a zero extended load.
[Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417 --- Comment #20 from Jim Wilson --- Maybe convert_to_mode is recursively calling convert_to_mode until you run out of stack space. You can use --save-temps to generate a .i preprocessed file form your input testcasxe, then run cc1 under gdb. You need to give the default arch/abi options or you will get an error (gdb) run -march=rv64gc -mabi=lp64d -O2 tmp.i when look at the backtrace when you hit the segfault. There are other ways to get the zero extend we need here. We could just generate the RTL for the insn directly instead of calling the gen_zero_extendXiYi2 functions because we know that they exist and what form they are in. This is inconvenient though. We could try querying the optabs table to get the right insn code. There is a gen_extend_insn function that looks like it would work and is more direct than convert_to_mode. gen_extend_insn does require that the input is in a form that the convert will accept, so it must be forced to a register if it isn't already a register. Another solution would be to use one of the rtx simplier functions, e.g. you can do simplify_gen_unary (ZERO_EXTEND, word_mode, src, mode); but the simplify functions are really for simplifying complex RTL to simpler RTL, so I think not the right approach here. I think gen_extend_insn is the best approach if we can't use convert_to_mode.
[Bug c/97746] New: ice in vect_init_pattern_stmt, at tree-vect-patterns.c:116
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97746
Bug ID: 97746
Summary: ice in vect_init_pattern_stmt, at
tree-vect-patterns.c:116
Product: gcc
Version: unknown
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:
int a, b, c;
extern int k(void);
extern int l(void);
void main(void) {
char *d, *e, f = 1, g = 1;
char h = 0, i, j = 0;
while (k()) {
j++;
h = 1;
}
while (a <= 0) {
if (a)
f = 0;
if (j)
i = 1;
if (h)
e[0] = e[1] = b;
if (i && d && h == 0)
i = 0;
if (f)
g = 2;
if (i && d)
for (; c < g;)
if (l())
return;
}
}
compiled by recent gcc trunk and compiler flag -O3 -march=bdver2,
does this:
uring GIMPLE pass: slp
bug668.c: In function ‘main’:
bug668.c:4:6: internal compiler error: in vect_init_pattern_stmt, at
tree-vect-p
atterns.c:116
4 | void main(void) {
| ^~~~
0x18acdd4 vect_init_pattern_stmt(vec_info*, gimple*, _stmt_vec_info*,
tree_node*
)
../../trunk.git/gcc/tree-vect-patterns.c:115
0x18ac829 vect_set_pattern_stmt(vec_info*, gimple*, _stmt_vec_info*,
tree_node*)
../../trunk.git/gcc/tree-vect-patterns.c:133
The bug first seems to appear between 20201105 and 20201106.
[Bug c++/67453] vtable not emitted for class with no key method and defaulted destructor with attribute((used))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67453 --- Comment #5 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:6c282c14d1be0bba2bf5d49acd074b349f28ad17 commit r11-4798-g6c282c14d1be0bba2bf5d49acd074b349f28ad17 Author: Jakub Jelinek Date: Fri Nov 6 20:33:39 2020 +0100 c++: Propagate attributes to clones in duplicate_decls [PR67453] On the following testcase where the cdtor attributes aren't on the in-class declaration but on an out-of-class definition, the cdtors have their clones created from the in-class declaration, and later on duplicate_decls updates attributes on the abstract cdtors, but nothing propagates them to the clones. 2020-11-06 Jakub Jelinek PR c++/67453 * decl.c (duplicate_decls): Propagate DECL_ATTRIBUTES and DECL_PRESERVE_P from olddecl to its clones if any. * g++.dg/ext/attr-used-2.C: New test.
[Bug tree-optimization/97741] [11 Regression] ICE: verify_gimple failed with "-Os -fno-toplevel-reorder -fno-tree-ccp -fno-tree-fre" since r11-4724
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97741 Andrew Macleod changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Andrew Macleod --- fixed.
[Bug tree-optimization/97737] [11 Regression] ICE at -Os and above: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.c:88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97737 Andrew Macleod changed: What|Removed |Added Resolution|DUPLICATE |FIXED --- Comment #6 from Andrew Macleod --- I also put this testcase into the suite since propagating undefined in range-ops would also fix the Other PR, but not this one. So although the problem are similar and covered by the same patch, its possible to change the fix for one and not fix the other. Still, fixed.
[Bug c++/97518] Improving static_assert diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97518
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
--- Comment #3 from Marek Polacek ---
I have a trivial patch that improves
template
void foo()
{
static_assert (sizeof(T) == 4);
}
void
g ()
{
foo();
}
from
97518-2.C: In instantiation of ‘void foo() [with T = char]’:
97518-2.C:10:13: required from here
97518-2.C:4:28: error: static assertion failed
4 | static_assert (sizeof(T) == 4);
| ~~^~~~
to
97518-2.C: In instantiation of ‘void foo() [with T = char]’:
97518-2.C:10:13: required from here
97518-2.C:4:28: error: static assertion failed due to requirement ‘(sizeof
(char) == 4)’
4 | static_assert (sizeof(T) == 4);
| ~~^~~~
[Bug tree-optimization/97737] [11 Regression] ICE at -Os and above: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.c:88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97737 --- Comment #5 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:129e1a8a96d140150705fab30d25afb464eb1d99 commit r11-4795-g129e1a8a96d140150705fab30d25afb464eb1d99 Author: Andrew MacLeod Date: Fri Nov 6 14:14:46 2020 -0500 Combine new calculated ranges with existing range. When a range is recalculated, retain what was previously known as IL changes can produce different results from un-executed code. This also paves the way for external injection of ranges. gcc/ PR tree-optimization/97737 PR tree-optimization/97741 * gimple-range.cc: (gimple_ranger::range_of_stmt): Intersect newly calculated ranges with the existing known global range. gcc/testsuite/ * gcc.dg/pr97737.c: New. * gcc.dg/pr97741.c: New.
[Bug tree-optimization/97741] [11 Regression] ICE: verify_gimple failed with "-Os -fno-toplevel-reorder -fno-tree-ccp -fno-tree-fre" since r11-4724
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97741 --- Comment #5 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:129e1a8a96d140150705fab30d25afb464eb1d99 commit r11-4795-g129e1a8a96d140150705fab30d25afb464eb1d99 Author: Andrew MacLeod Date: Fri Nov 6 14:14:46 2020 -0500 Combine new calculated ranges with existing range. When a range is recalculated, retain what was previously known as IL changes can produce different results from un-executed code. This also paves the way for external injection of ranges. gcc/ PR tree-optimization/97737 PR tree-optimization/97741 * gimple-range.cc: (gimple_ranger::range_of_stmt): Intersect newly calculated ranges with the existing known global range. gcc/testsuite/ * gcc.dg/pr97737.c: New. * gcc.dg/pr97741.c: New.
[Bug middle-end/97738] Optimizing division by value & - value for HAKMEM 175
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97738 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- What about a version that still sets lowest_bit to value & -value; rather than 1 < ctz? Also, I'm not sure you can safely do the (changed_bits >> ctz) >> 2 to changed_bits >> (ctz + 2) transformation, while because of the division one can count on value not being 0 (otherwise UB), value & -value can still be e.g. 1U << 31 and then ctz 31 too, and changed_bits >> (31 + 2) being UB, while (changed_bits >> 31) >> 2 well defined returning 0. So, I think we could e.g. during expansion (or isel) based on target cost optimize x / (y & -y) to x >> __builtin_ctz (y) (also assuming the optab for ctz exists), but anything else looks complicated.
[Bug middle-end/97738] Optimizing division by value & - value for HAKMEM 175
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97738 --- Comment #3 from Thomas Koenig --- Even faster code: ctz = __builtin_ctz (value); lowest_bit = value & - value; left_bits = value + lowest_bit; changed_bits = value ^ left_bits; right_bits = changed_bits >> (ctz + 2); return left_bits | right_bits; The first two instructions get compiled directly (with -march=native) to blsi%edi, %edx tzcntl %edi, %eax
[Bug fortran/97652] [11 Regression] New gfortran.dg/pdt_14.f03 failure after g:617695cdc2b3d950f1e4deb5ea85d5cc302943f4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97652 --- Comment #18 from CVS Commits --- The releases/gcc-9 branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:542b564343fdb896ede9c9d5e32d45dcd96b2a00 commit r9-9028-g542b564343fdb896ede9c9d5e32d45dcd96b2a00 Author: Tobias Burnus Date: Fri Nov 6 08:26:51 2020 +0100 Fortran: Fix type-decl for PDT / wrong-code pdt_14.f03 issue [PR97652] Parameterized derived types are handled in a special way and start with 'Pdt'. If the 'P' is not uppercase, gfc_get_derived_type (which calls gfc_get_module_backend_decl) does not find the existing declaration and builds a new type. The middle end then sees those types as being different and nonalising, creating an endless loop for pdt_14.f03. gcc/fortran/ChangeLog: PR fortran/97652 * module.c (mio_symbol): Fix symbol name for pdt_type. (cherry picked from commit c283a711c850efaab4fe3bca5ef7200eb854bba1)
[Bug tree-optimization/97744] [11 regression] 32 bit floating point result errors after r11-4637
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97744 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0 Keywords||wrong-code --- Comment #1 from Richard Biener --- Needs some investigation.
[Bug c++/97745] [10 Regression] ICE in tsubst_decl, at cp/pt.c:14666
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97745 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.3 Keywords||ice-on-invalid-code
[Bug tree-optimization/97737] [11 Regression] ICE at -Os and above: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.c:88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97737 --- Comment #4 from Zhendong Su --- I would guess that it makes more sense to mark PR 97741 as a dup of this bug.
[Bug debug/97713] [gsplit-dwarf] label generated for .debug_abbrev.dwo offset, corresponding relocation ignored by objcopy --extract-dwo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97713 Tom de Vries changed: What|Removed |Added CC||ccoutant at gmail dot com, ||jason at gcc dot gnu.org --- Comment #4 from Tom de Vries --- (In reply to Tom de Vries from comment #0) > Now, should objcopy implement the relocation? Nick proposed a patch that errors out on current gcc output. > Note that llvm emits a '0' as abbrev offset instead of a label. And gcc would have to emit a 0, like llvm. It that ok from gcc perspective?
[Bug tree-optimization/97741] [11 Regression] ICE: verify_gimple failed with "-Os -fno-toplevel-reorder -fno-tree-ccp -fno-tree-fre" since r11-4724
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97741 --- Comment #4 from Andrew Macleod --- btw, the resulting code for this function is cleaned up a lot: : a = 6; goto ; [INV] : c = 0; : a.0_2 = a; if (a.0_2 != 0) goto ; [INV] else goto ; [INV] : # e_5 = PHI <0(4)> return;
[Bug tree-optimization/97741] [11 Regression] ICE: verify_gimple failed with "-Os -fno-toplevel-reorder -fno-tree-ccp -fno-tree-fre" since r11-4724
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97741 Andrew Macleod changed: What|Removed |Added CC||zhendong.su at inf dot ethz.ch --- Comment #3 from Andrew Macleod --- *** Bug 97737 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/97737] [11 Regression] ICE at -Os and above: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.c:88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97737 Andrew Macleod changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Macleod --- This is actually the same issue as 97741. The iL is being changed and we lose info. The first thing visited is: e_4 = PHI <1(2), e_3(7)> and the incoming edge from bb7 is determined to be undefined, so we fold e_4 to 1 but later on the undefined edge becomes defined due a "harmless" constant in unreachable code being propagated. The end result is now: : b = 1; a.0_1 = a; e_10 = 1 / a.0_1; if (e_10 == 0) goto ; [INV] else goto ; [INV] : c.1_2 = c; : return; *** This bug has been marked as a duplicate of bug 97741 ***
[Bug c++/97745] New: [10 Regression] ICE in tsubst_decl, at cp/pt.c:14666
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97745
Bug ID: 97745
Summary: [10 Regression] ICE in tsubst_decl, at cp/pt.c:14666
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at debian dot org
Target Milestone: ---
https://bugs.debian.org/973698
seen with the gcc-10 branch, compiler configured with
--enable-checking=yes,extra,rtl
gives an error on the gcc-9 branch and trunk.
$ cat search_collection_test.ii
template b aa;
template auto ab() -> decltype(aa);
# 1 "" 3
template concept d = __is_base_of(c, br);
template struct bz;
struct {
template
auto operator()(cb e, cc... g) -> decltype(e(g...));
} bw;
template
using ce = decltype(bw(ab(), ab...));
namespace ch {
struct cx;
}
template concept da = d, ch::cx>;
template concept db = da;
struct {
template bz operator()(cd);
} dc;
struct h {
template
requires db friend operator|(f, bz);
};
template struct bz : h {};
struct {
template auto operator()(cd e) { return dc(e); }
} dm;
class {
count() {
count | dm([*this](auto) {})
}
};
$ g++ -c -std=c++17 -fconcepts -Wall search_collection_test.ii
: In instantiation of ‘::count():: [with auto:1
= int (::* (*)())()]’:
:5:47: required by substitution of ‘template decltype
(e(._anon_0::operator()::g ...))::operator()(cb, cc ...) [with
cb = ::count()::; cc = {int (::*
(*)())()}]’
:8:23: required from ‘int operator|(f, bz) [with f = int (::*)(); cy = ::count()::]’
:27:32: required from here
:27:28: internal compiler error: in tsubst_decl, at cp/pt.c:14666
0x6656de tsubst_decl
../../src/gcc/cp/pt.c:14666
0xc21587 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.c:18002
0xc1e8e8 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.c:18219
0xc1c831 instantiate_decl(tree_node*, bool, bool)
../../src/gcc/cp/pt.c:25824
0xb5084a maybe_instantiate_decl
../../src/gcc/cp/decl2.c:5370
0xb52f40 maybe_instantiate_decl
../../src/gcc/cp/decl2.c:
0xb52f40 mark_used(tree_node*, int)
../../src/gcc/cp/decl2.c:5581
0xaa4322 build_over_call
../../src/gcc/cp/call.c:9093
0xaa91b1 build_op_call_1
../../src/gcc/cp/call.c:4872
0xaa91b1 build_op_call(tree_node*, vec**, int)
../../src/gcc/cp/call.c:4901
0xc64f8e finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../src/gcc/cp/semantics.c:2689
0xc2ec88 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:20115
0xc30cf4 tsubst(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.c:15946
0xc3b54a tsubst_function_type
../../src/gcc/cp/pt.c:14932
0xc308f0 tsubst(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.c:15753
0xc3f3cc tsubst_function_decl
../../src/gcc/cp/pt.c:13787
0xc28c3f tsubst_decl
../../src/gcc/cp/pt.c:14230
0xc39569 instantiate_template_1
../../src/gcc/cp/pt.c:20871
0xc48ecb instantiate_template(tree_node*, tree_node*, int)
../../src/gcc/cp/pt.c:20928
0xc48ecb fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
../../src/gcc/cp/pt.c:21372
Please submit a full bug report,
with preprocessed source if appropriate.
$ g++-9 -c -std=c++17 -fconcepts -Wall search_collection_test.ii
: In member function ‘int::count()’:
:27:11: error: invalid use of non-static member function ‘int::count()’
:26:3: note: declared here
: At global scope:
:29:2: error: abstract declarator ‘’ used as declaration
:15:33: error: ‘bz::operator()(cd) [with cd = ::count()::]’, declared using local type ‘::count()::’, is used but never defined [-fpermissive]
$ /usr/lib/gcc-snapshot/bin/g++ -c -std=c++17 -fconcepts -Wall
search_collection_test.ii
: In member function 'int::count()':
:27:11: error: invalid use of non-static member function 'int::count()'
:26:3: note: declared here
: At global scope:
:29:2: error: abstract declarator '' used as declaration
:15:33: error: 'bz::operator()(cd) [with cd = ::count()::]', declared using local type '::count()::', is used but never defined [-fpermissive]
[Bug tree-optimization/97741] [11 Regression] ICE: verify_gimple failed with "-Os -fno-toplevel-reorder -fno-tree-ccp -fno-tree-fre" since r11-4724
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97741 --- Comment #2 from Andrew Macleod --- Created attachment 49517 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49517=edit don't lose info already in the global range The problem here is the IL being changed by propagation under to covers sometimes loses information. The first thing examined is: e_4 = PHI <0(2), e_8(6)> and the ranger goes off on the backedge to block 6 and eventually determines that the edge 6->2 can never be executed, and thus e_8 is undefined on that edge, which means the range of the PHI can be determined to be [0,0], and can thus be folded. Later on the propagator visits the blocks this originates in and sees e_8 = PHI which is fed by the sequence: : b.1_3 = b; if (b.1_3 != 0) goto ; [INV] : e_12 = e_5 + 1; : # e_5 = PHI <0(5), e_12(8)> if (e_5 == 20) goto ; [INV] The ranger had figured out that although the branch says e_5 must be 20 on the edge from bb5,it can only get to this code if it is 20 AND goes thru the e_12 = e_5 + 1, which means e_12 must only be [21, 21] which makes the whole thing undefined.. and it is. it can never happen. However, when the propagator later visits stmts, and we get to e_12 = e_5 + 1; when this is re-evaluated, e_5 is undefined and rather than propagating e_12 as undefined, we decided a while ago to treat undefined as VARYING when doing math.. we change e_12 to VARYING now, even tho we had earlier decided it was [21,21] This has ripple effects that eventually results in deciding that e_5 must be [20,20] coming from bb 7, it replaces that first PHI: e_8 = PHI with e_8 = PHI <20(7)> when we then ask for the range of e_4 again at a use: : _1 = (char) e_4; e_4 = PHI <0(2), e_8(6)> e_8 is now hardwired to [20,20] so it now recalculates e_4 to be [0,0][20,20] instead of 0, and the engine does not fold the statement. which ends up leaving e_4 in the IL with no definition. THe easiest way to fix this sort of thing is to recognize that with the IL changing under the covers in ways not really controlled by the ranger, we should keep the previous value we defined, and refine it as we go along rather than fully recalculating it. I think this will resolve an entire class of issues until we change the way we propagate things, or revisit the slightly schizophrenic interpretation of undefined. The original RVRP pass simply propagated values via the immediate-use chains, so the IL always reflected exactly what it knew. The attached patch is currently being tested.
[Bug fortran/97652] [11 Regression] New gfortran.dg/pdt_14.f03 failure after g:617695cdc2b3d950f1e4deb5ea85d5cc302943f4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97652 --- Comment #17 from CVS Commits --- The releases/gcc-10 branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:099857318ca92210e34cfb8975c5c58c00bf1587 commit r10-8989-g099857318ca92210e34cfb8975c5c58c00bf1587 Author: Tobias Burnus Date: Fri Nov 6 08:26:51 2020 +0100 Fortran: Fix type-decl for PDT / wrong-code pdt_14.f03 issue [PR97652] Parameterized derived types are handled in a special way and start with 'Pdt'. If the 'P' is not uppercase, gfc_get_derived_type (which calls gfc_get_module_backend_decl) does not find the existing declaration and builds a new type. The middle end then sees those types as being different and nonalising, creating an endless loop for pdt_14.f03. gcc/fortran/ChangeLog: PR fortran/97652 * module.c (mio_symbol): Fix symbol name for pdt_type. (cherry picked from commit c283a711c850efaab4fe3bca5ef7200eb854bba1)
[Bug c++/81660] Add -Wexceptions warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81660 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug middle-end/97738] Optimizing division by value & - value for HAKMEM 175
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97738 --- Comment #2 from Thomas Koenig --- Created attachment 49516 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49516=edit Small benchmark Here's a small benchmark for counting all 32-bit numbers with 16 bits set according to the HAKMEM source. Timing is (first float is elapsed time in seconds for version with division, second float is for the shift): 2.319526 601080391 1.147284 601080391 with -O3 -march=native on an AMD Ryzen 7 1700X, 4.539288 601080391 2.700514 601080391 on POWER9.
[Bug debug/97713] [gsplit-dwarf] label generated for .debug_abbrev.dwo offset, corresponding relocation ignored by objcopy --extract-dwo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97713 --- Comment #3 from Tom de Vries --- Mentioning dwarf 5 standard bit @ "7.3.2.2 Second Partition (Unlinked or in a .dwo File)": ... Split DWARF object files do not get linked with any other files, therefore references between sections must not make use of normal object file relocation information. As a result, symbolic references within or between sections are not possible. ...
[Bug tree-optimization/97744] New: [11 regression] floating point result errors after r11-4637
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97744 Bug ID: 97744 Summary: [11 regression] floating point result errors after r11-4637 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:f5e18dd9c7dacc9671044fc669bd5c1b26b6bdba, r11-4637 This revision causes errors in the 32 bit run of the 172.mgrid test case, part of spec 2000. Running Benchmarks Running 172.mgrid ref base wds_test_32 default *** Miscompare of mgrid.out, see cpu2000/benchspec/CFP2000/172.mgrid/run/0011/mgrid.out.mis Running 172.mgrid ref base wds_test_32 default *** Miscompare of mgrid.out, see cpu2000/benchspec/CFP2000/172.mgrid/run/0011/mgrid.out.mis Running 172.mgrid ref base wds_test_32 default *** Miscompare of mgrid.out, see cpu2000/benchspec/CFP2000/172.mgrid/run/0011/mgrid.out.mis Error: 3x172.mgrid cat cpu2000/benchspec/CFP2000/172.mgrid/run/0011/mgrid.out.mis 12732: 0.620103E-12 -0.425977E-12 ^ 12733: 0.620103E-12 -0.425977E-12 ^ 12734: 0.627531E-12 -0.431079E-12 ^ 12735: 0.627531E-12 -0.431079E-12 ^ 12736: 0.629423E-12 -0.432379E-12 ^ 12737: 0.629423E-12 -0.432379E-12 ^ 12738: 0.629932E-12 -0.432729E-12 ^
[Bug tree-optimization/97706] [11 Regression] ICE with LTO at -O3: verify_gimple failed (incompatible types in 'PHI' argument 0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97706 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from Richard Biener --- Fixed.
[Bug tree-optimization/97706] [11 Regression] ICE with LTO at -O3: verify_gimple failed (incompatible types in 'PHI' argument 0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97706 --- Comment #10 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:22175d0dc6a89ddd630f19d0f32a2d1ddb046807 commit r11-4787-g22175d0dc6a89ddd630f19d0f32a2d1ddb046807 Author: Richard Biener Date: Thu Nov 5 12:34:42 2020 +0100 tree-optimization/97706 - handle PHIs in pattern recog mask precison This adds handling of PHIs to mask precision compute which is eventually needed to detect a bool pattern when the def chain contains such a PHI node. 2020-11-06 Richard Biener PR tree-optimization/97706 * tree-vect-patterns.c (possible_vector_mask_operation_p): PHIs are possible mask operations. (vect_determine_mask_precision): Handle PHIs. (vect_determine_precisions): Walk PHIs in BB analysis. * gcc.dg/vect/bb-slp-pr97706.c: New testcase.
[Bug gcov-profile/97594] [11 Regression] new test case gcc.dg/tree-prof/pr97461.c execution failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97594 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Martin Liška --- Fixed in r11-4785-g15bcd01a94c23f312ac03b5faea29f18ef8d2a07.
[Bug gcov-profile/97461] [11 Regression] allocate_gcov_kvp() deadlocks in firefox LTO+PGO build (overridden malloc() recursion)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97461 --- Comment #22 from Martin Liška --- (In reply to CVS Commits from comment #21) > The master branch has been updated by Martin Liska : > > https://gcc.gnu.org/g:15bcd01a94c23f312ac03b5faea29f18ef8d2a07 > > commit r11-4785-g15bcd01a94c23f312ac03b5faea29f18ef8d2a07 > Author: Kewen Lin > Date: Fri Nov 6 14:45:06 2020 +0100 > > testsuite: fix malloc alignment in test > > gcc/testsuite/ChangeLog: > > PR gcov-profile/97461 > * gcc.dg/tree-prof/pr97461.c: Return aligned memory. Bad revision, it belongs to PR97594.
[Bug gcov-profile/97461] [11 Regression] allocate_gcov_kvp() deadlocks in firefox LTO+PGO build (overridden malloc() recursion)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97461 --- Comment #21 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:15bcd01a94c23f312ac03b5faea29f18ef8d2a07 commit r11-4785-g15bcd01a94c23f312ac03b5faea29f18ef8d2a07 Author: Kewen Lin Date: Fri Nov 6 14:45:06 2020 +0100 testsuite: fix malloc alignment in test gcc/testsuite/ChangeLog: PR gcov-profile/97461 * gcc.dg/tree-prof/pr97461.c: Return aligned memory.
[Bug tree-optimization/97623] [9/10/11 Regression] Extremely slow O2 compile (>>O(n^2))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97623 --- Comment #16 from Richard Biener --- (In reply to Martin Liška from comment #14) > With -O2 -fno-code-hoisting it's fixed since r10-300-gaae6da83564549a6. Ah, that makes sense.
[Bug tree-optimization/97623] [9/10/11 Regression] Extremely slow O2 compile (>>O(n^2))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97623 --- Comment #15 from Richard Biener --- OK, noting down low-hanging optimization fruits: - phi-translation caching uses a hash with needless indirection, XNEW-ing expr_pred_trans_d - old issue, value_id_constant_p is expensive - better would be to make those negative, requires separate value_expressions array for constants - sorted_array_from_bitmap_set could be cached at least for sorting of ANTIC_IN during insertion since that doesn't change (helps when iterating), and we could remove (zero) entries we already inserted to avoid repeated work going to work on a few of those.
[Bug c/66249] -Wformat-signedness should not warn on enums
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66249 --- Comment #3 from Peter Eisentraut --- The GCC documentation on implementation-defined behavior states that enums are unsigned unless negative values are included. It says that -fshort-enums is the default for some ABIs, but there is no indication that signed enums are the default on some ABIs or platforms or other circumstances. If that is accurate, then it would seemingly be okay to use %u for enums in most cases (unless they are signed by inclusion of a negative value) without worries about platform differences.
[Bug inline-asm/97708] Inline asm does not use the local register asm specified with register ... asm() as input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
--- Comment #30 from Alexander Monakov ---
Asm operand binding should work by looking at bound lvalue: "c"(a) binds an
lvalue so if 'a' is a register var the compiler must remember its associated
register; "c"(a+0) binds an rvalue, so what kind of variable 'a' is is
irrelevant.
The way it should work internally is at gimplification time the compiler should
produce an additional asm statement argument that stores the associated
register names for each operand. For example. for
register int a asm("%eax");
asm("" : "r"(a+0), "r"(a), "r"(0));
gcc could internally produce a string ",%eax," signifying that operand 1 is
bound to %eax and operands 0 and 2 are not bound to any particular register.
Then all passes up to IRA don't need to give any particular care for asm
operands, and IRA can use the string to place operands in appropriate registers
(and diagnose a mismatch).
This is also the only proper way to fix PR 87984 as far as I can tell.
[Bug tree-optimization/97623] [9/10/11 Regression] Extremely slow O2 compile (>>O(n^2))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97623 Martin Liška changed: What|Removed |Added Keywords|needs-bisection | --- Comment #14 from Martin Liška --- With -O2 -fno-code-hoisting it's fixed since r10-300-gaae6da83564549a6.
[Bug gcov-profile/97594] [11 Regression] new test case gcc.dg/tree-prof/pr97461.c execution failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97594 --- Comment #4 from Martin Liška --- Thank you Kewen, the patch works! The analysis is correct, what a stupid mistake from my side :P.
[Bug c++/97675] GCC does not allow turning off the warning for exceptions being caught by an earlier handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97675 --- Comment #3 from Louis Dionne --- Thanks a lot!
[Bug fortran/97652] [11 Regression] New gfortran.dg/pdt_14.f03 failure after g:617695cdc2b3d950f1e4deb5ea85d5cc302943f4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97652 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #16 from Richard Biener --- Fixed.
[Bug tree-optimization/97623] [9/10/11 Regression] Extremely slow O2 compile (>>O(n^2))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97623 Richard Biener changed: What|Removed |Added Keywords||needs-bisection --- Comment #13 from Richard Biener --- OK, on that testcase the good news is that GCC 10 is much better than GCC 9 resulting in -O2 -fno-code-hoisting tree PRE : 2.25 ( 50%) 0.05 ( 20%) 2.32 ( 49%) 31794 kB ( 20%) TOTAL : 4.47 0.25 4.72 161356 kB compared to GCC 9 where I can indeed reproduce tree PRE : 37.81 ( 95%) 0.04 ( 13%) 37.96 ( 95%) 32604 kB ( 20%) TOTAL : 39.63 0.30 39.99 161584 kB suspicious are diffs in insertions and insert iterations: Insertions: 1258 insert iterations == 3: 1 Eliminated: 1553 vs bad: Insertions: 8616 insert iterations == 128: 1 Eliminated: 8955 I wonder what triggered this change ... On patched trunk we're in the same ballpark as GCC 10 but without requiring -fno-code-hoisting. The testcase is still an interesting one for PRE (50% of the compile spent there is a bit much, even if just 2 seconds).
[Bug tree-optimization/70547] Optimize multiplication of booleans to bit_and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70547 Gabriel Ravier changed: What|Removed |Added CC||gabravier at gmail dot com --- Comment #6 from Gabriel Ravier --- Looks like it is now indeed optimized to a boolean and, at least on the latest trunk I could test...
[Bug tree-optimization/97623] [9/10/11 Regression] Extremely slow O2 compile (>>O(n^2))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97623 --- Comment #12 from Wilson Snyder --- Created attachment 49515 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49515=edit Larger testcase Attached is the larger testcase. time g++ -O2 -c -o Vtb_top__3_ii.o Vtb_top__3_ii.cpp user1m38.456s
[Bug c++/97742] endless loop with code reduced by creduce/cvise
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97742 Martin Liška changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #2 from Martin Liška --- Started with r10-3735-gcb57504a55015891.
[Bug c++/97742] endless loop with code reduced by creduce/cvise
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97742
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2020-11-06
--- Comment #1 from Martin Liška ---
Reduced to:
$ cat search_collection_test.ii
template < = requires {
[Bug middle-end/97743] Failure to optimize boolean multiplication to select
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97743 --- Comment #5 from Andrew Pinski --- (In reply to Andrew Pinski from comment #4) > What about: > (-B)&743 > Is that faster? Never mind I see it was not :)
[Bug middle-end/97743] Failure to optimize boolean multiplication to select
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97743 --- Comment #4 from Andrew Pinski --- What about: (-B)&743 Is that faster?
[Bug tree-optimization/97706] [11 Regression] ICE with LTO at -O3: verify_gimple failed (incompatible types in 'PHI' argument 0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97706 --- Comment #9 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:7307d8e10727aea8069c0e47e64a7a9b8588a22e commit r11-4776-g7307d8e10727aea8069c0e47e64a7a9b8588a22e Author: Richard Biener Date: Fri Nov 6 11:11:42 2020 +0100 tree-optimization/97706 - part one, refactor vect_determine_mask_precision This computes vect_determine_mask_precision in a RPO forward walk rather than in a backward walk and using a worklist. It will make fixing PR97706 easier but for bisecting I wanted it to be separate. 2020-11-06 Richard Biener PR tree-optimization/97706 * tree-vect-patterns.c (vect_determine_mask_precision): Remove worklist operation. (vect_determine_stmt_precisions): Do not call vect_determine_mask_precision here. (vect_determine_precisions): Compute mask precision in a forward walk.
[Bug middle-end/97743] Failure to optimize boolean multiplication to select
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97743 --- Comment #3 from Richard Biener --- imull on core & zen is 3-4 cycles latency (no idea if they special-case 0 or 1 values somehow, guess not).
[Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #19 from Levy ---
Also tested code without int extend, just zero-extend with unsignedp set to 1,
Still seg fault.
if (GET_MODE_CLASS (mode) == MODE_INT
&& GET_MODE_SIZE (mode) < UNITS_PER_WORD
&& can_create_pseudo_p()
&& MEM_P (src))
{
rtx temp_reg = force_reg (word_mode, convert_to_mode (word_mode, src, 1));
riscv_emit_move(dest, temp_reg);
return true;
}
[Bug middle-end/97743] Failure to optimize boolean multiplication to select
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97743 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Benchmarking shows at least on i9-7960X the multiplications to be faster - 0m0.493s for multiplication, 0m0.737s for ? 743 : 0 for 1 billion iterations in a tight loop storing the result into memory.
[Bug middle-end/97743] Failure to optimize boolean multiplication to select
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97743 Richard Biener changed: What|Removed |Added Last reconfirmed||2020-11-06 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Component|tree-optimization |middle-end Target||x86_64-*-* --- Comment #1 from Richard Biener --- But is it really faster? movzbl %dil, %eax imull $743, %eax, %eax vs. negb%dil sbbl%eax, %eax andl$743, %eax clang9 produces testl %edi, %edi movl$743, %eax # imm = 0x2E7 cmovel %edi, %eax more like a middle-end/RTL expansion transform, target dependent.
[Bug tree-optimization/97743] New: Failure to optimize boolean multiplication to select
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97743
Bug ID: 97743
Summary: Failure to optimize boolean multiplication to select
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
int f(bool b)
{
return b * 743;
}
This can be optimized to `return b ? 743 : 0;`. This optimization is done by
LLVM, but not GCC.
[Bug tree-optimization/97741] [11 Regression] ICE: verify_gimple failed with "-Os -fno-toplevel-reorder -fno-tree-ccp -fno-tree-fre" since r11-4724
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97741 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/97732] [11 Regression] ICE tree check: expected integer_cst, have addr_expr in get_len, at tree.h:6014 since r11-4646-gf53e9d40de721241
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97732 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Richard Biener --- Fixed.
[Bug tree-optimization/97741] [11 Regression] ICE: verify_gimple failed with "-Os -fno-toplevel-reorder -fno-tree-ccp -fno-tree-fre" since r11-4724
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97741 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |11.0 CC||jakub at gcc dot gnu.org Last reconfirmed||2020-11-06 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Summary|ICE: verify_gimple failed |[11 Regression] ICE: |with "-Os |verify_gimple failed with |-fno-toplevel-reorder |"-Os -fno-toplevel-reorder |-fno-tree-ccp |-fno-tree-ccp |-fno-tree-fre" |-fno-tree-fre" since ||r11-4724 --- Comment #1 from Jakub Jelinek --- Started with r11-4724-ge86fd6a17cdb26710d1f13c9a47a3878c76028f9
[Bug other/97742] New: endless loop with code reduced by creduce/cvise
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97742 Bug ID: 97742 Summary: endless loop with code reduced by creduce/cvise Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: doko at debian dot org Target Milestone: --- Created attachment 49514 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49514=edit preprocessed source seen with the gcc-10 branch, seen while reducing via cvise/creduce $ g++ -c -std=c++17 -fconcepts -Wall search_collection_test.ii In file included from search_collection_test.ii:689: /usr/include/x86_64-linux-gnu/bits/libc-header-start.h:1148:13: error: expected primary-expression before ‘namespace’ /usr/include/x86_64-linux-gnu/bits/libc-header-start.h:1150:11: error: expected ‘;’ before ‘namespace’ /usr/include/x86_64-linux-gnu/bits/libc-header-start.h:1165:12: error: expected primary-expression before ‘namespace’ In file included from search_collection_test.ii:689: /usr/include/x86_64-linux-gnu/bits/libc-header-start.h:1187:11: error: expected ‘;’ before ‘namespace’ /usr/include/x86_64-linux-gnu/bits/libc-header-start.h:1191:13: error: expected primary-expression before ‘namespace’ [...] the compiler continues to emit error messages, doesn't terminate. compiler configured with --enable-checking=yes,extra,rtl
[Bug tree-optimization/97741] New: ICE: verify_gimple failed with "-Os -fno-toplevel-reorder -fno-tree-ccp -fno-tree-fre"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97741
Bug ID: 97741
Summary: ICE: verify_gimple failed with "-Os
-fno-toplevel-reorder -fno-tree-ccp -fno-tree-fre"
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: suochenyao at 163 dot com
Target Milestone: ---
***
OS and Platform:
CentOS Linux release 7.8.2003 (Core), x86_64 GNU/Linux
***
Program:
short a = 0;
long b = 0;
char c = 0;
void d() {
int e = 0;
f:
for (a = 6; a;)
c = e;
e = 0;
for (; e == 20; ++e)
for (; b;)
goto f;
}
int main() { return 0; }
***
gcc version:
$ gcc -v
Using built-in specs.
COLLECT_GCC=/home/suocy/bin/gcc-dev/bin/gcc
COLLECT_LTO_WRAPPER=/home/suocy/bin/gcc-dev/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/home/suocy/bin/gcc-dev
--disable-multilib --enable-languages=c,c++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20201106 (experimental) (GCC)
***
Command Lines:
$ gcc -Wall -Wextra -fno-strict-aliasing -fwrapv -Os -fno-toplevel-reorder
-fno-tree-ccp -fno-tree-fre a.c
a.c: In function ‘d’:
a.c:14:1: error: invalid types in nop conversion
14 | int main() { return 0; }
| ^~~
char
<<< error >>>
_1 = (char) _4;
during GIMPLE pass: evrp
a.c:14:1: internal compiler error: verify_gimple failed
0xe1a2ba verify_gimple_in_cfg(function*, bool)
../../gcc/tree-cfg.c:5461
0xcf7e17 execute_function_todo
../../gcc/passes.c:2039
0xcf887e execute_todo
../../gcc/passes.c:2093
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[Bug tree-optimization/97732] [11 Regression] ICE tree check: expected integer_cst, have addr_expr in get_len, at tree.h:6014 since r11-4646-gf53e9d40de721241
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97732 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:8ebedfcd86aa5e3fc902fb442ce12c9d440c23c8 commit r11-4773-g8ebedfcd86aa5e3fc902fb442ce12c9d440c23c8 Author: Richard Biener Date: Fri Nov 6 09:35:27 2020 +0100 tree-optimization/97732 - fix init of SLP induction vectorization This PR exposes two issues - one that the vector builder treats as eligible for VECTOR_CST elements and one that SLP induction vectorization forgets to convert init elements to the vector component type which makes a difference for pointer vs. integer. 2020-11-06 Richard Biener PR tree-optimization/97732 * tree-vect-loop.c (vectorizable_induction): Convert the init elements to the vector component type. * gimple-fold.c (gimple_build_vector): Use CONSTANT_CLASS_P rather than TREE_CONSTANT to determine if elements are eligible for VECTOR_CSTs. * gcc.dg/vect/bb-slp-pr97732.c: New testcase.
[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504 --- Comment #32 from Martin Liška --- (In reply to Eric Botcazou from comment #31) > > Unfortunately, it still fails. > > OK, can you try the new one? This one works, thanks for it.
[Bug tree-optimization/97733] [11 Regression] internal compiler error: in operator[], at vec.h:880 with "-O1 -fno-toplevel-reorder -fno-tree-bit-ccp -fno-tree-dce -fno-tree-dominator-opts -fno-tree-sc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97733 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Richard Biener --- Fixed.
[Bug tree-optimization/97623] [9/10/11 Regression] Extremely slow O2 compile (>>O(n^2))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97623 --- Comment #11 from rguenther at suse dot de --- On Fri, 6 Nov 2020, wsnyder at wsnyder dot org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97623 > > --- Comment #10 from Wilson Snyder --- > Running -O2 -fno-code-hoisting -ftime-report > > and I deleted the 0%/0%/0% lines: > > Time variable usr sys > wall > GGC > tree PRE : 36.36 ( 95%) 0.05 ( 19%) 36.34 ( > 94%) > 32604 kB ( 20%) OK, that's still all PRE :/ Can you share the full testcase somehow?
[Bug tree-optimization/97736] [9/10/11 Regression] switch codegen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97736 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Last reconfirmed||2020-11-06 Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Mine then.
[Bug tree-optimization/97737] [11 Regression] ICE at -Os and above: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.c:88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97737 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||10.2.0 Known to fail||11.0 CC||amacleod at redhat dot com, ||marxin at gcc dot gnu.org Ever confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed||2020-11-06 --- Comment #2 from Martin Liška --- Started with r11-4724-ge86fd6a17cdb2671.
[Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #18 from Levy ---
if (GET_MODE_CLASS (mode) == MODE_INT
&& GET_MODE_SIZE (mode) < UNITS_PER_WORD
&& can_create_pseudo_p()
&& MEM_P (src))
{
int extend = (LOAD_EXTEND_OP (mode) == ZERO_EXTEND);
rtx temp_reg = force_reg (word_mode, convert_to_mode (word_mode, src,
extend));
riscv_emit_move(dest, temp_reg);
return true;
}
tried to insert code at the beginning of riscv_legitimize_move() but seems
convert_to_mode() raised seg fault druing make
[Bug target/97734] GCC using branches when a conditional move would be better
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97734 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #2 from Alexander Monakov --- By the time RTL ce2 pass runs the RTL is suitable for if-conversion, but the pass rejects the transform (probably due to costs, not visible in dumps so impossible to tell without gdb'ing the compiler). Note that this cmov lengthens the loop-carried data dependency on 'i', so it's only beneficial on workloads where the control dependency it replaces corresponds to an unpredictable branch. And GCC has no way to know that. For a recent counter-example (cmov dramatically slowing down a loop with a trivially predictable branch) please see https://stackoverflow.com/a/64285902/4755075 At risk of needlessly repeating myself: I think what people doing such research really need is __builtin_branchless_select that is properly guaranteed to be branchless (selection statement on GIMPLE and branchless sequence on RTL). Otherwise they spend time tweaking their code to make cmov appear where they need it.
[Bug c++/90736] [9 Regression] Bogus error with alignas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90736 Jakub Jelinek changed: What|Removed |Added CC||stanislav.pikulik at lge dot com --- Comment #11 from Jakub Jelinek --- *** Bug 97739 has been marked as a duplicate of this bug. ***
[Bug c++/97739] alignas() fails to compile with const expression like std::max or std::min
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97739 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jakub Jelinek --- Dup of an already fixed bug. *** This bug has been marked as a duplicate of bug 90736 ***
[Bug c++/97740] New: Weird error message about accessing a private member of my own class inside of std::string_view inside of constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97740
Bug ID: 97740
Summary: Weird error message about accessing a private member
of my own class inside of std::string_view inside of
constexpr
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: markus.boeck02 at gmail dot com
Target Milestone: ---
Created attachment 49513
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49513=edit
Reproduction of the bug. Simply compile with -std=c++17
I want to apologize for the code you are about to see already. I am one of
those people who likes to constexpr and templates at times. In one of my recent
code that does some constexpr string parsing and validation I encountered a
very very weird error message:
/opt/compiler-explorer/gcc-10.2.0/include/c++/10.2.0/string_view: In
instantiation of
'cld::detail::CommandLine::parseOptions, {detail::INCLUDESbind0,
std::in_place_type >
>}>:: [with auto:7 = {const
std::pair,
std::in_place_type_t > >
>&}]':
/opt/compiler-explorer/gcc-10.2.0/include/c++/10.2.0/type_traits:2506:26:
required by substitution of 'template static
std::__result_of_success()((declval<_Args>)()...)),
std::__invoke_other> std::__result_of_other_impl::_S_test(int) [with _Fn =
cld::detail::CommandLine::parseOptions, {detail::INCLUDESbind0,
std::in_place_type >
>}>::; _Args = {const
std::pair,
std::in_place_type_t > >
>&}]'
/opt/compiler-explorer/gcc-10.2.0/include/c++/10.2.0/type_traits:2517:55:
required from 'struct std::__result_of_impl, {detail::INCLUDESbind0,
std::in_place_type >
>}>::, const
std::pair,
std::in_place_type_t > >
>&>'
/opt/compiler-explorer/gcc-10.2.0/include/c++/10.2.0/type_traits:138:12:
recursively required by substitution of 'template
struct std::__is_invocable_impl<_Result, _Ret, true, std::__void_t > [with _Result =
std::__invoke_result, {detail::INCLUDESbind0,
std::in_place_type >
>}>::, const
std::pair,
std::in_place_type_t > >
>&>; _Ret = void]'
/opt/compiler-explorer/gcc-10.2.0/include/c++/10.2.0/type_traits:138:12:
required from 'struct
std::__and_, {detail::INCLUDESbind0,
std::in_place_type >
>}>::, const
std::pair,
std::in_place_type_t > >
>&>, void, true, void>,
std::__call_is_nothrow, {detail::INCLUDESbind0,
std::in_place_type >
>}>::, const
std::pair,
std::in_place_type_t > >
>&>,
cld::detail::CommandLine::parseOptions, {detail::INCLUDESbind0,
std::in_place_type >
>}>::, const
std::pair,
std::in_place_type_t > >
>&> >'
/opt/compiler-explorer/gcc-10.2.0/include/c++/10.2.0/type_traits:2979:12:
required from 'struct
std::is_nothrow_invocable, {detail::INCLUDESbind0,
std::in_place_type >
>}>::, const
std::pair,
std::in_place_type_t > >
>&>'
/opt/compiler-explorer/gcc-10.2.0/include/c++/10.2.0/tuple:1715:37: required
from 'constexpr const bool std::__unpack_std_tuple struct std::is_nothrow_invocable,
cld::detail::CommandLine::parseOptions, {detail::INCLUDESbind0,
std::in_place_type >
>}>::, const
std::tuple, std::in_place_type_t > > > >&>'
/opt/compiler-explorer/gcc-10.2.0/include/c++/10.2.0/tuple:1730:14: required
from 'constexpr decltype(auto) std::apply(_Fn&&, _Tuple&&) [with _Fn =
cld::detail::CommandLine::parseOptions, {detail::INCLUDESbind0,
std::in_place_type >
>}>::; _Tuple = const
std::tuple, std::in_place_type_t > > > >&]'
:456:36: required from 'constexpr auto
cld::detail::CommandLine::parseOptions(std::string_view, cld::CLIMultiArg)
[with T = cld::detail::CommandLine::Pack; auto& ...args =
{detail::INCLUDESbind0, std::in_place_type > >}; std::string_view = std::basic_string_view]'
:502:62: required from here
/opt/compiler-explorer/gcc-10.2.0/include/c++/10.2.0/string_view:287:34: error:
'char cld::Constexpr::basic_fixed_string::m_data [7]' is private
within this context
287 | return basic_string_view{_M_str + __pos, __rlen};
| ~~~^~~
:18:5: note: declared private here
18 | T m_data[N] = {};
|
I tried to create a minimum reproducible from scratch but failed to so. Instead
I now used my code and tried to minimize that as much as possible which sadly
still amounts to 500 lines of code but does reproduce the issue. I have
attached the file.
To my knowledge the code is correct and clang and MSVC compile it without
issues. Changing m_data in basic_fixed_string from private to public makes the
build succeed. Every version of GCC 8 to trunk fail with the same error. GCC 7
instead has an internal compiler error.
Alternatively see this compiler explorer link: https://godbolt.org/z/snnfo7
[Bug c++/97739] New: alignas() fails to compile with const expression like std::max or std::min
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97739
Bug ID: 97739
Summary: alignas() fails to compile with const expression like
std::max or std::min
Product: gcc
Version: 8.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: stanislav.pikulik at lge dot com
Target Milestone: ---
#include
template
constexpr T foo(T arg) { return arg; }
template
constexpr auto bar(T arg1, T arg2) { return arg1>arg2 ? arg1 : arg2; }
int main()
{
alignas(foo(2)) char a1[3]; // ok
alignas(bar(1,2)) char a2[3];// ok
const size_t b3 = std::max(1,2);
alignas(b3) char a3[3]; // ok
constexpr size_t b4 = std::max(1,2);
alignas(b4) char a4[3]; // ok
alignas(std::max(1,2)) char a5[3]; // error: requested alignment is not an
integer constant
return 0;
}
[Bug tree-optimization/97733] [11 Regression] internal compiler error: in operator[], at vec.h:880 with "-O1 -fno-toplevel-reorder -fno-tree-bit-ccp -fno-tree-dce -fno-tree-dominator-opts -fno-tree-sc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97733 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:2210bf6dec4a9868c828af546890805cac353f84 commit r11-4767-g2210bf6dec4a9868c828af546890805cac353f84 Author: Richard Biener Date: Fri Nov 6 08:34:16 2020 +0100 tree-optimization/97733 - fix SLP of reductions with zero relevant This adds a missing check. 2020-11-06 Richard Biener PR tree-optimization/97733 * tree-vect-slp.c (vect_analyze_slp_instance): If less than two reductions were relevant or live do nothing.
[Bug middle-end/97738] Optimizing division by value & - value for HAKMEM 175
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97738 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Component|rtl-optimization|middle-end --- Comment #1 from Richard Biener --- OK, guess that we should see to replace x / y with y known to have exactly one bit set to x >> (ctz (y) + 1) note I'm quite sure this isn't faster for all power-of-two y. It's also not canonically simpler. In the end sth for instruction selection / RTL expansion I guess.
[Bug rtl-optimization/97738] New: Optimizing division by value & - value for HAKMEM 175
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97738
Bug ID: 97738
Summary: Optimizing division by value & - value for HAKMEM 175
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
A straightforward implementation of HAKMEM 175 (returning
the next number with the same number of bits) is
unsigned int
next_same_bit (unsigned int value)
{
unsigned int lowest_bit;
unsigned int left_bits;
unsigned int changed_bits;
unsigned int right_bits;
lowest_bit = value & - value;
left_bits = value + lowest_bit;
changed_bits = value ^ left_bits;
right_bits = (changed_bits / lowest_bit) >> 2;
return left_bits | right_bits;
}
In two's complement, this can be replaced by
unsigned int
next_s_bit (unsigned int value)
{
unsigned int lowest_bit;
unsigned int ctz;
unsigned int left_bits;
unsigned int changed_bits;
unsigned int right_bits;
ctz = __builtin_ctz (value);
lowest_bit = 1u << ctz;
left_bits = value + lowest_bit;
changed_bits = value ^ left_bits;
right_bits = changed_bits >> (ctz + 2);
return left_bits | right_bits;
}
to replace the expensive division by what is known to be a
power of two by a shift.
That transformation is counter-productive (and might be done
the other way) if there is no division by lowest_bit.
