[Bug target/99718] [11 regression] ICE in new test case gcc.target/powerpc/pr98914.c for 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99718 --- Comment #12 from luoxhu at gcc dot gnu.org --- Not sure whether TARGET_DIRECT_MOVE_64BIT is the right MACRO to correctly differentiate m32 and m64?
[Bug target/99718] [11 regression] ICE in new test case gcc.target/powerpc/pr98914.c for 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99718 --- Comment #11 from luoxhu at gcc dot gnu.org --- Created attachment 50474 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50474=edit 32bit variable vec_insert LLVM also generates store-hit-load instruction: addi 3, 1, -16 rlwinm 4, 5, 2, 28, 29 stvx 2, 0, 3 stwx 6, 3, 4 lvx 2, 0, 3 blr .long 0 .quad 0 I didn't use "can't" in my reply, sorry that caused the confusion, we though it was inefficient to move SF to SI on 32bit mode , but it turns out also huge performance gain (46.704s -> 4.369s). Attached the patch that also support variable vec_insert for 32bit, testing on P8BE/PBLE/P9LE, could you please verify it on AIX? Will refine it and send to the mail-list to fix this P1 issue fundamentally.
[Bug target/99782] New: Compile time and memory hog w/ __int128 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99782
Bug ID: 99782
Summary: Compile time and memory hog w/ __int128 on aarch64
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: compile-time-hog, memory-hog
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: aarch64-linux-gnu
gcc-11.0.1-alpha20210321 snapshot (g:fc24ea2374259d401a46ce3526688b7e79d4cc13)
takes indefinite time and consumes inordinate memory when compiling the
following testcase w/ -O3:
int hb;
void
w4 (__int128 uv, int ng)
{
int vh;
for (vh = 0; vh < 14; ++vh)
{
++ng;
hb = (hb == uv) && ng;
}
}
% timeout 10 aarch64-linux-gnu-gcc-11.0.1 -O3 -c nujte7ga.c
zsh: exit 124 timeout 10 aarch64-linux-gnu-gcc-11.0.1 -O3 -c nujte7ga.c
(gdb) where
#0 0x778b2afa in memset () from /lib64/libc.so.6
#1 0x009b5a48 in memset (__len=, __ch=175,
__dest=0x7ffe8239c000) at /usr/include/bits/string_fortified.h:56
#2 ggc_internal_alloc (size=size@entry=402653184, f=f@entry=0x0, s=s@entry=0,
n=n@entry=1)
at
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210321/work/gcc-11-20210321/gcc/ggc-page.c:1400
#3 0x00bbd629 in ggc_internal_alloc (s=402653184)
at
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210321/work/gcc-11-20210321/gcc/ggc.h:130
#4 ggc_realloc (x=0x7fff3c79e000, size=size@entry=402653184)
at
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210321/work/gcc-11-20210321/gcc/ggc-common.c:152
#5 0x00b03fa9 in emit_status::ensure_regno_capacity
(this=this@entry=0x243c920 )
at
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210321/work/gcc-11-20210321/gcc/emit-rtl.c:1229
#6 0x00b04046 in gen_reg_rtx (mode=mode@entry=E_DImode)
at
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210321/work/gcc-11-20210321/gcc/emit-rtl.c:1202
#7 0x00b1bd07 in force_reg (x=0x7750f9b0, mode=E_DImode)
at
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210321/work/gcc-11-20210321/gcc/explow.c:686
#8 force_reg (mode=E_DImode, x=0x7750f9b0)
at
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210321/work/gcc-11-20210321/gcc/explow.c:666
#9 0x00b1d9ab in use_anchored_address (x=0x7ffea54bade0)
at
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210321/work/gcc-11-20210321/gcc/explow.c:606
#10 use_anchored_address (x=0x7ffea54bade0)
at
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210321/work/gcc-11-20210321/gcc/explow.c:559
#11 0x00b40982 in expand_expr_real_1 (exp=,
target=, tmode=E_TImode, modifier=EXPAND_NORMAL,
alt_rtl=0x0, inner_reference_p=)
at
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210321/work/gcc-11-20210321/gcc/expr.c:10301
#12 0x00b411d4 in expand_expr_real_1 (exp=0x774ff000,
target=, tmode=E_TImode, modifier=EXPAND_NORMAL,
alt_rtl=0x0, inner_reference_p=)
at
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210321/work/gcc-11-20210321/gcc/gimple.h:2597
#13 0x00b3a764 in expand_expr (modifier=EXPAND_NORMAL, mode=E_TImode,
target=0x0, exp=0x774ff000)
at
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210321/work/gcc-11-20210321/gcc/expr.h:282
#14 expand_expr_real_2 (ops=, target=,
tmode=, modifier=EXPAND_NORMAL)
at
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210321/work/gcc-11-20210321/gcc/expr.c:8802
#15 0x00b41bdb in expand_expr_real_1 (exp=0x774ff438,
target=, tmode=E_VOIDmode, modifier=EXPAND_NORMAL,
alt_rtl=0x0, inner_reference_p=)
at
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210321/work/gcc-11-20210321/gcc/expr.c:10210
#16 0x00b4ba55 in expand_expr (modifier=EXPAND_NORMAL, mode=E_VOIDmode,
target=, exp=)
at
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210321/work/gcc-11-20210321/gcc/expr.h:282
#17 expand_operands (exp0=exp0@entry=0x774ff438,
exp1=exp1@entry=0x7760cd38, target=target@entry=0x0,
op0=op0@entry=0x7ffef370, op1=op1@entry=0x7ffef378,
modifier=modifier@entry=EXPAND_NORMAL)
at
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210321/work/gcc-11-20210321/gcc/expr.c:8110
#18 0x012996e0 in aarch64_gen_ccmp_next
(prep_seq=prep_seq@entry=0x7ffef558, gen_seq=gen_seq@entry=0x7ffef560,
prev=prev@entry=0x7ffea54badc8, cmp_code=86, treeop0=0x774ff438,
treeop1=0x7760cd38, bit_code=66)
at
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210321/work/gcc-11-20210321/gcc/config/aarch64/aarch64.c:21990
#19 0x01937fb5 in expand_ccmp_next (op=op@entry=0x774ff3a8,
code=code@entry=BIT_AND_EXPR, prev=prev@entry=0x7ffea54badc8,
prep_seq=0x7ffef558,
[Bug target/99781] New: [11 Regression] ICE in partial_subreg_p, at rtl.h:3144
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99781 Bug ID: 99781 Summary: [11 Regression] ICE in partial_subreg_p, at rtl.h:3144 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: asolokha at gmx dot com Target Milestone: --- Target: aarch64-linux-gnu g++-11.0.1-alpha20210321 snapshot (g:fc24ea2374259d401a46ce3526688b7e79d4cc13) ICEs when compiling gcc/testsuite/g++.target/aarch64/sve/dup_sel_2.C w/ -march=armv8-a+sve: % aarch64-linux-gnu-g++-11.0.1 -march=armv8-a+sve -c gcc/testsuite/g++.target/aarch64/sve/dup_sel_2.C during RTL pass: reload gcc/testsuite/g++.target/aarch64/sve/dup_sel_2.C: In function 'void foo(int32_t)': gcc/testsuite/g++.target/aarch64/sve/dup_sel_2.C:18:1: internal compiler error: in partial_subreg_p, at rtl.h:3144 18 | } | ^ 0x1042d61 partial_subreg_p(machine_mode, machine_mode) /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210321/work/gcc-11-20210321/gcc/rtl.h:3144 0x1042d61 partial_subreg_p(machine_mode, machine_mode) /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210321/work/gcc-11-20210321/gcc/rtl.h:3138 0x1042d61 process_bb_lives /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210321/work/gcc-11-20210321/gcc/lra-lives.c:744 0x104488c lra_create_live_ranges_1 /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210321/work/gcc-11-20210321/gcc/lra-lives.c:1394 0x10452df lra_create_live_ranges(bool, bool) /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210321/work/gcc-11-20210321/gcc/lra-lives.c:1463 0x1023aeb lra(_IO_FILE*) /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210321/work/gcc-11-20210321/gcc/lra.c:2376 0xfd9ba4 do_reload /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210321/work/gcc-11-20210321/gcc/ira.c:5834 0xfd9ba4 execute /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210321/work/gcc-11-20210321/gcc/ira.c:6020
[Bug fortran/99711] Crash when reading an allocated character array in namelist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99711 --- Comment #14 from Jerry DeLisle --- Created attachment 50473 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50473=edit -fdump-tree-original for failing case Attached the dump file of the failing case.
[Bug target/99780] New: ICE in verify_curr_properties, at passes.c:2152
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99780
Bug ID: 99780
Summary: ICE in verify_curr_properties, at passes.c:2152
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-checking, ice-on-valid-code, lto
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: aarch64-linux-gnu
gcc-11.0.1-alpha20210321 snapshot (g:fc24ea2374259d401a46ce3526688b7e79d4cc13)
ICEs when compiling the following testcase w/ -flto --param
stack-clash-protection-guard-size=12 --param
stack-clash-protection-probe-interval=12:
#pragma GCC optimize 1
void
empty (void)
{
}
% aarch64-linux-gnu-gcc-11.0.1 -flto --param
stack-clash-protection-guard-size=12 --param
stack-clash-protection-probe-interval=12 -c wf5ivtoh.c
wf5ivtoh.c: In function 'empty':
wf5ivtoh.c:5:1: error: stack clash guard size '16' must be equal to probing
interval '12'
5 | }
| ^
during IPA pass: targetclone
wf5ivtoh.c: At top level:
wf5ivtoh.c:5:1: internal compiler error: in verify_curr_properties, at
passes.c:2152
0x73e8d9 verify_curr_properties
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210321/work/gcc-11-20210321/gcc/passes.c:2152
0x73e8d9 verify_curr_properties
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210321/work/gcc-11-20210321/gcc/passes.c:2149
0xdf50c6 do_per_function
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210321/work/gcc-11-20210321/gcc/passes.c:1694
0xdf88d7 do_per_function
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210321/work/gcc-11-20210321/gcc/passes.c:2564
[Bug fortran/99711] Crash when reading an allocated character array in namelist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99711
--- Comment #13 from Jerry DeLisle ---
Looking at the -fdump-tree-originals in the two cases:
The working case:
{.elem_len=10, .rank=1, .type=6});
The failing case:
D.3962 = (sizetype) NON_LVALUE_EXPR <.cbulist_ru>;
.
{.elem_len=(unsigned long) SAVE_EXPR , .rank=1, .type=6});
Also one sees this:
Breakpoint 1, _gfortran_st_set_nml_var (dtp=0x7fffd2a0, var_addr=0x408910,
var_name=0x402053 "cbulist_ru", len=1, string_length=10, dtype=...)
at ../../../trunk/libgfortran/io/transfer.c:4597
4597{
(gdb) p *dtype
Structure has no component named operator*.
(gdb) p dtype
$1 = {elem_len = 14971996835529359360, version = 0, rank = 1 '\001',
type = 6 '\006', attribute = 0}
The call to _gfortran_st_set_nml_var is created by the frontend as shown in the
dump, the elem_len is bogus.
As far as I can tell then, the front-end is failing in the allocation
initializing the size correctly.
[Bug c/99779] [GCC-10.1.0]A bug when assign to a pointer by function which process the pointer inside.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99779 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- In C, it is unspecified which side of the equal gets evaluated first. So in this case (*fp = foo();): this could be done as int *fpp = fp; *fpp = foo(); OR: int t = foo(); *fp = t; BOTH are valid for C. C++11 and above have different rules with respect to sequence points.
[Bug fortran/99711] Crash when reading an allocated character array in namelist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99711
--- Comment #12 from Jerry DeLisle ---
This is interesting, compiling with the -g option for debugging.
Running a test case that is working with:
character(len=10), dimension(:), allocatable :: cbulist_ru ! explicit char
len
Breakpoint 1, nml_read_obj (dtp=dtp@entry=0x7fffd260,
nl=nl@entry=0x5184c0, offset=offset@entry=0,
pprev_nl=pprev_nl@entry=0x7fffd068,
nml_err_msg=nml_err_msg@entry=0x7fffd100 "Internal namelist read
error", clow=1, chigh=0, nml_err_msg_size=200)
at ../../../trunk/libgfortran/io/list_read.c:2886
2886 if (dtp->u.p.nml_read_error || !nl->touched)
(gdb) p nl
$1 = (namelist_info *) 0x5184c0
(gdb) p *nl
$2 = {type = BT_CHARACTER, var_name = 0x518530 "cbulist_ru",
mem_pos = 0x515e80, dtio_sub = 0x0, vtable = 0x0, touched = 1, len = 1,
var_rank = 1, size = 10, string_length = 10, dim = 0x518550, ls = 0x518570,
next = 0x0}
string_length as expected.
Running the failing test case with:
character(len=:), dimension(:), allocatable :: cbulist_ru ! deferred len
Breakpoint 1, nml_read_obj (dtp=dtp@entry=0x7fffd240,
nl=nl@entry=0x5184c0, offset=offset@entry=0,
pprev_nl=pprev_nl@entry=0x7fffd048,
nml_err_msg=nml_err_msg@entry=0x7fffd0e0 "Internal namelist read
error", clow=1, chigh=0, nml_err_msg_size=200)
at ../../../trunk/libgfortran/io/list_read.c:2886
2886 if (dtp->u.p.nml_read_error || !nl->touched)
(gdb) p nl->string_length
$13 = 10
(gdb) p *nl
$14 = {type = BT_CHARACTER, var_name = 0x518530 "cbulist_ru",
mem_pos = 0x515e80, dtio_sub = 0x0, vtable = 0x0, touched = 1, len = 1,
var_rank = 1, size = 967676983855022080, string_length = 10, dim = 0x518550,
ls = 0x518570, next = 0x0}
(gdb) p *nl->dim
$15 = {_stride = 1, lower_bound = 1, _ubound = 5}
size is messed up badly.
[Bug c/99779] New: [GCC-10.1.0]A bug when assign to a pointer by function which process the pointer inside.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99779
Bug ID: 99779
Summary: [GCC-10.1.0]A bug when assign to a pointer by function
which process the pointer inside.
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: xin@compiler-dev.com
Target Milestone: ---
As shown in the following testcase：
int helloa = 12;
int hellob = 13;
int *fp=
int __attribute__((noinline)) foo()
{
fp=
return 15;
}
int main()
{
*fp = foo();
printf("helloa=%d,hellob=%d\n",helloa,hellob);
}
compile with gcc-10.1.0 and any optimization, the result is
helloa=15,hellob=13
but with clang-10.0.1, the result is
helloa=12,hellob=15
According to this testcase, in my opinion ,the clang's result is right.
gcc do not process it correctly.
[Bug target/99703] gcc-10.2.0 with Via C3 Eden: configure: error: Intel CET must be enabled on Intel CET enabled host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99703 --- Comment #33 from Worx --- Let me know, if you want something from me.
[Bug target/99766] [11 Regression] ICE: unable to generate reloads with SVE code since r11-7807-gbe70bb5e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99766 --- Comment #6 from Vladimir Makarov --- (In reply to rsand...@gcc.gnu.org from comment #5) > I wonder if the CT_RELAXED_MEMORY cases should be following > on from CT_MEMORY rather than CT_SPECIAL_MEMORY. They're really > normal memory constraints that just happen to accept more than > a standard constraint. Yes, this is the right question. The patch I am working on treats CT_SPECIAL_MEMORY the same way as CT_MEMORY everywhere although it is enough to do this only in lra-constraints.c. After finishing testing I'll commit the patch. Unfortunately compiler farm arm64 machines are too slow (2 runs of gcc tests take almost 8 hours to run with -j8). I guess I'll fix it tomorrow.
[Bug c++/99778] New: Spurious -Wzero-as-null-pointer-constant on three-way comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99778
Bug ID: 99778
Summary: Spurious -Wzero-as-null-pointer-constant on three-way
comparisons
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: headch at gmail dot com
Target Milestone: ---
Consider the following code:
#include
#include
int main() {
std::strong_ordering o = 1 <=> 2;
if(o == 0) {
std::cout << "equal\n";
} else {
std::cout << "unequal\n";
}
return 0;
}
When compiled with -Wzero-as-null-pointer-constant, this generates a warning on
the “if” line.
This sounds almost the same as bug #95242, except that bug is closed as fixed
for 10.2, and I am running 10.2.0 and still get this problem; also, the code
quoted in that bug does not generate a warning for me, while this code still
does.
[Bug debug/99654] Incorrect DW_AT_entry_pc values for inlined function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99654 --- Comment #1 from Will Cohen --- Jan Kratochvil at Red Hat mentioned that the DW_AT_entry_pc values looked reasonable when -gno-as-locview-support was added to the command line. I checked and they do look more reasonable. Does this mean an issue with gas from binutils-2.36.1-7.fc35.x86_64 ?
[Bug tree-optimization/55288] Improve handling/suppression of maybe-uninitialized warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55288 Martin Sebor changed: What|Removed |Added Target Milestone|--- |4.9.0 CC||msebor at gcc dot gnu.org --- Comment #3 from Martin Sebor --- The false positive was fixed in r202496. Let me add the test. Clang implements attribute uninitialized (with slightly different meaning than what's being requested here) so adding support for it to GCC to help control warnings might make sense: https://clang.llvm.org/docs/AttributeReference.html#uninitialized
[Bug tree-optimization/99777] [11 Regression] ICE in build2, at tree.c:4869 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99777 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Seems to be a fold-const.c bug.
[Bug tree-optimization/99777] [11 Regression] ICE in build2, at tree.c:4869 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99777
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Target Milestone|--- |11.0
Summary|ICE in build2, at |[11 Regression] ICE in
|tree.c:4869 with -O3|build2, at tree.c:4869 with
||-O3
CC||jakub at gcc dot gnu.org
Priority|P3 |P1
Ever confirmed|0 |1
Last reconfirmed||2021-03-25
--- Comment #1 from Jakub Jelinek ---
Started with r11-3705-gdae673abd37d400408959497e50fe1f3fbef5533
Testcase without any includes:
template
constexpr inline const T&
min(const T& a, const T& b) { if (b < a) return b; return a; }
template
constexpr inline const T&
max(const T& a, const T& b) { if (a < b) return b; return a; }
extern int var_142;
extern int a, c;
long h;
unsigned long long e;
signed char d;
extern short arr_323[][7][5][30];
void test(long long b, short f[][17][25][22][20])
{
for (char i = 0; i < 7; i += 3)
for (unsigned char l = e; l < 5; l += 2) {
if (max(0LL, min(7LL, b)))
for (bool j = 0; j < 1; j = b) {
for (unsigned k = d; k < 20; k++)
h = f[0][i][l][b][k];
for (int m = 0; m < 5; m++)
arr_323[c][i][l][m] = 0;
}
for (int n = 0; n < 4; n += a)
var_142 = n;
}
}
[Bug tree-optimization/55060] False un-initialized variable warnings (fixed, add testcase to testsuite)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55060 --- Comment #8 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:e88ca9f42306e291d3cb2d34dd7f2b017a3c1e52 commit r11-7841-ge88ca9f42306e291d3cb2d34dd7f2b017a3c1e52 Author: Martin Sebor Date: Thu Mar 25 17:23:06 2021 -0600 PR tree-optimization/55060 - False un-initialized variable warnings gcc/testsuite/ChangeLog: PR tree-optimization/55060 * gcc.dg/uninit-pr55060.c: New.
[Bug tree-optimization/55060] False un-initialized variable warnings (fixed, add testcase to testsuite)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55060 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||msebor at gcc dot gnu.org Target Milestone|--- |5.0 --- Comment #7 from Martin Sebor --- Bisection points to r217125 as the fix. Let me add the test and resolve it.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 55060, which changed state. Bug 55060 Summary: False un-initialized variable warnings (fixed, add testcase to testsuite) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55060 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 54804, which changed state. Bug 54804 Summary: -Wuninitialized fails to warn about uninitialized local union https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54804 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug middle-end/54804] -Wuninitialized fails to warn about uninitialized local union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54804 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED CC||msebor at gcc dot gnu.org Status|NEW |RESOLVED Target Milestone|--- |7.0 Keywords||diagnostic --- Comment #2 from Martin Sebor --- GCC 7 and later warn for both. The change was introduced in r245840. pr54804.c: In function ‘yyparse’: pr54804.c:7:13: warning: ‘yylval’ is used uninitialized [-Wuninitialized] 7 | return yylval; | ^~ pr54804.c:6:20: note: ‘yylval’ declared here 6 | union YYSTYPE yylval; |^~ pr54804.c: In function ‘yyparse_with_struct’: pr54804.c:16:13: warning: ‘xxlval’ is used uninitialized [-Wuninitialized] 16 | return xxlval; | ^~ pr54804.c:15:15: note: ‘xxlval’ declared here 15 | struct s xxlval; | ^~
[Bug tree-optimization/83336] [meta-bug] Issues with displaying inlining chain for middle-end warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83336 Bug 83336 depends on bug 53917, which changed state. Bug 53917 Summary: Wuninitialized warning points to place where variable doesn't occur https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53917 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 53917, which changed state. Bug 53917 Summary: Wuninitialized warning points to place where variable doesn't occur https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53917 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug tree-optimization/40635] bogus name and location in 'may be used uninitialized' warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40635 Martin Sebor changed: What|Removed |Added CC||pa...@matos-sorge.com --- Comment #15 from Martin Sebor --- *** Bug 53917 has been marked as a duplicate of this bug. ***
[Bug middle-end/53917] Wuninitialized warning points to place where variable doesn't occur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53917 Martin Sebor changed: What|Removed |Added Resolution|--- |DUPLICATE CC||msebor at gcc dot gnu.org Status|NEW |RESOLVED --- Comment #8 from Martin Sebor --- The underlying problem with the test case in comment #1 is the same as the one discussed in bug 40635 comment #13. With the patch there applied, GCC issues a note after the warning that points to the uninitialized variable: pr53917-c1.c: In function ‘fn4’: pr53917-c1.c:38:8: warning: ‘valid’ may be used uninitialized [-Wmaybe-uninitialized] 38 | if (fn3 (_t1_rw_fsm_data.tag_mem_config)) |^ pr53917-c1.c:25:9: note: ‘valid’ was declared here 25 | int valid; | ^ There may be more that can be done to improve the context of the warning to make it clearer but we can track those improvements separately. *** This bug has been marked as a duplicate of bug 40635 ***
[Bug tree-optimization/99777] New: ICE in build2, at tree.c:4869 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99777
Bug ID: 99777
Summary: ICE in build2, at tree.c:4869 with -O3
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vsevolod.livinskij at frtk dot ru
Target Milestone: ---
The error is not specific to skylake-avx512, I have a reproducer that shows it.
Reproducer:
#include
extern int var_142;
extern int a, c;
long h;
unsigned long long e;
signed char d;
extern short arr_323[][7][5][30];
void test(long long b,
short f[][17][25][22][20]) {
for (char i = 0; i < 7; i += 3)
for (unsigned char l = e; l < 5; l += 2) {
if (std::max((long long)0, std::min((long long)7, b)))
for (bool j = 0; j < 1; j = b) {
for (unsigned k = d; k < 20; k++)
h = f[0][i][l][b][k];
for (int m = 0; m < 5; m++)
arr_323[c][i][l][m] = 0;
}
for (int n = 0; n < 4; n += a)
var_142 = n;
}
}
Error:
>$ g++ -O3 -march=skylake-avx512 func.cpp -c
during GIMPLE pass: lim
func.cpp: In function ‘void test(long long int, short int
(*)[17][25][22][20])’:
func.cpp:10:6: internal compiler error: in build2, at tree.c:4869
10 | void test(long long b,
| ^~~~
0x85386f build2(tree_code, tree_node*, tree_node*, tree_node*)
gcc/gcc_src/gcc/tree.c:4869
0xddb96f build2_loc
gcc/gcc_src/gcc/tree.h:4407
0xddb96f fold_build2_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
gcc/gcc_src/gcc/fold-const.c:13736
0xde8de3 extract_muldiv_1
gcc/gcc_src/gcc/fold-const.c:6976
0xdea422 extract_muldiv
gcc/gcc_src/gcc/fold-const.c:6662
0xdea422 extract_muldiv
gcc/gcc_src/gcc/fold-const.c:6662
0xdea422 extract_muldiv
gcc/gcc_src/gcc/fold-const.c:6662
0xdd6bb1 fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
gcc/gcc_src/gcc/fold-const.c:11486
0xddb94d fold_build2_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
gcc/gcc_src/gcc/fold-const.c:13734
0x1c3b096 aff_combination_add_elt(aff_tree*, tree_node*,
generic_wide_int > const&)
gcc/gcc_src/gcc/tree-affine.c:187
0x1c3b3d5 aff_combination_add(aff_tree*, aff_tree*)
gcc/gcc_src/gcc/tree-affine.c:215
0x124fc0f mem_refs_may_alias_p
gcc/gcc_src/gcc/tree-ssa-loop-im.c:1718
0x124fc83 refs_independent_p
gcc/gcc_src/gcc/tree-ssa-loop-im.c:2703
0x12502b4 ref_indep_loop_p
gcc/gcc_src/gcc/tree-ssa-loop-im.c:2764
0x1255ff4 can_sm_ref_p
gcc/gcc_src/gcc/tree-ssa-loop-im.c:2832
0x1255ff4 find_refs_for_sm
gcc/gcc_src/gcc/tree-ssa-loop-im.c:2853
0x1255ff4 store_motion_loop
gcc/gcc_src/gcc/tree-ssa-loop-im.c:2889
0x1255ddc store_motion_loop
gcc/gcc_src/gcc/tree-ssa-loop-im.c:2896
0x1255ddc store_motion_loop
gcc/gcc_src/gcc/tree-ssa-loop-im.c:2896
0x1258262 do_store_motion
gcc/gcc_src/gcc/tree-ssa-loop-im.c:2911
gcc version 11.0.1 20210323 (6b1f841ce0ccf30eda7896ba5ab0aa94c72307b2) (GCC)
[Bug tree-optimization/52523] Missing "uninitialized" warning (VOP, taking address of var)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52523 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org Status|NEW |RESOLVED Keywords||diagnostic Resolution|--- |FIXED Target Milestone|--- |11.0 Known to fail||10.2.0, 4.7.0, 4.8.4, ||4.9.4, 5.5.0, 6.4.0, 7.2.0, ||8.3.0, 9.1.0 --- Comment #2 from Martin Sebor --- GCC 11 (since g:b825a22890740f341eae566af27e18e528cd29a7) diagnoses passing an uninitialized object by const reference by -Wmaybe-uninitialized: $ g++ -S -Wall pr52523.C pr52523.C: In function ‘int main()’: pr52523.C:6:13: warning: ‘x’ is used uninitialized [-Wuninitialized] 6 | std::cout << x; | ~~^~~~ pr52523.C:5:7: note: ‘x’ declared here 5 | int x; | ^
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 52523, which changed state. Bug 52523 Summary: Missing "uninitialized" warning (VOP, taking address of var) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52523 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 52167, which changed state. Bug 52167 Summary: self-initialization should at least produce use-of-uninitialized warning https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52167 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/52167] self-initialization should at least produce use-of-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52167 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Known to fail||10.2.0, 4.1.0, 4.8.4, ||4.9.4, 5.5.0, 6.4.0, 7.2.0, ||8.3.0, 9.1.0 Target Milestone|--- |11.0 Status|NEW |RESOLVED Component|c++ |tree-optimization --- Comment #8 from Martin Sebor --- GCC 11 (since g:b825a22890740f341eae566af27e18e528cd29a7) diagnoses passing an uninitialized object by const reference by -Wmaybe-uninitialized: $ g++ -S -Wall pr52167.C pr52167.C: In function ‘int main()’: pr52167.C:8:23: warning: ‘foo’ may be used uninitialized [-Wmaybe-uninitialized] 8 | const string foo(foo); | ^ In file included from /build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/string:55, from /build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/locale_classes.h:40, from /build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/ios_base.h:41, from /build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/ios:42, from /build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/ostream:38, from /build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/iostream:39, from pr52167.C:1: /build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:448:7: note: by argument 2 of type ‘const std::__cxx11::basic_string&’ to ‘std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char; _Traits = std::char_traits; _Alloc = std::allocator]’ declared here 448 | basic_string(const basic_string& __str) | ^~~~ pr52167.C:8:16: note: ‘foo’ declared here 8 | const string foo(foo); |^~~
[Bug tree-optimization/48483] Construct from yourself w/o warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48483 --- Comment #23 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:26e80a496853b21da1886779d97ff613ccb64f9b commit r11-7840-g26e80a496853b21da1886779d97ff613ccb64f9b Author: Martin Sebor Date: Thu Mar 25 16:08:00 2021 -0600 PR tree-optimization/48483 - Construct from yourself w/o warning gcc/testsuite/ChangeLog: PR tree-optimization/48483 * g++.dg/warn/uninit-pr48483.C: New test.
[Bug c++/52167] self-initialization should at least produce use-of-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52167 Bug 52167 depends on bug 48483, which changed state. Bug 48483 Summary: Construct from yourself w/o warning https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48483 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/48483] Construct from yourself w/o warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48483
Martin Sebor changed:
What|Removed |Added
Known to work||10.2.0, 11.0, 5.1.0
Status|NEW |RESOLVED
Component|c++ |tree-optimization
Resolution|--- |FIXED
CC||msebor at gcc dot gnu.org
--- Comment #22 from Martin Sebor ---
GCC diagnoses the test case in comment #0 at -O0 (one warning) as well as above
(two warnings) since r209443:
pr48483.C: In function ‘int main()’:
pr48483.C:12:22: warning: ‘a.A::b’ is used uninitialized [-Wuninitialized]
12 | A a(a.b);
| ^
pr48483.C:12:17: note: ‘a’ declared here
12 | A a(a.b);
| ^
With -O1 and higher it also diagnoses the test case in comment #2:
In member function ‘int A::TheInt()’,
inlined from ‘int main()’ at pr48483-c2.C:11:16:
pr48483-c2.C:6:33: warning: ‘a.A::a’ is used uninitialized [-Wuninitialized]
6 | int TheInt(){return a;}
| ^
pr48483-c2.C: In function ‘int main()’:
pr48483-c2.C:11:17: note: ‘a’ declared here
11 | A a(a.TheInt());
| ^
At -O0 and above it also diagnoses the test case in comment #3 (also since
r209443)
pr48483-c3.C:5:12: warning: ‘s.main()::S::a’ is used uninitialized
[-Wuninitialized]
5 | return s.a;
|^
pr48483-c3.C:4:23: note: ‘s’ declared here
4 | struct S { int a; } s;
| ^
The test case in comment #16 isn't diagnosed but that one is sufficiently
different that I think it should be tracked separately (if it isn't yet; I
suspect there probably is a duplicate somewhere but if not I'll add one).
With that, let me add the passing test cases and resolve this as fixed.
[Bug ipa/99776] New: missed optimization for dead code elimination at -O3 (vs. -O1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99776
Bug ID: 99776
Summary: missed optimization for dead code elimination at -O3
(vs. -O1)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
CC: marxin at gcc dot gnu.org
Target Milestone: ---
[687] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/11.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.1 20210325 (experimental) [master revision
08103e4d6ad:4e4f8ee0bf5:a29124d28253cdf603ba1977db2f09c9f233fea5] (GCC)
[688] %
[688] % gcctk -O1 -S -o small_O1.s small.c
[689] % gcctk -O3 -S -o small_O3.s small.c
[690] %
[690] % wc small_O1.s small_O3.s
23 52 455 small_O1.s
37 82 682 small_O3.s
60 134 1137 total
[691] %
[691] % grep foo small_O1.s
[692] % grep foo small_O3.s
callfoo
[693] %
[693] % cat small.c
extern void foo(void);
static int a[2], b, *c[2];
int main() {
for (b = 0; b < 2; b++)
c[b] = [1];
if (!c[0])
foo();
return 0;
}
[Bug tree-optimization/44547] -Wuninitialized reports false warning in nested switch statements (missed switch optimization)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44547 --- Comment #7 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:1b229a305091f0a9c64e5be3c1af5ef62b75e3cb commit r11-7839-g1b229a305091f0a9c64e5be3c1af5ef62b75e3cb Author: Martin Sebor Date: Thu Mar 25 15:31:46 2021 -0600 New test for PR tree-optimization/44547 - -Wuninitialized reports false warning in nested switch statements. gcc/testsuite/ChangeLog: * gcc.dg/uninit-pr44547.c: New.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 44547, which changed state. Bug 44547 Summary: -Wuninitialized reports false warning in nested switch statements (missed switch optimization) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44547 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/44547] -Wuninitialized reports false warning in nested switch statements (missed switch optimization)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44547 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED CC||msebor at gcc dot gnu.org Status|NEW |RESOLVED --- Comment #6 from Martin Sebor --- The warning is no longer issued. Bisection points to r189173 as the "fix" at -O2 and to r260350 as the revision when it stopped being issued at -O1. Let me add the test and resolve this as fixed.
[Bug target/99766] [11 Regression] ICE: unable to generate reloads with SVE code since r11-7807-gbe70bb5e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99766 rsandifo at gcc dot gnu.org changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #5 from rsandifo at gcc dot gnu.org --- I wonder if the CT_RELAXED_MEMORY cases should be following on from CT_MEMORY rather than CT_SPECIAL_MEMORY. They're really normal memory constraints that just happen to accept more than a standard constraint.
[Bug tree-optimization/40635] bogus name and location in 'may be used uninitialized' warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40635 Martin Sebor changed: What|Removed |Added Target Milestone|--- |12.0 Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #14 from Martin Sebor --- Let me handle this for GCC 12.
[Bug tree-optimization/40635] bogus name and location in 'may be used uninitialized' warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40635
Martin Sebor changed:
What|Removed |Added
Last reconfirmed|2019-02-24 00:00:00 |2021-3-25
Known to fail|9.0 |10.2.0, 11.0, 9.3.0
--- Comment #13 from Martin Sebor ---
I think the reason why the location for the last PHI argument isn't set is
because the argument is itself a PHI whose arguments have different locations:
[local count: 1073741824]:
# _16 = PHI <[pr40635.c:21:20] -1(13), [pr40635.c:19:15] s42_9(7),
[pr40635.c:28:16] -1(15), s42_21(9)>
[pr40635.c:37:5] foo ();
[pr40635.c:38:8] _28 = _16 < 0;
[pr40635.c:38:8] _5 = (int) _28;
[pr40635.c:38:8] _4 = -_5;
return _4;
[local count: 39298952]:
[local count: 383953502]:
# s42_21 = PHI <[pr40635.c:13:9] s42_18(D)(12), [pr40635.c:19:15] s42_9(14)>
goto ; [100.00%]
}
Even if -Wuninitialized is changed to extract the location from the
uninitialized argument to s42_21(9), it doesn't use it because it prefers to
use the location of the statement where the variable us used. -Wuninitialized
usually prints a note pointing to the uninitialized variable but it has the
code below that guards is:
if (xloc.file != floc.file
|| linemap_location_before_p (line_table, location, cfun_loc)
|| linemap_location_before_p (line_table, cfun->function_end_locus,
location))
inform (DECL_SOURCE_LOCATION (var), "%qD was declared here", var);
Because the location of the variable is in a different function than the
current one the note isn't printed. The patch below removes this IMO pointless
test and improves the output a bit:
pr40635.c:38:8: warning: ‘s42’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
38 | if (sockt_rd < 0)
|^
pr40635.c:13:9: note: ‘s42’ was declared here
13 | int s42, x;
| ^~~
diff --git a/gcc/tree-ssa-uninit.c b/gcc/tree-ssa-uninit.c
index 0800f596ab1..a578a596fee 100644
--- a/gcc/tree-ssa-uninit.c
+++ b/gcc/tree-ssa-uninit.c
@@ -126,8 +126,6 @@ warn_uninit (enum opt_code wc, tree t, tree expr, tree var,
const char *gmsgid, void *data, location_t phiarg_loc)
{
gimple *context = (gimple *) data;
- location_t location, cfun_loc;
- expanded_location xloc, floc;
/* Ignore COMPLEX_EXPR as initializing only a part of a complex
turns in a COMPLEX_EXPR with the not initialized part being
@@ -170,6 +168,7 @@ warn_uninit (enum opt_code wc, tree t, tree expr, tree var,
|| TREE_NO_WARNING (expr))
return;
+ location_t location;
if (context != NULL && gimple_has_location (context))
location = gimple_location (context);
else if (phiarg_loc != UNKNOWN_LOCATION)
@@ -178,9 +177,7 @@ warn_uninit (enum opt_code wc, tree t, tree expr, tree var,
location = DECL_SOURCE_LOCATION (var);
location = linemap_resolve_location (line_table, location,
LRK_SPELLING_LOCATION, NULL);
- cfun_loc = DECL_SOURCE_LOCATION (cfun->decl);
- xloc = expand_location (location);
- floc = expand_location (cfun_loc);
+
auto_diagnostic_group d;
if (warning_at (location, wc, gmsgid, expr))
{
@@ -188,11 +185,7 @@ warn_uninit (enum opt_code wc, tree t, tree expr, tree
var,
if (location == DECL_SOURCE_LOCATION (var))
return;
- if (xloc.file != floc.file
- || linemap_location_before_p (line_table, location, cfun_loc)
- || linemap_location_before_p (line_table, cfun->function_end_locus,
- location))
- inform (DECL_SOURCE_LOCATION (var), "%qD was declared here", var);
+ inform (DECL_SOURCE_LOCATION (var), "%qD was declared here", var);
}
}
[Bug c++/99672] std::source_location yield different column numbers between free function and template functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99672 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug c++/99672] std::source_location yield different column numbers between free function and template functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99672 --- Comment #4 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:2132a36370e282d8c0ed0c97e5bfb952e23dbfa1 commit r11-7836-g2132a36370e282d8c0ed0c97e5bfb952e23dbfa1 Author: Jakub Jelinek Date: Thu Mar 25 21:35:11 2021 +0100 c++: Fix source_location inconsistency between calls from templates and non-templates [PR99672] The srcloc19.C testcase shows inconsistency in std::source_location::current() locations between calls from templates and non-templates. The location used by __builtin_source_location comes in both cases from input_location which is set on it by bot_manip when handling the default argument, called during finish_call_expr. The problem is that in templates that input_location comes from the CALL_EXPR we built earlier and that has the combined locus with range between first character of the function name and closing paren with caret on the opening paren, so something printed as caret as: foobar (); ~~^~ But outside of templates, finish_call_expr is called when input_location is just the closing paren token, i.e. foobar (); ^ and only after that returns we create the combined location and set the CALL_EXPR location to that. So, it means std::source_location::current() reports in templates the column of opening (, while outside of templates closing ). The following patch makes it consistent by creating the combined location already before calling finish_call_expr and temporarily overriding input_location to that. 2021-03-25 Jakub Jelinek PR c++/99672 * parser.c (cp_parser_postfix_expression): For calls, create combined_loc and temporarily set input_location to it before calling finish_call_expr. * g++.dg/concepts/diagnostic2.C: Adjust expected caret line. * g++.dg/cpp1y/builtin_location.C (f4, n6): Move #line directives to match locus changes. * g++.dg/cpp2a/srcloc1.C: Adjust expected column numbers. * g++.dg/cpp2a/srcloc2.C: Likewise. * g++.dg/cpp2a/srcloc15.C: Likewise. * g++.dg/cpp2a/srcloc16.C: Likewise. * g++.dg/cpp2a/srcloc19.C: New test. * g++.dg/modules/adhoc-1_b.C: Adjust expected column numbers and caret line. * g++.dg/modules/macloc-1_c.C: Adjust expected column numbers. * g++.dg/modules/macloc-1_d.C: Likewise. * g++.dg/plugin/diagnostic-test-expressions-1.C: Adjust expected caret line. * testsuite/18_support/source_location/consteval.cc (main): Adjust expected column numbers. * testsuite/18_support/source_location/1.cc (main): Likewise.
[Bug c++/93383] ICE on accessing field of a structure which is non-type template parameter, -std=c++2a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93383 Marek Polacek changed: What|Removed |Added CC||wouter at voti dot nl --- Comment #9 from Marek Polacek --- *** Bug 99775 has been marked as a duplicate of this bug. ***
[Bug c++/99775] segmentation fault on template variable as template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99775 Marek Polacek changed: What|Removed |Added Resolution|--- |DUPLICATE CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #1 from Marek Polacek --- Dup. *** This bug has been marked as a duplicate of bug 93383 ***
[Bug c++/94751] [9/10/11 Regression] ICE on invalid code in maybe_instantiate_noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94751 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Marek Polacek --- Fixed in GCC 11.
[Bug c++/99775] New: segmentation fault on template variable as template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99775
Bug ID: 99775
Summary: segmentation fault on template variable as template
parameter
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wouter at voti dot nl
Target Milestone: ---
Segmentation fault with 10.x (on gotbolt ) on this code:
#include
template< int N >
constexpr auto immutable_string_decimal = std::array< char, 1 >( '0' + N );
template< std::array strings > struct component_name { };
template< int n >
struct blink : component_name< immutable_string_decimal< 8 > > { };
[Bug c++/94751] [9/10/11 Regression] ICE on invalid code in maybe_instantiate_noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94751 --- Comment #7 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:d4e0bdbc036644401f9de49f594b2bb16b287381 commit r11-7835-gd4e0bdbc036644401f9de49f594b2bb16b287381 Author: Marek Polacek Date: Fri Mar 5 15:46:50 2021 -0500 c++: ICE on invalid with inheriting constructors [PR94751] This is an ICE on invalid where we crash because since r269032 we keep error_mark_node around instead of using noexcept_false_spec when things go wrong; see the walk_field_subobs hunk. We crash in deduce_inheriting_ctor which calls synthesized_method_walk to deduce the exception-specification, but fails to do so in this case, because the testcase is invalid so get_nsdmi returns error_mark_node for the member 'c', and per r269032 the error_mark_node propagates back to deduce_inheriting_ctor which subsequently calls build_exception_variant whereon we crash. I think we should return early if the deduction fails and I decided to call mark_used to get an error right away instead of hoping that it would get called later. My worry is that we could forget that there was an error and think that we just deduced noexcept(false). And then I noticed that the test still crashes in C++98. Here again we failed to deduce the exception-specification in implicitly_declare_fn, but nothing reported an error between synthesized_method_walk and the assert. Well, not much we can do except calling synthesized_method_walk again, this time in the verbose mode and making sure that we did get an error. gcc/cp/ChangeLog: PR c++/94751 * call.c (build_over_call): Maybe call mark_used in case deduce_inheriting_ctor fails and return error_mark_node. * cp-tree.h (deduce_inheriting_ctor): Adjust declaration. * method.c (deduce_inheriting_ctor): Return bool if the deduction fails. (implicitly_declare_fn): If raises is error_mark_node, call synthesized_method_walk with diag being true. gcc/testsuite/ChangeLog: PR c++/94751 * g++.dg/cpp0x/inh-ctor37.C: New test.
[Bug c++/99745] ICE when parameter pack not expanded in bit field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99745 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug c++/99745] ICE when parameter pack not expanded in bit field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99745 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:0b86a6438191f720bebf880a2b932cd97d10229a commit r11-7834-g0b86a6438191f720bebf880a2b932cd97d10229a Author: Jakub Jelinek Date: Thu Mar 25 21:06:09 2021 +0100 c++: Diagnose bare parameter packs in bitfield widths [PR99745] The following invalid tests ICE because we don't diagnose (and drop) bare parameter packs in bitfield widths. 2021-03-25 Jakub Jelinek PR c++/99745 * decl2.c (grokbitfield): Diagnose bitfields containing bare parameter packs and don't set DECL_BIT_FIELD_REPRESENTATIVE in that case. * g++.dg/cpp0x/variadic181.C: New test.
[Bug c++/99331] [8/9/10 Regression] -Wconversion false-positive in immediate context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99331 Marek Polacek changed: What|Removed |Added Summary|[8/9/10/11 Regression] |[8/9/10 Regression] |-Wconversion false-positive |-Wconversion false-positive |in immediate context|in immediate context --- Comment #6 from Marek Polacek --- Fixed on trunk thus far.
[Bug c++/99331] [8/9/10/11 Regression] -Wconversion false-positive in immediate context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99331
--- Comment #5 from CVS Commits ---
The master branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:9efd72d28956eb79c7fca38e3c959733a3bb25bb
commit r11-7833-g9efd72d28956eb79c7fca38e3c959733a3bb25bb
Author: Marek Polacek
Date: Thu Mar 4 20:20:40 2021 -0500
c++: -Wconversion vs value-dependent expressions [PR99331]
This PR complains that we issue a -Wconversion warning in
template struct X {};
template X foo();
saying "conversion from 'long unsigned int' to 'int' may change value".
While it's not technically wrong, I suspect -Wconversion warnings aren't
all that useful for value-dependent expressions. So this patch disables
them. This is a regression that started with r241425:
@@ -7278,7 +7306,7 @@ convert_template_argument (tree parm,
val = error_mark_node;
}
}
- else if (!dependent_template_arg_p (orig_arg)
+ else if (!type_dependent_expression_p (orig_arg)
&& !uses_template_parms (t))
/* We used to call digest_init here. However, digest_init
will report errors, which we don't want when complain
Here orig_arg is SIZEOF_EXPR; dependent_template_arg_p (orig_arg) was
true, but type_dependent_expression_p (orig_arg) is false so we warn in
convert_nontype_argument.
gcc/cp/ChangeLog:
PR c++/99331
* call.c (build_converted_constant_expr_internal): Don't emit
-Wconversion warnings.
gcc/testsuite/ChangeLog:
PR c++/99331
* g++.dg/warn/Wconversion5.C: New test.
[Bug analyzer/99774] False positive from -Wanalyzer-malloc-leak in loop (qemu:libvhost-user.c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99774 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-03-25 Status|UNCONFIRMED |ASSIGNED
[Bug analyzer/99774] New: False positive from -Wanalyzer-malloc-leak in loop (qemu:libvhost-user.c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99774
Bug ID: 99774
Summary: False positive from -Wanalyzer-malloc-leak in loop
(qemu:libvhost-user.c)
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Created attachment 50472
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50472=edit
Reduced reproducer
I got a report about a false leak warning from the analyzer on some code in
qemu.
I'm attaching a reduced reproducer from qemu which triggers the issue:
$ ./xgcc -B. -S -fanalyzer ../../src/libvhost-user-1.c
../../src/libvhost-user-1.c: In function ‘vu_check_queue_inflights’:
../../src/libvhost-user-1.c:52:51: warning: leak of ‘*vq.resubmit_list’
[CWE-401] [-Wanalyzer-malloc-leak]
52 | vq->resubmit_list[vq->resubmit_num].index = i; /* { dg-bogus
"leak" } */
| ~~^~~
‘vu_check_queue_inflights’: events 1-11
|
| 44 | if (vq->inuse) {
| | ^
| | |
| | (1) following ‘true’ branch...
| 45 | vq->resubmit_list = calloc(vq->inuse,
sizeof(VuVirtqInflightDesc));
| |
~~
| | ||
| | |(2) ...to here
| | (3) allocated here
| 46 | if (!vq->resubmit_list) {
| |~
| ||
| |(4) assuming ‘*vq.resubmit_list’ is non-NULL
| |(5) following ‘false’ branch...
|..
| 50 | for (i = 0; i < vq->inflight->desc_num; i++) {
| | ~ ~~
| || |
| || (7) following ‘true’ branch...
| || (9) following ‘true’ branch...
| |(6) ...to here
| 51 | if (vq->inflight->desc[i].inflight) {
| |
| | |
| | (8) ...to here
| | (10) ...to here
| 52 | vq->resubmit_list[vq->resubmit_num].index = i; /* {
dg-bogus "leak" } */
| | ~
| | |
| | (11)
‘*vq.resubmit_list’ leaks here; was allocated at (3)
|
[Bug middle-end/95622] [11 Regression] force_output flag on a variable prevents optimization / regresses c-c++-common/goacc/kernels-alias-ipa-pta{-2,-4,}.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95622
--- Comment #8 from Tobias Burnus ---
I am not sure whether this is a sensible solution, but it fixes
the issue for c-c++-common/goacc/kernels-alias-ipa-pta-2.c ...
diff --git a/gcc/tree-ssa-structalias.c b/gcc/tree-ssa-structalias.c
index 529ec3a5b80..c93e9b46d8d 100644
--- a/gcc/tree-ssa-structalias.c
+++ b/gcc/tree-ssa-structalias.c
@@ -8132,7 +8132,7 @@ refered_from_nonlocal_fn (struct cgraph_node *node, void
*data)
*nonlocal_p |= (node->used_from_other_partition
|| DECL_EXTERNAL (node->decl)
|| TREE_PUBLIC (node->decl)
- || node->force_output
+ || (node->force_output && !node->offloadable)
|| lookup_attribute ("noipa", DECL_ATTRIBUTES (node->decl)));
return false;
}
@@ -8195,7 +8195,7 @@ ipa_pta_execute (void)
bool nonlocal_p = (node->used_from_other_partition
|| DECL_EXTERNAL (node->decl)
|| TREE_PUBLIC (node->decl)
-|| node->force_output
+|| (node->force_output && !node->offloadable)
|| lookup_attribute ("noipa",
DECL_ATTRIBUTES (node->decl)));
node->call_for_symbol_thunks_and_aliases (refered_from_nonlocal_fn,
[Bug middle-end/36823] missing uninitialized warning (IPA, inlining)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36823 --- Comment #5 from Martin Sebor --- Bisection shows the -Wuninitialized at -O2 disappeared between r176911 and r176920. The likely candidate is r176918.
[Bug target/99773] ARM v8.1-m MVE interaction with -mfloat-abi not clear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99773
--- Comment #3 from Christophe Lyon ---
I tried changing TARGET_HARD_FLOAT_SUB in arm.h to:
#define TARGET_HARD_FLOAT_SUB (arm_float_abi != ARM_FLOAT_ABI_SOFT\
&& (bitmap_bit_p (arm_active_target.isa, \
isa_bit_vfpv2) \
|| bitmap_bit_p (arm_active_target.isa, \
isa_bit_mve)) \
&& TARGET_32BIT)
but that has other implications, like enabing VFP patterns: for instance
mulsf3_vfp becomes enabled, leading to a failure when builing libgcc (vmul.f32
is generated for powisf2, but rejected by the assembler)
So maybe we just change the condition to emit the attributes in arm_file_start?
Something like:
if (! TARGET_SOFT_FLOAT || TARGET_HAVE_MVE)
{
if ((TARGET_HARD_FLOAT && TARGET_VFP_SINGLE) || TARGET_HAVE_MVE)
arm_emit_eabi_attribute ("Tag_ABI_HardFP_use", 27, 1);
if (TARGET_HARD_FLOAT_ABI || TARGET_HAVE_MVE)
arm_emit_eabi_attribute ("Tag_ABI_VFP_args", 28, 1);
}
but that does not look very clean
[Bug fortran/31279] Uninitialized warning for call-by-reference arguments with known intent(in)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31279
Martin Sebor changed:
What|Removed |Added
Component|middle-end |fortran
--- Comment #7 from Martin Sebor ---
GCC added the attributes mentioned in comment #4 under the name access -- see
below. Getting the middle end to issue a warning for the cases described in
comment #0 should be a matter of the Fortran front end making use of the
attribute.
$ cat x.c && gcc -S -Wall x.c
__attribute__ ((access (read_only, 1))) void f (int*);
void g (void)
{
int x;
f ();
}
x.c: In function ‘g’:
x.c:6:3: warning: ‘x’ is used uninitialized [-Wuninitialized]
6 | f ();
| ^~
x.c:1:46: note: in a call to ‘f’ declared with attribute ‘access (read_only,
1)’ here
1 | __attribute__ ((access (read_only, 1))) void f (int*);
| ^
x.c:5:7: note: ‘x’ declared here
5 | int x;
| ^
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 33802, which changed state. Bug 33802 Summary: bogus "is used uninitialized" (VOPs) (inlining) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33802 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/33802] bogus "is used uninitialized" (VOPs) (inlining)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33802 Martin Sebor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||msebor at gcc dot gnu.org --- Comment #15 from Martin Sebor --- The original test cases don't compile for me and I don't see the warning for the test case in comment 13 with recent GCC (6 through 11). I'm having trouble pinpointing when it disappeared.
[Bug libfortran/99740] floating point exception in rand() in gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99740 --- Comment #4 from Steve Kargl --- On Thu, Mar 25, 2021 at 12:52:53PM +, pvoytas at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99740 > > --- Comment #3 from Paul A. Voytas --- > I see what you mean--if i test for rand(0)=0.d0 I do get hist with gfortran on > the EL7 machine. > > But it seems like there must still be something different from older versions. > The info pages for rand() say "between 0 and 1" which I always took to be > exclusive of the endpoints (of course there's machine precision). On CentOS6 > with g77 when I run the above code I get no errors--even with 10x more > attempts--and the test for rand(0)=0.d0 never is true. On that same CentOS6 > machine with gfortran, code does show rand(0)=0.d0 cases (and the > -log(rand(0)) > returns +Infinity. > g77 has not been supported for nearly 1.5 decades (gcc-3.4.6 released on 6 Mar 2006). gfortran tries to provide some level of API compatibility with g77. I believe there has never been a commitment to provide bit-for-bit compatibility (especially for something like rand()). Having now looked at g77's rand() implementation, I see that it is a wrapper around the libc routine by the same name rand(3). The quality of implementation of libc's rand(3) certainly varies across operating systems. gfortran's rand() implements the classic Park and Miller LCG RNG with an internal range of [0, 2**31-1), which yields a random number in [0., 1.). You really want to switch to using random_number(). The internal generator used in it has an enormous period and very good statistical quality, and random_number() is specified by the actual Fortran standard.
[Bug target/99773] ARM v8.1-m MVE interaction with -mfloat-abi not clear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99773 Alex Coplan changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-03-25 Ever confirmed|0 |1 --- Comment #2 from Alex Coplan --- Confirmed, then.
[Bug target/99718] [11 regression] ICE in new test case gcc.target/powerpc/pr98914.c for 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99718 --- Comment #10 from Jakub Jelinek --- https://gcc.gnu.org/pipermail/gcc-patches/2021-March/567215.html
[Bug target/99773] ARM v8.1-m MVE interaction with -mfloat-abi not clear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99773 --- Comment #1 from Richard Earnshaw --- -march=armv8.1-m.main+mve -mfloat-abi=hard should use the VFP registers for passing any FP arguments so the build attribute for Tag_ABI_VFP_args should be set to show that. It's true that soft-float routines will still be needed to do any FP operations in this case, but that doesn't affect the ABI at public interfaces.
[Bug target/99718] [11 regression] ICE in new test case gcc.target/powerpc/pr98914.c for 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99718 David Edelsohn changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||dje at gcc dot gnu.org Last reconfirmed||2021-03-25 Ever confirmed|0 |1 --- Comment #9 from David Edelsohn --- Confirmed.
[Bug target/99718] [11 regression] ICE in new test case gcc.target/powerpc/pr98914.c for 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99718 --- Comment #8 from David Edelsohn --- Xionghu, please do not write "can't" when you mean "it's difficult" or "it hasn't been implemented" or "it's too inefficient" (such as moving the data through memory). Please be very precise in your explanations. I never wrote that there is no need variable vec_insert support for m32 build. Does LLVM generate good code for this operation in 32 bit mode? As Jakub said, this is a P1 blocker. We may want to fix this differently in the short term than the long term. We may want to TEMPORARILY avoid this situation for m32 configuration for the upcoming release but GCC should generate a better instruction sequence in the next release cycle.
[Bug target/99718] [11 regression] ICE in new test case gcc.target/powerpc/pr98914.c for 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99718 --- Comment #7 from Segher Boessenkool --- (In reply to Jakub Jelinek from comment #6) > I did not know whether it is implementable (in VSX or in Altivec) for 32-bit > targets etc., all I was suggesting was what to do if it is not implementable. Yes. > If it is implementable, somebody familiar with VSX/Altivec should add the > implementation, or we can temporarily use the patch that has been posted and > get back to it later. I haven't seen a patch posted yet? > Or if it is partly implementable (e.g. can be done in > VSX and can't be done in Altivec, etc.), then the patch can still be used > after amendments for what will and what will not work. The only thing I am saying it should be massively easier to just implement it for -m32 as well, much easier than adding extra conditions (and unavoidably getting that wrong). > Right now it is a P1 blocker because we ICE on something that worked > perfectly fine (perhaps slower than it could) in GCC 10. So something needs > to be done before GCC 11 and we have ~ a month left for that. Yup. I'll review any patch that is sent (cc: me, so that I see it immediately, instead of after 3 to 6 weeks). Thanks, Segher
[Bug target/99773] New: ARM v8.1-m MVE interaction with -mfloat-abi not clear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99773
Bug ID: 99773
Summary: ARM v8.1-m MVE interaction with -mfloat-abi not clear
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
I noticed an unexpected linker error when compiling with
-march=armv8.1-m.main+mve -mfloat-abi=hard -mcpu=cortex-m55 -mthumb
error: /tmp/ccQvvmcJ.o uses VFP register arguments, ./XXX.exe does not
Using mve.fp instead of mve fixes that.
However, I'm used to -mfloat-abi=hard defining the eabi attribute:
Tag_ABI_VFP_args: VFP registers
Compiling
===
typedef int __attribute((vector_size(16))) v4si;
float g(float x, float y)
{
x += y;
return x;
}
v4si f(v4si x, v4si y)
{
return x + y;
}
===
with -O2 -march=armv8.1-m.main+mve -mfloat-abi=hard
generates for f:
vadd.i32 q0, q0, q1
bx lr
which uses the MVE registers for the parameters, but the object files does not
have the Tag_ABI_VFP_args: VFP registers attribute I would expect.
It does have
Tag_MVE_arch: MVE Integer only
is that enough?
Is the current behavior expected or is there a bug?
[Bug c++/99772] New: New built-ins for pointer comparisons that yield a total order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99772
Bug ID: 99772
Summary: New built-ins for pointer comparisons that yield a
total order
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Blocks: 93628
Target Milestone: ---
[comparisons.general] says:
For templates less, greater, less_equal, and greater_equal, the specializations
for any pointer type yield a result consistent with the implementation-defined
strict total order over pointers (3.27).
We do:
_GLIBCXX14_CONSTEXPR bool
operator()(_Tp* __x, _Tp* __y) const _GLIBCXX_NOTHROW
{
#if __cplusplus >= 201402L
#ifdef _GLIBCXX_HAVE_BUILTIN_IS_CONSTANT_EVALUATED
if (__builtin_is_constant_evaluated())
#else
if (__builtin_constant_p(__x < __y))
#endif
return __x < __y;
#endif
return (__UINTPTR_TYPE__)__x < (__UINTPTR_TYPE__)__y;
}
The casts were added for PR libstdc++/78420 because GCC started to optimize
based on unspecified < comparisons. So we can't just use the built-in
comparisons.
Furthermore:
For template specializations less, greater, less_equal, and
greater_equal, if the call operator calls a built-in operator comparing
pointers, the call operator yields a result consistent with the
implementation-defined strict total order over pointers.
This one is harder, as we have to jump through several hoops to detect "if the
call operator calls a built-in operator comparing pointers", and if it does,
then use std::less to get a total order.
Then [comparisons.three.way] has another "if <=> ... resolve to a built-in
operator comparing pointers" and again requires a total order. And again in
[range.cmp].
Our current approach doesn't work for std::compare_three_way
std::ranges::equal_to with two types that are (or convert to) function pointers
(see PR 93628).
It would be faster to compile and (I assume) more reliable if we could just ask
the compiler to do the comparison and give a total order (so that the
middle-end doesn't optimize as though the result is unspecified).
I don't know exactly what the front-end support would look like. Maybe one
helper to check whether a given expression "resolves to a built-in operator
comparing pointers" and another to do the comparison to get a total order, but
I'm not sure that would solve PR 93628.
Maybe what we want is __builtin_less(x, y) and __builtin_equal_to(x, y) and
__builtin_compare_three_way(x, y) which evaluate xy
respectively, but guarantee a total order. If x for floating-point
types (PR 96526) which could presumably be subsumed by
__builtin_compare_three_way.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93628
[Bug 93628] ranges::equal_to doesn't work for types convertible to function
pointers
[Bug c++/95675] [8/9/10/11 Regression] internal compiler error: in build_over_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95675 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|8.5 |9.4 Status|ASSIGNED|RESOLVED --- Comment #11 from Jason Merrill --- Fixed for 9.4/10.3/11.
[Bug middle-end/99768] [11 Regression] Bogus -Wuninitialized diagnostic with type punning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99768
Martin Sebor changed:
What|Removed |Added
Last reconfirmed||2021-03-25
Status|UNCONFIRMED |NEW
Component|c |middle-end
Ever confirmed|0 |1
CC||msebor at gcc dot gnu.org
--- Comment #2 from Martin Sebor ---
The -Wuninitialized was introduced in
g:b825a22890740f341eae566af27e18e528cd29a7. I don't think I meant for this to
be diagnosed so I suspect it's a bug in the new code. I see no basis in the IL
(below) to issue the warning. GCC should issue -Wstrict-aliasing instead (it
does but only at level 2).
float foo (unsigned int v)
{
float * f;
unsigned int tmp;
float _5;
:
tmp = v_2(D);
f_4 =
_5 = *f_4;<< -Wuninitialized
tmp ={v} {CLOBBER};
return _5;
}
[Bug c++/99565] [11 Regression] Bogus identical branches warning when returning references to union members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99565 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Jakub Jelinek --- Fixed.
[Bug c++/98940] Implement C++23 language features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98940 Bug 98940 depends on bug 98942, which changed state. Bug 98942 Summary: [C++23] Implement P1102R2 - Down with ()! https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98942 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/98942] [C++23] Implement P1102R2 - Down with ()!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98942 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Marek Polacek --- Implemented in GCC 11.
[Bug target/99718] [11 regression] ICE in new test case gcc.target/powerpc/pr98914.c for 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99718 --- Comment #6 from Jakub Jelinek --- I did not know whether it is implementable (in VSX or in Altivec) for 32-bit targets etc., all I was suggesting was what to do if it is not implementable. If it is implementable, somebody familiar with VSX/Altivec should add the implementation, or we can temporarily use the patch that has been posted and get back to it later. Or if it is partly implementable (e.g. can be done in VSX and can't be done in Altivec, etc.), then the patch can still be used after amendments for what will and what will not work. Right now it is a P1 blocker because we ICE on something that worked perfectly fine (perhaps slower than it could) in GCC 10. So something needs to be done before GCC 11 and we have ~ a month left for that.
[Bug target/99764] ICE in extract_insn, at recog.c:2770
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99764 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- I would expect this ICEs since r10-6020-g2e87b2f4121fe1d39edb76f4e492dfe327be6a1b when __bf16 support has been added, at least r11-1 already ICEs
[Bug fortran/99765] Explicit dimension size declaration of pointer array allowed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99765 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #3 from Tobias Burnus --- (In reply to Dominique d'Humieres from comment #1) > so I think > real, dimension(10), pointer :: a(:) => null() > and > real, dimension(10), allocatable :: a(10) > are invalid and shall give an error. I concur with the second example (violating the cited constraint), but the first one looks valid to me. In particular: F2018 has in 8.2 [92:1-3]): "The type declaration statement also specifies the attributes whose keywords appear in the attr-spec, except that the DIMENSION attribute can be specified or overridden for an entity by the appearance of array-spec in its entity-decl," Thus, unless I missed some example, this PR looks invalid to me.
[Bug tree-optimization/96974] [10/11 Regression] ICE in vect_get_vector_types_for_stmt compiling for SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96974 --- Comment #12 from CVS Commits --- The releases/gcc-10 branch has been updated by Stam Markianos-Wright : https://gcc.gnu.org/g:a1b4d742f180ff6f1e538e79e590065afe2cce6e commit r10-9545-ga1b4d742f180ff6f1e538e79e590065afe2cce6e Author: Stam Markianos-Wright Date: Thu Mar 25 15:31:17 2021 + tree-optimization/96974 - avoid ICE by replacing assert with standard failure Minor patch to add a graceful exit in the rare case where an invalid combination of TYPE_VECTOR_SUBPARTS for nunits_vectype and *stmt_vectype_out is reached in vect_get_vector_types_for_stmt. This resolves the ICE seen in PR tree-optimization/96974, however the issue of correctly handling this rare vectorization combination is left for a later patch. Bootstrapped and reg-tested on aarch64-linux-gnu. 2021-03-25 Stam Markianos-Wright gcc/ChangeLog: PR tree-optimization/96974 * tree-vect-stmts.c (vect_get_vector_types_for_stmt): Replace assert with graceful exit. gcc/testsuite/ChangeLog: PR tree-optimization/96974 * g++.target/aarch64/sve/pr96974.C: New test.
[Bug tree-optimization/96974] [10/11 Regression] ICE in vect_get_vector_types_for_stmt compiling for SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96974 --- Comment #11 from CVS Commits --- The master branch has been updated by Stam Markianos-Wright : https://gcc.gnu.org/g:aac12084fc07319d5c8232c51dafa4e297bd5415 commit r11-7830-gaac12084fc07319d5c8232c51dafa4e297bd5415 Author: Stam Markianos-Wright Date: Thu Mar 25 15:29:41 2021 + tree-optimization/96974 - avoid ICE by replacing assert with standard failure Minor patch to add a graceful exit in the rare case where an invalid combination of TYPE_VECTOR_SUBPARTS for nunits_vectype and *stmt_vectype_out is reached in vect_get_vector_types_for_stmt. This resolves the ICE seen in PR tree-optimization/96974, however the issue of correctly handling this rare vectorization combination is left for a later patch. Bootstrapped and reg-tested on aarch64-linux-gnu. 2021-03-25 Stam Markianos-Wright gcc/ChangeLog: PR tree-optimization/96974 * tree-vect-stmts.c (vect_get_vector_types_for_stmt): Replace assert with graceful exit. gcc/testsuite/ChangeLog: PR tree-optimization/96974 * g++.target/aarch64/sve/pr96974.C: New test.
[Bug target/99767] [9/10/11 Regression] ICE in expand_direct_optab_fn, at internal-fn.c:3360
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99767
--- Comment #3 from Jakub Jelinek ---
E.g. as
int a[1024], b[1024];
void
foo (void)
{
#pragma omp simd
for (int i = 0; i < 1024; i++)
if (b[i] > 23) {
a[i] = b[i] + 1;
int v = 1 / 0;
}
}
(omp simd is there only to convince it to vectorize it and not give up).
[Bug lto/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447 --- Comment #12 from Martin Liška --- @doko: Can you please reduce objects and then .ii files needed to reproduce the issue?
[Bug analyzer/99771] Analyzer diagnostics should not say ""
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99771 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-03-25 Status|UNCONFIRMED |ASSIGNED
[Bug analyzer/99771] New: Analyzer diagnostics should not say ""
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99771 Bug ID: 99771 Summary: Analyzer diagnostics should not say "" Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Target Milestone: --- Various analyzer diagnostics talk about ""; examples can be seen in the testsuite: data-model-10.c: *new_table->m_f = NULL; // "dereference of possibly-NULL ''" malloc-1.c (test_44): free (global_ptr); // "leak of ''" malloc-ipa-13.c: calls_free (f.m_p); //"passing freed pointer '' in call to 'calls_free' from 'test'" and IIRC I've seen these "in the wild" recently as well. We shouldn't emit "" to the end-user. Filing this bug to have a place to track fixing these.
[Bug target/99766] [11 Regression] ICE: unable to generate reloads with SVE code since r11-7807-gbe70bb5e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99766 --- Comment #4 from Vladimir Makarov --- (In reply to Alex Coplan from comment #2) > The above ICEs with just -O3 -march=armv8.2-a+sve. Thank you for reporting. I reproduced it тоо. I think соме constraint was not categorized rightly. It might be simply to find and to fix but it will need a lot of testing.
[Bug target/99767] [9/10/11 Regression] ICE in expand_direct_optab_fn, at internal-fn.c:3360
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99767 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Yeah, I don't see a problem on the omp simd cloning side, one could write such code by hand too. The thing is the DCE disabling, ifcvt adds .COND_DIV on the to be vectorized loop copy only, but in the end the loop is vectorized but .COND_DIV is not because it is dead and the vectorizer supposedly only considers statements that are actually used. So, either the vectorizer should do something for the dead statements in the loop (whatever, including failing the vectorization, or vectorizing them too, ...), or ifcvt shouldn't add those for the dead statements, or we need to lower those ifns back into scalar statements at the end of vectorization, or be able to expand them even when scalar.
[Bug ipa/99751] [11 Regression] wrong code at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99751
--- Comment #6 from Martin Liška ---
Maybe a nicer names:
$ cat pr99751.c
int *ptr1 = 0, **ptr2 =
int *identity(int *p)
{
return p;
}
void store_to_c(int *p)
{
*ptr2 = identity(p);
}
int main()
{
int f;
store_to_c();
if (ptr1 != )
__builtin_abort();
return 0;
}
[Bug libstdc++/77691] [8/9/10/11 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691
seurer at gcc dot gnu.org changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
--- Comment #48 from seurer at gcc dot gnu.org ---
Just an FYI: the patch done for gcc 10 (trunk at the time I believe) fixed a
32-bit failure in experimental/memory_resource/new_delete_resource.cc on
powerpc64 32 bit testing. The failure still occurs with gcc 9.
make -k check RUNTESTFLAGS="--target_board=unix'{-m32}'
conformance.exp=experimental/memory_resource/new_delete_resource.cc"
FAIL: experimental/memory_resource/new_delete_resource.cc execution test
# of expected passes1
# of unexpected failures1
/home/seurer/gcc/git/gcc-9-test/libstdc++-v3/testsuite/experimental/memory_resource/new_delete_resource.cc:125:
void test03(): Assertion 'aligned(p)' failed.
[Bug target/96582] aarch64:ICE during GIMPLE pass: veclower
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96582 Alex Coplan changed: What|Removed |Added CC||acoplan at gcc dot gnu.org --- Comment #5 from Alex Coplan --- FWIW, the ICE was "fixed" with r11-4912-g46c705e70e078f6a1920d92e49042125d5e18495: commit 46c705e70e078f6a1920d92e49042125d5e18495 Author: Richard Sandiford Date: Wed Nov 11 11:42:46 2020 + aarch64: Support SVE comparisons for unpacked integers This patch adds support for comparing unpacked SVE integer vectors, such as byte elements stored in the bottom bytes of halfword containers. It also adds support for selects between unpacked SVE vectors (both integer and floating-point), since selects and compares are closely tied via the vcond optab interface. so not sure if the issue was really fixed or perhaps just hidden.
[Bug tree-optimization/27039] [4.1 Regression] Unable to determine # of iterations for a simple loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27039 Bug 27039 depends on bug 27214, which changed state. Bug 27214 Summary: The C frontend introduces undefined pointer overflow https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27214 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c/27214] The C frontend introduces undefined pointer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27214 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #15 from Richard Biener --- Fixed. That the POINTER_PLUS_EXPR is unsigned sizetype is a design decision, it is interpreted signed and thus there is no bad overflow. Yes, we should have used signed sizetype.
[Bug tree-optimization/19831] Missing DSE/malloc/free optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19831
--- Comment #20 from Richard Biener ---
The original cases are all fixed but what remains is us failing to elide
void f ()
{
void *p = __builtin_malloc (1);
if (!p)
__builtin_abort ();
__builtin_free (p);
}
if that's even desirable. Note that we mark the abort() call as necessary
since it has side-effects which is contrary to this expectation. If you
think of, say,
extern int alloc_fails;
extern int alloc_success;
void f ()
{
void *p = __builtin_malloc (1);
if (!p)
alloc_fails++;
else
alloc_success++;
__builtin_free (p);
}
then the question is really whether we may assume that malloc does not
return NULL. We can then avoid marking 'p' necessary on NULL checks
on malloc returned pointers and upon DCEing the malloc/free pair
replace the def of 'p' with a non-zero constant.
Related would be to play similar things with realloc - replace
void *p = realloc (q, n);
free (p);
with
free (q);
and
void *p = realloc (q, n);
if (p == q)
not_copied++;
free (p);
with
void *p = q;
if (p == q)
not_copied++;
free(q);
so here we'd not only have to deal with != NULL but other pointer equality
checks.
[Bug target/90330] gcc 9.1.0 fails to install on macOS 10.14.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330 --- Comment #34 from Matt Thompson --- Iain, Apologies. I forgot about this. Seeing as I'm now using GNU 10.2.0 on my Macbook...I guess it's working. I currently do: ../gcc-10.2.0/configure --prefix=$HOME/installed/Core/gcc-gfortran/10.2.0 --enable-languages=c,c++,fortran --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk |& tee configure.log when I configure it which is much as you suggested. My guess is I worked with my admins nuking and restoring XCode until we got it right (or something, government laptops are fun, no sudo, lots of restrictions...). Thanks for your help, and I can't wait for 10.3 or 11.0 or whatever is next! N Note: I'm still on an Intel Mac, so I won't need to bother "Iain Sandoe, master of M1 GNU" about that for a while. :D
[Bug target/99744] __attribute__ ((target("general-regs-only"))) doesn't work with GPR intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99744 H.J. Lu changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #7 from H.J. Lu --- The fix was reverted by commit de00a7bda94910835012bc7150be53b460a5c8b6 Author: H.J. Lu Date: Thu Mar 25 06:57:37 2021 -0700 Revert "x86: Skip ISA check for always_inline in system headers" This reverts commit 72982851d70dfbc547d83ed2bb45356b9ebe3ff0.
[Bug middle-end/98209] [8/9/10 Regression] printf failed with O1 or above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98209 --- Comment #14 from H.J. Lu --- The fix was reverted by commit de00a7bda94910835012bc7150be53b460a5c8b6 Author: H.J. Lu Date: Thu Mar 25 06:57:37 2021 -0700 Revert "x86: Skip ISA check for always_inline in system headers" This reverts commit 72982851d70dfbc547d83ed2bb45356b9ebe3ff0.
[Bug tree-optimization/99755] failure to fold a conditional that's a subset of another expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99755 Andrew Macleod changed: What|Removed |Added CC||amacleod at redhat dot com --- Comment #2 from Andrew Macleod --- f2 and f4 are "similar" when I look at whats going on with these. The interesting bits are bb3 and bb4 === BB 3 i_9(D) int [2, +INF] j_10(D) int [3, +INF] Relational : (x_12 > i_9(D)) : x_12 = i_9(D) + 1; x_12 : int [3, +INF] === BB 4 Imports: i_9(D) j_10(D) Exports: _4 _5 _6 i_9(D) j_10(D) _4 : i_9(D)(I) _5 : j_10(D)(I) _6 : _4 _5 i_9(D)(I) j_10(D)(I) i_9(D) int VARYING j_10(D) int VARYING : # x_8 = PHI _4 = i_9(D) == 2; _5 = j_10(D) == 3; _6 = _4 & _5; if (_6 != 0) goto ; [INV] else goto ; [INV] x_8 : int [3, +INF] 4->5 (T) _4 : _Bool [1, 1] 4->5 (T) _5 : _Bool [1, 1] 4->5 (T) _6 : _Bool [1, 1] 4->5 (T) i_9(D) : int [2, 2] 4->5 (T) j_10(D) : int [3, 3] 4->7 (F) _6 : _Bool [0, 0] we have the ability to recompute stmts on edges when the dependencies change. This currently applies only to range-ops enabled stmts. An extension to PHIS and other non-range-ops is in the works. The gist being x_8 is directly dependant on x_11 and x_12. x_11 is undefined, so it boils down to a dependency on x_12. x_12 in turn is dependant on i_9 which is a modified export from this block. So when recomputation is extended to PHIS, we should be able to see that i_9 has changed on this edge, and reevaluate x_12 for that edge, x_12 = i_9 + 1 --> [2,2] + 1 == [3,3] and feeding that into a PHI recalculation for the edge producing x_8 = PHI and then we'd resolve x_8 = [3,3] on the true edge, and the desired fold should happen. The other issue is that when we do recalculations, we currently only go back one degree of dependency for the sake of compilation speed... x_8's direct dependencies are that one degree.. I have not done experiments on more than one degree, but it may make sense to look back one degree for phi arguemnts as well, which would then get cases like this. It may also make sense instead to adjust the phi optimization pass to utilize ranger to do a more in-depth analysis of argument ranges and their dependencies and get it there. I'll update this once I have enabled recomputation for phis, and have something more concrete.
[Bug tree-optimization/41898] GCC ignores restrict on array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41898 --- Comment #5 from Richard Biener --- Possibly related (implementation-wise) are ideas to handle array element contents field-sensitive but not elements, thus have for T p[10]; fields for members of 'T' but re-use the appropriate member for each array element of 'p'. This would support doing field-sensitive analysis for allocated storage and varinfo fields would "wrap around" the full variables size. One conservative subfield allocation strathegy for allocated storage is N pointers aligned to pointer alignment.
[Bug middle-end/41953] missing uninitialized warning (SRA,VOP)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41953
Richard Biener changed:
What|Removed |Added
Last reconfirmed|2009-11-06 10:02:19 |2021-3-25
--- Comment #5 from Richard Biener ---
Reconfirmed with -O2 -fno-tree-pre -fno-tree-sra or -O -fno-tree-sra.
Basically the IL not warning is
int f (const struct ExtentsBase & e1, int n)
{
struct ExtentsBase my_extents;
int _1;
int _7;
[local count: 1073741824]:
if (n_3(D) != 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870912]:
goto ; [100.00%]
[local count: 536870913]:
_1 = e1_5(D)->startx_;
my_extents.startx_ = _1;
[local count: 1073741824]:
_7 = my_extents.startx_;
my_extents ={v} {CLOBBER};
return _7;
}
while we for example warn for (PRE enabled):
int f (const struct ExtentsBase & e1, int n)
{
struct ExtentsBase my_extents;
int _1;
int pretmp_9;
int prephitmp_10;
[local count: 1073741824]:
if (n_3(D) != 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870912]:
pretmp_9 = my_extents.startx_;
goto ; [100.00%]
[local count: 536870913]:
_1 = e1_5(D)->startx_;
[local count: 1073741824]:
# prephitmp_10 = PHI
my_extents ={v} {CLOBBER};
return prephitmp_10;
[Bug middle-end/98209] [8/9/10 Regression] printf failed with O1 or above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98209 Richard Biener changed: What|Removed |Added Summary|[8/9/10/11 Regression] |[8/9/10 Regression] printf |printf failed with O1 or|failed with O1 or above |above | Target Milestone|11.0|8.5 Known to work||11.0
[Bug libfortran/99740] floating point exception in rand() in gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99740 --- Comment #3 from Paul A. Voytas --- I see what you mean--if i test for rand(0)=0.d0 I do get hist with gfortran on the EL7 machine. But it seems like there must still be something different from older versions. The info pages for rand() say "between 0 and 1" which I always took to be exclusive of the endpoints (of course there's machine precision). On CentOS6 with g77 when I run the above code I get no errors--even with 10x more attempts--and the test for rand(0)=0.d0 never is true. On that same CentOS6 machine with gfortran, code does show rand(0)=0.d0 cases (and the -log(rand(0)) returns +Infinity.
[Bug target/99744] __attribute__ ((target("general-regs-only"))) doesn't work with GPR intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99744 H.J. Lu changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |11.0 Status|NEW |RESOLVED --- Comment #6 from H.J. Lu --- Fixed for GCC 11.
