[Bug fortran/97046] Bad interaction between lbound/ubound, allocatable arrays and bind(C) subroutine with dimension(..) parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97046 --- Comment #5 from Igor Gayday --- I'd like to add that Gilles Gouaillardet is the author of the reproducer in my original post.
[Bug c++/97055] New: Copy and move constructors shadowed by templatized constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97055
Bug ID: 97055
Summary: Copy and move constructors shadowed by templatized
constructor
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: amir.ahmed.ansari at outlook dot com
Target Milestone: ---
Created attachment 49219
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49219=edit
Failing program
The attached simple program fails to compile on GCC 10.2. It compiles on both
clang 10.0.1 and MSVC 19.24. The error produced on godbolt.org with no
compilation options given:
: In function 'int main()':
:20:43: error: use of deleted function 'C::C(const U&) [with U =
std::vector]'
20 | auto v2 = std::vector{std::move(v1)};
| ^
:14:5: note: declared here
14 | C(const U&) = delete;
| ^
:21:32: error: use of deleted function 'C::C(const U&) [with U =
std::vector]'
21 | auto v3 = std::vector{v1};
|^
:14:5: note: declared here
14 | C(const U&) = delete;
| ^
Compiler returned: 1
[Bug target/97054] [r10-3559 Regression] Runtime segfault with attached test code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97054 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||richard.sandiford at arm dot com Ever confirmed|0 |1 Version|11.0|10.2.0 Last reconfirmed||2020-09-15 Target Milestone|--- |10.3
[Bug target/97054] New: [r10-3559 Regression] Runtime segfault with attached test code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97054 Bug ID: 97054 Summary: [r10-3559 Regression] Runtime segfault with attached test code Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: skpgkp2 at gmail dot com CC: crazylht at gmail dot com, hjl.tools at gmail dot com Target Milestone: --- Created attachment 49218 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49218=edit reproducer test case. Test case attached. How to reproduce: $g++ -fno-strict-aliasing -msse4.2 -mfpmath=sse -gdwarf-2 -Wall -Wwrite-strings -fPIC -Wformat-security -fstack-protector-strong -O2 -Wfatal-errors -Wformat -Werror -Wundef repro.cc && ./a.out Segmentation fault (core dumped) (gdb) run The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /local/skpandey/gccwork/toolwork/a.out Program received signal SIGSEGV, Segmentation fault. 0x004011b0 in p2_ep_REBIND_IPC () at repro.cc:55 55 cur_pro->pc_RIP.i64 = code_lin_to_log(cur_pro, int2linaddr(cur_pro, ipc)); (gdb) disass Dump of assembler code for function p2_ep_REBIND_IPC(): 0x00401180 <+0>: push %r15 0x00401182 <+2>: push %r12 0x00401184 <+4>: mov%rbp,%r12 0x00401187 <+7>: mov%r12,%rdi 0x0040118a <+10>:sub$0x18,%rsp 0x0040118e <+14>:mov$0x4040a0,%r15 0x00401195 <+21>:mov0x10(%rbp),%rbp 0x00401199 <+25>:mov(%r15),%rsi 0x0040119c <+28>:mov%rbp,0x8(%rsp) 0x004011a1 <+33>:mov%rsi,0x30(%r12) 0x004011a6 <+38>:mov%rsi,0x8(%r12) 0x004011ab <+43>:callq 0x401150 => 0x004011b0 <+48>:movq $0x0,0x10(%rbp) 0x004011b8 <+56>:mov%rbp,%rdi 0x004011bb <+59>:callq 0x401160 0x004011c0 <+64>:mov%rbp,%rdi 0x004011c3 <+67>:mov0x8(%rsp),%rbp 0x004011c8 <+72>:mov%rbp,%rsi 0x004011cb <+75>:callq 0x401170 0x004011d0 <+80>:addq $0x4,(%r15) 0x004011d4 <+84>:xor%edx,%edx 0x004011d6 <+86>:mov%rax,0x30(%r12) 0x004011db <+91>:subl $0x1,0x4(%rbp) 0x004011df <+95>:mov0x4(%rbp),%eax 0x004011e2 <+98>:test %eax,%eax 0x004011e4 <+100>: movsbl 0x0(%rbp),%eax 0x004011e8 <+104>: setle %dl 0x004011eb <+107>: or %eax,%edx 0x004011ed <+109>: jne0x4011f5 0x004011ef <+111>: mov(%r15),%rax 0x004011f2 <+114>: mov(%rax),%r13d 0x004011f5 <+117>: add$0x18,%rsp 0x004011f9 <+121>: xor%eax,%eax 0x004011fb <+123>: pop%r12 0x004011fd <+125>: pop%r15 0x004011ff <+127>: retq End of assembler dump. Configured with: ../../gcc/configure --prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r10-3559/usr --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --with-fpmath=sse --disable-libsanitizer --enable-languages=c,c++,fortran --enable-cet --without-isl --enable-libmpx --disable-bootstrap 1bcb4c4faa4bd6b1c917c75b100d618faf9e628c is the first bad commit commit 1bcb4c4faa4bd6b1c917c75b100d618faf9e628c Author: Richard Sandiford Date: Wed Oct 2 07:37:10 2019 + [LRA] Don't make eliminable registers live (PR91957) One effect of https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00802.html was to strengthen the sanity check in lra_assigns so that it checks whether reg_renumber is consistent with the whole conflict set. This duly tripped on csky for a pseudo that had been allocated to the eliminated frame pointer. (csky doesn't have a separate hard frame pointer.) lra-lives uses: /* Set of hard regs (except eliminable ones) currently live. */ static HARD_REG_SET hard_regs_live; to track the set of live directly-referenced hard registers, and it correctly implements the exclusion when setting up the initial set: hard_regs_live &= ~eliminable_regset; But later calls to make_hard_regno_live and make_hard_regno_dead would process eliminable registers like other registers, recording conflicts for them and potentially making them live. (Note that after r266086, make_hard_regno_dead adds conflicts for registers that are already marked dead.) I think this would have had the effect of pessimising targets without a separate hard frame pointer. 2019-10-02 Richard Sandiford gcc/ PR middle-end/91957 * lra-lives.c (make_hard_regno_dead): Don't record conflicts for
[Bug tree-optimization/94234] missed ccp folding for (addr + 8 * n) - (addr + 8 * (n - 1))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94234 --- Comment #4 from CVS Commits --- The master branch has been updated by Feng Xue : https://gcc.gnu.org/g:f9d2def016410a2095df6b399097b482f82064a5 commit r11-3199-gf9d2def016410a2095df6b399097b482f82064a5 Author: Feng Xue Date: Tue Sep 1 17:17:58 2020 +0800 tree-optimization/94234 - Fold plusminus_mult expr with multi-use operands 2020-09-03 Feng Xue gcc/ PR tree-optimization/94234 * genmatch.c (dt_simplify::gen_1): Emit check on final simplification result when "!" is specified on toplevel output expr. * match.pd ((A * C) +- (B * C) -> (A +- B) * C): Allow folding on expr with multi-use operands if final result is a simple gimple value. gcc/testsuite/ PR tree-optimization/94234 * gcc.dg/pr94234-2.c: New test.
[Bug c++/97053] New: an O3 codegen bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97053
Bug ID: 97053
Summary: an O3 codegen bug
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: cuzdav at gmail dot com
Target Milestone: ---
Created attachment 49217
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49217=edit
preprocessed code in case something changes after submitting
"Wrong" output codegen bug. Very sensitive, almost any code change prevents
the problem, including O2 or less, as well as running under ubsan or asan,
reordering variables, and in some cases changing the values involved (such as
setting p=0 instead of 1)
Copying a buffer of 8 bytes of data (null terminated) results in a 6-bytes (of
data) null terminated "string", losing 2 bytes from the end.
A variable "len" holds the strlen() of this string, reports 6, but some code
affected by optimizer seems to think it is a larger value.
Expected output:
runtime len=8
orig=ABCD
copy=ABCD
actual output:
runtime len=6
orig=ABCD
copy=ABCDXX
Even though above the actual output shows len=6 when printing "len", a separate
line of code is not present in the assembly (presumably optimized away under a
confused compile-time eval.)
if (len < 8)
printf("len < 8\n"); // but len == 6
Problem visible in 10.1 and 10.2 at -O2 and -O3, but not -O1 or less, nor in in
9.x or earlier.
CODE:
#include
#include
struct Data
{
short n;
char name[8 + 1];
int p;
char s;
int b;
};
int main(int argc, char** argv)
{
int p = 1;
char orig[9]{""};
std::memcpy(orig, "ABCD", 4);
Data data{};
data.n = 5u;
// this should copy ABCD but loses final 2 XX's
std::memcpy(data.name, orig, 8);
data.s = 'X';
data.b = p;
const size_t len = strlen(data.name);
if (len < 8)
printf("len < 8\n"); // does not print
std::printf("runtime len=%lu\n", len); // this, however, prints 6
std::printf("orig=%s\ncopy=%s\n", orig, data.name);
}
Live on godbolt: https://godbolt.org/z/v6xqh8
[Bug target/97035] csky-linux-gnuabiv2 won't build with binutils master branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97035 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=26608 --- Comment #1 from H.J. Lu --- Moved.
[Bug c++/97051] Evaluating is_constant_evaluated in requires clause fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97051 --- Comment #2 from Marek Polacek --- This compiles when __builtin_is_constant_evaluated is used instead.
[Bug c++/97051] Evaluating is_constant_evaluated in requires clause fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97051 Marek Polacek changed: What|Removed |Added Last reconfirmed||2020-09-15 Keywords||rejects-valid CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug c++/97052] Internal compiler error with substitution failure in template parameter list of concept declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97052 Marek Polacek changed: What|Removed |Added Last reconfirmed||2020-09-15 Status|UNCONFIRMED |NEW Keywords||ice-on-valid-code Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Confirmed.
[Bug c++/97052] New: Internal compiler error with substitution failure in template parameter list of concept declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97052
Bug ID: 97052
Summary: Internal compiler error with substitution failure in
template parameter list of concept declaration
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david at doublewise dot net
Target Milestone: ---
The following code
```
template
concept foo = true;
constexpr bool f(foo auto) {
return false;
}
constexpr bool f(int) {
return true;
}
static_assert(f(0));
```
fails to compile with
```
:4:18: internal compiler error: in dependent_type_p, at cp/pt.c:26440
4 | constexpr bool f(foo auto) {
| ^~~
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug target/97042] powerpc64 UINT_MAX constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042 --- Comment #9 from Alan Modra --- I think that splitter should disappear and rs6000_emit_set_long_const handle all special cases where you might want combinations of two logical instructions before handling the li;rldicl, li;rldicr or any other expansions with rotates.
[Bug c++/97051] New: Evaluating is_constant_evaluated in requires clause fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97051 Bug ID: 97051 Summary: Evaluating is_constant_evaluated in requires clause fails Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: david at doublewise dot net Target Milestone: --- The following program #include template requires((std::is_constant_evaluated(), true)) constexpr int a = 0; constexpr int b = a; when compiled with `g++ -std=c++20` fails with :9:19: error: use of invalid variable template 'a' 9 | constexpr int b = a; | ^~ :9:19: note: constraints not satisfied Compiler returned: 1 See it live: https://godbolt.org/z/fc5cWE
[Bug fortran/97046] Bad interaction between lbound/ubound, allocatable arrays and bind(C) subroutine with dimension(..) parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97046
--- Comment #4 from Gilles Gouaillardet
---
I crafted the reproducer based on a previous one that has already been merged,
and using a libc subroutine was not an issue back then.
https://gcc.gnu.org/git?p=gcc.git;a=blob;f=gcc/testsuite/gfortran.dg/ISO_Fortran_binding_14.f90;h=388c5438252d49342f6bd357850062697fafb7b4;hb=980f185ce3ba6d532530ce0f23bfb6e30320fd8a
But I get your point, and you can
SUBROUTINE dummyc(x0) BIND(C, name="dummyc")
and then in dummyc.c
#include "ISO_Fortran_binding.h"
void dummyc (CFI_cdesc_t * x){
}
This does not change the fact that the test fails with GNU compilers though.
[Bug target/97042] powerpc64 UINT_MAX constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042 --- Comment #8 from Segher Boessenkool --- (In reply to Alan Modra from comment #7) > and of course, li 0x is li -1 which sets all bits. Erm, yes. Duh. So that g:5d3ae76af13 splitter should not fire for numbers that fit in 32 bits but that have the high bit of both 16-bit halfs set.
[Bug fortran/97046] Bad interaction between lbound/ubound, allocatable arrays and bind(C) subroutine with dimension(..) parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97046
--- Comment #3 from Steve Kargl ---
On Mon, Sep 14, 2020 at 11:56:18PM +, gilles.gouaillardet at gmail dot com
wrote:
> This is the libc subroutine
>
> void sync(void);
>
> The point here is any subroutine (that will not cause a crash) can be used to
> evidence the issue.
>
Isn't there a mismatch in the number of
arguments provided by your Fortran code
and the parameters expected in sync(2)?
dummy (struct array15_unknown & restrict x0)
{
{
void * cfi.0;
x0->span = (integer(kind=4)) x0->dtype.elem_len;
x0->dtype.attribute = 2;
cfi.0 = 0B;
_gfortran_gfc_desc_to_cfi_desc (, (struct array15_unknown *) x0);
x0->dtype.attribute = 2;
dummyc (cfi.0);
_gfortran_cfi_desc_to_gfc_desc ((struct array15_unknown *) x0, );
__builtin_free (cfi.0);
}
}
dummyc(cfi.0) becomes sync(cfi.0).
Is this standard conform?
[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
--- Comment #26 from Segher Boessenkool ---
What Joseph says in c#25. Also, the documentation currently says
The @code{KIND} value matches the storage size in bytes, [...]
which will have to change, too (the standard does not require this,
it is merely a convention, and it prevent having two REAL types of
size 16, as we need).
[Bug fortran/97046] Bad interaction between lbound/ubound, allocatable arrays and bind(C) subroutine with dimension(..) parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97046 Gilles Gouaillardet changed: What|Removed |Added CC||gilles.gouaillardet at gmail dot c ||om --- Comment #2 from Gilles Gouaillardet --- This is the libc subroutine void sync(void); The point here is any subroutine (that will not cause a crash) can be used to evidence the issue.
[Bug target/97042] powerpc64 UINT_MAX constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042 --- Comment #7 from Alan Modra --- and of course, li 0x is li -1 which sets all bits.
[Bug fortran/96041] [11 regression] ICE in gfortran.dg/pr93423.f90 after r11-1792
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96041 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #9 from Tobias Burnus --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553799.html
[Bug target/97042] powerpc64 UINT_MAX constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042 --- Comment #6 from Alan Modra --- That's easy. rs6000_emit_set_long_const doesn't generate that sequence. Incidentally, a patch I had to generate more constants from li;rldicl also fixes this pr.
[Bug c++/97049] Cryptic warning "__builtin_memmove pointer overflow between offset ... and size ..." with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97049 Martin Sebor changed: What|Removed |Added Known to work||11.0, 9.3.0 Ever confirmed|0 |1 CC||msebor at gcc dot gnu.org Last reconfirmed||2020-09-14 Known to fail||10.2.0 Status|UNCONFIRMED |NEW --- Comment #1 from Martin Sebor --- Confirmed with GCC 10. Trunk doesn't show the warning because it doesn't synthesize the invalid memmove call. The warning is issued on the basis of the memmove call in IL below. The constant 4294967288 is too large to represent a valid size of an object in ILP32. The -Warray-bounds warning complains about the same thing (that the result of adding the offset into the object to the size isn't a valid pointer). [local count: 714496489]: _44 = MEM[(const struct InlineStorage *)]._capacity; if (_44 != 1) goto ; [66.00%] else goto ; [34.00%] [local count: 242928809]: _135 = (unsigned int) [(void *)]; _37 = (unsigned int) [(struct InlineStorage *)]._union; _46 = _37 - _135; _102 = [(void *) + 8B] + _46; _31 = [(void *)] + _46; __builtin_memmove (_102, _31, 4294967288); MEM[(int *) + 8B] = 6; pos_32 = [(struct InlineStorage *)]._union + 4; goto ; [100.00%]
[Bug analyzer/96650] [11 Regression] ICE in on_fact, at analyzer/constraint-manager.cc:1785
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96650 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-09-14 Ever confirmed|0 |1 --- Comment #1 from David Malcolm --- Thanks for filing this bug. Confirmed.
[Bug libbacktrace/93608] [libbacktrace] Add support for .gnu_debugdata section (aka MiniDebugInfo)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93608 Ian Lance Taylor changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #5 from Ian Lance Taylor --- This now works.
[Bug libbacktrace/93608] [libbacktrace] Add support for .gnu_debugdata section (aka MiniDebugInfo)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93608 --- Comment #4 from CVS Commits --- The master branch has been updated by Ian Lance Taylor : https://gcc.gnu.org/g:05f40bc4c116ba48843728201bc7290a5e518598 commit r11-3196-g05f40bc4c116ba48843728201bc7290a5e518598 Author: Ian Lance Taylor Date: Mon Sep 14 14:01:56 2020 -0700 libbacktrace: support MiniDebugInfo libbacktrace/ChangeLog: PR libbacktrace/93608 Add support for MiniDebugInfo. * elf.c (struct elf_view): Define. Replace most uses of backtrace_view with elf_view. (elf_get_view): New static functions. Replace most calls of backtrace_get_view with elf_get_view. (elf_release_view): New static functions. Replace most calls of backtrace_release_view with elf_release_view. (elf_uncompress_failed): Rename from elf_zlib_failed. Change all callers. (LZMA_STATES, LZMA_POS_STATES, LZMA_DIST_STATES): Define. (LZMA_DIST_SLOTS, LZMA_DIST_MODEL_START): Define. (LZMA_DIST_MODEL_END, LZMA_FULL_DISTANCES): Define. (LZMA_ALIGN_SIZE, LZMA_LEN_LOW_SYMBOLS): Define. (LZMA_LEN_MID_SYMBOLS, LZMA_LEN_HIGH_SYMBOLS): Define. (LZMA_LITERAL_CODERS_MAX, LZMA_LITERAL_CODER_SIZE): Define. (LZMA_PROB_IS_MATCH_LEN, LZMA_PROB_IS_REP_LEN): Define. (LZMA_PROB_IS_REP0_LEN, LZMA_PROB_IS_REP1_LEN): Define. (LZMA_PROB_IS_REP2_LEN, LZMA_PROB_IS_REP0_LONG_LEN): Define. (LZMA_PROB_DIST_SLOT_LEN, LZMA_PROB_DIST_SPECIAL_LEN): Define. (LZMA_PROB_DIST_ALIGN_LEN): Define. (LZMA_PROB_MATCH_LEN_CHOICE_LEN): Define. (LZMA_PROB_MATCH_LEN_CHOICE2_LEN): Define. (LZMA_PROB_MATCH_LEN_LOW_LEN): Define. (LZMA_PROB_MATCH_LEN_MID_LEN): Define. (LZMA_PROB_MATCH_LEN_HIGH_LEN): Define. (LZMA_PROB_REP_LEN_CHOICE_LEN): Define. (LZMA_PROB_REP_LEN_CHOICE2_LEN): Define. (LZMA_PROB_REP_LEN_LOW_LEN): Define. (LZMA_PROB_REP_LEN_MID_LEN): Define. (LZMA_PROB_REP_LEN_HIGH_LEN): Define. (LZMA_PROB_LITERAL_LEN): Define. (LZMA_PROB_IS_MATCH_OFFSET, LZMA_PROB_IS_REP_OFFSET): Define. (LZMA_PROB_IS_REP0_OFFSET, LZMA_PROB_IS_REP1_OFFSET): Define. (LZMA_PROB_IS_REP2_OFFSET): Define. (LZMA_PROB_IS_REP0_LONG_OFFSET): Define. (LZMA_PROB_DIST_SLOT_OFFSET): Define. (LZMA_PROB_DIST_SPECIAL_OFFSET): Define. (LZMA_PROB_DIST_ALIGN_OFFSET): Define. (LZMA_PROB_MATCH_LEN_CHOICE_OFFSET): Define. (LZMA_PROB_MATCH_LEN_CHOICE2_OFFSET): Define. (LZMA_PROB_MATCH_LEN_LOW_OFFSET): Define. (LZMA_PROB_MATCH_LEN_MID_OFFSET): Define. (LZMA_PROB_MATCH_LEN_HIGH_OFFSET): Define. (LZMA_PROB_REP_LEN_CHOICE_OFFSET): Define. (LZMA_PROB_REP_LEN_CHOICE2_OFFSET): Define. (LZMA_PROB_REP_LEN_LOW_OFFSET): Define. (LZMA_PROB_REP_LEN_MID_OFFSET): Define. (LZMA_PROB_REP_LEN_HIGH_OFFSET): Define. (LZMA_PROB_LITERAL_OFFSET): Define. (LZMA_PROB_TOTAL_COUNT): Define. (LZMA_IS_MATCH, LZMA_IS_REP, LZMA_IS_REP0): Define. (LZMA_IS_REP1, LZMA_IS_REP2, LZMA_IS_REP0_LONG): Define. (LZMA_DIST_SLOT, LZMA_DIST_SPECIAL, LZMA_DIST_ALIGN): Define. (LZMA_MATCH_LEN_CHOICE, LZMA_MATCH_LEN_CHOICE2): Define. (LZMA_MATCH_LEN_LOW, LZMA_MATCH_LEN_MID): Define. (LZMA_MATCH_LEN_HIGH, LZMA_REP_LEN_CHOICE): Define. (LZMA_REP_LEN_CHOICE2, LZMA_REP_LEN_LOW): Define. (LZMA_REP_LEN_MID, LZMA_REP_LEN_HIGH, LZMA_LITERAL): Define. (elf_lzma_varint): New static function. (elf_lzma_range_normalize): New static function. (elf_lzma_bit, elf_lzma_integer): New static functions. (elf_lzma_reverse_integer): New static function. (elf_lzma_len, elf_uncompress_lzma_block): New static functions. (elf_uncompress_lzma): New static function. (backtrace_uncompress_lzma): New function. (elf_add): Add memory and memory_size parameters. Change all callers. Look for .gnu_debugdata section, and, if found, decompress it and use it for symbols and debug info. Permit the descriptor parameter to be -1. * internal.h (backtrace_uncompress_lzma): Declare. * mtest.c: New file. * xztest.c: New file. * configure.ac: Check for nm, xz, and comm programs. Check for liblzma library. (HAVE_MINIDEBUG): Define. * Makefile.am (mtest_SOURCES): Define. (mtest_CFLAGS, mtest_LDADD): Define. (TESTS): Add mtest_minidebug if HAVE_MINIDEBUG. (%_minidebug): New pattern rule, if
[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983 --- Comment #25 from joseph at codesourcery dot com --- On Mon, 14 Sep 2020, anlauf at gcc dot gnu.org wrote: > Remember that Fortran needs a correspondence between a storage representation > (in bytes / bits) and the kind type on the language side. We'd thus need a > method to get the machine mode for a given representation. If there are > multiple representations with the same storage size (ieee128 vs. ibm128), > the ME needs to provide a way to the FE to uniquely address those. What that suggests to me is having a target hook mapping a Fortran kind to a floating-point machine mode (or to one of the global tree nodes for floating-point types), alongside the target hook mapping a C type (float, double, long double) to a machine mode.
[Bug c++/97050] ICE with segfault in lambda overload resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97050
--- Comment #2 from Marek Polacek ---
Reduced:
namespace a {
template constexpr bool f = __is_same_as(d, e);
}
struct g {};
struct h;
template auto operator+(i, j) {
auto k = [](auto l) requires a::f{};
return k;
}
void m() {
struct n {
} b;
n c;
auto o = b + c;
a::f;
}
[Bug c++/97050] ICE with segfault in lambda overload resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97050 Marek Polacek changed: What|Removed |Added Last reconfirmed||2020-09-14 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org Keywords||ice-on-valid-code Version|og10 (devel/omp/gcc-10) |11.0 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug c++/97050] New: ICE with segfault in lambda overload resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97050
Bug ID: 97050
Summary: ICE with segfault in lambda overload resolution
Product: gcc
Version: og10 (devel/omp/gcc-10)
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: numerical.simulation at web dot de
Target Milestone: ---
This issue can be observed in several varainst of gcc-trunk and 10.2.
--- 8< ---
#include
#include
#include
// See
https://arne-mertz.de/2018/05/overload-build-a-variant-visitor-on-the-fly/
template
struct overload : Fs... {
template
overload(Ts&& ...ts) : Fs{std::forward(ts)}...
{}
using Fs::operator()...;
};
template
overload(Ts&&...) -> overload...>;
struct get_operator {};
struct get_operands {};
struct plus {};
template auto operator+(T1 const & t1, T2 const & t2)
{
auto && operands_ =
[&](auto tag)
requires std::is_same_v
{
return std::make_tuple(t1, t2);
};
auto && operator_ =
[&](auto tag)
requires std::is_same_v
{
return plus{};
};
return overload(operator_, operands_);
}
int main() {
struct A{}; struct B{}; struct C{};
A a; B b; C c;
auto sum = a + b + c;
static_assert(std::is_same_v);
}
--- 8< ---
yields
: In instantiation of 'operator+::, operator+:: >, main()::C>:: [with auto:11 =
get_operator]':
:47:61: required from here
:47:61: internal compiler error: Segmentation fault
47 | static_assert(std::is_same_v);
| ^
Please submit a full bug report
Weblink for quick check:
https://godbolt.org/#z:OYLghAFBqd5QCxAYwPYBMCmBRdBLAF1QCcAaPECAM1QDsCBlZAQwBtMQBGAFlICsupVs1qhkAUgBMAISnTSAZ0ztkBPHUqZa6AMKpWAVwC2tQVvQAZPLUwA5YwCNMxLgA5SAB1QLC62nsMTQS8fNTorG3sjJxdOdyUVMNoGAmZiAgDjU05FZUxVPxS0ggi7R2c3RVT0zKCchWqS6zLoiriASkVUA2JkDgByKQBma2RDLABqcSGdAzVWQgBPaexxAAYAQWHR8cwpmYJFj0wAfQJiZkIFFfWtyRHaMYNJ6Z0CAw92G83bgHpfiYMTB7BAEAgeBQgf5pGwAWiMzgIAC8AHRYX6SNZxX5rACsv1QADdnKxUMx0LCHAY8KwKcxYYS0ngRAQGXhQiRYXRYQQEJhYVRWItfrdbgRMEZPsxxfsdGNmAoFBMUSqAGLXIarTYNYgGVQTIkksnoCYgCbqlUoqYAdlkmwmE3FkuEMte8sVypVABUNVqNg7DcRSeSID6pAA2COelEEBTtU3m662hroEAgGjEADuaXQrzDmogsfa4mtABFLbcHSXZGWpj97RMDD5RIm06hjhciMQIO0K0M7Vsy9MB2KJVLXTN3UrLfm/YHg%2BhQ9dJJGV5b47CVgbiUHja8U2niBLDScj1RnFo%2Bmc876%2B6t%2B6Ltec9QQJsBMAQTu3nNKSDaa6Ww63DqL5vh%2BX4diI6BKtWJaAQ%2B9YbCB%2BqfE2/5wUBiFOuOmCvIcxy0MwCITF6OSOkcWhEXsXqSFuzBzKgBqQV2cihpwExoLQDRTCujpkTRHF0NxUYEJI8awQ2Dr0UQPGruGTE/toCgnPspZ1v6DqaVWuKyCu4i4qWEDSYxqTAOJklaRMR4AI7UkeSoHiA7InAoVEnISrxYGM%2BGYIWzBmaQYGft%2BFxKVulaWVWtoRZFllHu8xC0BMjlGMwADWpzvJ8vkEGRonFv26mxTa8HSFWiFacZslRiFv7ECp0xqTFln6bpkYGUZDGOv55kaZFNl2ZgDkEKmTnKa5CLuZ5%2BSsD5fkBUFEE/ixmrNVpEl9cVVkfj0SWoUmAGYZt61DghWwWfFu3bkaIa1V2JyBbVSknAVZWikOiHWK%2BqXWD26EWchr6DodhWAxMNYg2VYM6LBp0Dlp/rMMO4MTA4yM6BxR3NVVCjGKpEzMDxZUOETmNnVpDTSngyAnAqSjpBAjnORNpweTMXmzRRjPGNA4F3SQsOlu0nQTPtKyve9pb9J0rAgP0uL9KQpj9GsiuoHLMMyHIyXdL0ezDJwisEHLqvC6QaUgLiQwotaazWri1pxFiuLhuGuLuLL/TcIryuq6Q6v9IrkJrKQxsq9LpBwLAMCICgqCSjSzjkJQaAJ%2BwLjAJwaySKQVA0uKxCQhADgm4rDjWGkixy4bpCpwi9AAPK0EKpekFgqWiOwrf4EeBTEpC4ekJgAAe%2BRzAMNdfcorcLA4FzEIsehYNXRvEHgRgr50ND0EwbAcDw/CCMIogoHIchCHgDiQpAnTtkkA%2BwrCKaNRIWsyJiQd5AUGgQOYtTZEPbQpQogxGCN4XwdB/5gNCH4YB5RYi5ESIURoUD6hfySEUdIcDWgIMpjUfQWRBB4KaJEeBXBOgKF1n0chQg5YKyVq3AOw9XDhlhOGbgb5kDIAmFnFEkgJgQFwIQP8BtAp6DTs4HiQxODxk1rpaQRtS5mwtriEOntvakA3qohhg8A5BxACHMOptI4xwgEgbo4I5jJwgKnDwicEGYHwF2QQ29GAsC7gfTMFwPCb1ofLH2jC5YGwmJmQgCAJjMNYewzh3DeGSEUeHM2fJyQVB7H4jRWiQ6%2BzVnLfRhilGdAttwcMfCACckhuCSFcJwUprhuBDCGPUvxQwAm6NyaHApfj4k6L9nojpiTOg7h8BobgQA
[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983 --- Comment #24 from anlauf at gcc dot gnu.org --- I've submitted the patch in comment#19 for review: https://gcc.gnu.org/pipermail/fortran/2020-September/055079.html This would also change the affected testcase to include comment#2, and defer the issue for power*-*-*-
[Bug middle-end/97048] [meta-bug] bogus/missing -Wstringop-overread warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97048 Bug 97048 depends on bug 81437, which changed state. Bug 81437 Summary: missing -Wstringop-overread reading past the end of a string https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81437 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/81437] missing -Wstringop-overread reading past the end of a string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81437 Martin Sebor changed: What|Removed |Added Target Milestone|--- |11.0 Blocks|88443 |97048 Status|NEW |RESOLVED Known to fail|10.0|10.2.0 Known to work||11.0 Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Summary|missing -Wstringop-overflow |missing -Wstringop-overread |reading past the end of a |reading past the end of a |string |string --- Comment #5 from Martin Sebor --- GCC 11 diagnoses all instances of the problem with the new -Wstringop-overead warning, both in the test case in comment #0 as well in comment #4: $ gcc -O2 -S pr81437.c pr81437.c: In function ‘f’: pr81437.c:5:3: warning: ‘__builtin_memcpy’ reading between 1 and 4294967295 bytes from a region of size 0 [-Wstringop-overread] 5 | __builtin_memcpy (d, a + 4, n); // warning (ok) | ^~ pr81437.c:3:14: note: at offset 4 into source object ‘a’ 3 | const char a[] = "123"; | ^ pr81437.c: In function ‘g’: pr81437.c:12:3: warning: ‘__builtin_memcpy’ reading 1 byte from a region of size 0 [-Wstringop-overread] 12 | __builtin_memcpy (d, a + 4, n); // missing warning | ^~ pr81437.c:10:14: note: at offset 4 into source object ‘a’ 10 | const char a[] = "123"; | ^ pr81437.c: In function ‘h’: pr81437.c:18:3: warning: ‘__builtin_strcpy’ reading 1 or more bytes from a region of size 0 [-Wstringop-overread] 18 | __builtin_strcpy (d, a + 4); // missing warning | ^~~ pr81437.c:17:14: note: at offset 4 into source object ‘a’ 17 | const char a[] = "123"; | ^ pr81437.c: In function ‘fx’: pr81437.c:26:10: warning: ‘__builtin_strcmp’ reading between 1 and 4 bytes from a region of size 0 [-Wstringop-overread] 26 | return __builtin_strcmp (a, [4]); // missing warning | ^~~ pr81437.c:22:6: note: at offset 4 into source object ‘a’ 22 | char a[4]; | ^ pr81437.c: In function ‘gx’: pr81437.c:31:10: warning: ‘__builtin_puts’ reading between 1 and 4 bytes from a region of size 0 [-Wstringop-overread] 31 | return __builtin_puts ([4]); // missing warning | ^~ pr81437.c:22:6: note: at offset 4 into source object ‘a’ 22 | char a[4]; | ^ pr81437.c: In function ‘fc4’: pr81437.c:26:10: warning: ‘__builtin_strcmp’ reading between 1 and 4 bytes from a region of size 0 [-Wstringop-overread] 26 | return __builtin_strcmp (a, [4]); // missing warning | ^~~ pr81437.c:22:6: note: at offset 4 into source object ‘a’ 22 | char a[4]; | ^ pr81437.c: In function ‘gc4’: pr81437.c:31:10: warning: ‘__builtin_puts’ reading between 1 and 4 bytes from a region of size 0 [-Wstringop-overread] 31 | return __builtin_puts ([4]); // missing warning | ^~ pr81437.c:22:6: note: at offset 4 into source object ‘a’ 22 | char a[4]; | ^ Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 [Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97048 [Bug 97048] [meta-bug] bogus/missing -Wstringop-overread warnings
[Bug middle-end/97048] [meta-bug] bogus/missing -Wstringop-overread warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97048 Bug 97048 depends on bug 82456, which changed state. Bug 82456 Summary: missing -Wstringop-overread on strcpy reading past the end of an array https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82456 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/82456] missing -Wstringop-overread on strcpy reading past the end of an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82456 Martin Sebor changed: What|Removed |Added Known to fail|10.0|10.2.0 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Status|NEW |RESOLVED Target Milestone|--- |11.0 Known to work||11.0 Resolution|--- |FIXED Blocks|88443 |97048 Summary|missing -Wstringop-overflow |missing -Wstringop-overread |on strcpy reading past the |on strcpy reading past the |end of an array |end of an array --- Comment #4 from Martin Sebor --- GCC 11 diagnoses all four instances with the new -Wstringop-overread warning added in g:d14c547abd484d3540b692bb8048c4a6efe92c8b. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 [Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97048 [Bug 97048] [meta-bug] bogus/missing -Wstringop-overread warnings
[Bug rtl-optimization/96475] direct threaded interpreter with computed gotos generates suboptimal dispatch loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96475 --- Comment #23 from Dimitar Dimitrov --- (In reply to Segher Boessenkool from comment #20) > Could you guys please test the attached patch? Thanks in advance! Yes, it fixed all new regressions for pru-elf. Thanks.
[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983 --- Comment #23 from anlauf at gcc dot gnu.org --- (In reply to jos...@codesourcery.com from comment #22) > Closely related: the LONG_DOUBLE_TYPE_SIZE target macro which assumes > "size in bits" can uniquely determine the format of long double. In the > absence of hacks such as the above, LONG_DOUBLE_TYPE_SIZE needs replacing > by a target hook that returns the machine mode, not "size in bits" (maybe > a hook that covers all of float, double and long double). Remember that Fortran needs a correspondence between a storage representation (in bytes / bits) and the kind type on the language side. We'd thus need a method to get the machine mode for a given representation. If there are multiple representations with the same storage size (ieee128 vs. ibm128), the ME needs to provide a way to the FE to uniquely address those.
[Bug c++/97049] New: Cryptic warning "__builtin_memmove pointer overflow between offset ... and size ..." with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97049 Bug ID: 97049 Summary: Cryptic warning "__builtin_memmove pointer overflow between offset ... and size ..." with -m32 Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: officesamurai at gmail dot com Target Milestone: --- Created attachment 49216 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49216=edit The code in question This looks similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92879 but this one needs -m32 to reproduce. Also, the warning message doesn't mention the offending line number which makes it particularly cryptic. - $ g++-10.2.0 -O2 -m32 -c gcc10_builtin_memmove_exceeds_maximum_obj_size.cpp In function ‘void foo()’: cc1plus: warning: ‘void* __builtin_memmove(void*, const void*, unsigned int)’ specified bound 4294967288 exceeds maximum object size 2147483647 []8;;https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wstringop-overflow=-Wstringop-overflow=]8;;] - With -Wno-stringop-overflow -Wall another warning is produced: - $ g++-10.2.0 -O2 -m32 -c gcc10_builtin_memmove_exceeds_maximum_obj_size.cpp -Wno-stringop-overflow -Wall In function ‘void foo()’: cc1plus: warning: ‘void* __builtin_memmove(void*, const void*, unsigned int)’ pointer overflow between offset [0, 1073741831] and size 4294967288 []8;;https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Warray-bounds-Warray-bounds]8;;] - Interestingly, if I change the type of 'size' on the line 116 to 'int', the warnings go away. The compiler: - $ g++-10.2.0 -v Using built-in specs. COLLECT_GCC=g++-10.2.0 COLLECT_LTO_WRAPPER=/home/brd/soft/gcc-10.2.0/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ./configure --prefix=/home/brd/soft/gcc-10.2.0 Thread model: posix Supported LTO compression algorithms: zlib gcc version 10.2.0 (GCC) -
[Bug c++/91741] Implement new warning -Wsizeof-array-div
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91741 Marek Polacek changed: What|Removed |Added Keywords||patch --- Comment #3 from Marek Polacek --- https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553888.html
Re: [Bug target/96968] aarch64 : ICE in vregs or expand pass, lowering __builtin_aarch64_get_{fpcr,fpsr,fpcr64,fpsr64}
Patch posted at: https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553882.html
[Bug target/96968] aarch64 : ICE in vregs or expand pass, lowering __builtin_aarch64_get_{fpcr,fpsr,fpcr64,fpsr64}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96968 --- Comment #4 from Andrea Corallo --- Patch posted at: https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553882.html
[Bug fortran/97046] Bad interaction between lbound/ubound, allocatable arrays and bind(C) subroutine with dimension(..) parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97046 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- (In reply to Igor Gayday from comment #0) > Consider the following code: > > MODULE FOO > INTERFACE > SUBROUTINE dummyc(x0) BIND(C, name="sync") > type(*), dimension(..) :: x0 > END SUBROUTINE > END INTERFACE What are the implementation details for sync?
[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983 --- Comment #22 from joseph at codesourcery dot com --- On Fri, 11 Sep 2020, segher at gcc dot gnu.org wrote: > > #ifndef RS6000_MODES_H > > #define RS6000_MODES_H 1 > > #define FLOAT_PRECISION_IFmode 128 > > #define FLOAT_PRECISION_TFmode 127 > > #define FLOAT_PRECISION_KFmode 126 > > Yes, this is a useful hack, but it has its own problems; the underlying > problem *still* has to be fixed (namely, the assumption that if you have > two floating point modes, they are ordered such that any number in one of > the modes can be represented in the other. In reality no such ordering > exists: __ibm128 has values not representable in __ieee128, and vice versa). > > We do have two 16 byte floating point modes, and neither is "greater" than > the other. Closely related: the LONG_DOUBLE_TYPE_SIZE target macro which assumes "size in bits" can uniquely determine the format of long double. In the absence of hacks such as the above, LONG_DOUBLE_TYPE_SIZE needs replacing by a target hook that returns the machine mode, not "size in bits" (maybe a hook that covers all of float, double and long double).
[Bug analyzer/96653] -Wanalyzer-too-complex on very large switch statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96653 David Malcolm changed: What|Removed |Added Summary|Compile time and memory hog |-Wanalyzer-too-complex on |w/ -O1 -fanalyzer |very large switch statement --- Comment #3 from David Malcolm --- The compile-time/memory blow-up should be fixed by above commit. However, I had to add -Wno-analyzer-too-complex to the testcase. Keeping this bug open to track that (updating bug title accordingly).
[Bug analyzer/97029] [11 Regression] ICE in wide_int_to_tree_1, at tree.c:1612
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97029 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from David Malcolm --- Should be fixed by above commit.
[Bug analyzer/96653] Compile time and memory hog w/ -O1 -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96653 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:799dd4e10047a4aa772fd69c910c5c6a96c36b9f commit r11-3190-g799dd4e10047a4aa772fd69c910c5c6a96c36b9f Author: David Malcolm Date: Thu Sep 10 21:23:38 2020 -0400 analyzer: fix constraint explosion on many-cased switch [PR96653] PR analyzer/96653 reports a CPU-time and memory explosion in -fanalyzer seen in Linux 5.9-rc1:drivers/media/v4l2-core/v4l2-ctrls.c on a switch statement with many cases. The issue is some old code in constraint_manager::get_or_add_equiv_class for ensuring that comparisons between equivalence classes containing constants work correctly. The old code added constraints for every pair of ECs containing constants, leading to O(N^2) constraints (for N constants). Given that get_or_add_equiv_class also involves O(N) comparisons, this led to at least O(N^3) CPU time, and O(N^2) memory consumption when handling the "default" case, where N is the number of other cases in the switch statement. The state rewrite of r11-2694-g808f4dfeb3a95f50f15e71148e5c1067f90a126d added checking for comparisons between constants, making these explicit constraints redundant, but failed to remove the code mentioned above. This patch removes it, fixing the blow-up of constraints in the default case. gcc/analyzer/ChangeLog: PR analyzer/96653 * constraint-manager.cc (constraint_manager::get_or_add_equiv_class): Don't accumulate transitive closure of all constraints on constants. gcc/testsuite/ChangeLog: PR analyzer/96653 * gcc.dg/analyzer/pr96653.c: New test.
[Bug analyzer/97029] [11 Regression] ICE in wide_int_to_tree_1, at tree.c:1612
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97029 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:35e3f0829d8e9cdc7ea19917c9f3a7add3f14847 commit r11-3188-g35e3f0829d8e9cdc7ea19917c9f3a7add3f14847 Author: David Malcolm Date: Sat Sep 12 09:28:05 2020 -0400 analyzer: fix ICE on setjmp with non-pointer-type [PR97029] gcc/analyzer/ChangeLog: PR analyzer/97029 * analyzer.cc (is_setjmp_call_p): Require the initial arg to be a pointer. * region-model.cc (region_model::deref_rvalue): Assert that the svalue is of pointer type. gcc/testsuite/ChangeLog: * gcc.dg/analyzer/pr97029.c: New test.
[Bug middle-end/97047] missing warning reading past the end of a constant string returned from a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97047 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Blocks||56456, 97048 --- Comment #1 from Martin Sebor --- With -Wall the test case triggers -Warray-bounds. Without -Wall it triggers -Wstringop-overread. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 [Bug 56456] [meta-bug] bogus/missing -Warray-bounds https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97048 [Bug 97048] [meta-bug] bogus/missing -Wstringop-overread warnings
[Bug middle-end/97048] [meta-bug] bogus/missing -Wstringop-overread warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97048 Martin Sebor changed: What|Removed |Added Summary|bogus/missing |[meta-bug] bogus/missing |-Wstringop-overread |-Wstringop-overread |warnings|warnings Status|UNCONFIRMED |NEW Last reconfirmed||2020-09-14 Alias||Wstringop-overread Keywords||diagnostic Ever confirmed|0 |1
[Bug middle-end/97048] New: bogus/missing -Wstringop-overread warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97048 Bug ID: 97048 Summary: bogus/missing -Wstringop-overread warnings Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- This is a meta-bug to track false positives and negatives in the -Wstringop-overread warning, new in GCC 11 (formerly included in -Wstringop-overflow).
[Bug middle-end/97047] New: missing warning reading past the end of a constant string returned from a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97047
Bug ID: 97047
Summary: missing warning reading past the end of a constant
string returned from a function
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The first call to memcpy below triggers a warning for reading past the end of
the string returned from f(), but the second call doesn't.
$ cat x.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout x.c
const char* f (void) { return "123"; }
char a[32];
void g (void)
{
__builtin_memcpy (a, "123", sizeof a); // warning (good)
}
void h (void)
{
__builtin_memcpy (a, f (), sizeof a);// missing warning (bug)
}
;; Function f (f, funcdef_no=0, decl_uid=1931, cgraph_uid=1, symbol_order=0)
f ()
{
[local count: 1073741824]:
return "123";
}
x.c: In function ‘g’:
x.c:7:3: warning: ‘__builtin_memcpy’ forming offset [4, 31] is out of the
bounds [0, 4] [-Warray-bounds]
7 | __builtin_memcpy (a, "123", sizeof a); // warning (good)
| ^
;; Function g (g, funcdef_no=1, decl_uid=1935, cgraph_uid=2, symbol_order=2)
g ()
{
[local count: 1073741824]:
__builtin_memcpy (, "123", 32); [tail call]
return;
}
;; Function h (h, funcdef_no=2, decl_uid=1938, cgraph_uid=3, symbol_order=3)
h ()
{
[local count: 1073741824]:
MEM [(char * {ref-all})] = MEM
[(char * {ref-all})"123"];
return;
}
[Bug tree-optimization/80794] constant objects can be assumed to be immutable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80794 --- Comment #10 from Matthijs Kooijman --- Also note that pr96996, that was marked as a duplicate of this report, talks about a notable subcase of the case presented in this report. While this report talks about constant complete objects (e.g. a variable marked const), pr96996 talks about const subobjects (e.g. a const member of a variable that might not be const itself). That pr has some motivation to argue that such const subobjects can be optimized in the same way as const complete objects. Maybe this is obvious for seasoned gcc devs, but I wanted to point it out regardless, since the cases seem distinct enough to me that one might end up fixing this for objects and forgetting about subobjects :-)
[Bug rtl-optimization/96475] direct threaded interpreter with computed gotos generates suboptimal dispatch loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96475 --- Comment #22 from Christophe Lyon --- Yes, that fixes the build for aarch64, thanks!
[Bug tree-optimization/80794] constant objects can be assumed to be immutable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80794 Martin Sebor changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=90404, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=86318 --- Comment #9 from Martin Sebor --- See also pr86318 and especially pr90404. As noted in c#2 on the former, issuing a warning when an attempt is detected to modify a const object (or subobject) as requested in pr90404 should help detect changes, resulting from the optimization, to the behavior of code that deliberately violates the restriction to modify constant subobjects.
[Bug tree-optimization/86318] const local aggregates can be assumed not to be modified even when escaped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86318 Martin Sebor changed: What|Removed |Added Host||90404 --- Comment #2 from Martin Sebor --- I should add that issuing a warning when an attempt is detected to modify a const object (or subobject) as requested in pr90404 should help detect changes, resulting from the optimization, to the behavior of code that deliberately violates the restriction to modify constant subobjects.
[Bug fortran/97046] New: Bad interaction between lbound/ubound, allocatable arrays and bind(C) subroutine with dimension(..) parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97046 Bug ID: 97046 Summary: Bad interaction between lbound/ubound, allocatable arrays and bind(C) subroutine with dimension(..) parameter Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: igor.gayday at mu dot edu Target Milestone: --- Consider the following code: MODULE FOO INTERFACE SUBROUTINE dummyc(x0) BIND(C, name="sync") type(*), dimension(..) :: x0 END SUBROUTINE END INTERFACE contains SUBROUTINE dummy(x0) type(*), dimension(..) :: x0 call dummyc(x0) END SUBROUTINE END MODULE PROGRAM main USE FOO IMPLICIT NONE integer :: before(2), after(2) INTEGER, parameter :: n = 1 DOUBLE PRECISION, ALLOCATABLE :: buf(:) DOUBLE PRECISION :: buf2(n) ALLOCATE(buf(n)) before(1) = LBOUND(buf,1) before(2) = UBOUND(buf,1) CALL dummy (buf) after(1) = LBOUND(buf,1) after(2) = UBOUND(buf,1) if (before(1) .NE. after(1)) stop 1 if (before(2) .NE. after(2)) stop 2 before(1) = LBOUND(buf2,1) before(2) = UBOUND(buf2,1) CALL dummy (buf2) after(1) = LBOUND(buf2,1) after(2) = LBOUND(buf2,1) if (before(1) .NE. after(1)) stop 3 if (before(2) .NE. after(2)) stop 4 END PROGRAM lbound() and ubound() of an allocatable array return different values before and after a Fortran subroutine with dimension(..) parameter (that in turns invokes a bind(C) subroutine) is invoked. Note that if the main program directly CALL dummyc(buf) (instead of dummy(buf)), then the error does not occur. gcc versions 9.2.0, 10.2.0 and the latest master branch are all affected. In particular, this causes issues with mpi_f08 module, see: https://stackoverflow.com/questions/63824065/lbound-of-an-array-changes-after-call-to-mpi-gatherv-when-using-mpi-f08-module This might be a duplicate of Bug #94070.
[Bug rtl-optimization/96475] direct threaded interpreter with computed gotos generates suboptimal dispatch loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96475 --- Comment #21 from Arseny Solokha --- (In reply to Segher Boessenkool from comment #20) > Could you guys please test the attached patch? Thanks in advance! It fixed the ICE on x86_64 I've reported in comment 17. I didn't run a regtest, though.
[Bug tree-optimization/96996] Missed optimzation for constant members of non-constant objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96996 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE CC||msebor at gcc dot gnu.org Component|c++ |tree-optimization See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=86318 --- Comment #7 from Martin Sebor --- Let me confirm this as a potential generic optimization. In fact, I believe it's a duplicate of pr80794. The related pr86318, when implemented, should extend this optimization to non-const locals as well. *** This bug has been marked as a duplicate of bug 80794 ***
[Bug tree-optimization/80794] constant objects can be assumed to be immutable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80794 Martin Sebor changed: What|Removed |Added CC||matthijs at stdin dot nl --- Comment #8 from Martin Sebor --- *** Bug 96996 has been marked as a duplicate of this bug. ***
[Bug c/96907] [docs] document builtins for fputc and putc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96907
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #6 from Martin Sebor ---
Rather than en enumerating all the functions that are handled as built-ins (and
keeping them in sync with the code) it would be simpler to state that any
function prescribed by this or that revision of a standard may be implemented
as a built-in, and suggesting to use the __has_builtin() preprocessor function
to query support for each.
Besides adding attributes to their declarations, GCC transforms calls to some
of them into others (e.g., fputs to fputc, or fprintf to fputs or fputc) or
eliminated altogether (e.g., fputs("", f)). It might be helpful to mention
that in the manual and point users who want to avoid such transformations to
-fno-builtin-.
[Bug fortran/97045] New: A wrong column is selected when addressing individual elements of unlimited polymorphic dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97045 Bug ID: 97045 Summary: A wrong column is selected when addressing individual elements of unlimited polymorphic dummy argument Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: igor.gayday at mu dot edu Target Milestone: --- Consider the following Fortran program: program test_prg implicit none integer :: i integer, allocatable :: arr(:, :) arr = reshape([(i, i = 1, 100)], [10, 10]) do i = 1, 3 print *, 'Column', i call write_array(arr(1:2, i)) end do contains subroutine write_array(array) class(*), intent(in) :: array(:) integer :: i do i = 1, size(array) select type (elem => array(i)) type is (integer) print '(I0)', elem end select end do end subroutine subroutine write_array_alt(array) class(*), intent(in) :: array(:) integer :: i select type (array) type is (integer) print '(I0)', array end select end subroutine end program Compiled with gfortran 9.3.0 (and 10.2), the program prints: Column 1 1 2 Column 2 21 22 Column 3 41 42 As you can see, it skips every other column. If I replace the call to write_array with the call to write_array_alt, where I select type of the whole array and not individual elements, then every column is printed, as expected. This issue was originally reported here: https://stackoverflow.com/questions/63841012/a-wrong-column-is-selected-when-addressing-individual-elements-of-unlimited-poly
[Bug target/97042] powerpc64 UINT_MAX constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042 --- Comment #5 from Segher Boessenkool --- So hrm, why did GCC generate lis 0x ; ori 0x ; rldicl instead of li 0x ; oris 0x ?
[Bug go/92567] libgo regression in syscall test on ppc64le resulting in timeout due to hang in read
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92567 --- Comment #2 from Paul E. Murphy --- For clarity, the prototype of ptrace from glibc: extern long int ptrace (enum __ptrace_request __request, ...) __THROW;
[Bug rtl-optimization/96475] direct threaded interpreter with computed gotos generates suboptimal dispatch loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96475 --- Comment #20 from Segher Boessenkool --- Could you guys please test the attached patch? Thanks in advance!
[Bug rtl-optimization/96475] direct threaded interpreter with computed gotos generates suboptimal dispatch loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96475 --- Comment #19 from Segher Boessenkool --- Created attachment 49215 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49215=edit proposed patch for the ICEs
[Bug target/97042] powerpc64 UINT_MAX constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042 Segher Boessenkool changed: What|Removed |Added Attachment #49214|0 |1 is obsolete|| Attachment #49214|proposed patch for the ICEs |proposed patch for the ICEs description|| (wrong PR, sorry) --- Comment #4 from Segher Boessenkool --- Comment on attachment 49214 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49214 proposed patch for the ICEs (wrong PR, sorry) >diff --git a/gcc/bb-reorder.c b/gcc/bb-reorder.c >index 76e56b5..2ad5197 100644 >--- a/gcc/bb-reorder.c >+++ b/gcc/bb-reorder.c >@@ -2760,6 +2760,10 @@ duplicate_computed_gotos (function *fun) > if (computed_jump_p (BB_END (bb)) && can_duplicate_block_p (bb)) > changed |= maybe_duplicate_computed_goto (bb, max_size); > >+ /* Some blocks may have become unreachable. */ >+ if (changed) >+cleanup_cfg (0); >+ > /* Duplicating blocks will redirect edges and may cause hot blocks > previously reached by both hot and cold blocks to become dominated > only by cold blocks. */
[Bug target/97042] powerpc64 UINT_MAX constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042 --- Comment #3 from Segher Boessenkool --- Created attachment 49214 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49214=edit proposed patch for the ICEs
[Bug tree-optimization/96522] [9/10 Regression] Incorrect with with -O -fno-tree-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96522 --- Comment #8 from CVS Commits --- The releases/gcc-10 branch has been updated by Richard Biener : https://gcc.gnu.org/g:1dbb919d0868319a5503b91049283a189ac1b4ac commit r10-8760-g1dbb919d0868319a5503b91049283a189ac1b4ac Author: Richard Biener Date: Thu Aug 27 11:48:15 2020 +0200 tree-optimization/96522 - transfer of flow-sensitive info in copy_ref_info This removes the bogus tranfer of flow-sensitive info in copy_ref_info plus fixes one oversight in FRE when flow-sensitive non-NULLness was added to points-to info. 2020-08-27 Richard Biener PR tree-optimization/96522 * tree-ssa-address.c (copy_ref_info): Reset flow-sensitive info of the copied points-to. Transfer bigger alignment via the access type. * tree-ssa-sccvn.c (eliminate_dom_walker::eliminate_stmt): Reset all flow-sensitive info. * gcc.dg/torture/pr96522.c: New testcase. (cherry picked from commit eb68d9d828f94d28afa5900fbf3072bbcd64ba8a)
[Bug go/92567] libgo regression in syscall test on ppc64le resulting in timeout due to hang in read
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92567 Paul E. Murphy changed: What|Removed |Added CC||murphyp at linux dot vnet.ibm.com --- Comment #1 from Paul E. Murphy --- So, this turns out to be an ABI violation of how ptrace() is called, and maybe a documentation bug. ptrace is actually implemented as a variadic function in glibc which takes exactly 4 arguments, and this is not clear from the documentation. The golang code does not seem to allocate the parameter save space required (2.2.2.3 of the ppc64 elfv2-1.4), and the space where golang saves the link register gets stomped, and the forked process faults waiting for the tracer. Newer versions of GCC seem to compile ptrace without needing to spill into the parameter save space, so in many cases this issue is invisible.
[Bug rtl-optimization/96475] direct threaded interpreter with computed gotos generates suboptimal dispatch loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96475 --- Comment #18 from Segher Boessenkool --- I have a patch.
[Bug tree-optimization/97043] latent wrong-code with SLP vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97043 --- Comment #2 from CVS Commits --- The releases/gcc-10 branch has been updated by Richard Biener : https://gcc.gnu.org/g:e93428a8b056aed83a7678d4dc8272131ab671ba commit r10-8759-ge93428a8b056aed83a7678d4dc8272131ab671ba Author: Richard Biener Date: Mon Sep 14 11:25:04 2020 +0200 tree-optimization/97043 - fix latent wrong-code with SLP vectorization When the unrolling decision comes late and would have prevented eliding a SLP load permutation we can end up generating aligned loads when the load is in fact unaligned. Most of the time alignment analysis figures out the load is in fact unaligned but that cannot be relied upon. The following removes the SLP load permutation eliding based on the still premature vectorization factor. 2020-09-14 Richard Biener PR tree-optimization/97043 * tree-vect-slp.c (vect_analyze_slp_instance): Do not elide a load permutation if the current vectorization factor is one.
[Bug c++/96994] Missing code from consteval constructor initializing const variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96994 --- Comment #7 from Jakub Jelinek --- So, what I see is that expand_default_init calls build_special_member_call for the default ctor, but because the default ctor is an immediate method, it returns a TARGET_EXPR with CONSTRUCTOR as the initializer, rather than a call. expand_default_init doesn't return anything, just appends the rval as statement, but that doesn't really do anything. So, one way to fix this would be in expand_default_init check for rval being a TARGET with TREE_CONSTANT as the initializer and if it is that, build an INIT_EXPR like it e.g. does that for constexpr ctors. --- gcc/cp/init.c.jj2020-09-10 11:24:05.019805303 +0200 +++ gcc/cp/init.c 2020-09-14 15:06:59.467341241 +0200 @@ -1999,6 +1999,9 @@ expand_default_init (tree binfo, tree tr rval = build2 (INIT_EXPR, type, exp, e); } } + else if (TREE_CODE (rval) == TARGET_EXPR + && TREE_CONSTANT (TARGET_EXPR_INITIAL (rval))) +rval = build2 (INIT_EXPR, type, exp, rval); /* FIXME put back convert_to_void? */ if (TREE_SIDE_EFFECTS (rval)) fixes the testcase
[Bug tree-optimization/78164] SLP vectorizer: prologue cost biased by redundancies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78164 Richard Biener changed: What|Removed |Added Last reconfirmed||2020-09-14 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Blocks||53947 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #1 from Richard Biener --- I do have patches to "CSE" those, still not in perfect shape though. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug tree-optimization/59617] [vectorizer] ICE in vectorizable_mask_load_store with AVX-512F's gathers enabled.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59617 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #20 from Richard Biener --- I'm sure this is fixed.
[Bug tree-optimization/57512] Vectorizer: cannot handle accumulation loop of signed char type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57512 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Known to work||10.1.0 --- Comment #3 from Richard Biener --- This has been fixed, for GCC 10+ I think.
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 57512, which changed state. Bug 57512 Summary: Vectorizer: cannot handle accumulation loop of signed char type https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57512 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/56624] Vectorizer gives up on a group-access if it contains stores to the same location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56624
--- Comment #6 from Richard Biener ---
(In reply to Michael Zolotukhin from comment #4)
> Sorry, it looks like the reproducer with if could be made, and here it is:
> void foo (long *a)
> {
> int i;
> for (i = 0; i < 100; i+=2)
> {
> if (a[i] == 0)
> {
> a[i+1] = 2;
> a[i] = 3;
> }
> else
> {
> a[i+1] = 3;
> a[i] = 4;
> }
> }
> }
> In this example we have:
> group_access2.c:4: note: === vect_analyze_data_ref_accesses ===
> group_access2.c:4: note: READ_WRITE dependence in interleaving.
> group_access2.c:4: note: not vectorized: complicated access pattern.
> group_access2.c:4: note: bad data access.
> group_access2.c:1: note: vectorized 0 loops in function.
>
> The diagnostic is a bit different, but rootcause is the same I guess.
>
> The test is attached (reproducer 2).
We now vectorize this loop (not with plain SSE2 but with SSE4.2 for example):
.L2:
movq(%rdi), %xmm0
movdqa %xmm2, %xmm4
addq$16, %rdi
punpcklqdq %xmm0, %xmm0
pcmpeqq %xmm1, %xmm0
pblendvb%xmm0, %xmm3, %xmm4
movups %xmm4, -16(%rdi)
cmpq%rdi, %rax
jne .L2
probably because we now sink the common stores from the if arm. Modifying
the testcase to the following reproduces the original issue again:
void foo (long *a)
{
int i;
for (i = 0; i < 100; i+=2)
{
if (a[i] == 0)
{
a[i+1] = 2;
a[i] = 3;
}
else
{
a[i] = 4;
a[i+1] = 3;
}
}
}
[Bug target/97042] powerpc64 UINT_MAX constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042 Peter Bergner changed: What|Removed |Added CC||bergner at gcc dot gnu.org --- Comment #2 from Peter Bergner --- With a patch I'm working on for PR93176, I get the following code (even with the commit below): li 9,-1 rldic 9,9,0,32 subf 3,3,9 blr
[Bug tree-optimization/50680] -ftree-vectorizer-verbose does not report about "basic block SLP" (attempt of) vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50680
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2020-09-14
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from Richard Biener ---
Still the case because most of the analysis is under a dump-scope:
vect_slp_analyze_bb_1 (bb_vec_info bb_vinfo, int n_stmts, bool ,
vec *dataref_groups)
{
DUMP_VECT_SCOPE ("vect_slp_analyze_bb");
and BB analysis does not return a opt_result yet to communicate the relevant
part up.
[Bug tree-optimization/46011] 256bit vectorizer failed on double->int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46011 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Richard Biener --- Fixed in GCC10+
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 46011, which changed state. Bug 46011 Summary: 256bit vectorizer failed on double->int https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46011 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/97043] latent wrong-code with SLP vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97043 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug tree-optimization/97043] latent wrong-code with SLP vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97043
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Ever confirmed|0 |1
Blocks||96522
Status|UNCONFIRMED |NEW
Last reconfirmed||2020-09-14
--- Comment #1 from Richard Biener ---
This blocks backporting the fix for PR96522, causing the gcc.dg/vect/pr81410.c
testcase to FAIL execution with an unaligned access using an aligned load.
The trunk rev. that fixed this is gbc484e250990393e887f7239157cc85ce6fadcce
A pragmatic fix might be
diff --git a/gcc/tree-vect-slp.c b/gcc/tree-vect-slp.c
index f6331eeea86..3fdf56f9335 100644
--- a/gcc/tree-vect-slp.c
+++ b/gcc/tree-vect-slp.c
@@ -2309,9 +2309,8 @@ vect_analyze_slp_instance (vec_info *vinfo,
/* The load requires permutation when unrolling exposes
a gap either because the group is larger than the SLP
group-size or because there is a gap between the groups.
*/
- && (known_eq (unrolling_factor, 1U)
- || (group_size == DR_GROUP_SIZE (first_stmt_info)
- && DR_GROUP_GAP (first_stmt_info) == 0)))
+ && group_size == DR_GROUP_SIZE (first_stmt_info)
+ && DR_GROUP_GAP (first_stmt_info) == 0)
{
SLP_TREE_LOAD_PERMUTATION (load_node).release ();
continue;
with biggest effects eventually on load-lane targets (arm/aarch64) where
we then eventually prefer more of those. For the testcase in question
we then generate the following, matching trunk
movdqa (%rdx), %xmm2
movdqa 16(%rdx), %xmm0
shufpd $1, 32(%rdx), %xmm0
instead of
movdqa (%rdx), %xmm1
addq$48, %rdx
movdqu -24(%rdx), %xmm2
(or with the backport of PR96522 a wrong movdqa in place of the movdqu).
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96522
[Bug 96522] [9/10 Regression] Incorrect with with -O -fno-tree-pta
[Bug libstdc++/97044] New: Undefined format macros because of include order on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97044
Bug ID: 97044
Summary: Undefined format macros because of include order on
AIX
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: clement.chigot at atos dot net
Target Milestone: ---
On AIX, C++ format macros like "PRIu32" might not be defined even if
"cinttypes" is included. It happends when other headers which have a dependency
on "inttypes.h" are included before.
On AIX, __STDC_FORMAT_MACROS must be defined before "sys/inttypes.h" is
included in order to have these macros defined. But with for example ,
as "string.h" includes "sys/types" which included "sys/inttypes.h",
__STDC_FORMAT_MACROS won't be defined when "sys/inttypes.h" is first included
thus the format macros won't be defined.
This program works on Linux but not on AIX.
#include
#include
#include
int main(){
#ifdef PRIu32
std::cout << "PRIu32 defined" << std::endl;
#else
std::cout << "PRIu32 not defined" << std::endl;
#endif
}
My question is what are the G++ standards saying on that ? Should
always defined "PRIu32"-like macros ? Or does the developers should be careful
the order when are included the headers or always add -D__STDC_FORMAT_MACROS ?
I would clearly go for one. Especially, because knowing that "#include
" must be after "#include " if you want to use "PRIu32" is
not obvious.
Clément
[Bug tree-optimization/97043] New: latent wrong-code with SLP vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97043
Bug ID: 97043
Summary: latent wrong-code with SLP vectorization
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
There's a latent wrong-code bug on the branches visible with the
gcc.dg/vect/pr81410.c testcase. The issue is avoided on trunk
by means of delaying optimizing/validating of SLP permutations until
the vectorization factor is final whilst on branches we throw away
the permutation prematurely via
if (!this_load_permuted
/* The load requires permutation when unrolling exposes
a gap either because the group is larger than the SLP
group-size or because there is a gap between the groups.
*/
&& (known_eq (unrolling_factor, 1U)
|| (group_size == DR_GROUP_SIZE (first_stmt_info)
&& DR_GROUP_GAP (first_stmt_info) == 0)))
{
SLP_TREE_LOAD_PERMUTATION (load_node).release ();
because unrolling_factor is 1 but later is upped to 2 due to hybrid
SLP/non-SLP vectorization. This causes us to run into the gap adjustment
code added by the PR81410 fix:
/* With SLP permutation we load the gaps as well, without
we need to skip the gaps after we manage to fully load
all elements. group_gap_adj is DR_GROUP_SIZE here. */
group_elt += nunits;
if (maybe_ne (group_gap_adj, 0U)
&& !slp_perm
&& known_eq (group_elt, group_size - group_gap_adj))
{
poly_wide_int bump_val
= (wi::to_wide (TYPE_SIZE_UNIT (elem_type))
* group_gap_adj);
tree bump = wide_int_to_tree (sizetype, bump_val);
dataref_ptr = bump_vector_ptr (dataref_ptr, ptr_incr, gsi,
stmt_info, bump);
group_elt = 0;
}
which notes that we do not load the gaps. Now, alignment analysis
correctly analyzes the load of x[] to be aligned due to the VF being 2:
poly_uint64 vf = LOOP_VINFO_VECT_FACTOR (loop_vinfo);
step_preserves_misalignment_p
= multiple_p (DR_STEP_ALIGNMENT (dr_info->dr) * vf, vect_align_c);
but that assumes contiguous aligned loads. The
VMAT_CONTIGUOUS-with-gap-without-permutation vectorization OTOH assumes that
each individual instance
of the group is aligned which it is not. Trying to fix up there
would also require unaligned access support checking at analysis time
as well as possible cost adjustments.
[Bug rtl-optimization/96475] direct threaded interpreter with computed gotos generates suboptimal dispatch loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96475 Arseny Solokha changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #17 from Arseny Solokha --- (In reply to Dimitar Dimitrov from comment #16) > Patch is also causing ICE in a few test cases on pru-elf target: It causes ICEs on practically any target, though I believe it should have been reported separately rather than in this PR. % gcc-11.0.0 -O1 -fexpensive-optimizations -w -c gcc/testsuite/gcc.c-torture/execute/920302-1.c during RTL pass: ce3 gcc/testsuite/gcc.c-torture/execute/920302-1.c: In function 'execute': gcc/testsuite/gcc.c-torture/execute/920302-1.c:25:1: internal compiler error: in calc_dfs_tree, at dominance.c:458 25 | } | ^ 0x618911 calc_dfs_tree /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200913/work/gcc-11-20200913/gcc/dominance.c:458 0x98bec9 calculate_dominance_info(cdi_direction) /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200913/work/gcc-11-20200913/gcc/dominance.c:734 0x921972 flow_loops_find(loops*) /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200913/work/gcc-11-20200913/gcc/cfgloop.c:431 0xbd6eae loop_optimizer_init(unsigned int) /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200913/work/gcc-11-20200913/gcc/loop-init.c:93 0x1761c73 if_convert /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200913/work/gcc-11-20200913/gcc/ifcvt.c:5382 0x176494d execute /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200913/work/gcc-11-20200913/gcc/ifcvt.c:5566 w/ gcc-11.0.0-alpha20200913 snapshot.
[Bug fortran/97031] the content of a comment line breaks compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97031 --- Comment #5 from jean-pierre.flam...@univ-lille.fr --- I am sorry to bother you once again, for the last time. I have now understood all things that happened while compiling the very complicated (!) program below. program tstmak implicit none ! a comment with /* integer :: i ! #ifdef _MYDEBUG_ print *,' debug printing' #endif i = 25 print *,'normal printing: i=',i end program tstmak I compiled this fortran with and without -cpp, and always with -D_MYDEBUG_ in a command like that one gfortran -v -ffree-form -Wall -msse2 -g -fbounds-check -fbacktrace -D_MYDEBUG_ -cpp tstmak1.f -o v1 1) if -cpp is PRESENT a) the '/*' in the comment line causes a great problem (in that case an "end of file") and no executable is produced b) if I change the '/*' to anything else, no message, the executable is produced, and prints what is expected 2) if -cpp is ABSENT a) the '/*' in the comment line has no catastrophic effect, but a WARNING appears "Warning: tstmak.f:6: Illegal preprocessor directive" however the executable is produced, and prints what is expected It is because of this warning (and not an error) that I always put "-cpp" in my makefiles ! ===> conclusion: gfortran "tolerates" and understands "#" type directives. This is in opposition to other compilers, which also caused my trouble Sorry for the disturbance JP Flament - Mail original - De: "kargl at gcc dot gnu.org" À: "jean-pierre flament" Envoyé: Dimanche 13 Septembre 2020 11:55:28 Objet: [Bug fortran/97031] the content of a comment line breaks compilation https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97031 --- Comment #3 from Steve Kargl --- On Sun, Sep 13, 2020 at 08:02:01AM +, jean-pierre.flam...@univ-lille.fr wrote: > > I just noticed that cpp recognizes the extensions .fpp .F and other uppercase > extensions. > This is why I added -cpp in the gfortran command (otherwise I have a > diagnostic > because of #ifdef's > > I have renamed my file with the .fpp extension; with "-cpp" in the gfortran > submission I get the same errors. > > If I compile the file with extension *.f or .fpp without -cpp > > 1) the compilation has no error > 2) a #ifdef...#endif is recognized even with a .f extension, without -cpp, in > my simple example, (I should check that the directive really is taken into > account !) > 3) IF I compile my full project in a makefile, the absence of "-cpp" in the > gfortran command induces > a "Illegal preprocessor directive" error in all the routines having that > #ifdef...#endif > I don't quite follow you. But, it come down to gfortran uses the C pre-processor when asked to pre-process a file. If you have a C language construct such as '/*' in your Fortran code it will cause problems.
[Bug rtl-optimization/97041] ICE during RTL pass: sched_fusion: in operator[], at vec.h:880
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97041 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #2 from Christophe Lyon --- This was already reported at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96475#c9 I believe Segher is looking at it.
[Bug target/97028] [9/10/11 Regression] Compilation errors for AVX512 intrinsic with -masm=intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97028 --- Comment #5 from Jakub Jelinek --- Created attachment 49213 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49213=edit gcc11-pr97028.patch Untested fix.
[Bug target/97028] [9/10/11 Regression] Compilation errors for AVX512 intrinsic with -masm=intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97028 --- Comment #4 from Jakub Jelinek --- Introduced with r9-3563-gc038638ea9dfc75fac9559cdb035754af85960d0 and r9-3560-gfda5d5e6e040d23e7e751a491097090b8f5ff58a
[Bug target/97028] [9/10/11 Regression] Compilation errors for AVX512 intrinsic with -masm=intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97028 Jakub Jelinek changed: What|Removed |Added Summary|Compilation errors for |[9/10/11 Regression] |AVX512 intrinsic with |Compilation errors for |-masm=intel |AVX512 intrinsic with ||-masm=intel Target Milestone|--- |9.4 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|WAITING |ASSIGNED CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- I can reproduce it.
[Bug rtl-optimization/97041] ICE during RTL pass: sched_fusion: in operator[], at vec.h:880
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97041 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-09-14 Status|UNCONFIRMED |WAITING --- Comment #1 from Richard Biener --- Please attach preprocessed source (the backtrace doesn't make much sense to me)
[Bug analyzer/97029] [11 Regression] ICE in wide_int_to_tree_1, at tree.c:1612
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97029 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0
[Bug target/97028] Compilation errors for AVX512 intrinsic with -masm=intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97028 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Last reconfirmed||2020-09-14 --- Comment #2 from Richard Biener --- it works for me, what assembler version are you using? I'm using gas 2.34.0
[Bug debug/97026] -flto and DW_AT_GNU_macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97026
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed||2020-09-14
Status|UNCONFIRMED |NEW
Keywords||lto
Version|unknown |10.2.0
--- Comment #1 from Richard Biener ---
(In reply to Pedro Alves from comment #0)
> With:
>
> #define ZERO 0
> int main () { return ZERO; }
>
> Compiled with -flto and -g3 so we emit macro debug info:
>
> $ gcc macro.c -o macro -flto -g3
>
> Using gcc version 11.0.0 20200910, commit 3d0af0c997fe,
> we end up with a "DW_AT_name: " compile unit that basically
> wraps another with DW_AT_abstract_origin:
>
> ~
> Compilation Unit @ offset 0x0:
>Length:0x41 (32-bit)
>Version: 4
>Abbrev Offset: 0x0
>Pointer Size: 8
> <0>: Abbrev Number: 1 (DW_TAG_compile_unit)
>DW_AT_producer: (indirect string, offset: 0x12): GNU GIMPLE
> 11.0.0 20200910 (experimental) -mtune=generic -march=x86-64 -g -g3
> -fno-openmp -fno-openacc -fPIC
> -fcf-protection=none -fltrans
> <10> DW_AT_language: 12 (ANSI C99)
> <11> DW_AT_name: (indirect string, offset: 0x5):
> <15> DW_AT_comp_dir: (indirect string, offset: 0x0): /tmp
> <19> DW_AT_low_pc : 0x118e
> <21> DW_AT_high_pc : 0xb
> <29> DW_AT_stmt_list : 0x0
> <1><2d>: Abbrev Number: 2 (DW_TAG_subprogram)
> <2e> DW_AT_abstract_origin: <0x66>
> <32> DW_AT_low_pc : 0x118e
> <3a> DW_AT_high_pc : 0xb
> <42> DW_AT_frame_base : 1 byte block: 9c
> (DW_OP_call_frame_cfa)
> <44> DW_AT_GNU_all_call_sites: 1
> <1><44>: Abbrev Number: 0
> Compilation Unit @ offset 0x45:
>Length:0x31 (32-bit)
>Version: 4
>Abbrev Offset: 0x24
>Pointer Size: 8
> <0><50>: Abbrev Number: 1 (DW_TAG_compile_unit)
> <51> DW_AT_producer: (indirect string, offset: 0x282f): GNU C17
> 11.0.0 20200910 (experimental) -mtune=generic -march=x86-64 -g3 -flto
> <55> DW_AT_language: 12 (ANSI C99)
> <56> DW_AT_name: (indirect string, offset: 0x287d): macro.c
> <5a> DW_AT_comp_dir: (indirect string, offset: 0x0): /tmp
> <5e> DW_AT_stmt_list : 0x41
> <62> DW_AT_GNU_macros : 0x0
> <1><66>: Abbrev Number: 2 (DW_TAG_subprogram)
> <67> DW_AT_external: 1
> <67> DW_AT_name: (indirect string, offset: 0x27c8): main
> <6b> DW_AT_decl_file : 1
> <6c> DW_AT_decl_line : 3
> <6d> DW_AT_decl_column : 5
> <6e> DW_AT_type: <0x72>
> [...]
> ~
>
> Notice however how DW_AT_GNU_macros appears in the latter "abstract"
> compilation unit, but not in the "DW_AT_name: " "concrete"
> compilation unit.
>
> When GDB wants to access the macros visible in the current function, it
> looks up the compilation unit for the current PC, and that finds the
> "" compilation unit, since that is the concrete one with the
> DW_AT_low_pc / DW_AT_high_pc ranges. But since that compilation unit does
> not have the DW_AT_GNU_macros attribute, GDB does not find the macro debug
> information at all:
>
> $ gdb ./macro
> ...
> (gdb) start
> Temporary breakpoint 1 at 0x1192: file macro.c, line 3.
> Starting program: /tmp/macro
>
> Temporary breakpoint 1, main () at macro.c:3
> 3 int main () { return ZERO; }
> (gdb) p ZERO
> No symbol "ZERO" in current context.
>
> Looking at the DWARF5 specification, I did not find anything suggesting that
> DW_AT_abstract_origin would also cause the abstract origin's compile unit's
> properties like DW_AT_GNU_macros to also be "inlined" into the concrete
> compile unit.
>
> So... this seems like a compiler bug to me. How is this officially supposed
> to work? How is the debugger supposed to find the macro info for a PC of a
> function described by the concrete compilation unit?
I have no idea how DWARF intends it to work. So - you're a debugger guy - how
would you like the compiler to output things? Note ...
> The
> "<5e> DW_AT_stmt_list : 0x41"
> in the abstract compilation unit also looks suspect. The .debug_line info
> at offset 0x41 has no line number statements.
>
> Something made GCC emit the real line info:
>"<29> DW_AT_stmt_list : 0x0"
> in the concrete "" compilation unit.
> Why isn't DW_AT_GNU_macros emitted there instead too?
The information to generate the .debug_macro section isn't available at
link-time. I did expect the debug consumer to pick up DW_AT_GNU_macros
via the abstract origin. I'm quite sure that making the concrete CU
have a DW_AT_GNU_macros but pointing to the
[Bug fortran/97031] the content of a comment line breaks compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97031 --- Comment #4 from jean-pierre.flam...@univ-lille.fr --- see below: - Mail original - De: "kargl at gcc dot gnu.org" À: "jean-pierre flament" Envoyé: Dimanche 13 Septembre 2020 11:55:28 Objet: [Bug fortran/97031] the content of a comment line breaks compilation https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97031 --- Comment #3 from Steve Kargl --- On Sun, Sep 13, 2020 at 08:02:01AM +, jean-pierre.flam...@univ-lille.fr wrote: > > I just noticed that cpp recognizes the extensions .fpp .F and other uppercase > extensions. > This is why I added -cpp in the gfortran command (otherwise I have a > diagnostic > because of #ifdef's > > I have renamed my file with the .fpp extension; with "-cpp" in the gfortran > submission I get the same errors. > > If I compile the file with extension *.f or .fpp without -cpp > > 1) the compilation has no error > 2) a #ifdef...#endif is recognized even with a .f extension, without -cpp, in > my simple example, (I should check that the directive really is taken into > account !) > 3) IF I compile my full project in a makefile, the absence of "-cpp" in the > gfortran command induces > a "Illegal preprocessor directive" error in all the routines having that > #ifdef...#endif > I don't quite follow you. But, it come down to gfortran uses the C pre-processor when asked to pre-process a file. If you have a C language construct such as '/*' in your Fortran code it will cause problems. > In my remarks just above 2) and 3) I just wanted to point that, apprently, in addtion, gfortran+cpp seem to have a different behaviour when called in a makefile or in a simple command line. I can check that more. ===> as regards the intial point: do you find it normal that, processing a fortran file (and I imagine that CPP knows that point since it was launched within the gfortran command) CPP does not consider fortran comment lines as such, and ignores their content. In addition I noticed that there is a '*/' construct farther in the file in an other commented line (line = "... */ ...", and that thus all the stuff inbetween was ignored, suppresing all the declarations (character and others) ans some other statements; this explains the diagnostics of the compiler. another questions raises: the '*/' was within " ", i.e. a character string... a legal fortran statement. before commenting this line I had an other message reporting an end for file before the end of a comment (I don't remember exactly the formulation). That's why I finally decided to create the test file that you have, commenting all the lines with call's and the famous line = "" . I know understand what happened. but once again: cpp does not seem to understand the syntax of fortran ! this is very annoying !
[Bug c++/97022] -Werror flag aborts compilation of "current" git pull on main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97022 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Richard Biener --- .
