[Bug c/95429] Wrong code generated for -Os with target m68k on Ubuntu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95429 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andreas Schwab --- m68k-linux does not support -m68000, it hardcodes -mno-strict-align. You need to configure for m68k-elf.
[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95348 --- Comment #16 from Martin Liška --- > For our application, all processes generating profiling feedback data to a > single directory seems is not a choice. Why is it problem? You need to provide reasoning for that. > We chose -fprofile-dir=%p and then use gcov-merge to merge them. Sure, that's possible but you pay with a lot of disk space needed. Btw. how long does it take to merge all the collected data with gcov-tool?
[Bug c++/95241] [10 Regression] internal compiler error: tree check: expected integer_cst, have range_expr in to_wide, at tree.h:5900
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95241 Mateusz Tabaka changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #6 from Mateusz Tabaka --- Verified.
[Bug target/95435] New: bad builtin memcpy performance with znver1/znver2 and 32bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95435 Bug ID: 95435 Summary: bad builtin memcpy performance with znver1/znver2 and 32bit Product: gcc Version: 10.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jan at jki dot io Target Milestone: --- Created attachment 48641 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48641&action=edit gcc -g -m32 -march=znver2 -O1 -s testmem_modified.c -o tm32 Hi, I have found a regression with znver2 and 32bit compiles regarding builtin memcpy. Test program is this one: https://github.com/level1wendell/memcpy_sse results: gcc -g -m32 -march=znver2 -O1 -s testmem_modified.c -o tm32 32 MB = 2.462717 ms gcc -g -m32 -march=skylake -O1 -s testmem_modified.c -o tm32 32 MB = 1.135762 ms gcc -fno-builtin-memcpy -g -m32 -march=znver2 -O1 -s testmem_modified.c -o tm32 32 MB = 1.138656 ms I have attached the generated assembler code for the first 2 cases.
[Bug target/95435] bad builtin memcpy performance with znver1/znver2 and 32bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95435 --- Comment #1 from Jan --- Created attachment 48642 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48642&action=edit gcc -g -m32 -march=skylake -O1 -s testmem_modified.c -o tm32
[Bug target/95435] bad builtin memcpy performance with znver1/znver2 and 32bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95435 --- Comment #2 from Jan --- Created attachment 48643 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48643&action=edit source code
[Bug target/95435] bad builtin memcpy performance with znver1/znver2 and 32bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95435 Marc Glisse changed: What|Removed |Added Target||x86-*-* --- Comment #3 from Marc Glisse --- "regression" means that a new version of gcc is working worse than an older one, can you mention which older version you are comparing to and what results you were getting with it?
[Bug target/95435] bad builtin memcpy performance with znver1/znver2 and 32bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95435 --- Comment #4 from Jan --- Sorry bad wording on my site. I meant the code is getting slower with znver2.
[Bug target/95436] New: [11 Regression] ICE in store_expr, at expr.c:5845 since r11-711-g43a4fc095e30188392cc42299c4081297e321104
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95436
Bug ID: 95436
Summary: [11 Regression] ICE in store_expr, at expr.c:5845
since
r11-711-g43a4fc095e30188392cc42299c4081297e321104
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux-gnu
Target: aarch64-linux-gnu
Since the revision I see:
$ ./xgcc -B.
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr68529-3.c
-fconserve-stack -mstrict-align
during RTL pass: expand
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr68529-3.c: In
function ‘foo1’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr68529-3.c:7:8:
internal compiler error: in store_expr, at expr.c:5845
7 | char c[1] = {};
|^
0xd33d19 store_expr(tree_node*, rtx_def*, int, bool, bool)
/home/marxin/Programming/gcc/gcc/expr.c:5845
0xd39fcb store_field
/home/marxin/Programming/gcc/gcc/expr.c:7256
0xd3147f expand_assignment(tree_node*, tree_node*, bool)
/home/marxin/Programming/gcc/gcc/expr.c:5374
0xbb4bd4 expand_gimple_stmt_1
/home/marxin/Programming/gcc/gcc/cfgexpand.c:3749
0xbb4fcd expand_gimple_stmt
/home/marxin/Programming/gcc/gcc/cfgexpand.c:3847
0xbbd25a expand_gimple_basic_block
/home/marxin/Programming/gcc/gcc/cfgexpand.c:5887
0xbbf120 execute
/home/marxin/Programming/gcc/gcc/cfgexpand.c:6571
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug target/95436] [11 Regression] ICE in store_expr, at expr.c:5845 since r11-711-g43a4fc095e30188392cc42299c4081297e321104
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95436 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2020-05-30
[Bug target/95436] [11 Regression] ICE in store_expr, at expr.c:5845 since r11-711-g43a4fc095e30188392cc42299c4081297e321104
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95436 --- Comment #1 from Jakub Jelinek --- https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546851.html
[Bug middle-end/92455] Unnecessary memory read in a loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92455 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #7 from Martin Liška --- Created attachment 48644 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48644&action=edit Complete LNT results There are complete LNT results, nothing has improved rapidly.
[Bug target/95151] [9/10/11 Regression] Add cmpmemM pattern for -minline-all-stringops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95151
--- Comment #2 from H.J. Lu ---
Initial attempt failed on
[hjl@gnu-cfl-2 pr95151]$ cat saved.c
#include
#include
#include
#include
unsigned char *buf1, *buf2;
int ret;
size_t page_size;
static void
do_one_test (char *dst, char *src, const char *orig_src, size_t len)
{
memcpy (src, orig_src, len);
memmove (dst, src, len);
if (memcmp (dst, orig_src, len) != 0)
{
ret = 1;
return;
}
}
void
__attribute__ ((noclone, noinline))
do_test (char *s1, char *s2, int n, size_t len)
{
int i;
for (i = 0; i < n; i++)
do_one_test (s2, s2, s1, len);
}
int
main (void)
{
page_size = 2 * getpagesize ();
buf1 = mmap (0, (1 + 1) * page_size, PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANON, -1, 0);
if (buf1 == MAP_FAILED)
return -1;
if (mprotect (buf1 + 1 * page_size, page_size, PROT_NONE))
return -1;
buf2 = mmap (0, 2 * page_size, PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANON, -1, 0);
if (buf2 == MAP_FAILED)
return -1;
if (mprotect (buf2 + page_size, page_size, PROT_NONE))
return -1;
memset (buf1, 0xa5, 1 * page_size);
memset (buf2, 0x5a, page_size);
char *s1 = (char *) buf1;
char *s2 = (char *) buf2;
size_t len;
size_t i, j;
len = 1 << 2;
for (i = 0, j = 1; i < len; i++, j += 23)
s1[i] = j;
do_test (s1, s2, 10, 1 << 2);
len = 1 << 4;
for (i = 0, j = 1; i < len; i++, j += 23)
s1[i] = j;
do_test (s1, s2, 10, 1 << 4);
return ret;
}
[hjl@gnu-cfl-2 pr95151]$ make saved
/export/build/gnu/tools-build/gcc-gitlab-release-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-gitlab-release-debug/build-x86_64-linux/gcc/
-O2 -minline-all-stringopssaved.c -o saved
[hjl@gnu-cfl-2 pr95151]$ ./saved
Segmentation fault (core dumped)
[hjl@gnu-cfl-2 pr95151]$
[Bug debug/95437] New: DW_TAG_typedef for template alias missing template type parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95437
Bug ID: 95437
Summary: DW_TAG_typedef for template alias missing template
type parameters
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: palves at redhat dot com
Target Milestone: ---
Currently GCC represents instantiations of alias templates using DW_TAG_typedef
instead of DW_TAG_template_alias.
And, while Clang does the same (at least 5.0.2 does), Clang includes the
template parameters in the typedef name, while GCC leaves the template
parameters out. This causes problems in GDB.
In more detail, with the following program:
~~~
template struct Templ2 { static void method () {} };
template using AliasTempl = Templ2;
typedef unsigned int UInt;
AliasTempl aliastmpl1;
AliasTempl aliastmpl2;
AliasTempl aliastmpl3;
int main () { return 0; }
~~~
If compiled with Clang (I have 5.0.2 handy), we get:
<1><2a>: Abbrev Number: 2 (DW_TAG_variable)
<2b> DW_AT_name: (indirect string, offset: 0xba): aliastmpl1
<2f> DW_AT_type: <0x3f>
<1><3f>: Abbrev Number: 3 (DW_TAG_typedef)
<40> DW_AT_type: <0x4a>
<44> DW_AT_name: (indirect string, offset: 0xe0): AliasTempl
<1><4a>: Abbrev Number: 4 (DW_TAG_structure_type)
<4b> DW_AT_name: (indirect string, offset: 0xce): Templ2
<1><73>: Abbrev Number: 2 (DW_TAG_variable)
<74> DW_AT_name: (indirect string, offset: 0xf0): aliastmpl2
<78> DW_AT_type: <0x88>
...
<1><88>: Abbrev Number: 3 (DW_TAG_typedef)
<89> DW_AT_type: <0x93>
<8d> DW_AT_name: (indirect string, offset: 0x117):
AliasTempl
<1><93>: Abbrev Number: 4 (DW_TAG_structure_type)
<94> DW_AT_name: (indirect string, offset: 0x104): Templ2
<1>: Abbrev Number: 2 (DW_TAG_variable)
DW_AT_name: (indirect string, offset: 0x128): aliastmpl3
DW_AT_type: <0xca>
(DW_OP_addr: 60101f)
<1>: Abbrev Number: 3 (DW_TAG_typedef)
DW_AT_type: <0xd5>
DW_AT_name: (indirect string, offset: 0x15b):
AliasTempl
<1>: Abbrev Number: 4 (DW_TAG_structure_type)
DW_AT_name: (indirect string, offset: 0x140): Templ2
So when debugging the Clang-built binary, we get:
(gdb) whatis aliastmpl1
type = AliasTempl
(gdb) whatis aliastmpl2
type = AliasTempl
(gdb) whatis aliastmpl3
type = AliasTempl
(gdb) ptype aliastmpl1
type = struct Templ2 [with T = char, U = int] {
}
(gdb) ptype aliastmpl2
type = struct Templ2 [with T = char, U = long] {
}
(gdb) ptype aliastmpl3
type = struct Templ2 [with T = char, U = unsigned int] {
}
(gdb)
However, with GCC-built binaries we get three different typedefs with the same
name:
<1><34>: Abbrev Number: 3 (DW_TAG_structure_type)
<35> DW_AT_name: (indirect string, offset: 0x10a): Templ2
<1><50>: Abbrev Number: 5 (DW_TAG_typedef)
<51> DW_AT_name: (indirect string, offset: 0x23): AliasTempl
<58> DW_AT_type: <0x34>
<1><5c>: Abbrev Number: 6 (DW_TAG_variable)
<5d> DW_AT_name: (indirect string, offset: 0x17b): aliastmpl1
<64> DW_AT_type: <0x50>
<1><72>: Abbrev Number: 3 (DW_TAG_structure_type)
<73> DW_AT_name: (indirect string, offset: 0x11c): Templ2
<1><8e>: Abbrev Number: 5 (DW_TAG_typedef)
<8f> DW_AT_name: (indirect string, offset: 0x23): AliasTempl
<96> DW_AT_type: <0x72>
<1><9a>: Abbrev Number: 6 (DW_TAG_variable)
<9b> DW_AT_name: (indirect string, offset: 0x0): aliastmpl2
DW_AT_type: <0x8e>
<1>: Abbrev Number: 3 (DW_TAG_structure_type)
DW_AT_name: (indirect string, offset: 0xef): Templ2
<1>: Abbrev Number: 5 (DW_TAG_typedef)
DW_AT_name: (indirect string, offset: 0x23): AliasTempl
DW_AT_type: <0xb0>
<1>: Abbrev Number: 6 (DW_TAG_variable)
DW_AT_name: (indirect string, offset: 0x18): aliastmpl3
DW_AT_type: <0xcc>
I.e., all three typedefs are named "AliasTempl".
This results in this with GDB:
(gdb) whatis aliastmpl1
type = AliasTempl
(gdb) whatis aliastmpl2
type = AliasTempl
(gdb) whatis aliastmpl3
type = AliasTempl
(gdb) ptype aliastmpl1
type = struct Templ2 [with T = char, U = int] {
}
(gdb) ptype aliastmpl2
type = struct Templ2 [with T = char, U = long] {
}
(gdb) ptype aliastmpl3
type = struct Templ2 [with T = char, U = unsigned int] {
}
I.e., the "whatis" command shows the same name three times, even though these
are different types.
And of course, the user is able to query info about the bogus "AliasTempl"
typedef:
(gdb) whatis AliasTempl
type = Templ2
This "missing template parameters info" issue also prevents setting breakpoints
using the alias template with GCC-built bi
[Bug jit/95438] New: Cannot cast pointer to int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95438 Bug ID: 95438 Summary: Cannot cast pointer to int Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: bouanto at zoho dot com Target Milestone: --- Hi. It seems there's no way to cast a pointer to int. When I try a cast, I get: libgccjit.so: error: gcc_jit_context_new_cast: cannot cast param from type: unsigned char * * to type: unsigned long long Thanks to allow this.
[Bug target/95439] New: Incorrect zero count check in cmpstrnsi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95439 Bug ID: 95439 Summary: Incorrect zero count check in cmpstrnsi Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: hubicka at ucw dot cz, ubizjak at gmail dot com Target Milestone: --- Target: i386,x86-64 cmpstrnsi expander has emit_insn (gen_cmp_1 (Pmode, countreg, countreg)); emit_insn (gen_cmpstrnqi_1 (addr1, addr2, countreg, align, operands[1], operands[2])); to guard against zero count. But it checks equality, not zero.
[Bug jit/95438] Cannot cast pointer to int and vice versa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95438 --- Comment #1 from bouanto at zoho dot com --- The opposite does not work as well: libgccjit.so: error: gcc_jit_context_new_cast: cannot cast (long long)(unsigned long long)*&binopResult from type: long long to type: unsigned char * *
[Bug debug/95437] DW_TAG_typedef for template alias missing template type parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95437 --- Comment #1 from Pedro Alves --- > This "missing template parameters info" issue also prevents setting > breakpoints > using the alias template with GCC-built binaries. This GDB commit adds a testcase exercising this issue: https://sourceware.org/pipermail/gdb-patches/2020-May/169163.html It's in the gdb.linespec/cp-replace-typedefs-ns-template.exp testcase which can be run like this: $ make check TESTS="gdb.linespec/cp-replace-typedefs-ns-template.exp" It currently passes cleanly with Clang, and with two XFAILs with GCC.
[Bug c/95379] Don't warn about the universal zero initializer for a structure with the 'designated_init' attribute.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95379
--- Comment #14 from Luc Van Oostenryck ---
(In reply to Tom Tromey from comment #7)
> The feature was added specifically to mimic what sparse does.
> If sparse changes, I think changing gcc would be appropriate.
Sparse warnings issued when using '{ 0 }' and not '{ }' were not really
intentional, but simply a consequence of how 'usual' initializers are
processed.
I think that '{ 0 }' and '{ }' should behave the same, they're just 2 way to
write the universal zero initializer, and thus there is no reasons to issue
theses warnings with '{ 0 }'.
I've now changed Sparse's default so that these warnings are not issued
anymore.
-- Luc
[Bug go/95389] Kubernetes build fails because of mangled PkgPath
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95389 --- Comment #3 from Ulrich Teichert --- BTW, I can reproduce the same strange reflect.Type.PkgPath issue on AMD64/Linux with gccgo 10.1.0
[Bug target/95435] bad builtin memcpy performance with znver1/znver2 and 32bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95435
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comment #5 from Alexander Monakov ---
Ugh. Stringop tuning for Ryzens is terribly anachronistic, all AMD processors
since K8 (!!) use the exact same tables, and 32-bit memset/memcpy don't use
libcall for large sizes:
static stringop_algs znver2_memcpy[2] = {
{libcall, {{6, loop, false}, {14, unrolled_loop, false},
{-1, rep_prefix_4_byte, false}}},
{libcall, {{16, loop, false}, {64, rep_prefix_4_byte, false},
{-1, libcall, false;
(first subarray is 32-bit tuning, the second is for 64-bit)
Using test_stringop microbenchmark from PR43052 it's easy to see that library
memset/memcpy are fastest on sizes 256 and above. Below that, the result from
the microbenchmark may be debatable, I think we should prefer the libcall
almost always except for tiniest sizes for I-cache locality reasons.
But anyway, current tuning is completely inappropriate.
[Bug c++/95440] New: [coroutines] ICE with static members in promise_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95440
Bug ID: 95440
Summary: [coroutines] ICE with static members in promise_type
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bruck.michael at googlemail dot com
Target Milestone: ---
https://gcc.godbolt.org/z/PoAYhX
#include
struct task
{
struct promise_type
{
auto get_return_object() const { return task{}; }
static constexpr std::suspend_never initial_suspend() { return
{}; }
/*static*/ constexpr std::suspend_never final_suspend() {
return {}; }
/*static*/ constexpr void return_void() {}
/*static*/ constexpr void unhandled_exception() {}
};
};
task
test_task()
{
co_await std::suspend_always{};
}
auto t = test_task();
int main() {}
[Bug c++/64794] GCC failed at virtual function with "override" trailing return type name, followed by override virt-specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64794 Atul Sharma changed: What|Removed |Added CC||atulsharma406 at gmail dot com --- Comment #1 from Atul Sharma --- Created attachment 48645 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48645&action=edit compilation failure log This file contains the compilation failure statements
[Bug c++/64794] GCC failed at virtual function with "override" trailing return type name, followed by override virt-specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64794
--- Comment #2 from Atul Sharma ---
Is there any update on the issue
I am facing this issue on the newer version of gcc(10.1.) as well
Added the details of compilation failure as attachement
I have been facing issue for the following mention code with the error
/*
main.cpp:11:17: error: two or more data types in declaration of 'type name'
11 | auto f() -> override override ;
*/
struct override { } ;
struct base
{
virtual auto f() -> override ;
} ;
struct derived : base
{
auto f() -> override override ;
} ;
int main()
{
return 0;
}
--
This should not have caused compilation failure since override specifier is not
a keyword and can be used to define a custom type
[Bug fortran/95090] ICE: identifier overflow: 129
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95090 --- Comment #13 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:bf5fbbbd8c9a3385c1083cc80683bdb0195b1ffc commit r11-742-gbf5fbbbd8c9a3385c1083cc80683bdb0195b1ffc Author: Harald Anlauf Date: Sat May 30 20:50:59 2020 +0200 PR fortran/95090 - ICE: identifier overflow Implement buffer overrun check for temporary that holds mangled names. 2020-05-30 Harald Anlauf gcc/fortran/ PR fortran/95090 * class.c (get_unique_type_string): Use buffer overrun check.
[Bug fortran/95373] [9/10/11 Regression] ICE in build_reference_type, at tree.c:7942
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95373 --- Comment #9 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:dd38c765a04d06c775134a135f68b18c3b7c9c78 commit r11-743-gdd38c765a04d06c775134a135f68b18c3b7c9c78 Author: Harald Anlauf Date: Sat May 30 20:59:41 2020 +0200 PR fortran/95373 - ICE in build_reference_type, at tree.c:7942 The use of KIND, LEN, RE, and IM inquiry references for applicable intrinsic types is valid only for suffienctly new Fortran standards. Add appropriate checks in the appropriate place. 2020-05-30 Harald Anlauf gcc/fortran/ PR fortran/95373 * primary.c (is_inquiry_ref): Move validity check of inquiry references against selected Fortran standard from here... (gfc_match_varspec) ...to here. gcc/testsuite/ PR fortran/95373 * gfortran.dg/pr95373_1.f90: Adjust error messages. * gfortran.dg/pr95373_2.f90: Adjust error message.
[Bug fortran/95373] [9/10/11 Regression] ICE in build_reference_type, at tree.c:7942
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95373 --- Comment #10 from anlauf at gcc dot gnu.org --- Master should be fixed now.
[Bug target/95441] New: Failure to reuse flag from float compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95441
Bug ID: 95441
Summary: Failure to reuse flag from float compare
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
int f(double x)
{
return (x < 0) - (x > 0);
}
With -Ofast, GCC outputs this :
f(double):
pxor xmm1, xmm1
xor eax, eax
comisd xmm1, xmm0
seta al
xor edx, edx
comisd xmm0, xmm1
seta dl
sub eax, edx
ret
LLVM outputs this :
f(double):
xorpd xmm1, xmm1
xor eax, eax
xor ecx, ecx
ucomisd xmm0, xmm1
setb al
seta cl
sub eax, ecx
ret
[Bug libfortran/95418] Static assert going off on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95418 anlauf at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Last reconfirmed||2020-05-30 --- Comment #1 from anlauf at gcc dot gnu.org --- (In reply to Markus Böck from comment #0) > Since commit "i386: Use generic division to generate INEXACT exception" > (d3a1459cd4f2d4997fb53e34ddef72e91a7855c1) libgfortran is not able to be > compiled with the target x86_64-w64-mingw32. This is due to a _Static_assert > going off in fpu-target.h. The exact error message is: > > In file included from ../../../libgfortran/runtime/fpu.c:29: > ./fpu-target.h:91:1: error: static assertion failed: > "GFC_FPE_STATE_BUFFER_SIZE is too small" >91 | _Static_assert (sizeof(struct fenv) <= (size_t) > GFC_FPE_STATE_BUFFER_SIZE, > | ^~ > > Reverting the above commit makes compilation succeed. Can you print sizeof(struct fenv)? On Linux, this is 32, the same as defined in gcc/fortran/libgfortran.h
[Bug middle-end/95442] New: LRA inserts a reload insn for REG_DEAD register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95442
Bug ID: 95442
Summary: LRA inserts a reload insn for REG_DEAD register
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: vmakarov at redhat dot com
Target Milestone: ---
match_reload has
if (find_reg_note (curr_insn, REG_UNUSED, out_rtx) == NULL_RTX)
{
start_sequence ();
lra_emit_move (out_rtx, copy_rtx (new_out_reg));
emit_insn (*after);
*after = get_insns ();
end_sequence ();
}
For
(insn 68 67 69 10 (parallel [
(set (reg:CC 17 flags)
(if_then_else:CC (ne (reg:DI 104 [ _1 ])
(const_int 0 [0]))
(compare:CC (mem:BLK (reg/v/f:DI 86 [ s2 ]) [0 MEM
[(void *)s2_5(D)]+0 A8])
(mem:BLK (reg/v/f:DI 85 [ s1 ]) [0 MEM
[(void *)s1_6(D)]+0 A8]))
(const_int 0 [0])))
(use (const_int 8 [0x8]))
(use (reg:CC 17 flags))
(clobber (reg/f:DI 102 [ s2 ]))
(clobber (reg/f:DI 103 [ s1 ]))
(clobber (reg:DI 104 [ _1 ]))
]) "foo.c":9:7 1011 {*cmpstrnqi_1}
(expr_list:REG_DEAD (reg:DI 104 [ _1 ])
(expr_list:REG_UNUSED (reg:DI 104 [ _1 ])
(expr_list:REG_UNUSED (reg/f:DI 103 [ s1 ])
(expr_list:REG_UNUSED (reg/f:DI 102 [ s2 ])
(expr_list:REG_EQUAL (if_then_else:CC (ne (reg:DI 82 [ _1
])
(const_int 0 [0]))
(compare:CC (mem:BLK (reg/v/f:DI 86 [ s2 ]) [0 MEM
[(void *)s2_5(D)]+0 A8])
(mem:BLK (reg/v/f:DI 85 [ s1 ]) [0 MEM
[(void *)s1_6(D)]+0 A8]))
(const_int 0 [0]))
(nil)))
(insn 69 68 70 10 (set (reg:QI 105)
(gtu:QI (reg:CC 17 flags)
(const_int 0 [0]))) "foo.c":9:7 732 {*setcc_qi}
(nil))
LRA inserts a reload insn for REG_DEAD (reg:DI 104 [ _1 ] after it. Should
it be
diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c
index bf6d4a2fd4b..570ee37e34d 100644
--- a/gcc/lra-constraints.c
+++ b/gcc/lra-constraints.c
@@ -1068,7 +1068,8 @@ match_reload (signed char out, signed char *ins, signed
char *outs,
return;
/* See a comment for the input operand above. */
narrow_reload_pseudo_class (out_rtx, goal_class);
- if (find_reg_note (curr_insn, REG_UNUSED, out_rtx) == NULL_RTX)
+ if (find_reg_note (curr_insn, REG_UNUSED, out_rtx) == NULL_RTX
+ && find_reg_note (curr_insn, REG_DEAD, out_rtx) == NULL_RTX)
{
start_sequence ();
lra_emit_move (out_rtx, copy_rtx (new_out_reg));
[Bug target/95443] New: cmpstrnqi patterns update string length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95443
Bug ID: 95443
Summary: cmpstrnqi patterns update string length
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: crazylht at gmail dot com, hubicka at ucw dot cz, ubizjak
at gmail dot com
Target Milestone: ---
Target: i386,x86-64
We have
countreg = ix86_zero_extend_to_Pmode (operands[3]);
/* %%% Iff we are testing strict equality, we can use known alignment
to good advantage. This may be possible with combine, particularly
once cc0 is dead. */
align = operands[4];
if (CONST_INT_P (operands[3]))
{
if (operands[3] == const0_rtx)
{
emit_move_insn (operands[0], const0_rtx);
DONE;
}
emit_insn (gen_cmpstrnqi_nz_1 (addr1, addr2, countreg, align,
operands[1], operands[2]));
}
else
{
emit_insn (gen_cmp_1 (Pmode, countreg, countreg));
emit_insn (gen_cmpstrnqi_1 (addr1, addr2, countreg, align,
operands[1], operands[2]));
}
cmpstrnqi patterns updates countreg to 0, wich can lead to wrong codes.
[Bug target/95444] New: Incorrect constraints on length operand in cmpstrnqi patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95444 Bug ID: 95444 Summary: Incorrect constraints on length operand in cmpstrnqi patterns Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: crazylht at gmail dot com, hubicka at ucw dot cz, ubizjak at gmail dot com Target Milestone: --- Target: i386,x864-64 cmpstrnqi patterns has (define_insn "*cmpstrnqi_1" [(set (reg:CC FLAGS_REG) (if_then_else:CC (ne (match_operand:P 6 "register_operand" "2") (const_int 0)) (compare:CC (mem:BLK (match_operand:P 4 "register_operand" "0")) (mem:BLK (match_operand:P 5 "register_operand" "1"))) (const_int 0))) (use (match_operand:SI 3 "immediate_operand" "i")) (use (reg:CC FLAGS_REG)) (clobber (match_operand:P 0 "register_operand" "=S")) (clobber (match_operand:P 1 "register_operand" "=D")) (clobber (match_operand:P 2 "register_operand" "=c"))] "=c" is incorrect since the CX register is used for both input and output.
[Bug c/95445] New: diagnose incompatible calls to functions declared without prototype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95445
Bug ID: 95445
Summary: diagnose incompatible calls to functions declared
without prototype
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
GCC silently accepts calls to built-in functions declared without a prototype
as long as the arguments match the expected types (based on the prototype
hardcoded into GCC), but issues warnings for calls where the arguments don't
match.
But GCC makes no attempt to make sure that in calls to other (i.e.,
non-built-in) functions declared without prototype provided arguments have the
same type across all the calls. Diagnosing mismatches as suggested in the
comments below would help detect bugs caused by their incompatibily.
This enhancement is different from pr92212 which is about calls to K&R
functions defined in the same translation unit.
$ cat x.c && gcc -O2 -S -Wall x.c
char* strchr ();
char* f0 (const char *s)
{
return strchr (s, 'x');// no warning (okay)
}
char* f1 (const char *s)
{
return strchr (s, "y");// warning (good)
}
void g ();
void h (void)
{
g (1); // (presumably) okay, f's type is 'void (int)'
g ("foo"); // should be diagnosed
g (1, "bar"); // ditto
}
x.c: In function ‘f1’:
x.c:10:21: warning: passing argument 2 of ‘strchr’ makes integer from pointer
without a cast [-Wint-conversion]
10 | return strchr (s, "y");// warning (good)
| ^~~
| |
| char *
x.c:1:7: note: expected ‘int’ but argument is of type ‘char *’
1 | char* strchr ();
| ^~
[Bug c/95445] diagnose incompatible calls to functions declared without prototype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95445 Martin Sebor changed: What|Removed |Added Blocks||87403 Severity|normal |enhancement See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=92212 Keywords||diagnostic Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 [Bug 87403] [Meta-bug] Issues that suggest a new warning
[Bug fortran/95446] New: False positive for optional arguments of elemental procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95446 Bug ID: 95446 Summary: False positive for optional arguments of elemental procedure Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: m.diehl at mpie dot de Target Milestone: --- to my understanding, the following code is valid program elemental_optional implicit none integer :: m(5), r(5) m = 1 r = outer() r = outer(m) contains function outer(o) result(l) integer, intent(in), optional :: o(:) integer :: u(5), l(5) l = inner(o,u) end function outer elemental function inner(a,b) result(x) integer, intent(in), optional :: a integer, intent(in) :: b integer :: x if(present(a)) then x = a*b else x = b endif end function inner end program elemental_optional however, when compiling with "-pedantic-errors", the following error message shows up: Error: ‘o’ at (1) is an array and OPTIONAL; IF IT IS MISSING, it cannot be the actual argument of an ELEMENTAL procedure unless there is a non-optional argument with the same rank (12.4.1.5) [-Werror=pedantic]
[Bug bootstrap/95402] freebsd make: "/usr/home/cqwrteur/gcc_build/Makefile" line 26: Missing dependency operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95402 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Andrew Pinski --- (In reply to fdlbxtqi from comment #4) > (In reply to Jakub Jelinek from comment #1) > > As mentioned in https://gcc.gnu.org/install/prerequisites.html one needs to > > use GNU make to build gcc, are you sure make is a GNU make? > > g++ -fno-PIE -c -g -O2 -DIN_GCC -fno-exceptions -fno-rtti > -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings > -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic > -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common > -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. > -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include > -I/usr/local/include -I/home/cqwrteur/gcc_build/./mpfr/src > -I/home/cqwrteur/gcc/mpfr/src -I/home/cqwrteur/gcc/mpc/src > -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd > -I../libdecnumber -I../../gcc/gcc/../libbacktrace > -I/home/cqwrteur/gcc_build/./isl/include -I/home/cqwrteur/gcc/isl/include > -I/usr/local/include -o final.o -MT final.o -MMD -MP -MF ./.deps/final.TPo > ../../gcc/gcc/final.c > g++: fatal error: Killed signal terminated program cc1plus > compilation terminated. > gmake[2]: *** [Makefile:1123: final.o] Error 1 > gmake[2]: *** Waiting for unfinished jobs > g++: fatal error: Killed signal terminated program cc1plus > compilation terminated. > gmake[2]: *** [Makefile:1123: expr.o] Error 1 > gmake[2]: Leaving directory '/usr/home/cqwrteur/gcc_build/gcc' > gmake[1]: *** [Makefile:4408: all-gcc] Error 2 > gmake[1]: Leaving directory '/usr/home/cqwrteur/gcc_build' > gmake: *** [Makefile:967: all] Error 2 > > well lol. Still have issues. Looks like you are running out of memory. >Really? LLVM also provides a make?? LOL. What a freaking joke. GNU make has been around for over 30 years now. I am sorry you are anti-GNU but don't bring those views here.
[Bug c++/95428] ABI breakage for "base object constructor" for final classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95428 --- Comment #1 from Andrew Pinski --- Can you provide a full testcase? >From the sound of it, this might be a LLVM bug. As mentioned you can't extend a final class which means base object constructor can't be called. If LLVM is producing a call, then it seems like an ABI bug there.
[Bug target/95447] New: cmpstrn peepholes are out of date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95447
Bug ID: 95447
Summary: cmpstrn peepholes are out of date
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: crazylht at gmail dot com, hubicka at ucw dot cz, ubizjak
at gmail dot com
Target Milestone: ---
Target: i386,x86-64
cmpstrn peepholes are out of date. i386.md has
;; Peephole optimizations to clean up after cmpstrn*. This should be
;; handled in combine, but it is not currently up to the task.
;; When used for their truth value, the cmpstrn* expanders generate
;; code like this:
;;
;; repz cmpsb
;; seta %al
;; setb %dl
;; cmpb %al, %dl
;; jcclabel
;;
;; The intermediate three instructions are unnecessary.
But GCC no longer generates such code sequence. Instead, we generate
[hjl@gnu-cfl-2 pr95151]$ cat s1.i
extern void bar (void);
void
func (char *d, unsigned int l)
{
if (__builtin_strncmp (d, "foo", l))
bar ();
}
[hjl@gnu-cfl-2 pr95151]$ gcc -O2 -minline-all-stringops -S s1.i
[hjl@gnu-cfl-2 pr95151]$ cat s1.s
.file "s1.i"
.text
.section.rodata.str1.1,"aMS",@progbits,1
.LC0:
.string "foo"
.text
.p2align 4
.globl func
.type func, @function
func:
.LFB0:
.cfi_startproc
cmpl$4, %esi
movl%esi, %ecx
movl$4, %eax
movq%rdi, %r8
cmova %rax, %rcx
movl$.LC0, %edi
movq%r8, %rsi
cmpq%rcx, %rcx
repz cmpsb
seta%al
sbbb$0, %al
testb %al, %al
jne .L4
ret
.p2align 4,,10
.p2align 3
.L4:
jmp bar
.cfi_endproc
.LFE0:
.size func, .-func
.ident "GCC: (GNU) 10.1.1 20200507 (Red Hat 10.1.1-1)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-2 pr95151]$
The cmpstrn peepholes never kick in.
[Bug c/95448] New: Missing optimization: pointer untag, re-tag should be no-op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95448
Bug ID: 95448
Summary: Missing optimization: pointer untag, re-tag should be
no-op
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dancol at dancol dot org
Target Milestone: ---
Consider the following code. make_vector2() ought to be equivalent to just
"return make_vector_val()", and under Clang (10.0), it is. But GCC generates
this code for make_vector2:
make_vector2:
sub rsp, 8
callmake_vector_val
add rsp, 8
and rax, -8
or rax, 1
ret
The assume() in the code ought to be sufficient for convincing GCC that it
doesn't need to munge the return value of make_vector_val(). Emacs uses
patterns like this one pretty frequently.
---
#include
#include
#include
#define assume(x) do { if(!(x)) __builtin_unreachable(); } while(0)
enum { tagbits = 3 };
#define TAG_MASK (((uintptr_t)(1)<
[Bug target/95439] Incorrect zero count check in cmpstrnsi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95439 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from H.J. Lu --- It doesn't matter since if count != 0, repz cmpsb will set FLAGS.
[Bug target/95151] [9/10/11 Regression] Add cmpmemM pattern for -minline-all-stringops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95151 Bug 95151 depends on bug 95439, which changed state. Bug 95439 Summary: Incorrect zero count check in cmpstrnsi https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95439 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
[Bug fortran/95446] False positive for optional arguments of elemental procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95446
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
Priority|P3 |P4
--- Comment #1 from kargl at gcc dot gnu.org ---
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 280157)
+++ gcc/fortran/resolve.c (working copy)
@@ -2275,11 +2275,27 @@ resolve_elemental_actual (gfc_expr *expr, gfc_code *c)
&& (set_by_optional || arg->expr->rank != rank)
&& !(isym && isym->id == GFC_ISYM_CONVERSION))
{
- gfc_warning (OPT_Wpedantic,
- "%qs at %L is an array and OPTIONAL; IF IT IS "
- "MISSING, it cannot be the actual argument of an "
- "ELEMENTAL procedure unless there is a non-optional "
- "argument with the same rank (12.4.1.5)",
+ bool t = false;
+ gfc_actual_arglist *a;
+
+ /* Scan the argument list for a non-optional argument with the
+same rank as arg. */
+ for (a = arg0; a; a = a->next)
+if (a != arg
+ && a->expr->rank == arg->expr->rank
+ && !a->expr->symtree->n.sym->attr.optional)
+ {
+ t = true;
+ break;
+ }
+
+ if (!t)
+ gfc_warning (OPT_Wpedantic,
+ "%qs at %L is an array with an OPTIONAL attribute; "
+ "If it is not present, than it cannot be the actual "
+ "argument of an ELEMENTAL procedure unless there is "
+ "a non-optional argument with the same rank "
+ "(Fortran 2018, 15.5.2.12)",
arg->expr->symtree->n.sym->name, &arg->expr->where);
}
}
[Bug target/95420] arm-wrs-vxworks7: xgcc: error: unrecognised -mcpu target: armv7-a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95420 --- Comment #1 from Iain Buclaw --- (In reply to Iain Buclaw from comment #0) > Configuring with --target=arm-wrs-vxworks7 --with-cpu=arm8 and the selftests > pass. > I was going to ignore that you need to set VSB_DIR in order for the selftests to pass, however I've stumbled across this comment in gcc/Makefile.in, which seems to suggest that perhaps it should "just work" without. # GCC's selftests. # Specify a dummy input file to placate the driver. # Specify -nostdinc to work around missing WIND_BASE environment variable # required for *-wrs-vxworks-* targets.
