[Bug target/104946] [12 regression] Suboptimal gimple foding for blendvpd under sse4.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104946 Hongtao.liu changed: What|Removed |Added Keywords||missed-optimization Target||x86_64-*-* i?86-*-* --- Comment #1 from Hongtao.liu --- I think we should restrict gimple folding for __builtin_ia32_blendvpd under TARGET_SSE4_2. For other blendv builtins, corresponding vec_cmp is available as long as builtin isa matches.
[Bug target/104946] New: [12 regression] Suboptimal gimple foding for blendvpd under sse4.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104946
Bug ID: 104946
Summary: [12 regression] Suboptimal gimple foding for blendvpd
under sse4.1
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: crazylht at gmail dot com
Target Milestone: ---
When working on PR104666, i found
cat test.c
typedef double __m128d __attribute__((__vector_size__(16), __may_alias__));
__m128d sse4_1_blendvpd (__m128d a, __m128d b, __m128d c)
__attribute__((__target__("sse4.1")));
__m128d
generic_blendvpd (__m128d a, __m128d b, __m128d c)
{
return __builtin_ia32_blendvpd (a, b, c);
}
gcc -O2 -msse4.1 -mno-sse4.2
generic_blendvpd:
movqrax, xmm2
movapd xmm3, xmm0
testrax, rax
jns .L3
movapd xmm0, xmm1
.L3:
pextrq rax, xmm2, 1
unpckhpdxmm3, xmm3
testrax, rax
jns .L5
unpckhpdxmm1, xmm1
movapd xmm3, xmm1
.L5:
unpcklpdxmm0, xmm3
ret
It's because it pcmpgtq is under sse4.2 w/o which vec_cmpv2di will be lower to
scalar operations and not combined back.
w/ sse4.2 gcc can generate optimal code.
generic_blendvpd:
movapd xmm3, xmm0
movdqa xmm0, xmm2
blendvpdxmm3, xmm1, xmm0
movapd xmm0, xmm3
ret
[Bug tree-optimization/104941] ICE error: invalid (pointer) operands ‘minus_expr’ since r12-6482-g06bc1b0c539e3a60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104941 Siddhesh Poyarekar changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |siddhesh at gcc dot gnu.org
[Bug tree-optimization/104942] ICE in size_for_offset, at tree-object-size.cc:352 since r12-6482-g06bc1b0c539e3a60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104942 Siddhesh Poyarekar changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |siddhesh at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug libstdc++/104945] std::hash ignores the top 32 bits when size_t is 32 bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104945
--- Comment #1 from Andrew Pinski ---
Yes this is definitely an issue I think:
// Explicit specializations for integer types.
#define _Cxx_hashtable_define_trivial_hash(_Tp) \
template<>\
struct hash<_Tp> : public __hash_base \
{ \
size_t\
operator()(_Tp __val) const noexcept \
{ return static_cast(__val); }\
};
/// Explicit specialization for long long.
_Cxx_hashtable_define_trivial_hash(long long)
/// Explicit specialization for unsigned long long.
_Cxx_hashtable_define_trivial_hash(unsigned long long)
With no check on size of size_t vs long long.
[Bug libstdc++/104945] New: std::hash ignores the top 32 bits when size_t is 32 bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104945 Bug ID: 104945 Summary: std::hash ignores the top 32 bits when size_t is 32 bit Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: pdimov at gmail dot com Target Milestone: --- A benchmark in Boost.Unordered uses uint64_t keys of the form `i << 40`: https://github.com/boostorg/unordered/blob/33f81fd49039bccd1aa3dfd5a29ef6073b93009c/benchmark/uint64.cpp#L65 which leads to pathological behavior with std::unordered_map in 32 bit mode, because std::hash ignores the top 32 bits: https://godbolt.org/z/PncKbT7aq I'm not entirely sure whether this would be considered a bug, but decided that it's worth reporting. Ideally, std::hash ought to take into account all bits of the integral input, instead of truncating it to size_t.
[Bug c++/104944] New: incorrect alignas(void) accepted (with warning if templated)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104944
Bug ID: 104944
Summary: incorrect alignas(void) accepted (with warning if
templated)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gccbugbjorn at fahller dot se
Target Milestone: ---
The erroneous code:
struct alignas(void) S{};
Is accepted without any diagnostic with g++
(Compiler-Explorer-Build-gcc-98cd717fca9f21625b9c79c9231c2e909d1d93a3-binutils-2.36.1)
12.0.1 20220306 (experimental)
https://godbolt.org/z/q7das4G1W
With 'void' coming from a template, a confusing warning is issued:
template
struct alignas(T) S {};
S s;
The message is:
In instantiation of 'struct S':
:4:9: required from here
:2:16: warning: invalid application of '__alignof__' to a void type
[-Wpointer-arith]
2 | struct alignas(T) S {};
|^
This is not entirely incorrect, but I believe most programmers would recognize
that they have no `__alignof__` in their code, nor any pointer arithmetics.
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 101895, which changed state. Bug 101895 Summary: [11/12 Regression] SLP Vectorizer change pushes VEC_PERM_EXPR into bad location spoiling further optimization opportunities https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101895 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/101895] [11/12 Regression] SLP Vectorizer change pushes VEC_PERM_EXPR into bad location spoiling further optimization opportunities
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101895 Roger Sayle changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|11.3|12.0 --- Comment #7 from Roger Sayle --- This should now be fixed on mainline.
[Bug analyzer/104943] New: Analyzer fails to purge state for local structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104943
Bug ID: 104943
Summary: Analyzer fails to purge state for local structs
Product: gcc
Version: 12.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: ---
State purging only happens for SSA names, and locals of struct type aren't SSA
names.
Given e.g.:
struct boxed {
int value;
};
extern struct boxed boxed_add (struct boxed a, struct boxed b);
extern struct boxed boxed_mul (struct boxed a, struct boxed b);
struct boxed
test (struct boxed a, struct boxed b)
{
struct boxed result = boxed_add (boxed_mul (a, a),
boxed_mul (b, b));
return result;
}
without optimization we have this gimple:
struct boxed test (struct boxed a, struct boxed b)
{
struct boxed result;
struct boxed D.1994;
struct boxed D.1993;
struct boxed D.1992;
:
D.1992 = boxed_mul (b, b);
D.1993 = boxed_mul (a, a);
result = boxed_add (D.1993, D.1992);
D.1994 = result;
result ={v} {CLOBBER(eol)};
:
:
return D.1994;
}
and this final exploded node:
EN 11:
preds: EN: 10
succs:
callstring: []
after SN: 3
rmodel:
stack depth: 1
frame (index 0): frame: ‘test’@1
clusters within frame: ‘test’@1
cluster for: : CONJURED(D.1992 = boxed_mul (b, b);, )
cluster for: : CONJURED(D.1993 = boxed_mul (a, a);, )
cluster for: : CONJURED(result = boxed_add (D.1993, D.1992);,
result)
cluster for: : CONJURED(result = boxed_add (D.1993, D.1992);,
result)
m_called_unknown_fn: TRUE
constraint_manager:
equiv classes:
constraints:
where the various are the values of the local temporaries of struct
type, which ought to be purged; they don't matter anymore.
Seen on linux kernel: drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c which
amongst other things has:
struct bw_fixed {
int64_t value;
};
with numerous calls to manipulate values; the states get bloated with bindings
for temporaries that persist far longer than they are needed.
[Bug analyzer/95000] -fanalyzer confused by switch on non-int type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95000 --- Comment #7 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:d1d95846e3c901faea6fe36a36e47b9169f5b133 commit r12-7659-gd1d95846e3c901faea6fe36a36e47b9169f5b133 Author: David Malcolm Date: Tue Mar 15 17:56:29 2022 -0400 analyzer: add test coverage for PR 95000 PR analyzer/95000 isn't fixed yet; add test coverage with XFAILs. gcc/testsuite/ChangeLog: PR analyzer/95000 * gcc.dg/analyzer/pr95000-1.c: New test. Signed-off-by: David Malcolm
[Bug tree-optimization/104941] ICE error: invalid (pointer) operands ‘minus_expr’ since r12-6482-g06bc1b0c539e3a60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104941
--- Comment #1 from Martin Liška ---
And a similar problem from openssl:
$ cat bn_ctx.i
int BN_CTX_startBN_STACK_push_newsize;
void
memcpy2(void *__dest, void *__src, int __len) {
long __trans_tmp_1 = __builtin_dynamic_object_size(__dest, 0);
__builtin___memcpy_chk(__dest, __src, __len, __trans_tmp_1);
}
int *CRYPTO_malloc() __attribute__((alloc_size(1)));
void
BN_CTX_startBN_STACK_push_st() {
int *newitems = CRYPTO_malloc(BN_CTX_startBN_STACK_push_newsize);
memcpy2(newitems, BN_CTX_startBN_STACK_push_st, sizeof(int));
}
$ gcc bn_ctx.i -c -m32 -O3 -D_FORTIFY_SOURCE=3
bn_ctx.i: In function ‘BN_CTX_startBN_STACK_push_st’:
bn_ctx.i:12:1: error: non-trivial conversion in ‘ssa_name’
12 | BN_CTX_startBN_STACK_push_st() {
| ^~~~
unsigned int
int
_6 = BN_CTX_startBN_STACK_push_newsize.2_1;
during GIMPLE pass: objsz
bn_ctx.i:12:1: internal compiler error: verify_gimple failed
0xf97bf5 verify_gimple_in_cfg(function*, bool)
/home/marxin/Programming/gcc/gcc/tree-cfg.cc:5561
0xe55f3e execute_function_todo
/home/marxin/Programming/gcc/gcc/passes.cc:2084
0xe5655b execute_todo
/home/marxin/Programming/gcc/gcc/passes.cc:2138
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/104942] ICE in size_for_offset, at tree-object-size.cc:352 since r12-6482-g06bc1b0c539e3a60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104942 Martin Liška changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-03-15 Target Milestone|--- |12.0 Ever confirmed|0 |1
[Bug tree-optimization/104942] New: ICE in size_for_offset, at tree-object-size.cc:352 since r12-6482-g06bc1b0c539e3a60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104942
Bug ID: 104942
Summary: ICE in size_for_offset, at tree-object-size.cc:352
since r12-6482-g06bc1b0c539e3a60
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: siddhesh at gcc dot gnu.org
Target Milestone: ---
Reduced from gzip package:
$ cat savedir.i
char *streamsavedir_name_space;
long streamsavedir_used;
void *ximalloc() __attribute__((__alloc_size__(1)));
const char **x;
void
streamsavedir___src() {
streamsavedir_name_space = ximalloc(streamsavedir_used);
char *dest = streamsavedir_name_space + streamsavedir_used;
long __trans_tmp_1 = __builtin_dynamic_object_size(dest, 1);
__builtin___stpcpy_chk(dest, *x, __trans_tmp_1);
}
$ gcc savedir.i -D_FORTIFY_SOURCE=3 -O
during GIMPLE pass: objsz
savedir.i: In function ‘streamsavedir___src’:
savedir.i:9:1: internal compiler error: in size_for_offset, at
tree-object-size.cc:352
9 | streamsavedir___src() {
| ^~~
0x79987d size_for_offset
/home/marxin/Programming/gcc/gcc/tree-object-size.cc:352
0x1006124 plus_stmt_object_size
/home/marxin/Programming/gcc/gcc/tree-object-size.cc:1354
0x1006124 collect_object_sizes_for
/home/marxin/Programming/gcc/gcc/tree-object-size.cc:1645
0x10070a7 compute_builtin_object_size(tree_node*, int, tree_node**)
/home/marxin/Programming/gcc/gcc/tree-object-size.cc:1106
0xa1d849 fold_builtin_object_size
/home/marxin/Programming/gcc/gcc/builtins.cc:10397
0xa1d849 fold_builtin_2
/home/marxin/Programming/gcc/gcc/builtins.cc:9420
0xa1d849 fold_builtin_n
/home/marxin/Programming/gcc/gcc/builtins.cc:9528
0x1007d2e dynamic_object_sizes_execute_one
/home/marxin/Programming/gcc/gcc/tree-object-size.cc:1974
0x1007d2e object_sizes_execute
/home/marxin/Programming/gcc/gcc/tree-object-size.cc:2034
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/104941] ICE error: invalid (pointer) operands ‘minus_expr’ since r12-6482-g06bc1b0c539e3a60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104941 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-03-15 Status|UNCONFIRMED |NEW Priority|P3 |P1 Ever confirmed|0 |1 Target Milestone|--- |12.0
[Bug tree-optimization/104941] New: ICE error: invalid (pointer) operands ‘minus_expr’ since r12-6482-g06bc1b0c539e3a60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104941
Bug ID: 104941
Summary: ICE error: invalid (pointer) operands ‘minus_expr’
since r12-6482-g06bc1b0c539e3a60
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: siddhesh at gcc dot gnu.org
Target Milestone: ---
Reduced from exfatprogs package:
$ cat exfatprogs.i
struct bsx64 {
char reserved2[7];
};
struct pbr {
int bpb;
struct bsx64 bsx;
} static exfat_setup_boot_sector(struct pbr *ppbr) {
struct bsx64 *pbsx = >bsx;
long __trans_tmp_1 = __builtin_dynamic_object_size(pbsx->reserved2, 0);
__builtin___memset_chk(pbsx, 0, 7, __trans_tmp_1);
}
int x;
void
exfat_write_boot_sector_bd_0() {
struct pbr *ppbr = __builtin_malloc(x);
exfat_setup_boot_sector(ppbr);
}
$ gcc exfatprogs.i -c -D_FORTIFY_SOURCE=3 -O
exfatprogs.i: In function ‘exfat_write_boot_sector_bd_0’:
exfatprogs.i:17:1: error: type mismatch in binary expression
17 | exfat_write_boot_sector_bd_0() {
| ^~~~
long unsigned int
long unsigned int
struct bsx64 *
_6 = MAX_EXPR <_2, 4B>;
exfatprogs.i:17:1: error: invalid (pointer) operands ‘minus_expr’
_11 = _6 - 4B;
during GIMPLE pass: objsz
exfatprogs.i:17:1: internal compiler error: verify_gimple failed
0xf97bf5 verify_gimple_in_cfg(function*, bool)
/home/marxin/Programming/gcc/gcc/tree-cfg.cc:5561
0xe55f3e execute_function_todo
/home/marxin/Programming/gcc/gcc/passes.cc:2084
0xe5655b execute_todo
/home/marxin/Programming/gcc/gcc/passes.cc:2138
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug fortran/104908] [11/12 Regression] incorrect Fortran out-of-bound runtime error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104908 anlauf at gcc dot gnu.org changed: What|Removed |Added Summary|gfortran 11/trunk |[11/12 Regression] |regression: incorrect |incorrect Fortran |Fortran out-of-bound|out-of-bound runtime error. |runtime error. | Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-03-15 Priority|P3 |P4 --- Comment #1 from anlauf at gcc dot gnu.org --- Likely caused by the fix for PR95331 (r11-1235). Class-related. Applying diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc index cfb6eac11c7..3a14600101f 100644 --- a/gcc/fortran/trans-array.cc +++ b/gcc/fortran/trans-array.cc @@ -3864,8 +3864,8 @@ gfc_conv_array_ref (gfc_se * se, gfc_array_ref * ar, gfc_expr *expr, } decl = se->expr; - if (IS_CLASS_ARRAY (sym) && sym->attr.dummy && ar->as->type != AS_DEFERRED) -decl = sym->backend_decl; + // if (IS_CLASS_ARRAY (sym) && sym->attr.dummy && ar->as->type != AS_DEFERRED) + // decl = sym->backend_decl; cst_offset = offset = gfc_index_zero_node; add_to_offset (_offset, , gfc_conv_array_offset (decl)); apparently "fixes" the wrong bounds check.
[Bug sanitizer/104937] wrong code with _Complex division and -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104937 --- Comment #4 from Jakub Jelinek --- https://gcc.gnu.org/legacy-ml/gcc/2001-11/msg00790.html Regarding the debug info argument in there, this is being discussed for DWARF6.
[Bug sanitizer/104937] wrong code with _Complex division and -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104937
--- Comment #3 from Jakub Jelinek ---
For
_Complex unsigned
foo (_Complex unsigned x, _Complex unsigned y)
{
return y / x;
}
int
main ()
{
_Complex int a = foo (6 + 43i, 6 + 43i);
__builtin_printf ("%d %d\n", __real__ a, __imag__ a);
return 0;
}
from what I see if xr < xi we expand it as
t=xr/xi*xr + xi
((yr*xr/xi + yi) / t) + ((yi*xr/xi - yr) / t) * i
Now, for the given numbers that is t=43 and the result is
43 / 43 + (0 - 6) / 43 * i
For signed complex that "works" by producing 1 + 0i, but for unsigned
that 0U - 6U is some huge number divided by 43.
But now that I see it, I think it doesn't work properly in most cases for
_Complex int either - for signed the xr < xi is actually done as abs(xr) <
abs(xi), so for both signed and unsigned complex xr/xi is 0, and similarly the
other case where we use xi/xr, with the only exception when xr==xi and thus
xr/xi is 1. I bet the algorithm is well suited only for floating point...
[Bug libfortran/104939] Reading a file with / in leads to corrupt data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104939 Rob Farmer changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Rob Farmer --- I'm an idiot and this turns out to be a issue with the unformatted reads and /
[Bug analyzer/95000] -fanalyzer confused by switch on non-int type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95000 David Malcolm changed: What|Removed |Added Depends on||104940 --- Comment #6 from David Malcolm --- Still happens on trunk; adding to SMT tracker. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104940 [Bug 104940] RFE: integrate analyzer with an SMT solver
[Bug analyzer/104940] New: RFE: integrate analyzer with an SMT solver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104940
Bug ID: 104940
Summary: RFE: integrate analyzer with an SMT solver
Product: gcc
Version: 12.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: ---
-fanalyzer currently has its own constraint_manager class for tracking the
constraints that hold at a point on an execution path, but it only verifies
some of the interactions between constraints and symbolic values, which can
lead to false positives.
For example, consider:
#include "analyzer-decls.h"
void test (int x, int y)
{
if (y == 3)
if (2 * x == y)
__analyzer_dump_path ();
}
The current constraint_manager code has no knowledge that (2 * x == y) is
impossible for integers, and erroneously outputs:
../../src/gcc/testsuite/gcc.dg/analyzer/t.c: In function ‘test’:
../../src/gcc/testsuite/gcc.dg/analyzer/t.c:7:7: note: path
7 | __analyzer_dump_path ();
| ^~~
‘test’: events 1-5
|
|5 | if (y == 3)
| | ^
| | |
| | (1) following ‘true’ branch (when ‘y == 3’)...
|6 | if (2 * x == y)
| |~~
| || |
| || (2) ...to here
| |(3) following ‘true’ branch...
|7 | __analyzer_dump_path ();
| | ~~~
| | |
| | (4) ...to here
| | (5) here
|
Idea: get out of the business of tracking constraints by instead calling out to
an SMT solver.
I have a work-in-progress prototype of the analyzer which can call express
constraints as an SMT-LIB2 script, and call out to an external z3 binary.
Presumably we'd want an option to select between different constraint-tracking
implementations, to avoid depending on z3 (or other smt solvers). Might be
faster to link it in-process, but let's cross that bridge when we come to it.
I'm filing this bug as a tracker bug for other constraint-tracking bugs.
[Bug sanitizer/104937] wrong code with _Complex division and -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104937 --- Comment #2 from Zdenek Sojka --- There was PR104604 where _Complex unsigned division was fixed, but I didn't notice any other related wrong-code PR.
[Bug sanitizer/104937] wrong code with _Complex division and -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104937
Jakub Jelinek changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
Doesn't seem to be sanitizer specific.
Just change the testcase to:
_Complex unsigned
foo (_Complex unsigned x)
{
_Complex unsigned y = x;
return y / x;
}
int
main ()
{
_Complex unsigned x = foo (6 + 43 * 1i);
if (x != 1)
__builtin_abort ();
return 0;
}
so that it doesn't get folded to 1 + 0i in the FE and at -O0 you'll get abort
as well.
I think division just doesn't work at all for _Complex unsigned, seems to work
for _Complex signed.
Don't we have some PR covering it?
[Bug middle-end/103984] [12 regression] Possible maybe-uninitialized false positive on shaderc-2021.0 since r12-6329-g4f6bc28fc7dd86bd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103984 --- Comment #15 from Jakub Jelinek --- Created attachment 52632 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52632=edit gcc12-pr103984.patch Full untested patch.
[Bug libfortran/104939] New: Reading a file with / in leads to corrupt data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104939 Bug ID: 104939 Summary: Reading a file with / in leads to corrupt data Product: gcc Version: 11.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: robert.j.farmer37 at gmail dot com Target Milestone: --- program test character(len=256) :: tmp,tmp2 integer :: iounit open(newunit=iounit,file='./test.txt') read(iounit,*) tmp,tmp2 write(*,*) len_trim(tmp),len_trim(tmp2) write(*,*) trim(tmp),trim(tmp2) end program Compiled with: gfortran -o test testRead.f90 With the contents on test.txt being: / a I get outputted: 256 256 p �:Qu`�1 ��5R�5R�1 ��5R� ��5R�0hQuf5Qu0hQu flipping the file to be a / leads to: 1 256 a1���ߗߗ��0��-6��-0��--y��- This was found as the file had a [fe/h] as a column name, but reducing down it seems its the / that is breaking the read. This lead to a somewhat puzzling error as in my full code tmp2 ended up with the contents of a entirely different file that gfortran decided to start reading in, mid-read statement. I found this on linux with 11.2.1 but also have a confirmed failure on a mac with 10.2 valgrind ./test ==145356== Memcheck, a memory error detector ==145356== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==145356== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info ==145356== Command: ./test ==145356== ==145356== Conditional jump or move depends on uninitialised value(s) ==145356==at 0x4AD05D9: string_len_trim (string_intrinsics_inc.c:231) ==145356==by 0x4AD05D9: _gfortran_string_len_trim (string_intrinsics_inc.c:186) ==145356==by 0x401359: MAIN__ (in /home/rob/src/test/test) ==145356==by 0x4014CA: main (in /home/rob/src/test/test) ==145356== ==145356== Conditional jump or move depends on uninitialised value(s) ==145356==at 0x4AD05F7: string_len_trim (string_intrinsics_inc.c:240) ==145356==by 0x4AD05F7: _gfortran_string_len_trim (string_intrinsics_inc.c:186) ==145356==by 0x401359: MAIN__ (in /home/rob/src/test/test) ==145356==by 0x4014CA: main (in /home/rob/src/test/test) ==145356== 1 256 ==145356== Conditional jump or move depends on uninitialised value(s) ==145356==at 0x4AD05D9: string_len_trim (string_intrinsics_inc.c:231) ==145356==by 0x4AD05D9: _gfortran_string_len_trim (string_intrinsics_inc.c:186) ==145356==by 0x4AD062B: _gfortran_string_trim (string_intrinsics_inc.c:168) ==145356==by 0x401449: MAIN__ (in /home/rob/src/test/test) ==145356==by 0x4014CA: main (in /home/rob/src/test/test) ==145356== ==145356== Conditional jump or move depends on uninitialised value(s) ==145356==at 0x4AD05F7: string_len_trim (string_intrinsics_inc.c:240) ==145356==by 0x4AD05F7: _gfortran_string_len_trim (string_intrinsics_inc.c:186) ==145356==by 0x4AD062B: _gfortran_string_trim (string_intrinsics_inc.c:168) ==145356==by 0x401449: MAIN__ (in /home/rob/src/test/test) ==145356==by 0x4014CA: main (in /home/rob/src/test/test) ==145356== ==145356== Syscall param write(buf) points to uninitialised byte(s) ==145356==at 0x4D61817: write (write.c:26) ==145356==by 0x4AC2386: raw_write (unix.c:368) ==145356==by 0x4ACA5C1: UnknownInlinedFun (unix.h:59) ==145356==by 0x4ACA5C1: _gfortrani_fbuf_flush (fbuf.c:150) ==145356==by 0x4ABD404: _gfortrani_next_record (transfer.c:4087) ==145356==by 0x4AC03F9: finalize_transfer (transfer.c:4228) ==145356==by 0x4AC08B1: _gfortrani_st_write_done_worker (transfer.c:4419) ==145356==by 0x401493: MAIN__ (in /home/rob/src/test/test) ==145356==by 0x4014CA: main (in /home/rob/src/test/test) ==145356== Address 0x4e71c62 is 2 bytes inside a block of size 512 alloc'd ==145356==at 0x484486F: malloc (vg_replace_malloc.c:381) ==145356==by 0x4894C58: _gfortrani_xmalloc (memory.c:38) ==145356==by 0x4ACA475: _gfortrani_fbuf_init (fbuf.c:42) ==145356==by 0x4AC17EB: _gfortrani_init_units (unit.c:674) ==145356==by 0x4893371: init (main.c:70) ==145356==by 0x400527D: call_init (dl-init.c:70) ==145356==by 0x400527D: call_init (dl-init.c:26) ==145356==by 0x400536B: _dl_init (dl-init.c:117) ==145356==by 0x401C6D9: ??? (in /usr/lib64/ld-linux-x86-64.so.2) ==145356==
[Bug debug/104938] New: Possibly wrong location definition in DWARF with -ftree-cpp at -Og only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104938
Bug ID: 104938
Summary: Possibly wrong location definition in DWARF with
-ftree-cpp at -Og only
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: assaiante at diag dot uniroma1.it
Target Milestone: ---
In this minimized C example, variable l_3, which is initialized at line 5, is
associated to DWARF symbols having a possibly wrong location definition. This
causes the variable to not be available during debugging, for instance at line
6, until line 11 is reached. We observe the bug at -Og with the cause likely
being -ftree-ccp, while with other optimizations levels the variable is
correctly available at the lines where gdb can step (line 6 with -O1/O2/O3/Os,
also line 8 with -O1/Os). Please find below a detailed analysis for -Og on x64.
$ cat a.c
char a;
int b;
void foo(int *d) { a = 0; }
int main() {
int *l_3 =
int **e = _3;
f:
if (a)
goto f;
*e = l_3;
foo(*e);
}
GCC and GDB version (GCC commit id: 500d3f0a302):
$ gcc --version
gcc (GCC) 12.0.0 20211227 (experimental)
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gdb --version
GNU gdb (GDB) 11.2
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
GDB trace:
$ gcc -Og -g a.c -o opt
$ gdb -q opt
Reading symbols from opt...
(gdb) start
Temporary breakpoint 1 at 0x40048e: file a.c, line 8.
Starting program: /home/stepping/132/reduce/opt
Temporary breakpoint 1, main () at a.c:8
8 if (a)
(gdb) info locals
l_3 =
e =
(gdb) n
11foo(*e);
(gdb) info locals
l_3 = 0x60102c
e =
By dumping the DWARF info, we can see how the location associated to the
variable is defined with a range that does not include the instruction
associated to line 8, where the variable's value is not available despite the
original program has assigned (and, incidentally, also used) it by then.
ASM:
0040048e :
40048e: 80 3d 9b 0b 20 00 00cmpb $0x0,0x200b9b(%rip)#
601030
400495: 75 f7 jne40048e
400497: bf 2c 10 60 00 mov$0x60102c,%edi
40049c: e8 e5 ff ff ff callq 400486
4004a1: b8 00 00 00 00 mov$0x0,%eax
4004a6: c3 retq
4004a7: 66 0f 1f 84 00 00 00nopw 0x0(%rax,%rax,1)
4004ae: 00 00
DWARF info:
0x0084: DW_TAG_variable
DW_AT_name("l_3")
DW_AT_decl_file ("/home/stepping/132/reduce/a.c")
DW_AT_decl_line (5)
DW_AT_decl_column (0x08)
DW_AT_type(0x00cc "int*")
DW_AT_location(0x000e:
[0x00400497, 0x004004a1): DW_OP_addr
0x60102c, DW_OP_stack_value)
DW_AT_GNU_locviews(0x000c)
Through some testing we found out that the optimization flag that introduces
the bug is likely -ftree-ccp. If we add -fno-tree-ccp to the compilation
command line used above, variable l_3 appears in the current frame with its
value correctly available at line 8. The location of the variable appears now
to be correctly defined with the range including the cmp instruction that
corresponds to line 8 according to the line number table in DWARF info.
ASM with -fno-tree-ccp:
40048e: 48 83 ec 10 sub$0x10,%rsp
400492: 48 c7 44 24 08 2c 10movq $0x60102c,0x8(%rsp)
400499: 60 00
40049b: 80 3d 8e 0b 20 00 00cmpb $0x0,0x200b8e(%rip)#
601030
4004a2: 75 f7 jne40049b
4004a4: bf 2c 10 60 00 mov$0x60102c,%edi
4004a9: e8 d8 ff ff ff callq 400486
4004ae: b8 00 00 00 00 mov$0x0,%eax
4004b3: 48 83 c4 10 add$0x10,%rsp
4004b7: c3 retq
4004b8: 0f 1f 84 00 00 00 00nopl 0x0(%rax,%rax,1)
4004bf: 00
DWARF info with -fno-tree-ccp:
0x0093: DW_TAG_variable
DW_AT_name("e")
DW_AT_decl_file ("/home/stepping/132/reduce/a.c")
DW_AT_decl_line (6)
DW_AT_decl_column (0x09)
DW_AT_type(0x00d4 "int**")
DW_AT_location(0x000e:
[0x0040049b, 0x004004b8): DW_OP_fbreg -16,
[Bug tree-optimization/88398] vectorization failure for a small loop to do byte comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88398
--- Comment #49 from Wilco ---
(In reply to d_vampile from comment #48)
> (In reply to Jiu Fu Guo from comment #41)
> > (In reply to Wilco from comment #40)
> > > (In reply to Jiu Fu Guo from comment #39)
> > > > I’m thinking to draft a patch for this optimization. If any
> > > > suggestions,
> > > > please point out, thanks.
> > >
> > > Which optimization to be precise? Besides unrolling I haven't seen a
> > > proposal for an optimization which is both safe and generally applicable.
> >
> > 1. For unroll, there are still branches in the loop. And then need careful
> > merge on those reading and comparison. Another thing about unroll would be
> > that, if we prefer to optimize this early in GIMPLE, we still not GIMPLE
> > unroll on it.
> > while (len != max)
> > {
> > if (p[len] != cur[len])
> > break; ++len;
> > if (p[len] != cur[len])
> > break; ++len;
> > if (p[len] != cur[len])
> > break; ++len;
> >
> > }
> >
> > 2. Also thinking about if it makes sense to enhance GIMPLE vectorization
> > pass. In an aspect that using a vector to read and compare, also need to
> > handle/merge compares into vector compare and handle early exit carefully.
> > if (len + 8 < max && buffers not cross page) ///(p&4K) == (p+8)&4k?
> > 4k:pagesize
> > while (len != max)
> > {
> > vec a = xx p;
> > vec b = xx cur;
> > if (a != b) /// may not only for comparison
> > {;break;}
> > len += 8;
> > }
> >
> > 3. Introduce a new stand-alone pass to optimize reading/computing shorter
> > types into large(dword/vector) reading/computing.
> >
> > Thanks a lot for your comments/suggestions!
>
> Any progress or patches for the new pass mentioned in point 3? Or new ideas?
A new standalone pass would have to redo a lot of the work of the existing loop
optimizers and vectorizer. And you wouldn't be able to skip the extra checks to
guarantee safety of the optimization. This is why these optimizations are
typically done in the source code.
[Bug middle-end/103984] [12 regression] Possible maybe-uninitialized false positive on shaderc-2021.0 since r12-6329-g4f6bc28fc7dd86bd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103984
--- Comment #14 from Jakub Jelinek ---
Wonder about:
--- gcc/gimplify.cc.jj 2022-03-04 15:14:53.197812540 +0100
+++ gcc/gimplify.cc 2022-03-15 17:44:45.110734179 +0100
@@ -6997,8 +6997,6 @@ gimplify_target_expr (tree *expr_p, gimp
if (init)
{
- tree cleanup = NULL_TREE;
-
/* TARGET_EXPR temps aren't part of the enclosing block, so add it
to the temps list. Handle also variable length TARGET_EXPRs. */
if (!poly_int_tree_p (DECL_SIZE (temp)))
@@ -7019,37 +7017,6 @@ gimplify_target_expr (tree *expr_p, gimp
gimple_add_tmp_var (temp);
}
- /* If TARGET_EXPR_INITIAL is void, then the mere evaluation of the
-expression is supposed to initialize the slot. */
- if (VOID_TYPE_P (TREE_TYPE (init)))
- ret = gimplify_expr (, pre_p, post_p, is_gimple_stmt, fb_none);
- else
- {
- tree init_expr = build2 (INIT_EXPR, void_type_node, temp, init);
- init = init_expr;
- ret = gimplify_expr (, pre_p, post_p, is_gimple_stmt, fb_none);
- init = NULL;
- ggc_free (init_expr);
- }
- if (ret == GS_ERROR)
- {
- /* PR c++/28266 Make sure this is expanded only once. */
- TARGET_EXPR_INITIAL (targ) = NULL_TREE;
- return GS_ERROR;
- }
- if (init)
- gimplify_and_add (init, pre_p);
-
- /* If needed, push the cleanup for the temp. */
- if (TARGET_EXPR_CLEANUP (targ))
- {
- if (CLEANUP_EH_ONLY (targ))
- gimple_push_cleanup (temp, TARGET_EXPR_CLEANUP (targ),
-CLEANUP_EH_ONLY (targ), pre_p);
- else
- cleanup = TARGET_EXPR_CLEANUP (targ);
- }
-
/* Add a clobber for the temporary going out of scope, like
gimplify_bind_expr. */
if (gimplify_ctxp->in_cleanup_point_expr
@@ -7079,8 +7046,32 @@ gimplify_target_expr (tree *expr_p, gimp
}
}
}
- if (cleanup)
- gimple_push_cleanup (temp, cleanup, false, pre_p);
+
+ /* If TARGET_EXPR_INITIAL is void, then the mere evaluation of the
+expression is supposed to initialize the slot. */
+ if (VOID_TYPE_P (TREE_TYPE (init)))
+ ret = gimplify_expr (, pre_p, post_p, is_gimple_stmt, fb_none);
+ else
+ {
+ tree init_expr = build2 (INIT_EXPR, void_type_node, temp, init);
+ init = init_expr;
+ ret = gimplify_expr (, pre_p, post_p, is_gimple_stmt, fb_none);
+ init = NULL;
+ ggc_free (init_expr);
+ }
+ if (ret == GS_ERROR)
+ {
+ /* PR c++/28266 Make sure this is expanded only once. */
+ TARGET_EXPR_INITIAL (targ) = NULL_TREE;
+ return GS_ERROR;
+ }
+ if (init)
+ gimplify_and_add (init, pre_p);
+
+ /* If needed, push the cleanup for the temp. */
+ if (TARGET_EXPR_CLEANUP (targ))
+ gimple_push_cleanup (temp, TARGET_EXPR_CLEANUP (targ),
+CLEANUP_EH_ONLY (targ), pre_p);
/* Only expand this once. */
TREE_OPERAND (targ, 3) = init;
i.e. emitting the clobber gimple_push_cleanup for the TARGET_EXPRs before the
gimplification of the TARGET_EXPR_INITIAL instead of after it (and emitting the
WCE earlier means the cleanup is later (as in, outer try/finally).
[Bug c++/79318] [DR 1726] conversion member function preceded with & is not marked as error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79318 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #5 from Marek Polacek --- CWG 1726 is now a DR.
[Bug sanitizer/104937] New: wrong code with _Complex division and -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104937 Bug ID: 104937 Summary: wrong code with _Complex division and -fsanitize=undefined Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 52631 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52631=edit reduced testcase Output: $ x86_64-pc-linux-gnu-gcc -fsanitize=undefined testcase.c $ ./a.out Aborted The __imag__ part seems to be garbage. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-7654-20220315102422-gda24fce323e-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r12-7654-20220315102422-gda24fce323e-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.0.1 20220315 (experimental) (GCC)
[Bug fortran/104927] Invalid array size specification accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104927 --- Comment #3 from Steve Kargl --- On Tue, Mar 15, 2022 at 04:10:41PM +, federico.perini at gmail dot com wrote: > --- Comment #2 from federico --- > Yeah I'm surprised but wrong. The "overriding" option of the rhs size > specification is pretty clear from that statement from the standard. > Thanks for the bug report. We would rather see a bug report that is proven to be invalid than to have actual bugs go unreported.
[Bug target/97106] [nvptx] Issues with weak aliases introduced by C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97106
--- Comment #4 from Tom de Vries ---
This:
...
$ cat alias.c
void __f ()
{
__builtin_printf ("hello\n");
}
void f () __attribute__ ((alias ("__f")));
int
main (void)
{
f ();
return 0;
}
...
works fine at -O0 and -O1:
...
$ ./gcc.sh -O0 ./alias.c
$ ./install/bin/nvptx-none-run a.out
hello
$ ./gcc.sh -O1 ./alias.c
$ ./install/bin/nvptx-none-run a.out
hello
...
but at -O2 we have:
...
$ ./gcc.sh -O2 ./alias.c
$ ./install/bin/nvptx-none-run a.out
fatal : Internal error: reference to deleted section
nvptx-run: cuLinkComplete failed: unknown error (CUDA_ERROR_UNKNOWN, 999)
...
This seems to be due to f/__f being inlined into main, after which we have an
alias declaration which is unused:
...
.visible .func f;
.alias f,__f;
...
Removing these two lines make the executable run fine again.
Note: same thing when using nvptx-none-run -O0.
Fixed by:
...
diff --git a/gcc/config/nvptx/nvptx.cc b/gcc/config/nvptx/nvptx.cc
index ab1f62359d4b..3e51bf15776c 100644
--- a/gcc/config/nvptx/nvptx.cc
+++ b/gcc/config/nvptx/nvptx.cc
@@ -77,6 +77,7 @@
#include "opts.h"
#include "tree-pretty-print.h"
#include "rtl-iter.h"
+#include "cgraph.h"
/* This file should be included last. */
#include "target-def.h"
@@ -7396,6 +7397,10 @@ nvptx_mem_local_p (rtx mem)
void
nvptx_asm_output_def_from_decls (FILE *stream, tree name, tree value)
{
+ if (!cgraph_node::get (name)->referred_to_p ())
+/* Prevent "Internal error: reference to deleted section". */
+return;
+
std::stringstream s;
write_fn_proto (s, false, get_fnname_from_decl (name), name);
fputs (s.str().c_str(), stream);
...
[Bug sanitizer/104934] -fsanitize=undefined codegen err
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104934 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Jakub Jelinek --- .
[Bug sanitizer/104934] -fsanitize=undefined codegen err
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104934 --- Comment #2 from Dmitry G. Dyachenko --- (In reply to Jakub Jelinek from comment #1) > And the bug is? > The S class doesn't have the key method defined, so some other TU needs to > define it and thus provide the vtable and rtti for it. > Without -fsanitize=vptr the typeinfo isn't needed on this particular > testcase and the vtable isn't needed either, which is why you don't get an > undefined symbol in that case and you get it with -fsanitize=vptr or > -fsanitize=undefined that implies that. Thank you, Jakub. So, close as 'INVALID'?
[Bug fortran/104927] Invalid array size specification accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104927 federico changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from federico --- Yeah I'm surprised but wrong. The "overriding" option of the rhs size specification is pretty clear from that statement from the standard. This makes it even more evident: program test_invalid_shape implicit none integer, dimension(2,2) :: a(3),b(2,5),c print *, 'shape(a) = ',shape(a) print *, 'shape(b) = ',shape(b) print *, 'shape(c) = ',shape(c) end program test_invalid_shape produces shape(a) =3 shape(b) =2 5 shape(c) =2 2
[Bug target/104936] New: [nvptx] Handle weak decl/def distinction in common code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104936 Bug ID: 104936 Summary: [nvptx] Handle weak decl/def distinction in common code Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- At docs for ASM_WEAKEN_LABEL (stream, name) we find: ... If you don’t define this macro or ASM_WEAKEN_DECL, GCC will not support weak symbols and you should not define the SUPPORTS_WEAK macro. ... However, we have: ... $ grep define.*WEAKEN gcc/config/nvptx/* $ ... but still: ... $ grep SUPPORTS_WEAK gcc/config/nvptx/* gcc/config/nvptx/nvptx.h:#define SUPPORTS_WEAK 1 ... I think an argument for the discrepancy is made here: ... /* We support weak defintions, and hence have the right ASM_WEAKEN_DECL definition. Diagnose the problem here. */ if (DECL_WEAK (decl)) error_at (DECL_SOURCE_LOCATION (decl), "PTX does not support weak declarations" " (only weak definitions)"); ... where it's my understanding that the "right ASM_WEAKEN_DECL" is meant to refer to ASM_WEAKEN_DECL not being defined. It would be nice to solve this somehow in the common code instead of deviating from prescribed target macro usage.
[Bug middle-end/103984] [12 regression] Possible maybe-uninitialized false positive on shaderc-2021.0 since r12-6329-g4f6bc28fc7dd86bd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103984 --- Comment #13 from Jakub Jelinek --- What the gimplifier sees is: unit-size align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fffe8f0bd20 fields addressable used public external autoinline decl_3 QI pr103984.C:21:8 align:16 warn_if_not_align:0 context full-name "Z& Z::operator=(Z&&) noexcept" not-really-extern chain > context full-name "struct Z" needs-constructor needs-destructor X() X(constX&) this=(X&) n_parents=0 use_template=0 interface-unknown pointer_to_this reference_to_this chain > side-effects addressable arg:0 addressable used ignored read BLK pr103984.C:32:3 size unit-size align:64 warn_if_not_align:0 context > arg:1 > side-effects head 0x7fffe8e73660 tail 0x7fffe8e73780 stmts 0x7fffe8e860e0 0x7fffe8f61af0 0x7fffe8e861a0 0x7fffe8e3b758 stmt side-effects arg:0 side-effects arg:0 arg:0 arg:1 > arg:1 side-effects tree_0 arg:0 arg:1 side-effects arg:0 arg:1 constant arg:0 > arg:2 arg:3 readonly arg:0 pr103984.C:30:7 start: pr103984.C:30:7 finish: pr103984.C:30:9>> arg:2 side-effects nothrow fn constant arg:0 > arg:0 arg:0 >> pr103984.C:30:14 start: pr103984.C:30:7 finish: pr103984.C:30:15>> pr103984.C:35:1 start: pr103984.C:35:1 finish: pr103984.C:35:1> stmt side-effects static arg:0 arg:1 arg:2 side-effects arg:0 arg:1 side-effects nothrow fn constant arg:0 > arg:0 arg:0 arg:0 arg:1 >>> arg:2 constant>> pr103984.C:35:1 start: pr103984.C:35:1 finish: pr103984.C:35:1> stmt side-effects arg:0 side-effects arg:0 arg:0 arg:1 > arg:1 side-effects fn constant arg:0 > arg:0 side-effects arg:0 side-effects tree_0 arg:0 arg:1 >> pr103984.C:31:15 start: pr103984.C:31:7 finish: pr103984.C:31:19>> pr103984.C:35:1 start: pr103984.C:35:1 finish: pr103984.C:35:1> stmt side-effects arg:0 arg:1 pr103984.C:35:1 start: pr103984.C:35:1 finish: pr103984.C:35:1>> arg:2 side-effects nothrow fn constant arg:0 > arg:0 arg:0 >> pr103984.C:29:28 start: pr103984.C:29:28 finish: pr103984.C:32:3> i.e. the ~Z () is a cleanup is outer, while the ~string () cleanup is on an TARGET_EXPR inside of it (the one with D.31544 var). But the inner TARGET_EXPR has CLEANUP_EH_ONLY set on it, while the outer one (with D.31524 var) doesn't. Jason, is there any way how to arrange for such cases (with help of the C++ FE, say with some new flag on something or just pure gimplifier) to defer the D.31524 clobber only to outside of where the eh only cleanup is handled (that is on the enclosing CLEANUP_POINT_EXPR, right?)?
[Bug c++/103328] [11/12 Regression] ICE in remap_gimple_stmt, at tree-inline.c:1921 since r11-7419-g0f161cc8494cf728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103328 --- Comment #21 from Avi Kivity --- Benno, many thanks for the fix. Please consider posting it to gcc-patches as that may speed up review and merging.
[Bug fortran/104927] Invalid array size specification accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104927 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 --- A sure that code is invalid. F2018, p. 92. 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, ... Modifying your code to program test_invalid_shape implicit none integer, dimension(3,3) :: a(4) integer, dimension(3) :: b(2,2) integer, dimension(3,3) :: c(6,6) print *, 'shape(a) = ',shape(a) print *, 'shape(b) = ',shape(b) print *, 'shape(c) = ',shape(c) end program test_invalid_shape gives shape(a) =4 shape(b) =2 2 shape(c) =6 6 which is in line with the words from the Fortran standard.
[Bug middle-end/103984] [12 regression] Possible maybe-uninitialized false positive on shaderc-2021.0 since r12-6329-g4f6bc28fc7dd86bd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103984 --- Comment #12 from Jakub Jelinek --- In particular, in ehcleanup1 it is the sink_clobbers optimization added for PR51117. I think it would be strongly preferrable to fix this in the FE, because if we'd need to change sink_clobbers, I'd be afraid we'd get significantly worse code generation with -flifetime-dse than before.
[Bug middle-end/103984] [12 regression] Possible maybe-uninitialized false positive on shaderc-2021.0 since r12-6329-g4f6bc28fc7dd86bd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103984
--- Comment #11 from Jakub Jelinek ---
And it is ehcleanup that sinks the clobber. Before ehcleanup1 we have:
;; basic block 16, loop depth 0, maybe hot
;;prev block 15, next block 17, flags: (NEW, REACHABLE, VISITED)
;;pred: 15 (EH,EXECUTABLE)
:
D.31524 ={v} {CLOBBER(eol)};
resx 10
;;succ: 17 (EH,EXECUTABLE)
;; basic block 17, loop depth 0, maybe hot
;;prev block 16, next block 18, flags: (NEW, REACHABLE, VISITED)
;;pred: 4 (EH,EXECUTABLE)
;;16 (EH,EXECUTABLE)
# _3 = PHI <1(4), 0(16)>
:
D.31523 ={v} {CLOBBER(eol)};
resx 9
;;succ: 18 (EH,EXECUTABLE)
;; basic block 18, loop depth 0, maybe hot
;;prev block 17, next block 19, flags: (NEW, REACHABLE, VISITED)
;;pred: 17 (EH,EXECUTABLE)
:
if (_3 != 0)
goto ; [INV]
else
goto ; [INV]
;;succ: 19 (TRUE_VALUE,EXECUTABLE)
;;22 (FALSE_VALUE,EXECUTABLE)
;; basic block 19, loop depth 0, maybe hot
;;prev block 18, next block 20, flags: (NEW, REACHABLE, VISITED)
;;pred: 18 (TRUE_VALUE,EXECUTABLE)
_55 = MEM[(const struct basic_string *)]._M_dataplus._M_p;
so at this point, if we enter bb 17 from the edge from bb 4, D.31524 isn't
clobbered and the
_55 load is done (and conditional operator delete later), if we enter bb 16
then D.31524 is clobbered and then _3 is 0 and we don't try to delete it again.
But ehcleanup1, probably on the assumption that such conditional cleanups
aren't valid, turns that into:
...
;; basic block 14, loop depth 0, maybe hot
;;prev block 13, next block 15, flags: (NEW, REACHABLE, VISITED)
;;pred: 4 (EH,EXECUTABLE)
;;13 (EH,EXECUTABLE)
# _3 = PHI <1(4), 0(13)>
:
D.31524 ={v} {CLOBBER(eol)};
D.31523 ={v} {CLOBBER(eol)};
if (_3 != 0)
goto ; [INV]
else
goto ; [INV]
;;succ: 15 (TRUE_VALUE,EXECUTABLE)
;;18 (FALSE_VALUE,EXECUTABLE)
;; basic block 15, loop depth 0, maybe hot
;;prev block 14, next block 16, flags: (NEW, REACHABLE, VISITED)
;;pred: 14 (TRUE_VALUE,EXECUTABLE)
_55 = MEM[(const struct basic_string *)]._M_dataplus._M_p;
i.e. now D.31524 ={v} {CLOBBER(eol)}; is done no matter which path we enver
that bb from and then uninit pass is right about the warning, because
the _55 = MEM... load reads an uninitialized var.
[Bug target/99744] __attribute__ ((target("general-regs-only"))) doesn't work with GPR intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99744
--- Comment #18 from Marc Poulhiès ---
Solved our regressions in pr99744-{1,2,4,5}.c, thanks!
[Bug target/99744] __attribute__ ((target("general-regs-only"))) doesn't work with GPR intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99744
--- Comment #17 from H.J. Lu ---
(In reply to Marc Poulhiès from comment #16)
> Hi!
> I'm seeing regressions in pr99744-{1,2,4,5}.c for an i586 target where
> MMX/SSE are not enabled.
Please try
https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591716.html
[Bug c++/69623] Invalid deduction of non-trailing template parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69623 --- Comment #9 from jim x --- After reading [temp.deduct.call] p1 more carefully, I think you're right. Since the first function parameter pack does not participate in template argument deduction, the deduction will start to perform from the second function parameter to the last.
[Bug middle-end/103984] [12 regression] Possible maybe-uninitialized false positive on shaderc-2021.0 since r12-6329-g4f6bc28fc7dd86bd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103984
--- Comment #10 from Jakub Jelinek ---
What the C++ FE emits looks just weird to me. In the gimple dump:
[pr103984.C:35:1] D.31524.name = string_piece::str
([pr103984.C:35:1] ); [return slot optimization]
[pr103984.C:35:1] D.31544 = 1;
[pr103984.C:29:27] try
{
[pr103984.C:31:15] string_piece::string_piece
([pr103984.C:31:15] , [pr103984.C:31:16] );
try
{
[pr103984.C:31:15] _2 = to_stage ([pr103984.C:31:15]
);
[pr103984.C:35:1] D.31524.stage = _2;
[pr103984.C:35:1] D.31544 = 0;
try
{
try
{
[pr103984.C:29:27]
std::vector::emplace_back ([pr103984.C:29:27] _files,
[pr103984.C:29:28] );
}
finally
{
[pr103984.C:29:28] Z::~Z ([pr103984.C:29:28]
);
}
}
finally
{
[pr103984.C:29:28] D.31524 = {CLOBBER(eol)};
}
}
finally
{
[pr103984.C:31:15] D.31523 = {CLOBBER(eol)};
}
}
catch
{
[pr103984.C:35:1] if (D.31544 != 0) goto ; else
goto ;
:
[pr103984.C:35:1]
std::__cxx11::basic_string::~basic_string ([pr103984.C:35:1]
);
goto ;
:
:
}
Note the D.31524 CLOBBER being added only conditionally (if string_piece ctor
doesn't throw), while if it throws, there is a dtor on its element after that
and
no CLOBBER. The first spot that initializes part of the D.31524 temporary is
the above first line, so it would make more sense to me to wrap this whole
sequence above into try { ... } finally { [pr103984.C:29:28] D.31524 =
{CLOBBER(eol)}; } and remove the inner try finally that does that.
[Bug d/104911] [12 regression] Comparison failure in gcc/d/typesem.o etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104911 --- Comment #5 from Iain Buclaw --- (In reply to Rainer Orth from comment #4) > typesem.s indeed shows small codegen differences, while for semantic3.s > there are > both codegen differences per se as well as label renamings that may not > effect the > object files. With typesem.s, it looks like `byte.min' (-128) is being turned into 128 somewhere. Though I can't see how any change in the front-end would have caused that. With semantic3.s, it looks like the middle-end optimizer is removing some branches as dead code, when there should be no way it would possibly be able to infer that.
[Bug target/104923] [11/12 Regression] MMA __builtin_mma_disassemble_acc test case ICEs in LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104923 --- Comment #2 from CVS Commits --- The master branch has been updated by Peter Bergner : https://gcc.gnu.org/g:b5baf569f77e1f172061642d4d8593e1ea737add commit r12-7657-gb5baf569f77e1f172061642d4d8593e1ea737add Author: Peter Bergner Date: Tue Mar 15 08:46:47 2022 -0500 rs6000: Fix invalid address passed to __builtin_mma_disassemble_acc [PR104923] The mma_disassemble_output_operand predicate is too lenient on the types of addresses it will accept, leading to combine creating invalid address that eventually lead to ICEs in LRA. The solution is to restrict the addresses to indirect, indexed or those valid for quad memory accesses. 2022-03-15 Peter Bergner gcc/ PR target/104923 * config/rs6000/predicates.md (mma_disassemble_output_operand): Restrict acceptable MEM addresses. gcc/testsuite/ PR target/104923 * gcc.target/powerpc/pr104923.c: New test.
[Bug sanitizer/104934] -fsanitize=undefined codegen err
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104934 --- Comment #1 from Jakub Jelinek --- And the bug is? The S class doesn't have the key method defined, so some other TU needs to define it and thus provide the vtable and rtti for it. Without -fsanitize=vptr the typeinfo isn't needed on this particular testcase and the vtable isn't needed either, which is why you don't get an undefined symbol in that case and you get it with -fsanitize=vptr or -fsanitize=undefined that implies that.
[Bug target/104768] [nvptx] Exploit Independent Thread Scheduling for sm_70+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104768 --- Comment #1 from Tom de Vries --- Hmm, reading about it a bit more, it's more about enabling algorithms that were not possible before, than about performance improvements. So, we should aim at having test-cases, both openacc and openmp that hang on previous architectures but pass with sm_70+.
[Bug target/104893] [nvptx] Handle Independent Thread Scheduling for sm_70+ with -msoft-stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104893 --- Comment #1 from Tom de Vries --- (In reply to Tom de Vries from comment #0) > The per-thread call stack is handled for .local memory by the CUDA driver. > > For the 'soft stack' that's not the case. Hmm, actually there's .local memory used, just not "directly". Possibly the documentation needs updating to point that out. So, there doesn't seem to be an issue related to overlapping storage. So I wonder, is the stack pointer also per thread then? Or still per-warp?
[Bug tree-optimization/104931] wrong-code with number_of_iterations_lt_to_ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104931 --- Comment #2 from Richard Biener --- But maybe the code relies on a positive 'delta' - after all the same issue must exist for integer typed IVs. Probably most interesting cases get folded early in the correct way if they do not iterate. Given niter_type is unsigned_type_for (type) the use of FLOOR_MOD_EXPR seems pointless but would be required when doing a signed floor-mod as in the fix. Note there's tree niter_type = TREE_TYPE (step); tree mod = fold_build2 (FLOOR_MOD_EXPR, niter_type, *delta, step); .. if (integer_nonzerop (mod)) mod = fold_build2 (MINUS_EXPR, niter_type, step, mod); .. mpz_init (mmod); wi::to_mpz (wi::to_wide (mod), mmod, UNSIGNED); mpz_neg (mmod, mmod); so there's evidence that 'mod' is assumed to be positive in the end but 'delta' can be effectively signed here. Note 'step' is the absolute value of step, it's always (made) positive. The code has been this way since Zdenek wrote it. The proposed patch has passed bootstrap & testing (but I believe it's incomplete).
[Bug target/104666] [12 Regression] ICE in related_vector_mode, at stor-layout.c:537
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104666 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #9 from Jakub Jelinek --- .
[Bug tree-optimization/104935] [12 Regression] 554.roms_r ELF binary increased with r12-7612-g69619acd8d9b5856
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104935 --- Comment #2 from Martin Liška --- And the revision is also responsible for slower build time here of 481.wrf: https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=301.270.8
[Bug c++/103177] incorrect error message for ambiguous lookup with a static member function from a private base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103177 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |12.0 Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org CC||ppalka at gcc dot gnu.org Status|NEW |RESOLVED --- Comment #3 from Patrick Palka --- Fixed for GCC 12.
[Bug c++/103177] incorrect error message for ambiguous lookup with a static member function from a private base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103177 --- Comment #2 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:ffe9c0a0d3564a6083ea6194eb3374a89c29c085 commit r12-7656-gffe9c0a0d3564a6083ea6194eb3374a89c29c085 Author: Patrick Palka Date: Tue Mar 15 08:50:24 2022 -0400 c++: extraneous access error with ambiguous lookup [PR103177] When a lookup is ambiguous, lookup_member still attempts to check access of the first member found before diagnosing the ambiguity and propagating the error, and this may cause us to issue an extraneous access error as in the testcase below (for B1::foo). This patch fixes this by swapping the order of the ambiguity and access checks within lookup_member. In passing, since the only thing that could go wrong during lookup_field_r is ambiguity, we might as well hardcode that in lookup_member and get rid of lookup_field_info::errstr. PR c++/103177 gcc/cp/ChangeLog: * search.cc (lookup_field_info::errstr): Remove this data member. (lookup_field_r): Don't set errstr. (lookup_member): Check ambiguity before checking access. Simplify accordingly after errstr removal. Exit early upon error or empty result. gcc/testsuite/ChangeLog: * g++.dg/lookup/ambig6.C: New test.
[Bug target/91229] RISC-V ABI problem with zero-length bit-fields and float struct fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91229 --- Comment #5 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:98afdc3e2bfccf0a1337013b54f2c5634ef40ee5 commit r12-7655-g98afdc3e2bfccf0a1337013b54f2c5634ef40ee5 Author: Jakub Jelinek Date: Tue Mar 15 13:34:33 2022 +0100 riscv: Allow -Wno-psabi to turn off ABI warnings [PR91229] While checking if all targets honor -Wno-psabi for ABI related warnings or messages, I found that almost all do, except for riscv. In the testsuite when we want to ignore ABI related messages we typically use -Wno-psabi -w, but it would be nice to get rid of those -w uses eventually. The following allows silencing those warnings with -Wno-psabi rather than just -w even on riscv. 2022-03-15 Jakub Jelinek PR target/91229 * config/riscv/riscv.cc (riscv_pass_aggregate_in_fpr_pair_p, riscv_pass_aggregate_in_fpr_and_gpr_p): Pass OPT_Wpsabi instead of 0 to warning calls.
[Bug tree-optimization/104935] [12 Regression] 554.roms_r ELF binary increased with r12-7612-g69619acd8d9b5856
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104935 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0 --- Comment #1 from Richard Biener --- Possibly back to the level it had before (or with GCC 11). There's likely quite some changes, somebody needs to extract examples.
[Bug rtl-optimization/104814] [10/11 Regression] ifcvt: Deleting live variable in IF-CASE-2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104814 --- Comment #7 from Stefan Schulze Frielinghaus --- Gave trunk a try and it worked fine for me. Thanks for the fix!
[Bug tree-optimization/104935] New: [12 Regression] 554.roms_r ELF binary increased with r12-7612-g69619acd8d9b5856
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104935 Bug ID: 104935 Summary: [12 Regression] 554.roms_r ELF binary increased with r12-7612-g69619acd8d9b5856 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Blocks: 26163 Target Milestone: --- Can be seen here: https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=475.528.4 increased (w/o debug info) from 1316272 B to 1414656 B. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug sanitizer/104934] New: -fsanitize=undefined codegen err
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104934
Bug ID: 104934
Summary: -fsanitize=undefined codegen err
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: dimhen at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
r12-7608 FAIL
Probably FAIL long ago: gcc-8 FAIL
gcc version 8.0.1 20180125 (experimental) [trunk revision 257061] (GCC)
$ g++ -fsanitize=undefined -c -o x.o x.ii && nm -u --reverse-sort x.o
U _ZTI1S
$ g++ -c -o x.o x.ii && nm -u --reverse-sort x.o
$ cat x.ii
struct a {};
struct b {
a c;
};
struct S : a {
virtual int d();
};
struct e : b {
unsigned f();
};
unsigned e::f() { static_cast(); return 0; }
$ ~/arch-gcc/gcc_current/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/home/dimhen/arch-gcc/gcc_current/bin/g++
COLLECT_LTO_WRAPPER=/home/dimhen/arch-gcc/gcc_current/libexec/gcc/x86_64-pc-linux-gnu/12.0.1/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
Target: x86_64-pc-linux-gnu
Configured with: /home/dimhen/src/gcc_current/configure
--prefix=/home/dimhen/arch-gcc/gcc_current
--enable-checking=yes,df,fold,rtl,extra --enable-languages=c,c++,lto
--disable-multilib --enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-gnu-indirect-function --enable-cet --with-tune=native
--enable-libstdcxx-debug
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220311 (experimental) [master r12-7608-g5e28be89665] (GCC)
[Bug target/104933] New: [nvptx] muniform-simt optimization: determine inside/outside SIMT region at compile time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104933 Bug ID: 104933 Summary: [nvptx] muniform-simt optimization: determine inside/outside SIMT region at compile time Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- The switch -muniform-simt attempts to deal with a problem outside simt regions by rewriting the instruction stream. In the general case we don't know for an insn whether it's inside or outside an simt region, so the reorg pass nvptx_reorg_uniform_simt rewrites all insns. However, inside the simt regions, the rewrite should have no effect, and this is done by maintaining predicates in some registers which have different values inside and outside an simt region. But for a function that contains SIMT entry/exit markers, we do known whether an insn is inside or outside and SIMT region, and we could evaluate these predicates at compile time, which might be more optimal, and might make the code more readable.
[Bug target/104482] ICE: Segmentation fault (in rs6000_builtin_type_compatible), or ICE: tree check: expected class 'type', have 'reference' (attr_addr_expr) in cp_type_quals, at cp/typeck.cc:10955
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104482 --- Comment #2 from Kewen Lin --- One fix has been posted via https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591768.html
[Bug d/104911] [12 regression] Comparison failure in gcc/d/typesem.o etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104911 --- Comment #4 from Rainer Orth --- Created attachment 52630 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52630=edit stage 2 and 3 objects and assembler output I've now compiled typesem.d and semantic3.d using the stage 1 and 2 gdc respectively with -save-temps added (with a source tree as of 1b85638affe6c987a33427c54e0369b819cd7915, i.e. before the problematic commit, so I could repeat the procedure before and after with the same sources). typesem.s indeed shows small codegen differences, while for semantic3.s there are both codegen differences per se as well as label renamings that may not effect the object files.
[Bug target/104916] [nvptx] Handle Independent Thread Scheduling for sm_70+ with -muniform-simt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104916 --- Comment #3 from Tom de Vries --- Anyway, having reread the volta architecture whitepaper again, I think it's ok to use the solution I already found that does work (see PR104783): add a warp sync at simt exit. The tricky bit is that we rely on the warps to stay uniform after that warp sync until the next simt region entry. Which AFAICT is not something enforced by specification, but rather by a assuming that the 'Convergence optimizer' has a sane implementation.
[Bug c++/69623] Invalid deduction of non-trailing template parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69623
--- Comment #8 from Ed Catmur ---
(In reply to jim x from comment #7)
>
> auto f(auto..., auto a, auto...) { return a; }
>
> IIUC, this is just disallowed since all arguments would only match the first
> function parameter pack.
Maybe? But all 4 major compilers currently permit it (with identical behavior),
so is it worth breaking existing code by disallowing it?
[Bug target/99744] __attribute__ ((target("general-regs-only"))) doesn't work with GPR intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99744
Marc Poulhiès changed:
What|Removed |Added
CC||poulhies at adacore dot com
--- Comment #16 from Marc Poulhiès ---
Hi!
I'm seeing regressions in pr99744-{1,2,4,5}.c for an i586 target where MMX/SSE
are not enabled.
IIUC, your patch inserts "general-regs-only" in x86gprintrin.h if MMX or SSE is
enabled and makes the inlining of the calls in theses tests (using
target("general-regs-only")) be compatible with the intrinsics defined in the
header.
In my case, MMX/SSE being both disabled, the calls can't be inlined (mismatch
of target options).
Would that still be correct to change the
#if defined __MMX__ || defined __SSE__
by
#if defined __i686__
?
[Bug tree-optimization/104931] wrong-code with number_of_iterations_lt_to_ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104931
--- Comment #1 from Richard Biener ---
I think the issue is latent on trunk. The fix should be
diff --git a/gcc/tree-ssa-loop-niter.c b/gcc/tree-ssa-loop-niter.c
index b767056aeb0..21e25cabbd2 100644
--- a/gcc/tree-ssa-loop-niter.c
+++ b/gcc/tree-ssa-loop-niter.c
@@ -1171,7 +1171,17 @@ number_of_iterations_lt_to_ne (tree type, affine_iv
*iv0, affine_iv *iv1,
bool exit_must_be_taken, bounds *bnds)
{
tree niter_type = TREE_TYPE (step);
- tree mod = fold_build2 (FLOOR_MOD_EXPR, niter_type, *delta, step);
+ tree mod;
+ if (POINTER_TYPE_P (type))
+{
+ /* For pointers both step and delta have to be interpreted signed. */
+ mod = fold_build2 (FLOOR_MOD_EXPR, ssizetype,
+fold_convert (ssizetype, *delta),
+fold_convert (ssizetype, step));
+ mod = fold_convert (niter_type, mod);
+}
+ else
+mod = fold_build2 (FLOOR_MOD_EXPR, niter_type, *delta, step);
tree tmod;
mpz_t mmod;
tree assumption = boolean_true_node, bound, noloop;
[Bug target/104932] New: [nvptx] Subreg validation error for V2SI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104932
Bug ID: 104932
Summary: [nvptx] Subreg validation error for V2SI
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
When building with the patch from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104916#c2 , but allowing a shuffle
for V2SImode, we run into an assert when trying to create a subreg here:
...
case E_V2SImode:
{
rtx src0 = gen_rtx_SUBREG (SImode, src, 0);
rtx src1 = gen_rtx_SUBREG (SImode, src, 4); < HERE >
rtx dst0 = gen_rtx_SUBREG (SImode, dst, 0);
rtx dst1 = gen_rtx_SUBREG (SImode, dst, 4);
...
So, is this code otherwise not triggered and has it bitrotted, or is there
something specific about src that triggers the assert?
Assert looks like:
...
during RTL pass: mach
/home/vries/oacc/trunk/source-gcc/newlib/libc/stdlib/arc4random.c: In function
‘_rs_stir’:
/home/vries/oacc/trunk/source-gcc/newlib/libc/stdlib/arc4random.c:103:1:
internal compiler error: in gen_rtx_SUBREG, at emit-rtl.cc:1022
103 | }
| ^
0xde1b17 gen_rtx_SUBREG(machine_mode, rtx_def*, poly_int<1u, unsigned long>)
/home/vries/oacc/trunk/source-gcc/gcc/emit-rtl.cc:1022
0x197aedc nvptx_gen_shuffle(rtx_def*, rtx_def*, rtx_def*, nvptx_shuffle_kind)
/home/vries/oacc/trunk/source-gcc/gcc/config/nvptx/nvptx.cc:2000
0x1981165 nvptx_unisimt_handle_set
/home/vries/oacc/trunk/source-gcc/gcc/config/nvptx/nvptx.cc:3303
0x19816af nvptx_reorg_uniform_simt
/home/vries/oacc/trunk/source-gcc/gcc/config/nvptx/nvptx.cc:3386
0x1987bb7 nvptx_reorg
/home/vries/oacc/trunk/source-gcc/gcc/config/nvptx/nvptx.cc:5773
0x13c3e38 execute
/home/vries/oacc/trunk/source-gcc/gcc/reorg.cc:3927
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/104931] wrong-code with number_of_iterations_lt_to_ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104931 Richard Biener changed: What|Removed |Added Last reconfirmed||2022-03-15 Known to fail||10.3.1, 11.2.1 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 Keywords||wrong-code Known to work||12.0 Status|UNCONFIRMED |ASSIGNED
[Bug tree-optimization/104931] New: wrong-code with number_of_iterations_lt_to_ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104931
Bug ID: 104931
Summary: wrong-code with number_of_iterations_lt_to_ne
Product: gcc
Version: 11.2.0
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: ---
The premake tool is miscompiled when building it with LTO on i586-linux,
resulting in it immediately segfaulting via
==9912== Invalid read of size 4
==9912==at 0x8162378: UnknownInlinedFun (lapi.c:197)
==9912==by 0x8162378: lua_rotate.constprop.0 (lapi.c:217)
==9912==by 0x8063881: luaL_requiref (lauxlib.c:983)
==9912==by 0x807DF76: luaL_openlibs (linit.c:64)
==9912==by 0x8061128: main (premake_main.c:15)
==9912== Address 0x43816dc is 12 bytes before a block of size 408 alloc'd
==9912==at 0x4035EDB: realloc (in
/usr/lib64/valgrind/vgpreload_memcheck-x86-linux.so)
==9912==by 0x80806A3: luaM_realloc_ (lmem.c:86)
==9912==by 0x807727E: luaD_reallocstack (ldo.c:182)
this can be reproduced with GCC 10 and GCC 11 but not on trunk. After checking
out https://github.com/premake/premake-core.git do
make -f Bootstrap.mak linux CC="gcc-11 -m32" CFLAGS="-O2 -flto -g"
and ./bin/release/premake will then segfault.
I've narrowed this down to the first IPA CP clone of lua_rotate being
miscompiled, we enter number_of_iterations_lt_to_ne for
exit condition [(struct TValue *) (_2 + 4294967272) + 12, + ,
24](no_overflow) < _2 + 4294967272
with delta being 4294967284, the step type is unsigned int. The problem
is that for pointer IVs the step type has to be interpreted as signed, but
the code uses an unsigned FLOOR_MOD to compute the condition under which
the loop will not iterate which it computes to
result:
zero if (struct TValue *) (_2 + 4294967272) + 12 > _2 + 4294967292
# of iterations 178956971, bounded by 0
which is always false (but not folded). When making sure to use a signed
type to compute the modulo the miscompile is gone and we manage to
compute the correct
result:
zero if (struct TValue *) (_2 + 4294967272) + 12 > _2 + 4294967284(OVF)
# of iterations 0(OVF), bounded by 0
I've failed to create a small testcase - there seem to be special circumstances
required that make us enter niter analysis with exactly this SCEV. The
simplified testcase
struct X { int x[3]; };
static void reverse (struct X *from, struct X *to)
{
do
{
struct X temp = *from;
*from = *to;
*to = temp;
from++;
to--;
}
while (from < to);
}
void
lua_rotate (struct X **L)
{
struct X *y = *L;
struct X *to = y - 1;
struct X *from = y - 2;
reverse (from, to);
}
does not exhibit this problem.
[Bug target/104781] [12 regression] SEGV in _Unwind_GetGR during i386 Ada bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104781 --- Comment #15 from Jakub Jelinek --- r12-7654-gda24fce323eaf088 should fix that.
[Bug target/104916] [nvptx] Handle Independent Thread Scheduling for sm_70+ with -muniform-simt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104916 --- Comment #2 from Tom de Vries --- Created attachment 52629 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52629=edit Attempt, runs into driver internal error FTR, this is an attempt at a fix. It does the "predicate ld/st to only execute in lane 0, and propagate ld result", expect for modes where we run into a problem with producing a shuffle (HFmode, V2SImode), where we use the "wrap each ld/st in two bar.warp.sync" approach instead. For libgomp/testsuite/libgomp.c++/target_teams_distribute__parallel_for__simd.C (copied from OvO) I end up with: ... Linking Link complete: 0.00ms Link log warning : Stack size for entry function '_Z48test_target_teams_distribute__parallel_for__simdv$_omp_fn$0' cannot be statically determined libgomp: Link error log fatal : Internal error: reference to deleted section ... This may be due to a problem with the patch or the driver, I'm not sure.
[Bug target/104781] [12 regression] SEGV in _Unwind_GetGR during i386 Ada bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104781 Ulrich Drepper changed: What|Removed |Added CC||drepper.fsp+rhbz at gmail dot com --- Comment #14 from Ulrich Drepper --- My standard build now fails in stage 1 with this patch when compiling unwind-dw2.c for x86: .../gcc-builds/20220315/gcc/include/cetintrin.h: In function ‘_Unwind_RaiseException’: .../gcc-builds/20220315/gcc/include/cetintrin.h:47:1: error: inlining failed in call to ‘always_inline’ ‘_get_ssp’: target specific option mismatch 47 | _get_ssp (void) | ^~~~ .../gnu/gcc/libgcc/config/i386/shadow-stack-unwind.h:32:26: note: called from here 32 | _Unwind_Word ssp = _get_ssp (); \ | ^~~ .../gnu/gcc/libgcc/unwind-dw2.c:1654:7: note: in expansion of macro ‘_Unwind_Frames_Extra’ 1654 | _Unwind_Frames_Extra (FRAMES); \ | ^~~~ .../gnu/gcc/libgcc/unwind.inc:140:3: note: in expansion of macro ‘uw_install_context’ 140 | uw_install_context (_context, _context, frames); and so on for the other CET functions. When I comment out the LIBGCC2_UNWIND_ATTRIBUTE definition in config/i386/i386.h it works. The compiler command line that is used is .../gcc-builds/20220315/./gcc/xgcc -B.../gcc-builds/20220315/./gcc/ -B/usr/x86_64-redhat-linux/bin/ -B/usr/x86_64-redhat-linux/lib/ -isystem /usr/x86_64-redhat-linux/include -isystem /usr/x86_64-redhat-linux/sys-include -fno-checking -g -O2 -m32 -O2 -g -O2 -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fpic -mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fpic -mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -I. -I. -I../../.././gcc -I.../gcc/libgcc -I.../gcc/libgcc/. -I.../gcc/libgcc/../gcc -I.../gcc/libgcc/../include -I.../gcc/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -o unwind-dw2.o -MT unwind-dw2.o -MD -MP -MF unwind-dw2.dep -fexceptions -c .../gcc/libgcc/unwind-dw2.c -fvisibility=hidden -DHIDE_EXPORTS This is on an up-to-date Fedora 35 system with gcc 11.2.1-9
[Bug target/104930] built-in function requires "-flax-vector-conversions" to get better warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104930 --- Comment #2 from Kewen Lin --- It's regressed from r12-5752-gd08236359eb229, in the new bif infrastructure we don't use the type opaque_V4SI_type_node for prototype of overloaded built-in functions any more.
[Bug sanitizer/104929] UBSAN: false positive with sprintf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104929
--- Comment #3 from Jakub Jelinek ---
In this particular case the problem is that UBSAN adds the non-NULL tests, so
the IL becomes if (!s) __ubsan_handle_nonnull_arg (...); sprintf(s, " "); if
(!s) __ubsan_handle_nonnull_arg (...); return __builtin_strlen(s);
and then jump threading thinks it is a good idea to thread it, so turns it into
if (!s) { __ubsan_handle_nonnull_arg (...); sprintf(NULL, " ");
__ubsan_handle_nonnull_arg (...); } else sprintf(s, " ");
and that is why the warning is emitted (pain of all the middle-end warnings).
The ways out of this might be convince jump threading to punt in such cases
(when those are clearly ubsan tests) because we expect them to be extremely
unlikely,
or use some new internal function from between the ubsan pass and sanopt, where
the test for non-NULL wouldn't be explicit in the IL until very late (that
would also prevent the jump threading), or during the jump threading when we
detect these ubsan-ish tests suppress some of the warnings on the threaded
stmts.
[Bug target/104930] built-in function requires "-flax-vector-conversions" to get better warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104930 Kewen Lin changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org --- Comment #1 from Kewen Lin --- Although it's related to error messages change and users can get more reasonable error messages with extra option -flax-vector-conversions, I think we still want the previous behavior?
[Bug target/104930] New: built-in function requires "-flax-vector-conversions" to get better warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104930
Bug ID: 104930
Summary: built-in function requires "-flax-vector-conversions"
to get better warning
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
Target Milestone: ---
- Test case -
$cat new_test.c
typedef vector unsigned int v4u;
extern v4u vg;
v4u testXXPERMDI(void) { return __builtin_vsx_xxpermdi(vg, vg); }
- Option -
-mcpu=power9
===
GCC emits:
new_test.c: In function ‘testXXPERMDI’:
new_test.c:5:1: note: use ‘-flax-vector-conversions’ to permit conversions
between vectors with differing element types or numbers of subparts
5 | v4u testXXPERMDI(void) { return __builtin_vsx_xxpermdi(vg, vg); }
| ^~~
new_test.c:5:56: error: incompatible type for argument 1 of
‘__builtin_vsx_xxpermdi’
5 | v4u testXXPERMDI(void) { return __builtin_vsx_xxpermdi(vg, vg); }
|^~
||
|v4u {aka
__vector(4) unsigned int}
new_test.c:5:56: note: expected ‘__vector signed char’ {aka ‘__vector(16)
signed cha ’} but argument is of type ‘v4u’ {aka ‘__vector(4) unsigned int’}
new_test.c:5:60: error: incompatible type for argument 2 of
‘__builtin_vsx_xxpermdi’
5 | v4u testXXPERMDI(void) { return __builtin_vsx_xxpermdi(vg, vg); }
|^~
||
|v4u {aka
__vector(4) unsigned int}
new_test.c:5:60: note: expected ‘__vector signed char’ {aka ‘__vector(16)
signed cha ’} but argument is of type ‘v4u’ {aka ‘__vector(4) unsigned int’}
new_test.c:5:33: error: too few arguments to function ‘__builtin_vsx_xxpermdi’
5 | v4u testXXPERMDI(void) { return __builtin_vsx_xxpermdi(vg, vg); }
| ^~
But with r12-5751-gc9dd01314d8467, it only has:
new_test.c: In function ‘testXXPERMDI’:
new_test.c:5:33: error: too few arguments to function ‘__builtin_vsx_xxpermdi’
5 | v4u testXXPERMDI(void) { return __builtin_vsx_xxpermdi(vg, vg); }
| ^~
[Bug sanitizer/104929] UBSAN: false positive with sprintf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104929 --- Comment #2 from Andreas Schwab --- I think the point here is that s is not guaranteed to be non-NULL. You can add if (s == 0) __builtin_unreachable(); to suppress the warning.
[Bug sanitizer/104929] UBSAN: false positive with sprintf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104929 --- Comment #1 from Martin Liška --- It's a quite known limitation that usage of sanitizers tends to emit false positives of various warnings.
[Bug sanitizer/104929] New: UBSAN: false positive with sprintf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104929
Bug ID: 104929
Summary: UBSAN: false positive with sprintf
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: jengelh at inai dot de
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
// g++ -Wall -fsanitize=undefined -O2 -c t.cpp
#include
size_t fun(char *s)
{
sprintf(s, " ");
return __builtin_strlen(s);
}
Observed:
t.cpp: In function ‘size_t fun(char*)’:
t.cpp:5:16: warning: null destination pointer [-Wformat-overflow=]
5 | sprintf(s, " ");
//gcc version 11.2.1 20220103 [revision
d4a1d3c4b377f1d4acb34fe1b55b5088a3f293f6] (SUSE Linux), Linux amd64 glibc-2.35
Expected:
Don't warn(?)
[Bug target/104890] [12 Regression] fails to build the 32bit libgcc on x86_64-linux-gnu (--enable-cet --with-arch-32=i686)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104890 --- Comment #12 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:da24fce323eaf088239e0f900dd23f6b05d552c1 commit r12-7654-gda24fce323eaf088239e0f900dd23f6b05d552c1 Author: Jakub Jelinek Date: Tue Mar 15 10:24:22 2022 +0100 i386: Use no-mmx,no-sse for LIBGCC2_UNWIND_ATTRIBUTE [PR104890] Regardless of the outcome of the general-regs-only stuff in x86gprintrin.h, apparently general-regs-only is much bigger hammer than no-sse, and e.g. using 387 instructions in the unwinder isn't a big deal, it never needs to realign the stack because of it. So, the following patch uses no-sse (and adds no-mmx to it, even when not strictly needed). 2022-03-15 Jakub Jelinek PR target/104890 * config/i386/i386.h (LIBGCC2_UNWIND_ATTRIBUTE): Use no-mmx,no-sse instead of general-regs-only.
[Bug tree-optimization/104917] No runtime alias test required for dependent reductions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104917 --- Comment #2 from Richard Biener --- (In reply to Jakub Jelinek from comment #1) > What if x = y + 1 or y = x + 1 ? We then do (y+1)[i] += a[i]; (y+1)[i+1] += a[i+1]; y[i] += a[i]; y[i+1] += a[i+1]; instead of (y+1)[i] += a[i]; y[i] += a[i]; (y+1)[i+1] += a[i+1]; y[i+1] += a[i+1]; which should be OK if re-associating the adds to y[i+1] is OK.
[Bug libstdc++/104928] std::counting_semaphore on Linux can sleep forever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104928 --- Comment #1 from Tee Hao Wei --- Created attachment 52628 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52628=edit Preprocessed, gzipped reproducer
[Bug libstdc++/104928] New: std::counting_semaphore on Linux can sleep forever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104928
Bug ID: 104928
Summary: std::counting_semaphore on Linux can sleep forever
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: angelsl at in04 dot sg
Target Milestone: ---
The __atomic_semaphore implementation of std::counting_semaphore can sometimes
sleep forever, especially when there is high contention.
Here is a possible sequence of events that can lead to the issue:
1. _M_counter is 1.
2. thread A enters (semaphore_base.h) _M_acquire -> (atomic_wait.h)
__atomic_wait_address_bare -> _S_do_spin.
3. In _S_do_spin, thread A does __atomic_load on _M_counter and reads 1.
4. A different thread manages to decrement the semaphore. _M_counter is now 0.
5. Thread A enters __atomic_spin, and all calls to __pred (which just does
_S_do_try_acquire) fail, since _M_counter is now 0. Thread A returns from
__atomic_spin and _S_do_spin with false.
6. Another thread signals the semaphore. _M_counter is back to 1.
7. Thread A returns to __atomic_wait_address_bare and proceeds to call
__platform_wait using the value of _M_counter read in step 3 (= 1).
8. In __platform_wait, thread A calls futex on _M_counter with WAIT_PRIVATE and
value 1. Since _M_counter is still 1, the kernel puts thread A to sleep.
9. Unless the semaphore later reaches 0 again, thread A will never be awoken
since _M_release does not call futex WAKE unless the counter is 0.
This is sort of an ABA problem. I think the most proper solution would be to
make it so that futex is called with value 0 (since that is what we are waiting
for _M_counter to change from). But it will need some restructuring to the
current abstractions over futex that are being used here.
Here is an almost 100%-reliable minimal reproducible example for the issue:
---
// g++ -O2 -std=c++20 -o hang hang.cpp
#include
#include
#include
#include
int main(int argc, char *argv[]) {
std::counting_semaphore s{0};
std::vector threads;
for (size_t i = 0; i < 10; ++i) {
threads.emplace_back([]() {
for (size_t i = 0; i < 100; ++i) {
s.acquire();
}
});
threads.emplace_back([]() {
for (size_t i = 0; i < 100; ++i) {
s.release();
}
});
}
for (auto : threads) t.join();
return 0;
}
---
If you run it, you will observe one or two acquirer threads sleeping
indefinitely at the end. If you observe them in gdb, you will see that they are
waiting on futex, and also that the semaphore counter is actually positive.
Other notes:
- This probably affects the implementation of atomic::wait as well, but I have
not tried that.
- FWIW, libc++ also has this exact issue, but they sidestep it by passing a
timeout to futex(). I don't know whether specifying a timeout was done
intentionally to avoid this issue. I also don't personally think that that is a
great solution to this. (If you run the MRE with clang++ -stdlib=libc++, you
will observe the issue manifesting as some acquirer threads sleeping for a few
seconds until the futex timeout expires.)
System information:
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --enable-bootstrap
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit
--enable-cet=auto --enable-checking=release --enable-clocale=gnu
--enable-default-pie --enable-default-ssp --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-linker-build-id --enable-lto
--enable-multilib --enable-plugin --enable-shared --enable-threads=posix
--disable-libssp --disable-libstdcxx-pch --disable-werror
--with-build-config=bootstrap-lto --enable-link-serialization=1
gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (GCC)
I have attached the preprocessed version of the above MRE.
[Bug tree-optimization/104917] No runtime alias test required for dependent reductions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104917 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- What if x = y + 1 or y = x + 1 ?
[Bug tree-optimization/101895] [11/12 Regression] SLP Vectorizer change pushes VEC_PERM_EXPR into bad location spoiling further optimization opportunities
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101895
--- Comment #6 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:49fb0af9bf8f16907980d383c2bbc85e185ec2e0
commit r12-7653-g49fb0af9bf8f16907980d383c2bbc85e185ec2e0
Author: Roger Sayle
Date: Tue Mar 15 09:05:28 2022 +
PR tree-optimization/101895: Fold VEC_PERM to help recognize FMA.
This patch resolves PR tree-optimization/101895 a missed optimization
regression, by adding a costant folding simplification to match.pd to
simplify the transform "mult; vec_perm; plus" into "vec_perm; mult; plus"
with the aim that keeping the multiplication and addition next to each
other allows them to be recognized as fused-multiply-add on suitable
targets. This transformation requires a tweak to match.pd's
vec_same_elem_p predicate to handle CONSTRUCTOR_EXPRs using the same
SSA_NAME_DEF_STMT idiom used for constructors elsewhere in match.pd.
The net effect is that the following code example:
void foo(float * __restrict__ a, float b, float *c) {
a[0] = c[0]*b + a[0];
a[1] = c[2]*b + a[1];
a[2] = c[1]*b + a[2];
a[3] = c[3]*b + a[3];
}
when compiled on x86_64-pc-linux-gnu with -O2 -march=cascadelake
currently generates:
vbroadcastss%xmm0, %xmm0
vmulps (%rsi), %xmm0, %xmm0
vpermilps $216, %xmm0, %xmm0
vaddps (%rdi), %xmm0, %xmm0
vmovups %xmm0, (%rdi)
ret
but with this patch now generates the improved:
vpermilps $216, (%rsi), %xmm1
vbroadcastss%xmm0, %xmm0
vfmadd213ps (%rdi), %xmm0, %xmm1
vmovups %xmm1, (%rdi)
ret
2022-03-15 Roger Sayle
Marc Glisse
Richard Biener
gcc/ChangeLog
PR tree-optimization/101895
* match.pd (vec_same_elem_p): Handle CONSTRUCTOR_EXPR def.
(plus (vec_perm (mult ...) ...) ...): New reordering
simplification.
gcc/testsuite/ChangeLog
PR tree-optimization/101895
* gcc.target/i386/pr101895.c: New test case.
[Bug target/104894] [11/12 Regression] ICE with -fno-plt -mcpu=power10 on PowerPC64 LE Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104894 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- I.e. r11-2768-g95f17e26112d8a0700e so that it works as a hyperlink.
[Bug c++/104847] [11/12 Regression] ICE in write_unqualified_name, at cp/mangle.cc:1406
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104847 --- Comment #3 from Jakub Jelinek --- Though the nontype-class-union1.C testcase doesn't have explicit designator syntax either.
[Bug c++/104847] [11/12 Regression] ICE in write_unqualified_name, at cp/mangle.cc:1406
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104847
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
struct S { int i; };
union U { S k; };
template T sink(T&&, Ts&&...);
template
decltype(sink(U{.k={.i=1}},T())) f(T) { return U{1}; }
int main() { f(3); }
compiles fine. I guess the question is if ce->index == NULL should be mangled
without the di production of , or we should implicitly find
the first initializable field and use that with di, i.e. if this should mangle
as
_Z1fIiEDTcl4sinktl1Udi1kilLi1EEEcvT__EEES1_
or as
_Z1fIiEDTcl4sinktl1ULi1EEcvT__EEES1_
[Bug fortran/104927] New: Invalid array size specification accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104927 Bug ID: 104927 Summary: Invalid array size specification accepted Product: gcc Version: 10.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: federico.perini at gmail dot com Target Milestone: --- Created attachment 52627 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52627=edit test program A low priority bug, I guess. The following invalid code with double array size specifications is accepted by gfortran 10.3.0 all the way down to at least 8.1.0: integer, allocatable, dimension(:,:) :: a(:) integer, allocatable, dimension(:) :: b(:,:) integer, allocatable, dimension(:,:) :: c(:,:) It appears that the shape then picked by gfortran is that on the right hand side, but no errors/warning are printed. I've attached a test program for this. Thanks for the hardwork on gfortran! Federico
[Bug target/104926] New: [nvptx] Use human-readable register names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104926 Bug ID: 104926 Summary: [nvptx] Use human-readable register names Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- There are some pseudo registers that are used for a specific function, like cfun->machine->unisimt_outside_simt_predicate. It would be good to print these as '%outside_simt_p' or '%r_outside_simt_p' or some such. Perhaps the latter is better, to be able to easily distinguish them from ptx special registers like '%tid'.
[Bug rtl-optimization/104637] [9/10/11 Regression] ICE: maximum number of LRA assignment passes is achieved (30) with -Og -fno-forward-propagate -mavx since r9-5221-gd8fcab689435a29d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104637 Jakub Jelinek changed: What|Removed |Added Summary|[9/10/11/12 Regression] |[9/10/11 Regression] ICE: |ICE: maximum number of LRA |maximum number of LRA |assignment passes is|assignment passes is |achieved (30) with -Og |achieved (30) with -Og |-fno-forward-propagate |-fno-forward-propagate |-mavx since |-mavx since |r9-5221-gd8fcab689435a29d |r9-5221-gd8fcab689435a29d --- Comment #7 from Jakub Jelinek --- Fixed on the trunk.
[Bug target/104925] New: [nvptx] Use "%" as register prefix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104925 Bug ID: 104925 Summary: [nvptx] Use "%" as register prefix Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- In the ptx isa doc I read: ... PTX allows the percentage sign as the first character of an identifier. The percentage sign can be used to avoid name conflicts, e.g., between user- defined variable names and compiler-generated names. ... I've been using variable names for for instance temporary variables in various insn patterns without percentage signs, so there's the potential for a clash with user-defined names. This should be fixed by prefixing with '%'.
[Bug rtl-optimization/104814] [10/11 Regression] ifcvt: Deleting live variable in IF-CASE-2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104814 Jakub Jelinek changed: What|Removed |Added Summary|[10/11/12 Regression] |[10/11 Regression] ifcvt: |ifcvt: Deleting live|Deleting live variable in |variable in IF-CASE-2 |IF-CASE-2 --- Comment #6 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug c++/104623] [11 Regression] ICE in cp_parser_skip_to_pragma_eol, at cp/parser.cc:4107
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104623 Jakub Jelinek changed: What|Removed |Added Summary|[11/12 Regression] ICE in |[11 Regression] ICE in |cp_parser_skip_to_pragma_eo |cp_parser_skip_to_pragma_eo |l, at cp/parser.cc:4107 |l, at cp/parser.cc:4107 --- Comment #5 from Jakub Jelinek --- Fixed on the trunk so far. It is ice-on-invalid-code, so I'm a hesistant to backport this.
[Bug c++/104623] [11/12 Regression] ICE in cp_parser_skip_to_pragma_eol, at cp/parser.cc:4107
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104623 --- Comment #4 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:efd1582926f3278a5e57ebab7d87fc870f06ecea commit r12-7652-gefd1582926f3278a5e57ebab7d87fc870f06ecea Author: Jakub Jelinek Date: Tue Mar 15 09:15:27 2022 +0100 c++: Fix up cp_parser_skip_to_pragma_eol [PR104623] We ICE on the following testcase, because we tentatively parse it multiple times and the erroneous attribute syntax results in cp_parser_skip_to_end_of_statement, which when seeing CPP_PRAGMA (can be any deferred one, OpenMP/OpenACC/ivdep etc.) it calls cp_parser_skip_to_pragma_eol, which calls cp_lexer_purge_tokens_after. That call purges all the tokens from CPP_PRAGMA until CPP_PRAGMA_EOL, excluding the initial CPP_PRAGMA though (but including the final CPP_PRAGMA_EOL). This means the second time we parse this, we see CPP_PRAGMA with no tokens after it from the pragma, most importantly not the CPP_PRAGMA_EOL, so either if it is the last pragma in the TU, we ICE, or if there are other pragmas we treat everything in between as a pragma. I've tried various things, including making the CPP_PRAGMA token itself also purged, or changing the cp_parser_skip_to_end_of_statement (and cp_parser_skip_to_end_of_block_or_statement) to call it with NULL instead of token, so that this purging isn't done there, but each patch resulted in lots of regressions. But removing the purging altogether surprisingly doesn't regress anything, and I think it is the right thing, if we e.g. parse tentatively, why can't we parse the pragma multiple times or at least skip over it? 2022-03-15 Jakub Jelinek PR c++/104623 * parser.cc (cp_parser_skip_to_pragma_eol): Don't purge any tokens. * g++.dg/gomp/pr104623.C: New test.
[Bug rtl-optimization/104814] [10/11/12 Regression] ifcvt: Deleting live variable in IF-CASE-2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104814
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:a2645cd8fb33b36d737b310e26f4c47401305c7b
commit r12-7651-ga2645cd8fb33b36d737b310e26f4c47401305c7b
Author: Jakub Jelinek
Date: Tue Mar 15 09:12:03 2022 +0100
ifcvt: Punt if not onlyjump_p for find_if_case_{1,2} [PR104814]
find_if_case_{1,2} implicitly assumes conditional jumps and rewrites them,
so if they have extra side-effects or are say asm goto, things don't work
well, either the side-effects are lost or we could ICE.
In particular, the testcase below on s390x has there a doloop instruction
that decrements a register in addition to testing it for non-zero and
conditionally jumping based on that.
The following patch fixes that by punting for !onlyjump_p case, i.e.
if there are side-effects in the jump instruction or it isn't a plain PC
setter.
Also, it assumes BB_END (test_bb) will be always non-NULL, because basic
blocks with 2 non-abnormal successor edges should always have some
instruction
at the end that determines which edge to take.
2022-03-15 Jakub Jelinek
PR rtl-optimization/104814
* ifcvt.cc (find_if_case_1, find_if_case_2): Punt if test_bb
doesn't
end with onlyjump_p. Assume BB_END (test_bb) is always non-NULL.
* gcc.c-torture/execute/pr104814.c: New test.
[Bug target/104923] [11/12 Regression] MMA __builtin_mma_disassemble_acc test case ICEs in LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104923 Richard Biener changed: What|Removed |Added Target Milestone|12.0|11.3 Priority|P3 |P2 Summary|MMA |[11/12 Regression] MMA |__builtin_mma_disassemble_a |__builtin_mma_disassemble_a |cc test case ICEs in LRA|cc test case ICEs in LRA
[Bug target/103743] PPC: Inefficient equality compare for large 64-bit constants having only 16-bit relevant bits in high part
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103743 Jiu Fu Guo changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |guojiufu at gcc dot gnu.org --- Comment #4 from Jiu Fu Guo --- rot(a)==rot(b_)==> a==rot(b')
