[Bug target/97417] RISC-V Unnecessary andi instruction when loading volatile bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417 --- Comment #59 from jiawei --- Hi Kito, Okay, I will retest the benchmark on gem5. 发自我的小米手机在 "kito at gcc dot gnu.org" ，2020年12月25日 上午11:31写道： https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417 --- Comment #58 from Kito Cheng --- Hi jiawei: I would suggest you just using inst count rather than cycle or time for measuring benchmark if you using qemu, since qemu is functional simulator not cycle accurate neither nearly-cycle accurate simulator, so the performance number is coming from your native host (x86_64) cpu, and it also might sensitive on your host loading. or maybe you could try gem5 for that? Thanks your helping benchmark that :) -- You are receiving this mail because: You are on the CC list for the bug. 1. http://gnu.org
[Bug fortran/91648] [9/10/11 Regression] ICE in generate_finalization_wrapper, at fortran/class.c:2009
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91648 Thomas Koenig changed: What|Removed |Added Blocks||37336 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=92587 --- Comment #6 from Thomas Koenig --- (In reply to Ev Drikos from comment #5) > Hello, > > Is this PR still open once PR/92587 is done? ICE is gone. This is one of the effects of the fix for PR 92587 that I hoped for, that it would also fix other PRs as well. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336 [Bug 37336] [F03] Finish derived-type finalization
[Bug target/92658] x86 lacks vector extend / truncate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92658 --- Comment #22 from Uroš Bizjak --- (In reply to Hongtao.liu from comment #21) > Add define_code_attr like aarch64/iterators.md? > > -- > ;; Map rtl objects to optab names > (define_code_attr optab [(ashift "ashl") >(ashiftrt "ashr") >(lshiftrt "lshr") >(rotatert "rotr") >(sign_extend "extend") >(zero_extend "zero_extend") Yes. Please go ahead, the patch is preapproved.
[Bug rtl-optimization/97756] Inefficient handling of 128-bit arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97756 Thomas Koenig changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=98438 --- Comment #2 from Thomas Koenig --- Might be related to / dup of PR 98438.
[Bug rtl-optimization/48877] Inline asm for rdtsc generates silly code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48877 Ivan Sorokin changed: What|Removed |Added CC||vanyacpp at gmail dot com --- Comment #2 from Ivan Sorokin --- Modern GCC doesn't generate excessive moves for this example. It looks like the problem was fixed in 4.9.0: https://godbolt.org/z/MqE7sP . I think the bug can be closed now.
[Bug middle-end/56719] missed optimization: i > 0xffff || i*4 > 0xffff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56719 Ivan Sorokin changed: What|Removed |Added CC||vanyacpp at gmail dot com --- Comment #8 from Ivan Sorokin --- On the test code clang since 3.5 and before 9.0 does something very surprising. It optimizes (A > 0x || B > 0x) into (A | B) > 0x. I don't think this is what the reporter expected, but still is a potential optimization for GCC. See https://godbolt.org/z/WqPhbW
[Bug tree-optimization/47579] STL size() == 0 does unnecessary shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47579 Ivan Sorokin changed: What|Removed |Added CC||vanyacpp at gmail dot com --- Comment #3 from Ivan Sorokin --- Since 7.1 GCC doesn't produce any shifts on the test code as well as on the examples from comment #2. https://godbolt.org/z/f48EqP I think the bug can be closed now.
[Bug tree-optimization/98444] New: [10 Regression] compile error with -ftracer and -Werror=format-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98444 Bug ID: 98444 Summary: [10 Regression] compile error with -ftracer and -Werror=format-overflow Product: gcc Version: 10.2.1 URL: https://github.com/elogind/elogind/issues/189 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: drfiemost at email dot it Target Milestone: --- Created attachment 49843 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49843&action=edit Preprocessed source I get the following error compiling the attached code with gcc-10 (gcc version 10.2.1 20201205): $ gcc -O2 -ftracer -Werror=format-overflow -c pam_elogind.i ../src/login/pam_elogind.c: In function ‘export_legacy_dbus_address’: ../src/login/pam_elogind.c:315:13: error: ‘%s’ directive argument is null [-Werror=format-overflow=] cc1: some warnings being treated as errors According to upstream [1] the variable is asserted before calling the function so it will never be null. The code compiles fine with gcc-9 and even with gcc-10 when removing the -ftracer flag. I can't tell if it's a regression in gcc-10, just a false positive or what so I'm reporting it here. [1] https://github.com/elogind/elogind/issues/189
[Bug rtl-optimization/48877] Inline asm for rdtsc generates silly code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48877 Andy Lutomirski changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Andy Lutomirski --- (In reply to Ivan Sorokin from comment #2) > Modern GCC doesn't generate excessive moves for this example. It looks like > the problem was fixed in 4.9.0: https://godbolt.org/z/MqE7sP . > > I think the bug can be closed now. Indeed.
[Bug fortran/98445] New: Bogus error: derived type used as an actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98445 Bug ID: 98445 Summary: Bogus error: derived type used as an actual argument Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: townsend at astro dot wisc.edu Target Milestone: --- Created attachment 49844 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49844&action=edit Minimal working example I'm running into what I believe to be a bogus error, when passing a function that (via interface overloading) has the same name as a derived type. Attached is a MWE. When compiled, I get the error passed_procedure_bug.f90:30:11: 30 | call s(t) | 1 Error: Derived type 't' is used as an actual argument at (1) cheers, Rich
[Bug c++/98446] New: C++ modules test failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98446 Bug ID: 98446 Summary: C++ modules test failures Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: nathan at acm dot org Target Milestone: --- On a machine with 112 cores, "make check -j 112" generates FAIL: g++.dg/modules/alias-1_b.C -std=c++17 scan-lang-dump-times module "CMI is " 1 FAIL: g++.dg/modules/alias-1_b.C -std=c++17 (test for excess errors) FAIL: g++.dg/modules/alias-1_b.C -std=c++2a scan-lang-dump-times module "CMI is " 1 FAIL: g++.dg/modules/alias-1_b.C -std=c++2a (test for excess errors) FAIL: g++.dg/modules/alias-1_d.C module-cmi kevin (gcm.cache/kevin.gcm) FAIL: g++.dg/modules/alias-1_d.C -std=c++17 (test for excess errors) FAIL: g++.dg/modules/alias-1_d.C -std=c++2a (test for excess errors) FAIL: g++.dg/modules/alias-1_e.C -std=c++17 (test for excess errors) FAIL: g++.dg/modules/alias-1_e.C -std=c++2a (test for excess errors) FAIL: g++.dg/modules/alias-1_f.C -std=c++17 (test for excess errors) FAIL: g++.dg/modules/alias-1_f.C -std=c++2a (test for excess errors) FAIL: g++.dg/modules/alias-2_b.C -std=c++17 (test for excess errors) FAIL: g++.dg/modules/alias-2_b.C -std=c++2a (test for excess errors) FAIL: g++.dg/modules/cpp-6_c.C -std=c++17 (test for excess errors) FAIL: g++.dg/modules/cpp-6_c.C -std=c++2a (test for excess errors) FAIL: g++.dg/modules/dir-only-2_b.C -std=c++17 (test for excess errors) FAIL: g++.dg/modules/dir-only-2_b.C -std=c++2a (test for excess errors) In module imported at /export/gnu/import/git/sources/gcc/gcc/testsuite/g++.dg/modules/alias-1_b.C:5:1: /export/ssd/git/sources/gcc/gcc/testsuite/g++.dg/modules/alias-1_a.H: error: failed to read compiled module: No such file or directory /export/ssd/git/sources/gcc/gcc/testsuite/g++.dg/modules/alias-1_a.H: note: compiled module file is 'gcm.cache/./export/ssd/git/sources/gcc/gcc/testsuite/g++.dg/modules/alias-1_a.H.gcm' /export/ssd/git/sources/gcc/gcc/testsuite/g++.dg/modules/alias-1_a.H: note: imports must be built before being imported /export/ssd/git/sources/gcc/gcc/testsuite/g++.dg/modules/alias-1_a.H: fatal error: returning to the gate for a mechanical issue compilation terminated. compiler exited with status 1 FAIL: g++.dg/modules/alias-1_b.C -std=c++17 (test for excess errors) Does g++.dg/modules support "make -jN check"?
[Bug analyzer/98447] New: incorrect -Wanalyzer-shift-count-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98447
Bug ID: 98447
Summary: incorrect -Wanalyzer-shift-count-overflow warning
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
Consider the following code on a platform with a 64-bit unsigned long:
void f (unsigned long *p, int r, int i)
{
int b = 63, n = r % 16;
while (i >= 0)
{
if (n > b)
{
p[i--] = b + 1 >= 64 ? 0UL : 1UL << (b + 1);
b += 64;
}
b -= n;
}
}
The "1UL << (b + 1)" can be executed only if b + 1 < 64, so that the shift
count is always strictly less than 64.
But I get the following incorrect warning.
zira:~> gcc-snapshot -O2 -fanalyzer -c tst.c
tst.c: In function 'f':
tst.c:9:38: warning: shift by count ('64') >= precision of type ('64')
[-Wanalyzer-shift-count-overflow]
9 | p[i--] = b + 1 >= 64 ? 0UL : 1UL << (b + 1);
|~~^~~~
'f': events 1-5
|
|5 | while (i >= 0)
| | ~~^~~~
| ||
| |(1) following 'true' branch (when 'i >= 0')...
|6 | {
|7 | if (n > b)
| | ~
| | |
| | (2) ...to here
| | (3) following 'true' branch (when 'b < n')...
|8 | {
|9 | p[i--] = b + 1 >= 64 ? 0UL : 1UL << (b + 1);
| |~~
| | | |
| | | (4) ...to here
| | (5) shift by count '64' here
|
with
gcc (Debian 20201224-1) 11.0.0 20201224 (experimental) [master revision
085fd2a46e5:21536a75ed4:168be2b3afddd41d4575ed55439231812bc3e7c9]
Note: This is a simplified testcase obtained from GNU MPFR's tests/random2.c
file, on which I got this issue.
[Bug fortran/92065] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 --- Comment #24 from Ev Drikos --- The hack outlined in comment #23 had raised an error with coarrays that turns to be an uncovered error: https://groups.google.com/g/comp.lang.fortran/c/E3RGBJZt4ag/m/MTXpOqPgAwAJ In short, the hack has no regressions with gcc-4.8.5 But I am neither a committer, nor I can create draft patches for the code on trunk at the moment. Yet, I'll be glad to go into further details if asked. Ev. Drikos
[Bug fortran/92065] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 --- Comment #25 from Gabor --- I don't want to distract from the effort, but the code I have is way simpler than the code that has the original issue. I have a single class(*) array argument repeated in a few functions, and no other special things. So it may be easier to debug. It certainly looks like that having multiple functions with these types of arguments in the same module causes the issue. My example starts to work if the 4 functions are split into two modules separately. Which is the work-around I ended up doing (well, I had many more functions, but still getting them into two groups in two modules worked). Gabor
