[Bug middle-end/90323] powerpc should convert equivalent sequences to vec_sel()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90323
--- Comment #9 from luoxhu at gcc dot gnu.org ---
Then we could optimized it in match.pd
diff --git a/gcc/match.pd b/gcc/match.pd
index 036f92fa959..8944312c153 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -3711,6 +3711,17 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
(if (integer_all_onesp (@1) && integer_zerop (@2))
@0
+#if GIMPLE
+(simplify
+ (bit_xor @0 (bit_and @2 (bit_xor @0 @1)))
+ (if (optimize_vectors_before_lowering_p () && types_match (@0, @1)
+ && types_match (@0, @2) && VECTOR_TYPE_P (TREE_TYPE (@0))
+ && VECTOR_TYPE_P (TREE_TYPE (@1)) && VECTOR_TYPE_P (TREE_TYPE (@2)))
+ (with { tree itype = truth_type_for (type); }
+ (vec_cond (convert:itype @2) @1 @0
+#endif
in pr90323.c.033t.forwprop1, it will be optimized to:
:
_1 = ~mask_3(D);
l_5 = _1 & l_4(D);
_2 = mask_3(D) & r_6(D);
_8 = l_4(D) ^ r_6(D);
_10 = mask_3(D) & _8;
_11 = (vector(4) ) mask_3(D);
l_7 = VEC_COND_EXPR <_11, r_6(D), l_4(D)>;
return l_7;
Then in pr90323.c.243t.isel:
[local count: 1073741824]:
_6 = (vector(4) ) mask_1(D);
l_4 = .VCOND_MASK (_6, r_3(D), l_2(D));
return l_4;
final ASM:
without_sel:
.LFB11:
.cfi_startproc
xxsel 34,34,35,36
blr
.long 0
.byte 0,0,0,0,0,0,0,0
.cfi_endproc
.LFE11:
.size without_sel,.-without_sel
.align 2
.p2align 4,,15
.globl with_sel
.type with_sel, @function
with_sel:
.LFB12:
.cfi_startproc
xxsel 34,34,35,36
blr
@segher, Is this reasonable fix ???
[Bug middle-end/90323] powerpc should convert equivalent sequences to vec_sel()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90323
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
CC||luoxhu at gcc dot gnu.org
--- Comment #8 from luoxhu at gcc dot gnu.org ---
Two minor updates for the case mentioned in #c2:
for VEC_SEL (ARG1, ARG2, ARG3):
Returns a vector containing the value of either ARG1 or ARG2 depending on
the
value of ARG3.
#include
#include
volatile vector unsigned orig = {0xebebebeb, 0x34343434, 0x76767676,
0x12121212};
volatile vector unsigned mask = {0x, 0, 0x, 0};
volatile vector unsigned fill = {0xfefefefe, 0x, 0x,
0x};
volatile vector unsigned expected = {0xfefefefe, 0x34343434, 0x,
0x12121212};
__attribute__ ((noinline))
vector unsigned without_sel(vector unsigned l, vector unsigned r, vector
unsigned mask) {
-l = l & ~r;
+l = l & ~mask;
l |= mask & r;
return l;
}
__attribute__ ((noinline))
vector unsigned with_sel(vector unsigned l, vector unsigned r, vector unsigned
mask) {
-return vec_sel(l, mask, r);
+return vec_sel(l, r, mask);
}
int main() {
vector unsigned res1 = without_sel(orig, fill, mask);
vector unsigned res2 = with_sel(orig, fill, mask);
if (!vec_all_eq(res1, expected)) printf ("error1\n");
if (!vec_all_eq(res2, expected)) printf ("error2\n");
return 0;
}
And the ASM would be:
without_sel:
xxlxor 35,34,35
xxland 35,35,36
xxlxor 34,34,35
blr
.long 0
.byte 0,0,0,0,0,0,0,0
with_sel:
xxsel 34,34,35,36
blr
.long 0
.byte 0,0,0,0,0,0,0,0
[Bug c++/94529] [8/9/10/11 Regression] Wrong error message for template member function specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94529 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/99910] [11 Regression] g++.dg/modules/xtreme-header-2_b.C ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99910 --- Comment #1 from Hans-Peter Nilsson --- It looks like commit 41019bfae2673a818 / r11-8011 "libstdc++: Clarify static_assert message" accidentally swept this under the carpet. If I cut off the last word, " type", i.e. the second changed line changed to be " substituting _Tp must not be an lvalue reference", the ICE reappears. I have not ran valgrind or used gcc sanitize-address on this, but that would be a start.
[Bug middle-end/99857] [11 Regression] FAIL: libgomp.c/declare-variant-1.c (test for excess errors) by r11-7926
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99857
Arseny Solokha changed:
What|Removed |Added
CC||asolokha at gmx dot com
--- Comment #5 from Arseny Solokha ---
(In reply to Jan Hubicka from comment #4)
> Having smaller testcase is nice - the libgomp one had quite few
> release_body calls at compile time.
How about this one, reduced from
gcc/testsuite/c-c++-common/gomp/declare-variant-5.c?
void
f3 (void);
#pragma omp declare variant(f3) match(construct = {simd})
void
f5 (void)
{
int i;
#pragma omp simd
for (i = 0; i < 1; i++)
f5 ();
}
% gcc-11.0.1 -flto -fopenmp -c wskzgdhe.c
during IPA pass: modref
wskzgdhe.c:13:1: internal compiler error: in
omp_lto_output_declare_variant_alt, at omp-general.c:2368
13 | }
| ^
0x69caf3 omp_lto_output_declare_variant_alt(lto_simple_output_block*,
cgraph_node*, lto_symtab_encoder_d*)
/var/tmp/portage/sys-devel/gcc-11.0.1_alpha20210404/work/gcc-11-20210404/gcc/omp-general.c:2368
0xc8dca6 output_refs
/var/tmp/portage/sys-devel/gcc-11.0.1_alpha20210404/work/gcc-11-20210404/gcc/lto-cgraph.c:773
0xc8dca6 output_symtab()
/var/tmp/portage/sys-devel/gcc-11.0.1_alpha20210404/work/gcc-11-20210404/gcc/lto-cgraph.c:1017
0xca3961 lto_output()
/var/tmp/portage/sys-devel/gcc-11.0.1_alpha20210404/work/gcc-11-20210404/gcc/lto-streamer-out.c:2810
0xd2b351 write_lto
/var/tmp/portage/sys-devel/gcc-11.0.1_alpha20210404/work/gcc-11-20210404/gcc/passes.c:2680
0xd2b351 ipa_write_summaries_1
/var/tmp/portage/sys-devel/gcc-11.0.1_alpha20210404/work/gcc-11-20210404/gcc/passes.c:2744
0xd2b351 ipa_write_summaries()
/var/tmp/portage/sys-devel/gcc-11.0.1_alpha20210404/work/gcc-11-20210404/gcc/passes.c:2800
0x9a176d ipa_passes
/var/tmp/portage/sys-devel/gcc-11.0.1_alpha20210404/work/gcc-11-20210404/gcc/cgraphunit.c:2204
0x9a176d symbol_table::compile()
/var/tmp/portage/sys-devel/gcc-11.0.1_alpha20210404/work/gcc-11-20210404/gcc/cgraphunit.c:2291
0x9a3f87 symbol_table::compile()
/var/tmp/portage/sys-devel/gcc-11.0.1_alpha20210404/work/gcc-11-20210404/gcc/cgraphunit.c:2271
0x9a3f87 symbol_table::finalize_compilation_unit()
/var/tmp/portage/sys-devel/gcc-11.0.1_alpha20210404/work/gcc-11-20210404/gcc/cgraphunit.c:2539
[Bug tree-optimization/99927] [11 Regression] Wrong code since r11-39-gf9e1ea10e657af9f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99927 --- Comment #14 from Segher Boessenkool --- distribute_notes says Any clobbers from i2 or i1 can only exist if they were added by recog_for_combine. which is not true apparently. But all of this code *does* depend on that, it just doesn't make sense otherwise.
[Bug ipa/99951] Dead return value after modify_call() is not released
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99951 --- Comment #2 from Feng Xue --- Can we report error in verify_ssa() when a non-default SSA's defining statement has NULL bb, which is always a case that the statement is removed somewhere?
[Bug tree-optimization/99966] New: Bounds check not eliminated by assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99966
Bug ID: 99966
Summary: Bounds check not eliminated by assert
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jmuizelaar at mozilla dot com
Target Milestone: ---
#include
#include
#include
#include
uint64_t f(std::vector& data, size_t start, size_t end){
assert(start < end && start < data.size() && end <= data.size());
uint64_t total = 0;
for (size_t i = start; i < end; i++) {
total += data.at(i);
}
return total;
}
https://godbolt.org/z/Ksecrec11
Clang is able to eliminate the the check when using -mllvm
-enable-constraint-elimination
https://godbolt.org/z/K67b8PTM9
[Bug c++/99806] [10/11 Regression] ICE: in tsubst_copy, at cp/pt.c:17247
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99806
--- Comment #3 from Marek Polacek ---
A test that should be accepted:
// PR c++/99806
struct S {
template
void f(T) noexcept(B);
static constexpr bool B = true;
};
[Bug c++/18635] [DR 504] use of uninitialised reference accepted (without -Wuninitialized) in C++ front end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18635
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #18 from Martin Sebor ---
What is this a request for?
GCC 11 issues the warnings below, as well as for most of the test cases here.
Since (I assume most of us agree) rejecting the code would not be
correct/conforming, is there something else to enhance? (There are
bugs/limitations in -Wuninitialized that prevent diagnosing some similar cases
but I'd expect to track those as bugs separately from this request.)
$ cat t.C && gcc -S -Wall t.C
const int* fcp (const int *);
void gcp ()
{
const int *p = fcp (p);// -Wuninitialized
}
const int& fcr (const int &);
void gcr ()
{
const int = fcr (i);// -Wuninitialized
}
int& fr (int &);
void gr ()
{
int = fr (r); // -Wuninitialized
}
t.C: In function ‘void gcp()’:
t.C:5:22: warning: ‘p’ is used uninitialized [-Wuninitialized]
5 | const int *p = fcp (p);// -Wuninitialized
| ^~~
t.C:5:14: note: ‘p’ was declared here
5 | const int *p = fcp (p);// -Wuninitialized
| ^
t.C: In function ‘void gcr()’:
t.C:12:22: warning: ‘i’ is used uninitialized [-Wuninitialized]
12 | const int = fcr (i);// -Wuninitialized
| ^~~
t.C:12:14: note: ‘i’ was declared here
12 | const int = fcr (i);// -Wuninitialized
| ^
t.C: In function ‘void gr()’:
t.C:19:15: warning: ‘r’ is used uninitialized [-Wuninitialized]
19 | int = fr (r); // -Wuninitialized
|~~~^~~
t.C:19:8: note: ‘r’ was declared here
19 | int = fr (r); // -Wuninitialized
|^
[Bug tree-optimization/18501] [8/9/10/11 Regression] Missing 'used uninitialized' warning (CCP)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501 Martin Sebor changed: What|Removed |Added Known to fail||10.2.0, 11.0, 4.7.0, 4.8.4, ||4.9.4, 5.5.0, 6.4.0, 7.2.0, ||8.3.0, 9.1.0 Last reconfirmed|2018-11-03 00:00:00 |2021-4-7 See Also|https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=24639 | --- Comment #95 from Martin Sebor --- Reconfirmed with GCC 11. I wonder if running CCP first, just before the early uninit pass, but only to propagate constants and without modifying the CFG, and then the "late" uninitialized pass to look for uninitialized operands in the PHIs while evaluating the predicates using the CCP lattice values, would be a way to get back the warnings without introducing false positives.
[Bug libgcc/99964] android(bionic) cannot find crti.o and crtn.o on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99964 --- Comment #5 from cqwrteur --- (In reply to Jim Wilson from comment #1) > (In reply to cqwrteur from comment #0) > > bionic simply does not provide crti.o and crtn.o > > https://github.com/aosp-riscv/platform_bionic/tree/master/libc/arch-common/ > > bionic > > That is the RISC-V Android port in progress. It should not be used for > anything other than RISC-V, as RISC-V patches might have accidentally broken > other targets. Use the official Android sources for Aarch64, or maybe > something distributed by Linaro. build of arm-linux-androideabi-g++ is successful too. So it is aarch64 specific issue for android in libgcc. I think Jakub can help me fix it.
[Bug libgcc/99962] Error: unknown mnemonic `type' -- `type(_init)' for crti.s, targetting aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99962 cqwrteur changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from cqwrteur --- The issue is here https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99964
[Bug c++/52625] [8/9/10 Regression] Incorrect specialization semantics of friend class template declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52625 Jason Merrill changed: What|Removed |Added Known to work||11.0 Summary|[8/9/10/11 Regression] |[8/9/10 Regression] |Incorrect specialization|Incorrect specialization |semantics of friend class |semantics of friend class |template declaration|template declaration --- Comment #8 from Jason Merrill --- Fixed for 11 so far.
[Bug c++/41723] [8/9/10 Regression] Error when using a qualified name to declare a nested template instantiation as a friend of the containing template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41723 Jason Merrill changed: What|Removed |Added Summary|[8/9/10/11 Regression] |[8/9/10 Regression] Error |Error when using a |when using a qualified name |qualified name to declare a |to declare a nested |nested template |template instantiation as a |instantiation as a friend |friend of the containing |of the containing template |template Known to work||11.0 --- Comment #6 from Jason Merrill --- Fixed for 11 so far.
[Bug c++/41723] [8/9/10/11 Regression] Error when using a qualified name to declare a nested template instantiation as a friend of the containing template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41723 --- Comment #5 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:fb5ed6d8c90a4bf8e677a3ff9bd79d83636ccff9 commit r11-8035-gfb5ed6d8c90a4bf8e677a3ff9bd79d83636ccff9 Author: Jason Merrill Date: Wed Apr 7 16:42:44 2021 -0400 c++: friend with redundant qualification [PR41723] Different code paths were correctly choosing to look up D directly, since C is the current instantiation, but here we decided to try to make it a typename type, leading to confusion. Fixed by using dependent_scope_p as we do elsewhere. gcc/cp/ChangeLog: PR c++/41723 * parser.c (cp_parser_class_name): Check dependent_scope_p. gcc/testsuite/ChangeLog: PR c++/41723 * g++.dg/template/friend71.C: New test.
[Bug c++/52625] [8/9/10/11 Regression] Incorrect specialization semantics of friend class template declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52625 --- Comment #7 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:b40d45cb1930e9aa8a1f9a6a8728fd47ebeeaaac commit r11-8034-gb40d45cb1930e9aa8a1f9a6a8728fd47ebeeaaac Author: Jason Merrill Date: Wed Apr 7 15:38:07 2021 -0400 c++: base template friend [PR52625] Here we were mistakenly treating the injected-class-name as a partial specialization. gcc/cp/ChangeLog: PR c++/52625 * pt.c (maybe_process_partial_specialization): Check DECL_SELF_REFERENCE_P. gcc/testsuite/ChangeLog: PR c++/52625 * g++.dg/template/friend70.C: New test.
[Bug c++/99806] [10/11 Regression] ICE: in tsubst_copy, at cp/pt.c:17247
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99806
Marek Polacek changed:
What|Removed |Added
Keywords|ice-on-invalid-code |ice-on-valid-code
Priority|P3 |P2
--- Comment #2 from Marek Polacek ---
// PR c++/99806
constexpr bool B = true;
template concept C = requires (T a) { a.f(0); };
struct S { void f(auto) noexcept(B); };
static_assert(C);
[Bug target/99960] MVE: Wrong code storing V2DI vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99960
--- Comment #1 from Alex Coplan ---
Looks like both loads and stores are wrong in V2DImode:
typedef long long __attribute((vector_size(16))) v2di;
v2di load(v2di *p) { return *p; }
void store(v2di *p, v2di v) { *p = v; }
gives:
load:
vldr.64 d0, [r0]
bx lr
store:
vstr.64 d0, [r0]
bx lr
clang does:
load:
vldrw.u32 q0, [r0]
bx lr
store:
vstrw.32q0, [r0]
bx lr
It looks like the output code for *mve_mov needs tweaking.
[Bug c++/99965] segfault only happening with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99965 --- Comment #8 from Andrew Pinski --- (In reply to Juan Lucas Rey from comment #7) > the thing is removing the vector m_vPointers makes it work. Just by accident. > also this code works fine on clang.. why would it be misaligned? Because pBuf only needs to be aligned to 1 so in this case it is aligned to 8, and adding size_0 (10*2=20=4*5) makes it aigned to only 4. If you want aligned storage, use std::aligned_storage instead.
[Bug tree-optimization/99536] unexplained warning on "uninitialized value" in std::normal_distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99536 --- Comment #7 from Martin Sebor --- The IL I posted in comment #6 was before the libstdc++ change.
[Bug tree-optimization/99536] unexplained warning on "uninitialized value" in std::normal_distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99536
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
Keywords||missed-optimization
Known to work||10.2.0, 11.0
Component|c++ |tree-optimization
--- Comment #6 from Martin Sebor ---
I can reconfirm the warning with GCC 9. It's been suppressed in GCC 10 and 11.
GCC 10 sees the IL below (annotated with my comments). The warning triggers
because it doesn't know how to interpret the VIEW_CONVERT_EXPR. This
limitation has caused other false positives as well (including the one for
std::optional in pr80635. I suggested handling VIEW_CONVERT_EXPR in the pass
in response to the patch submitted to fix that bug and I still think that that
would be a good solution, even if other optimizations are enhanced to handle it
as well.
main ()
{
unsigned char norm_dist$24;
double norm_dist$_M_saved;
result_type __ret;
result_type __x;
result_type __y;
result_type __r2;
const result_type __mult;
result_type D.47826;
long unsigned int __res;
int i;
struct normal_distribution norm_dist;
struct default_random_engine generator;
bool _18;
double _20;
double _21;
double _23;
double _24;
double powmult_26;
double powmult_27;
bool _29;
bool _30;
bool _31;
double _32;
double _33;
double _34;
double _36;
unsigned int ivtmp_41;
unsigned int ivtmp_51;
[local count: 268435456]:
MEM[(struct linear_congruential_engine *)] ={v} {CLOBBER};
generator._M_x = 1;
MEM[(struct &)_dist] ={v} {CLOBBER};
MEM[(struct param_type *)_dist] ={v} {CLOBBER};
[local count: 805306365]:
# norm_dist$_M_saved_2 = PHI
# norm_dist$24_14 = PHI <0(2), norm_dist$24_13(9)> <<< zero when
norm_dist$_M_saved_2 is uninitialized
# ivtmp_41 = PHI <3(2), ivtmp_51(9)>
_18 = VIEW_CONVERT_EXPR(norm_dist$24_14); <<< not handled by
warning code
if (_18 != 0)
goto ; [50.00%] <<< norm_dist$_M_saved_2
= norm_dist$_M_saved_1(9)
else
goto ; [50.00%] <<< norm_dist$_M_saved_2
is uninitialized
[local count: 402653183]:
goto ; [100.00%]
[local count: 402653183]:
[local count: 3660483495]:
_20 = std::generate_canonical >
();
_21 = _20 * 2.0e+0;
__x_22 = _21 - 1.0e+0;
_23 = std::generate_canonical >
();
_24 = _23 * 2.0e+0;
__y_25 = _24 - 1.0e+0;
powmult_26 = __x_22 * __x_22;
powmult_27 = __y_25 * __y_25;
__r2_28 = powmult_26 + powmult_27;
_29 = __r2_28 <= 1.0e+0;
_30 = __r2_28 != 0.0;
_31 = _29 & _30;
if (_31 != 0)
goto ; [11.00%]
else
goto ; [89.00%]
[local count: 3257830313]:
goto ; [100.00%]
[local count: 402653182]:
_32 = log (__r2_28);
_33 = _32 * -2.0e+0;
_34 = _33 / __r2_28;
__mult_35 = sqrt (_34);
_36 = __x_22 * __mult_35;
__ret_37 = __y_25 * __mult_35;
[local count: 805306365]: <<<
norm_dist$_M_saved_2(11) == norm_dist$_M_saved_1(9)
# __ret_39 = PHI <__ret_37(5), norm_dist$_M_saved_2(11)>
# norm_dist$_M_saved_1 = PHI <_36(5), norm_dist$_M_saved_2(11)>
# norm_dist$24_13 = PHI <1(5), 0(11)>
foo (__ret_39); <<<
-Wmaybe-uninitialized
ivtmp_51 = ivtmp_41 + 4294967295;
if (ivtmp_51 == 0)
goto ; [25.00%]
else
goto ; [75.00%]
[local count: 603979774]:
goto ; [100.00%]
[local count: 268435456]:
generator ={v} {CLOBBER};
norm_dist ={v} {CLOBBER};
return 0;
}
[Bug c++/99965] segfault only happening with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99965 --- Comment #7 from Juan Lucas Rey --- the thing is removing the vector m_vPointers makes it work. also this code works fine on clang.. why would it be misaligned?
[Bug c++/99965] segfault only happening with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99965 --- Comment #6 from Juan Lucas Rey --- I get the following with -fsanitize=alignment bug.cpp:29:21: runtime error: store to misaligned address 0x02249044 for type 'char *', which requires 8 byte alignment 0x02249044: note: pointer points here 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[Bug c++/99965] segfault only happening with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99965 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #5 from Andrew Pinski --- (In reply to Juan Lucas Rey from comment #4) > I get the error "cannot find -lubsan" with -fsanitize=alignment You must not have all of the correct packages install; not a GCC issue. > > g++ bug.cpp -o bug -O2 -ftree-loop-vectorize -fvect-cost-model && ./bug > > this also reproduces the segfault Yes so this is an alignment issue. NOT a GCC bug. Check to make sure you have the correct alignment here: char** ppArray0 = reinterpret_cast(pBuf);
[Bug c++/99965] segfault only happening with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99965 --- Comment #4 from Juan Lucas Rey --- I get the error "cannot find -lubsan" with -fsanitize=alignment g++ bug.cpp -o bug -O2 -ftree-loop-vectorize -fvect-cost-model && ./bug this also reproduces the segfault
[Bug c++/41723] [8/9/10/11 Regression] Error when using a qualified name to declare a nested template instantiation as a friend of the containing template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41723 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org CC||jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/99965] segfault only happening with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99965 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Also, GCC 7.3 isn't supported anymore, only GCC 8+ is ATM.
[Bug c++/99965] segfault only happening with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99965 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2021-04-07 --- Comment #2 from Andrew Pinski --- I think you are violating C alignment rules. Can you try adding -fsanitize=alignment ?
[Bug libgcc/99964] android(bionic) cannot find crti.o and crtn.o on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99964 --- Comment #4 from cqwrteur --- (In reply to cqwrteur from comment #3) > (In reply to Jim Wilson from comment #1) > > (In reply to cqwrteur from comment #0) > > > bionic simply does not provide crti.o and crtn.o > > > https://github.com/aosp-riscv/platform_bionic/tree/master/libc/arch-common/ > > > bionic > > > > That is the RISC-V Android port in progress. It should not be used for > > anything other than RISC-V, as RISC-V patches might have accidentally broken > > other targets. Use the official Android sources for Aarch64, or maybe > > something distributed by Linaro. > > > This is my x86_64-linux-android toolchain. I does not need crti and crtn tbh. > https://github.com/expnkx/Windows-Hosted-x86_64-linux-android-GCC-Cross- > Compiler It does not need crti and crtn tbh.
[Bug libgcc/99964] android(bionic) cannot find crti.o and crtn.o on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99964 --- Comment #3 from cqwrteur --- (In reply to Jim Wilson from comment #1) > (In reply to cqwrteur from comment #0) > > bionic simply does not provide crti.o and crtn.o > > https://github.com/aosp-riscv/platform_bionic/tree/master/libc/arch-common/ > > bionic > > That is the RISC-V Android port in progress. It should not be used for > anything other than RISC-V, as RISC-V patches might have accidentally broken > other targets. Use the official Android sources for Aarch64, or maybe > something distributed by Linaro. This is my x86_64-linux-android toolchain. I does not need crti and crtn tbh. https://github.com/expnkx/Windows-Hosted-x86_64-linux-android-GCC-Cross-Compiler
[Bug c++/99965] segfault only happening with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99965 --- Comment #1 from Juan Lucas Rey --- g++ --version g++ (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5)
[Bug libgcc/99964] android(bionic) cannot find crti.o and crtn.o on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99964 --- Comment #2 from cqwrteur --- (In reply to Jim Wilson from comment #1) > (In reply to cqwrteur from comment #0) > > bionic simply does not provide crti.o and crtn.o > > https://github.com/aosp-riscv/platform_bionic/tree/master/libc/arch-common/ > > bionic > > That is the RISC-V Android port in progress. It should not be used for > anything other than RISC-V, as RISC-V patches might have accidentally broken > other targets. Use the official Android sources for Aarch64, or maybe > something distributed by Linaro. i successfully built my own android linux toolchain on x86_64. i think this is just a bug in libgcc since crti.o and crtn.o should not get included.
[Bug c++/99965] New: segfault only happening with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99965 Bug ID: 99965 Summary: segfault only happening with -O3 Product: gcc Version: 7.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: juanlucasrey at gmail dot com Target Milestone: --- Created attachment 50526 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50526=edit file to reproduce the following file runs fine with -O0, -O1 or -O2 but has a segmentation fault when compiled with -O3 g++ bug.cpp -o bug -O3 && ./bug I am executing this in a red hat docker container (if it matters)
[Bug libgcc/99964] android(bionic) cannot find crti.o and crtn.o on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99964 Jim Wilson changed: What|Removed |Added CC||wilson at gcc dot gnu.org --- Comment #1 from Jim Wilson --- (In reply to cqwrteur from comment #0) > bionic simply does not provide crti.o and crtn.o > https://github.com/aosp-riscv/platform_bionic/tree/master/libc/arch-common/ > bionic That is the RISC-V Android port in progress. It should not be used for anything other than RISC-V, as RISC-V patches might have accidentally broken other targets. Use the official Android sources for Aarch64, or maybe something distributed by Linaro.
[Bug middle-end/93181] [9/10/11 Regression] -Wuninitialized fails to warn about uninitialized value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93181
Martin Sebor changed:
What|Removed |Added
Summary|-Wuninitialized fails to|[9/10/11 Regression]
|warn about uninitialized|-Wuninitialized fails to
|value; |warn about uninitialized
|-Wmaybe-uninitialized |value
|should also warn. |
CC||msebor at gcc dot gnu.org
Last reconfirmed|2020-01-21 00:00:00 |2021-4-7
Known to fail||10.2.0, 11.0, 9.2.0
--- Comment #2 from Martin Sebor ---
Reconfirmed with GCC 11. The warning ceased to be issued between r120372 and
r120373 so it's technically a regression.
With optimization the warning sees the IL below. Both arguments of the p_3 PHI
that it considers are valid so it has nothing to complain about.
void ub_express (int x)
{
struct foo * p;
int _1;
int _2;
[local count: 1073741824]:
if (x_4(D) == 2)
goto ; [34.00%]
else
goto ; [66.00%]
[local count: 365072224]:
goto ; [100.00%]
[local count: 708669600]:
[local count: 1073741824]:
# p_3 = PHI <(3), (5)>
# VUSE <.MEM_6(D)>
_1 = p_3->count;
_2 = _1 + 1;
# .MEM_7 = VDEF <.MEM_6(D)>
p_3->count = _2;
# VUSE <.MEM_7>
return;
}
Without optimization the IL (below) does have a PHI with an uninitialized
operand so it could warn then, but it doesn't consider PHI nodes then.
Considering PHIs in the simplest cases (to avoid false positives) also when
-Wuninitialized runs early, without optimization, would make it possible to
detect this bug.
void ub_express (int x)
{
struct foo * p;
int _1;
int _2;
:
if (x_5(D) == 1)
goto ; [INV]
else
goto ; [INV]
:
p_7 =
:
# p_3 = PHI
if (x_5(D) == 2)
goto ; [INV]
else
goto ; [INV]
:
p_8 =
:
# p_4 = PHI
# VUSE <.MEM_9(D)>
_1 = p_4->count;
_2 = _1 + 1;
# .MEM_10 = VDEF <.MEM_9(D)>
p_4->count = _2;
# VUSE <.MEM_10>
return;
}
[Bug libgcc/99964] New: android(bionic) cannot find crti.o and crtn.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99964 Bug ID: 99964 Summary: android(bionic) cannot find crti.o and crtn.o Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- D:\msys64\aarch64-linux-android\aarch64-linux-android\bin\ld.exe: cannot find crti.o: No such file or directory D:\msys64\aarch64-linux-android\aarch64-linux-android\bin\ld.exe: cannot find crtn.o: No such file or directory collect2.exe: error: ld returned 1 exit status make[2]: *** [Makefile:995: libgcc_s.so] Error 1 make[2]: Leaving directory '/home/unlvs/gcc_aarcch64-android-build/aarch64-linux-android/libgcc' make[1]: *** [Makefile:13520: all-target-libgcc] Error 2 make[1]: Leaving directory '/home/unlvs/gcc_aarcch64-android-build' make: *** [Makefile:974: all] Error 2 bionic simply does not provide crti.o and crtn.o https://github.com/aosp-riscv/platform_bionic/tree/master/libc/arch-common/bionic I built the x86_64-linux-android toolchain and it succeeds. but fails for aarch64.
[Bug c++/99963] New: [concepts] template vs concept auto reports ambiguous overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99963
Bug ID: 99963
Summary: [concepts] template vs concept auto reports
ambiguous overload
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
Consider the following code (https://godbolt.org/z/h1bz1qxan).
#include
struct A{};
struct B : A {};
template
concept is_a = std::is_base_of_v;
template
concept is_b = is_a and std::same_as;
int foo(is_a auto, is_a auto);
#ifdef OK
int foo(is_b auto, is_a auto);
#else
template
int foo(is_b auto, A);
#endif
A a;
B b;
int d = foo(b, a);
:23:12: error: call of overloaded 'foo(B&, A&)' is ambiguous
23 | int d = foo(b, a);
| ~~~^~
With -DOK, which enables is_a auto syntax, this compiles. The template
fails.
[Bug libstdc++/99958] The seems to contain the entire and in C++20 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99958
--- Comment #2 from Jonathan Wakely ---
This seems to work:
diff --git a/libstdc++-v3/include/pstl/glue_algorithm_defs.h
b/libstdc++-v3/include/pstl/glue_algorithm_defs.h
index 48bc56ae401..cef78e22e31 100644
--- a/libstdc++-v3/include/pstl/glue_algorithm_defs.h
+++ b/libstdc++-v3/include/pstl/glue_algorithm_defs.h
@@ -10,7 +10,7 @@
#ifndef _PSTL_GLUE_ALGORITHM_DEFS_H
#define _PSTL_GLUE_ALGORITHM_DEFS_H
-#include
+#include
#include "execution_defs.h"
diff --git a/libstdc++-v3/include/pstl/utils.h
b/libstdc++-v3/include/pstl/utils.h
index 1711f292678..69d78c3ca0f 100644
--- a/libstdc++-v3/include/pstl/utils.h
+++ b/libstdc++-v3/include/pstl/utils.h
@@ -10,8 +10,9 @@
#ifndef _PSTL_UTILS_H
#define _PSTL_UTILS_H
+#include
#include
-#include
+#include
namespace __pstl
{
The header only requires declarations of std::bad_alloc and
std::terminate(), but includes and to get them. That could be
reduced with some minor surgery.
I'll test this too:
diff --git a/libstdc++-v3/include/bits/streambuf_iterator.h
b/libstdc++-v3/include/bits/streambuf_iterator.h
index 22af3fd5995..a188db69b53 100644
--- a/libstdc++-v3/include/bits/streambuf_iterator.h
+++ b/libstdc++-v3/include/bits/streambuf_iterator.h
@@ -32,7 +32,7 @@
#pragma GCC system_header
-#include
+#include
#include
namespace std _GLIBCXX_VISIBILITY(default)
[Bug libgcc/99962] Error: unknown mnemonic `type' -- `type(_init)' for crti.s, targetting aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99962 --- Comment #1 from cqwrteur --- i manually replace the macros with code and it worrks.
[Bug libgcc/99962] New: Error: unknown mnemonic `type' -- `type(_init)' for crti.s, targetting aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99962 Bug ID: 99962 Summary: Error: unknown mnemonic `type' -- `type(_init)' for crti.s, targetting aarch64 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- $ aarch64-linux-android-gcc -c crti.s -Ofast -s -flto crti.s: Assembler messages: crti.s:56: Error: unknown mnemonic `type' -- `type(_init)' crti.s:64: Error: unknown mnemonic `type' -- `type(_fini)'
[Bug libstdc++/99958] The seems to contain the entire and in C++20 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99958 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 CC||rodgertq at gcc dot gnu.org Last reconfirmed||2021-04-07 Status|UNCONFIRMED |NEW --- Comment #1 from Jonathan Wakely --- is included by which is included by which is included by which is included by which is included by which is included by . I think that is unavoidable. is included by , which is included by . That should not be including the whole of . It looks like it only needs . This is not a bug, but it's a compile-time pessimization to include huge headers that we don't need.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 92722, which changed state. Bug 92722 Summary: gcc considers "padding" byte of empty lambda to be uninitialized https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92722 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX
[Bug c++/54367] [meta-bug] lambda expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367 Bug 54367 depends on bug 92722, which changed state. Bug 92722 Summary: gcc considers "padding" byte of empty lambda to be uninitialized https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92722 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX
[Bug c++/92722] gcc considers "padding" byte of empty lambda to be uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92722
Martin Sebor changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|NEW |RESOLVED
CC||msebor at gcc dot gnu.org
--- Comment #4 from Martin Sebor ---
The IL the warning works with is below. It shows an unconditional read of the
uninitialized member array bytes so the warning behaves correctly. The warning
does have suppression logic for empty types, including lambdas, but the test
case copies the representation bytes of the object directly and there's nothing
to avoid the warning then. So I don't think there's anything for us to do
here.
In static member function ‘static void
noncopyable_function::trivial_direct_move(noncopyable_function*,
noncopyable_function*) [with int N = 1]’,
inlined from
‘noncopyable_function::noncopyable_function(noncopyable_function&&)’ at
pr92722.C:32:31,
inlined from ‘int main()’ at pr92722.C:43:40:
pr92722.C:22:43: warning: ‘a.noncopyable_function::direct[0]’ is used
uninitialized [-Wuninitialized]
22 | to->direct[i] = from->direct[i];
| ~~^
pr92722.C: In function ‘int main()’:
pr92722.C:42:26: note: ‘a’ declared here
42 | noncopyable_function a([] {});
| ^
int main ()
{
struct noncopyable_function b;
struct noncopyable_function a;
char _2;
[local count: 1073741824]:
# .MEM_7 = VDEF <.MEM_1(D)>
a ={v} {CLOBBER};
# .MEM_8 = VDEF <.MEM_7>
b ={v} {CLOBBER};
# VUSE <.MEM_8>
_2 = a.direct[0]; <<< a.direct[0] is uninitialized
# .MEM_9 = VDEF <.MEM_8>
b.direct[0] = _2; <<< -Wuninitialized
# .MEM_3 = VDEF <.MEM_9>
noncopyable_function::~noncopyable_function ();
# .MEM_4 = VDEF <.MEM_3>
noncopyable_function::~noncopyable_function ();
# .MEM_5 = VDEF <.MEM_4>
a ={v} {CLOBBER};
# .MEM_6 = VDEF <.MEM_5>
b ={v} {CLOBBER};
# VUSE <.MEM_6>
return 0;
}
[Bug c++/99961] requires clause rejects mentioning of function parameters too early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99961 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-04-07 Keywords||rejects-valid
[Bug c++/52625] [8/9/10/11 Regression] Incorrect specialization semantics of friend class template declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52625 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/92918] [8/9/10 Regression] Does not do name lookup when using from base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92918 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Known to work||11.0 Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Summary|[8/9/10/11 Regression] Does |[8/9/10 Regression] Does |not do name lookup when |not do name lookup when |using from base class |using from base class --- Comment #5 from Jason Merrill --- Fixed for 11 so far.
[Bug c++/92918] [8/9/10/11 Regression] Does not do name lookup when using from base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92918 --- Comment #4 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:a528594cf9a74e5a0fbac13ef673064ed73e1b89 commit r11-8033-ga528594cf9a74e5a0fbac13ef673064ed73e1b89 Author: Jason Merrill Date: Wed Apr 7 14:55:48 2021 -0400 c++: using overloaded with local decl [PR92918] The problem here was that the lookup for 'impl' when parsing the template only found the using-declaration, not the member function declaration. This happened because when trying to add the member function declaration, push_class_level_binding_1 saw that the current binding was a USING_DECL and the new value is an overload, and decided to just return success. That 'return true' dates back to r69921. In https://gcc.gnu.org/pipermail/gcc-patches/2003-July/110632.html Nathan mentions that we only push dependent USING_DECLs, which is no longer the case; now that we retain more USING_DECLs, handling this case like the other overloaded function cases seems like the obvious solution. gcc/cp/ChangeLog: PR c++/92918 * name-lookup.c (push_class_level_binding_1): Do overload a new function with a previous using-declaration. gcc/testsuite/ChangeLog: PR c++/92918 * g++.dg/lookup/using66.C: New test.
[Bug bootstrap/99920] [10 regression] ICE building gcc 10 on power 7 BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99920 --- Comment #12 from Jakub Jelinek --- Usually I'm trying to do binary search in these cases, build one tree with the bad compiler, one with good one, cp -al one of the trees to a new dir, make a list of the object files, start with half/half, copy them and touch all, make cc1 cc1plus, test the libgcc compilation, etc. That works if there is a single miscompiled one.
[Bug tree-optimization/90994] Bogus Wmaybe-uninitialized with fnon-call-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90994
Martin Sebor changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-04-07
Known to fail||10.2.0, 11.0, 9.2.0
CC||msebor at gcc dot gnu.org
--- Comment #1 from Martin Sebor ---
Confirmed. The warning sees the IL below. The reason for the false positive
is the assignment in bb 5 marked not handled. The warning walks up the control
flow graph from the point of the possibly uninitialized use to the definition
of the a_33 variable (a PHI), looking for predicates that guard it to try to
determine if they are mutually exclusive with those guarding the uninitialized
operand to the PHI. It recongnizes conditional expressions and switch
statements but nothing else (such the assignment here). As a result, the logic
fails to detect that the conditionals prevent the uninitialized variable from
being used.
int incorrectWarning ()
{
int D.2387;
int D.2383;
unsigned char b;
unsigned char a;
int _3;
int _5;
int _6;
bool prephitmp_10;
unsigned char _17;
int _18;
void * _19;
unsigned char _20;
void * _22;
[local count: 1073741824]:
# VUSE <.MEM_8(D)>
_17 ={v} MEM[(volatile unsigned char *)1234B];
[local count: 1073741824]:
[local count: 1073741824]:
# _18 = PHI <0(9), -1(4)><<< _18 != 0 in bb 4
# .MEM_23 = PHI <.MEM_8(D)(9), .MEM_26(4)>
# a_33 = PHI <_17(9), a_35(D)(4)><<< a_33 uninitialized if
_18 != 0
# prephitmp_10 = PHI <0(9), 1(4)>
__asm__ __volatile__("
" : : "X" prephitmp_10);
if (_18 != 0)
goto ; [51.12%]
else
goto ; [48.88%] <<< _18 == 0 implies a_33 =
_17(9)
[local count: 548896824]:
goto ; [100.00%]
[count: 0]:
:
# VUSE <.MEM_8(D)>
_19 = __builtin_eh_pointer (3);
# .MEM_25 = VDEF <.MEM_8(D)>
__cxa_begin_catch (_19);
# .MEM_26 = VDEF <.MEM_25>
__cxa_end_catch ();
goto ; [0.00%]
[local count: 524845000]:
# VUSE <.MEM_23>
_20 ={v} MEM[(volatile unsigned char *)1234B]; <<< not handled
[local count: 524845000]:
_3 = (int) a_33; <<< -Wmaybe-uninitialized
# .MEM_13 = VDEF <.MEM_23>
printval (_3);
_5 = (int) _20;
# .MEM_14 = VDEF <.MEM_13>
printval (_5);
goto ; [100.00%]
[count: 0]:
:
# VUSE <.MEM_23>
_22 = __builtin_eh_pointer (4);
# .MEM_29 = VDEF <.MEM_23>
__cxa_begin_catch (_22);
# .MEM_30 = VDEF <.MEM_29>
__cxa_end_catch ();
[local count: 1073741824]:
# _6 = PHI <0(6), 1(7), 1(10)>
# .MEM_7 = PHI <.MEM_14(6), .MEM_30(7), .MEM_23(10)>
# VUSE <.MEM_7>
return _6;
}
[Bug tree-optimization/99927] [11 Regression] Wrong code since r11-39-gf9e1ea10e657af9f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99927 --- Comment #13 from Segher Boessenkool --- Yes, combine just drops that clobber of flags, that was a thinko :-)
[Bug tree-optimization/99873] [11 Regression] GCC no longer makes as much use of ST3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99873 rsandifo at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from rsandifo at gcc dot gnu.org --- Fixed on trunk.
[Bug bootstrap/99920] [10 regression] ICE building gcc 10 on power 7 BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99920 --- Comment #11 from seurer at gcc dot gnu.org --- Swapping out those two .o files (individually and together) didn't yield a successful build. I brought in the 8.4.0 .o files in one at a time and eventually I got a successful build but at that point it had brought in most of them. I am now trying each .o swapped in individually.
[Bug tree-optimization/99927] [11 Regression] Wrong code since r11-39-gf9e1ea10e657af9f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99927 --- Comment #12 from Jakub Jelinek --- (In reply to Segher Boessenkool from comment #11) > (In reply to Jakub Jelinek from comment #7) > > Ah, create_log_links wants to work like that. > > So, the bug seems to be that insn 108 has REG_DEAD (reg:CC 17 flags) note. > > It doesn't initially, but it is added during 106 -> 108 combination > > But that combination should never have been made: flags is set in insn 107! Why? It is not across a LOG_LINK for the flags register, but for the r134 pseudo. Yes, the first insn has a clobber on flags, but don't most of x86 insns have that? The combiner doesn't move over the clobber, it just substs r134 to its SET_SRC.
[Bug tree-optimization/99927] [11 Regression] Wrong code since r11-39-gf9e1ea10e657af9f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99927 --- Comment #11 from Segher Boessenkool --- (In reply to Jakub Jelinek from comment #7) > Ah, create_log_links wants to work like that. > So, the bug seems to be that insn 108 has REG_DEAD (reg:CC 17 flags) note. > It doesn't initially, but it is added during 106 -> 108 combination But that combination should never have been made: flags is set in insn 107!
[Bug c++/99961] New: requires clause rejects mentioning of function parameters too early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99961
Bug ID: 99961
Summary: requires clause rejects mentioning of function
parameters too early
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nickgray0 at brown dot edu
Target Milestone: ---
the following code fails to compile:
struct A {
static constexpr auto x = 42;
};
auto f(auto a) requires (a.x > 10) {}
auto main()->int {
f(A{});
}
error message: :5:27: error: use of parameter outside function body
before '.' token
5 | auto f(auto a) requires (a.x > 10) {}
| ^
: In function 'int main()':
:8:6: error: no matching function for call to 'f(A)'
8 | f(A{});
| ~^
:5:6: note: candidate: 'template auto f(auto:1) requires
'
5 | auto f(auto a) requires (a.x > 10) {}
| ^
:5:6: note: template argument deduction/substitution failed:
:5:6: note: constraints not satisfied
as shown in the example above, a.x doesn't *actually* make use of a
[Bug c++/99859] constexpr evaluation with member function is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99859 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #15 from Jakub Jelinek --- Created attachment 50525 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50525=edit gcc11-pr99859.patch Full untested patch. As for PR80039, I for some reason can't reproduce the #c0 in there and #c1 looks too close to the testcases from this PR that I think it isn't useful to add it to the testsuite.
[Bug c/99955] gcc.c-torture/execute/pr92618.c violates strict aliasing rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99955 --- Comment #4 from joseph at codesourcery dot com --- I think may_alias ought to work together with vector_size, whatever its position in the attribute list, i.e. there is a front-end bug here for which making that combination of attributes work properly together in any order is the right fix.
[Bug c++/99795] [8/9/10/11 Regression] -Wnarrowing/-Woverflow false-negative in constant expression in undeduced context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99795 Jason Merrill changed: What|Removed |Added Assignee|jason at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW
[Bug c++/99795] [8/9/10/11 Regression] -Wnarrowing/-Woverflow false-negative in constant expression in undeduced context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99795 --- Comment #2 from Jason Merrill --- Created attachment 50524 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50524=edit WIP Fix This patch uses IMPLICIT_CONV_EXPR to get the narrowing error, but more and more changes are being necessary to prevent regressions; this isn't going to be safe for GCC 11 at this point, so I'm going to put it aside for now.
[Bug target/99912] Unnecessary / inefficient spilling of AVX2 ymm registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99912 --- Comment #7 from Richard Biener --- I've posted a series of two patches that will improve things for GCC 12. https://gcc.gnu.org/pipermail/gcc-patches/2021-April/567743.html https://gcc.gnu.org/pipermail/gcc-patches/2021-April/567731.html https://gcc.gnu.org/pipermail/gcc-patches/2021-April/567744.html the last will eventually see adjustments and/or a different implementation approach.
[Bug c++/99859] constexpr evaluation with member function is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99859 --- Comment #14 from Patrick Palka --- (In reply to Jakub Jelinek from comment #11) > For the global vars (so PR80039 too), can the problem be anything but when > cxx_eval_outermost_constant_expr is called on such an object (or part > thereof)? > Unfortunately, ctx->object might be NULL, perhaps we could stick a copy of > that into ctx->global->object (get_base_address of the outermost object it > is called on)? Sounds good to me FWIW (In reply to Jakub Jelinek from comment #13) > (In reply to Jakub Jelinek from comment #12) > > And in #c9 you're right that it could be embedded in CONSTRUCTORs too. > > Wonder if cp_walk_tree to find the ADDR_EXPR of heap var addresses and > ctx->global->object address would be enough. Sounds good to me too. Using cp_walk_tree means we'd also detect the case where the argument is 'heap_ptr + CST'.
[Bug rtl-optimization/99930] Failure to optimize floating point -abs(x) in nontrivial code at -O2/3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99930 --- Comment #8 from Segher Boessenkool --- That patch is no good. The combination is not allowed because it is not known what the "use"s are *for*. Checking if something is from the constant pools is not enough at all.
[Bug target/99937] Optimization needed for ARM with single cycle multiplier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99937 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #5 from Christophe Lyon --- Note that gcc also has another -mcpu: cortex-m0plus.small-multiply
[Bug target/99937] Optimization needed for ARM with single cycle multiplier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99937 --- Comment #4 from mike.robins at talktalk dot net --- (In reply to Richard Biener from comment #3) > (In reply to mike.robins from comment #2) > > (In reply to Richard Biener from comment #1) > > > You need to adjust RTX costing accordingly which likely means adding a new > > > subtarget tuning. > > > > Hi Richard > > Are you saying that this would have to be added at the GCC source level > > somehow. I.e that there is no existing -mtune... or -f... to achieve this? > > Mike > > Generally yes. I don't know the arm backend enough to tell whether there > exists an ARM variant with the multiplier behaving in this way (I suppose an > in-order, > non-pipelined m0 core might behave this way ...) It appears that other compilers default to the fast multiplier implementation, using a "small-multiply" option to tune for a smaller silicon, slower version. See https://community.nxp.com/t5/LPCXpresso-IDE-FAQs/Use-of-Cortex-M0-M0-multiply-instructions-on-LPC43xx-and/m-p/461571 and the -mtune section in https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html. Is it possible that the GCC default is somehow to use the small/slow multiply whereas it should default to the large/fast one if the small/slow version isn't specified?
[Bug c/99950] Option -Wchar-subscripts leads to wrong fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99950
Martin Sebor changed:
What|Removed |Added
Ever confirmed|0 |1
CC||msebor at gcc dot gnu.org
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=78155
Last reconfirmed||2021-04-07
Severity|normal |enhancement
Status|UNCONFIRMED |NEW
--- Comment #2 from Martin Sebor ---
Adding a note after the warning suggesting to cast the argument to unsigned
char would help. Enabling the warning also when the char argument is cast to a
wider type might also be worth considering. See also pr78155 for a related
request to enable the warning for calls to the character classification
built-ins.
$ cat pr99950.c && gcc -O2 -S -Wall -Wchar-subscripts pr99950.c
extern int a[255];
int f (char c)
{
return a[c]; // -Wchar-subscripts
}
int g (char c)
{
return a[(int)c]; // same bug, no warning
}
pr99950.c: In function ‘f’:
pr99950.c:5:11: warning: array subscript has type ‘char’ [-Wchar-subscripts]
5 | return a[c]; // -Wchar-subscripts
| ^
[Bug c++/99805] [9/10 Regression] filesystem::path::parent_path got a wrong path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99805 Jonathan Wakely changed: What|Removed |Added Summary|[9/10/11 Regression]|[9/10 Regression] |filesystem::path::parent_pa |filesystem::path::parent_pa |th got a wrong path |th got a wrong path --- Comment #7 from Jonathan Wakely --- Fixed on trunk only for now.
[Bug target/99960] New: MVE: Wrong code storing V2DI vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99960
Bug ID: 99960
Summary: MVE: Wrong code storing V2DI vector
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
For the following testcase:
typedef long long v2di __attribute((vector_size(16)));
void foo(v2di *p)
{
*p = (v2di){ 1, 2 };
}
we miscompile it at -O2 -march=armv8.1-m.main+mve -mfloat-abi=hard. Looking at
the generated code:
foo:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
vldr.64 d6, .L3
vldr.64 d7, .L3+8
vstr.64 d6, [r0]
bx lr
.L4:
.align 3
.L3:
.word 1
.word 0
.word 2
.word 0
.size foo, .-foo
it looks like we're missing a store of d7. Here's a full testcase:
typedef long long v2di __attribute((vector_size(16)));
__attribute((noipa))
void stvec (v2di *p) {
*p = (v2di){ 1, 2 };
}
int main () {
v2di v;
stvec();
if (v[1] != 2)
__builtin_abort ();
}
I originally noticed this while investigating an execution failure for
gcc.c-torture/execute/pr92618.c. FWIW, clang does:
foo:
adr r1, .LCPI0_0
vldrw.u32 q0, [r1]
vstrw.32q0, [r0]
bx lr
.LCPI0_0:
.long 1 @ 0x1
.long 0 @ 0x0
.long 2 @ 0x2
.long 0 @ 0x0
[Bug c++/99805] [9/10/11 Regression] filesystem::path::parent_path got a wrong path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99805 --- Comment #6 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:e06d3f5dd7d0c6b4a20fe813e6ee5addd097f560 commit r11-8031-ge06d3f5dd7d0c6b4a20fe813e6ee5addd097f560 Author: Jonathan Wakely Date: Wed Apr 7 16:05:42 2021 +0100 libstdc++: Fix filesystem::path construction from COW string [PR 99805] Calling the non-const data() member on a COW string makes it "leaked", possibly resulting in reallocating the string to ensure a unique owner. The path::_M_split_cmpts() member parses its _M_pathname string using string_view objects and then calls _M_pathname.data() to find the offset of each string_view from the start of the string. However because _M_pathname is non-const that will cause a COW string to reallocate if it happens to be shared with another string object. This results in the offsets calculated for each component being wrong (i.e. undefined) because the string views no longer refer to substrings of the _M_pathname member. The fix is to use the parse.offset(c) member which gets the offset safely. The bug only happens for the path(string_type&&) constructor and only for COW strings. When constructed from an lvalue string the string's contents are copied rather than just incrementing the refcount, so there's no reallocation when calling the non-const data() member. The testsuite changes check the lvalue case anyway, because we should probably change the deep copying to just be a refcount increment (by adding a path(const string_type&) constructor or an overload for __effective_range(const string_type&), for COW strings only). libstdc++-v3/ChangeLog: PR libstdc++/99805 * src/c++17/fs_path.cc (path::_M_split_cmpts): Do not call non-const member on _M_pathname, to avoid copy-on-write. * testsuite/27_io/filesystem/path/decompose/parent_path.cc: Check construction from strings that might be shared.
[Bug sanitizer/99945] missing maybe-uninitialized warning when using a cleanup function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99945 Martin Sebor changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=99959 --- Comment #6 from Martin Sebor --- I misread the report: it's actually about a false negative in all the cases where the warning isn't issued and not about it being issued with -fsanitize=undefined in the one case where it is. Mentioning the name of an artificial variable is certainly confusing, but I agree that warnings shouldn't be suppressed for it when it's created as a substitute for a real variable. That said, as the simpler test case case in pr99945 shows, warnings for the FRAME variable were apparently already (perhaps inadvertently) suppressed in r230968.
[Bug c++/99844] [9/10/11 Regression] ICE: unexpected expression 'B' of kind template_parm_index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99844
--- Comment #2 from Marek Polacek ---
We also ICE on
template
struct S {
void fn() noexcept(B);
};
void fn ()
{
S s;
s.fn();
}
so this needs to be fixed more generally than just in explicit().
[Bug middle-end/99959] [9/10/11 Regression] missing -Wuninitialized for an esra variable with TREE_NO_WARNING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99959
Martin Sebor changed:
What|Removed |Added
Summary|missing -Wuninitialized for |[9/10/11 Regression]
|an esra variable with |missing -Wuninitialized for
|TREE_NO_WARNING |an esra variable with
||TREE_NO_WARNING
Keywords||diagnostic
Known to fail||10.2.0, 11.0, 6.3.0, 7.0.1,
||8.3.0, 9.3.0
Blocks||24639
--- Comment #1 from Martin Sebor ---
The warning has been suppressed since r230968 (6.0.0 20151126). Until then,
GCC issued:
pr99959.c:7:5: warning: ‘FRAME.0.i’ is used uninitialized in this function
[-Wuninitialized]
__builtin_printf ("%i", i); // missing -Wuninitialized
^~
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues
[Bug analyzer/99860] RFE: analyzer does not respect "restrict"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99860 --- Comment #1 from David Malcolm --- Notes on "restrict": https://en.cppreference.com/w/c/language/restrict
[Bug middle-end/99959] New: missing -Wuninitialized for an esra variable with TREE_NO_WARNING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99959
Bug ID: 99959
Summary: missing -Wuninitialized for an esra variable with
TREE_NO_WARNING
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
GCC fails to issue -Wuninitialized for the following test case derived from
pr99945. The warning detects the uninitialized use but the SR.3 variable has
the TREE_NO_WARNING bit set which suppresses it.
$ cat z.c && gcc -O2 -S -Wall -fdump-tree-esra=/dev/stdout z.c
void g (void)
{
int i;
void f (int *t)
{
__builtin_printf ("%i", i); // missing -Wuninitialized
}
int t __attribute__ ((cleanup (f))) = 0;
}
;; Function f (f.0, funcdef_no=1, decl_uid=1947, cgraph_uid=1, symbol_order=0)
void f (int * t)
{
int _3;
:
_3 = CHAIN.1_2(D)->i;
__builtin_printf ("%i", _3);
return;
}
;; Function g (g, funcdef_no=0, decl_uid=1943, cgraph_uid=2, symbol_order=1)
Created a replacement for FRAME.0 offset: 0, size: 32: SR.3D.1962
void g ()
{
int SR.3;
struct FRAME.g FRAME.0;
int t;
void * _3;
int _8;
:
_3 = __builtin_dwarf_cfa (0);
FRAME.0.FRAME_BASE.PARENT = _3;
_8 = SR.3_10(D);
__builtin_printf ("%i", _8);
return;
}
[Bug target/97513] [11 regression] aarch64 SVE regressions since r11-3822
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97513 --- Comment #8 from CVS Commits --- The master branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:2f3d9104610cb2058cf091707a20c1c6eff8d470 commit r11-8030-g2f3d9104610cb2058cf091707a20c1c6eff8d470 Author: Richard Sandiford Date: Wed Apr 7 15:21:56 2021 +0100 vect: Restore variable-length SLP permutes [PR97513] Many of the gcc.target/sve/slp-perm*.c tests started failing after the introduction of separate SLP permute nodes. This patch adds variable-length support using a similar technique to vect_transform_slp_perm_load. As there, the idea is to detect when every permute mask vector is the same and can be generated using a regular stepped sequence. We can easily handle those cases for variable-length, but still need to restrict the general case to constant-length. Again copying vect_transform_slp_perm_load, the idea is to distinguish the two cases regardless of whether the length is variable or not, partly to increase testing coverage and partly because it avoids generating redundant trees. Doing this means that we can also use SLP for the two-vector permute in pr88834.c, which we couldn't before VEC_PERM_EXPR nodes were introduced. The patch therefore makes pr88834.c check that we don't regress back to not using SLP and adds pr88834_ld3.c to check for the original problem in the PR. gcc/ PR tree-optimization/97513 * tree-vect-slp.c (vect_add_slp_permutation): New function, split out from... (vectorizable_slp_permutation): ...here. Detect cases in which all VEC_PERM_EXPRs are guaranteed to have the same stepped permute vector and only generate one permute vector for that case. Extend that case to handle variable-length vectors. gcc/testsuite/ * gcc.target/aarch64/sve/pr88834.c: Expect the vectorizer to use SLP. * gcc.target/aarch64/sve/pr88834_ld3.c: New test.
[Bug tree-optimization/99873] [11 Regression] GCC no longer makes as much use of ST3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99873 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:5c5b31975e62b4c52d76dc5efd9dc717a361c710 commit r11-8029-g5c5b31975e62b4c52d76dc5efd9dc717a361c710 Author: Richard Sandiford Date: Wed Apr 7 15:21:55 2021 +0100 vect: Don't split store groups if we have IFN_STORE_LANES [PR99873] As noted in the PR, we were no longer using ST3 for the testcase and instead stored each lane individually. This is because we'd split the store group during SLP and couldn't recover when SLP failed. However, we can also get better code with ST3 and ST4 even if SLP would have succeeded, such as for vect-complex-5.c. I'm not sure exactly where the cut-off point is, but it seems reasonable to allow the split if either of the new groups would operate on full vectors *within* rather than across scalar loop iterations. E.g. on a Cortex-A57, pr99873_3.c performs better using ST4 while pr99873_2.c performs better with SLP. Another factor is that SLP can handle smaller iteration counts than IFN_STORE_LANES can, but we don't have the infrastructure to choose reliably based on that. gcc/ PR tree-optimization/99873 * tree-vect-slp.c (vect_slp_prefer_store_lanes_p): New function. (vect_build_slp_instance): Don't split store groups that could use IFN_STORE_LANES. gcc/testsuite/ * gcc.dg/vect/slp-21.c: Only expect 2 of the loops to use SLP if IFN_STORE_LANES is available. * gcc.dg/vect/vect-complex-5.c: Expect no loops to use SLP if IFN_STORE_LANES is available. * gcc.target/aarch64/pr99873_1.c: New test. * gcc.target/aarch64/pr99873_2.c: Likewise. * gcc.target/aarch64/pr99873_3.c: Likewise. * gcc.target/aarch64/sve/pr99873_1.c: Likewise. * gcc.target/aarch64/sve/pr99873_2.c: Likewise. * gcc.target/aarch64/sve/pr99873_3.c: Likewise.
[Bug c++/99958] New: The seems to contain the entire and in C++20 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99958
Bug ID: 99958
Summary: The seems to contain the entire
and in C++20 mode
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
I found that include will automatically include the entire
in C++17 mode, and both the and will be automatically
included in C++20 mode:
https://godbolt.org/z/G5hrsaPKs
#include
int main() {
std::string s{"hell"};
s.push_back('o');
std::vector v{1, 2};
v.push_back(3);
}
[Bug c++/99859] constexpr evaluation with member function is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99859
--- Comment #13 from Jakub Jelinek ---
(In reply to Jakub Jelinek from comment #12)
> And in #c9 you're right that it could be embedded in CONSTRUCTORs too.
Wonder if cp_walk_tree to find the ADDR_EXPR of heap var addresses and
ctx->global->object address would be enough.
Counter example I was thinking about would be:
constexpr int foo(auto x) { return ++*x->p; }
struct S {
int a = 0;
constexpr S() {
struct R { int* p; };
R b{};
R c{};
foo();
foo();
}
};
constexpr S s = S();
static_assert (s.a == 2);
but in that case we handle it correctly already as the address of the automatic
vars is already non-constant.
[Bug target/99872] [11 Regression] optimizations sometimes lead to missing asm prefixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99872 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Hopefully fixed.
[Bug target/99872] [11 Regression] optimizations sometimes lead to missing asm prefixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99872 --- Comment #7 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:b51321bc5193b65b308a26663fc02f786ba6cc89 commit r11-8028-gb51321bc5193b65b308a26663fc02f786ba6cc89 Author: Jakub Jelinek Date: Wed Apr 7 15:51:15 2021 +0200 varasm: Fix up constpool alias handling [PR99872] Last year, I have added in r11-2944-g0106300f6c3f7bae5eb1c46dbd45aa07c94e1b15 (aka PR54201 fix) code to find bitwise duplicates in constant pool and output them as aliases instead of duplicating the data. Unfortunately this broke mingw32 -m32. On most targets, ASM_GENERATE_INTERNAL_LABEL with "LC" emits something like *.LC123 and the targets don't add user label prefixes, so the aliases that we print should be something like .set.LC5, .LC6 or .set.LC5, .LC6 + 8 and I wasn't sure if ASM_OUTPUT_DEF can handle the * and therefore I have stripped it. But, on mingw32 -m32, ASM_GENERATE_INTERNAL_LABEL with "LC" emits *LC123 and the target has user label prefixes, which means what I wrote results in LC6: ... .set_LC5, _LC6 which results in unresolved symbols. I went through the ASM_OUTPUT_DEF definitions of all targets and all of them use assemble_name twice under the hood (with various differences on what they print before, in between or after those names). And assemble_name handles the name encoding properly, so if we pass it ASM_OUTPUT_DEF (..., "*.LC123", "*.LC456+16") it will emit .LC123 and .LC456+16 and if we pass it "*LC789", it will emit LC789. 2021-04-07 Jakub Jelinek PR target/99872 * varasm.c (output_constant_pool_contents): Don't strip name encoding from XSTR (desc->sym, 0) or from label before passing those to ASM_OUTPUT_DEF.
[Bug c++/99859] constexpr evaluation with member function is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99859 --- Comment #12 from Jakub Jelinek --- And in #c9 you're right that it could be embedded in CONSTRUCTORs too.
[Bug c++/99859] constexpr evaluation with member function is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99859 --- Comment #11 from Jakub Jelinek --- For the global vars (so PR80039 too), can the problem be anything but when cxx_eval_outermost_constant_expr is called on such an object (or part thereof)? Unfortunately, ctx->object might be NULL, perhaps we could stick a copy of that into ctx->global->object (get_base_address of the outermost object it is called on)?
[Bug c++/99859] constexpr evaluation with member function is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99859
--- Comment #10 from Jakub Jelinek ---
So perhaps
--- gcc/cp/constexpr.c.jj 2021-03-19 18:36:49.165304923 +0100
+++ gcc/cp/constexpr.c 2021-04-07 15:33:31.993242067 +0200
@@ -1616,6 +1616,22 @@ cxx_bind_parameters_in_call (const const
/* The destructor needs to see any modifications the callee makes
to the argument. */
*non_constant_args = true;
+ else
+ {
+ tree addr = arg;
+ STRIP_NOPS (addr);
+ /* When a method or function is called with address of a heap
+allocated variable, don't cache it so that any modifications
+in it are performed. */
+ if (TREE_CODE (addr) == ADDR_EXPR)
+ if (tree var = get_base_address (TREE_OPERAND (addr, 0)))
+ if (VAR_P (var)
+ && (DECL_NAME (var) == heap_uninit_identifier
+ || DECL_NAME (var) == heap_identifier
+ || DECL_NAME (var) == heap_vec_uninit_identifier
+ || DECL_NAME (var) == heap_vec_identifier))
+ *non_constant_args = true;
+ }
/* For virtual calls, adjust the this argument, so that it is
the object on which the method is called, rather than
for the heap vars and something similar for the global var ctors?
[Bug tree-optimization/99956] loop interchange fails when altering bwaves inner loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99956 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-04-07 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1
[Bug libstdc++/99957] Ill-formed std::pair construction supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99957 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=37919 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-04-07 Target Milestone|--- |12.0 --- Comment #1 from Jonathan Wakely --- The second commit in PR 40925 comment 8 was submitted to the lists as https://gcc.gnu.org/legacy-ml/libstdc++/2009-10/msg00142.html and references PR 37919.
[Bug tree-optimization/99956] loop interchange fails when altering bwaves inner loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99956
--- Comment #3 from Richard Biener ---
Sth as simple (and brute-force) as the following fixes this. Somehow SCEV
must already know the "point of failure" though and eventually always
instantiating from loop to loop_nest in steps might be more efficient than
trying all possibilities on failure (or maybe we should do that on failure).
diff --git a/gcc/gimple-loop-interchange.cc b/gcc/gimple-loop-interchange.cc
index f45b9364644..215587a8406 100644
--- a/gcc/gimple-loop-interchange.cc
+++ b/gcc/gimple-loop-interchange.cc
@@ -1320,7 +1320,14 @@ compute_access_stride (class loop *loop_nest, class loop
*loop,
}
tree scev_base = build_fold_addr_expr (ref);
tree scev = analyze_scalar_evolution (loop, scev_base);
- scev = instantiate_scev (loop_preheader_edge (loop_nest), loop, scev);
+ tree orig_scev = scev;
+ scev = instantiate_scev (loop_preheader_edge (loop_nest), loop, orig_scev);
+ while (chrec_contains_undetermined (scev) && loop_nest != loop)
+{
+ loop_nest = loop_nest->inner;
+ scev = instantiate_scev (loop_preheader_edge (loop_nest),
+ loop, orig_scev);
+}
if (! chrec_contains_undetermined (scev))
{
tree sl = scev;
[Bug c++/99859] constexpr evaluation with member function is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99859
--- Comment #9 from Patrick Palka ---
(In reply to Jakub Jelinek from comment #6)
> The argument is a pointer.
> Now, I bet a pointer to an automatic variable will be seen as non-constant
> and so in that case we might be ok.
> If the argument is a pointer to some global constexpr variable, dunno.
FWIW I think this is PR80039. I think we might have to worry about this case
only when evaluating the constructor of the global constexpr variable.
> Why does it work for:
> constexpr int foo(int* x) { return ++*x; }
> struct S { constexpr S() : a(0) { foo(); foo(); } int a; };
> constexpr S s;
> static_assert (s.a == 2);
> though? The argument to foo after constexpr processing it is which is
> TREE_CONSTANT too, yet we don't cache the calls.
Hmm, seems because ctx->strict is not set when the initialization of s gets
evaluated in this case. But it breaks if we instead do "constexpr S s = S();"
> And, on this testcase the argument is a heap pointer which during constexpr
> evaluation we pretend it is constant.
> So maybe cxx_bind_parameters_in_call should set *non_constant_args also when
> arg is ADDR_EXPR of something with heap_*identifier* VAR_DECL as base?
I think we'd also have to look inside TREE_CONSTANT CONSTRUCTORs to see if
they're storing a pointer to such a variable, so that we also suppress caching
for cases like:
constexpr int foo(auto x) { return ++*x.p; }
struct S {
int a = 0;
constexpr S() {
struct R { int* p; };
foo(R{});
foo(R{});
}
};
constexpr S s = S();
static_assert (s.a == 2);
[Bug libstdc++/99957] New: Ill-formed std::pair construction supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99957
Bug ID: 99957
Summary: Ill-formed std::pair construction supported
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: minor
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
This shouldn't compile:
#include
struct move_only
{
move_only() = default;
move_only(move_only&&) = default;
};
move_only mo() { return {}; }
std::pair p0(0, mo());
std::pair p1({}, mo());
According to the standard, these constructors are considered:
pair(const first_type&, const second_type&);
template pair(U1&&, U2&&);
For both p0 and p1, the first does not participate in overload resolution
because second_type is not copy constructible.
For p0, the second constructor does not participate because U1 is deduced as
int, and a pointer cannot be constructed from int. For p1, U1 cannot be deduced
from {}.
The code compiles with libstdc++ because we have additional non-standard
constructors, added by PR 40925 and described in
https://gcc.gnu.org/pipermail/libstdc++/2021-April/052299.html (where I
proposed to deprecate these non-standard constructors, and eventually remove
them).
[Bug tree-optimization/99954] [8/9/10 Regression] Copy loop over array of unions at -O3 generates memcpy instead of memmove, resulting in incorrect code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99954 Richard Biener changed: What|Removed |Added Known to work||11.0 Summary|[8/9/10/11 Regression] Copy |[8/9/10 Regression] Copy |loop over array of unions |loop over array of unions |at -O3 generates memcpy |at -O3 generates memcpy |instead of memmove, |instead of memmove, |resulting in incorrect code |resulting in incorrect code --- Comment #6 from Richard Biener --- Fixed on trunk sofar.
[Bug tree-optimization/99954] [8/9/10/11 Regression] Copy loop over array of unions at -O3 generates memcpy instead of memmove, resulting in incorrect code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99954 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:c01ae2ab6b227e21835d128c90e974dce4604be9 commit r11-8027-gc01ae2ab6b227e21835d128c90e974dce4604be9 Author: Richard Biener Date: Wed Apr 7 13:17:05 2021 +0200 tree-optimization/99954 - fix loop distribution memcpy classification This fixes bogus classification of a copy as memcpy. We cannot use plain dependence analysis to decide between memcpy and memmove when it computes no dependence. Instead we have to try harder later which the patch does for the gcc.dg/tree-ssa/ldist-24.c testcase by resorting to tree-affine to compute the difference between src and dest and compare against the copy size. 2021-04-07 Richard Biener PR tree-optimization/99954 * tree-loop-distribution.c: Include tree-affine.h. (generate_memcpy_builtin): Try using tree-affine to prove non-overlap. (loop_distribution::classify_builtin_ldst): Always classify as PKIND_MEMMOVE. * gcc.dg/torture/pr99954.c: New testcase.
[Bug tree-optimization/99956] loop interchange fails when altering bwaves inner loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99956 --- Comment #2 from Richard Biener --- Created attachment 50523 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50523=edit DSE patch For reference this is the patch adding an additional DSE pass which fails the existing gfortran.dg/pr81303.f and it's vect/ variant.
[Bug tree-optimization/99956] loop interchange fails when altering bwaves inner loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99956 Richard Biener changed: What|Removed |Added CC||amker at gcc dot gnu.org Keywords||missed-optimization --- Comment #1 from Richard Biener --- prepare_perfect_loop_nest fails doing compute_access_strides and I wonder if we should do prepare_data_references data-ref analysis with respect to the BBs containing loop and only after collecting all datarefs instantiate the access fns up to the outermost loop possible. I don't remember exactly how we deal with this but it looks like compute_access_stride doesn't look at the access function as computed by dataref analysis but instead it analyzes things itself and could in theory instantiate_scev one-loop-at-a-time communicating "failure" upwards?
[Bug c++/99859] constexpr evaluation with member function is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99859
--- Comment #8 from Jakub Jelinek ---
Why does it work for:
constexpr int foo(int* x) { return ++*x; }
struct S { constexpr S() : a(0) { foo(); foo(); } int a; };
constexpr S s;
static_assert (s.a == 2);
though? The argument to foo after constexpr processing it is which is
TREE_CONSTANT too, yet we don't cache the calls.
[Bug tree-optimization/99956] New: loop interchange fails when altering bwaves inner loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99956
Bug ID: 99956
Summary: loop interchange fails when altering bwaves inner loop
Product: gcc
Version: 11.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: ---
When scheduling an additional DSE pass the bwaves kernel
(gfortran.dg/pr81303.f)
is no longer interchanged because prepare_perfect_loop_nest tries to use
a too outer loop where we fail to compute access functions for the data
references. If artificially restricting the nest to only cover the two
innermost
loops the interchange still works.
A modified testcase simulating the effect of the DSE is provided below:
! { dg-options "-O3 -ffast-math -floop-interchange
-fdump-tree-linterchange-details" }
subroutine mat_times_vec(y,x,a,axp,ayp,azp,axm,aym,azm,
$ nb,nx,ny,nz)
implicit none
integer nb,nx,ny,nz,i,j,k,m,l,kit,im1,ip1,jm1,jp1,km1,kp1
real*8 y(nb,nx,ny,nz),x(nb,nx,ny,nz),tem
real*8 a(nb,nb,nx,ny,nz),
1 axp(nb,nb,nx,ny,nz),ayp(nb,nb,nx,ny,nz),azp(nb,nb,nx,ny,nz),
2 axm(nb,nb,nx,ny,nz),aym(nb,nb,nx,ny,nz),azm(nb,nb,nx,ny,nz)
do k=1,nz
km1=mod(k+nz-2,nz)+1
kp1=mod(k,nz)+1
do j=1,ny
jm1=mod(j+ny-2,ny)+1
jp1=mod(j,ny)+1
do i=1,nx
im1=mod(i+nx-2,nx)+1
ip1=mod(i,nx)+1
do l=1,nb
tem=0.0
do m=1,nb
tem=tem+
1 a(l,m,i,j,k)*x(m,i,j,k)+
2 axp(l,m,i,j,k)*x(m,ip1,j,k)+
3 ayp(l,m,i,j,k)*x(m,i,jp1,k)+
4 azp(l,m,i,j,k)*x(m,i,j,kp1)+
5 axm(l,m,i,j,k)*x(m,im1,j,k)+
6 aym(l,m,i,j,k)*x(m,i,jm1,k)+
7 azm(l,m,i,j,k)*x(m,i,j,km1)
enddo
y(l,i,j,k)=tem
enddo
enddo
enddo
enddo
return
end
! { dg-final { scan-tree-dump-times "is interchanged" 1 "linterchange" } }
[Bug c++/99859] constexpr evaluation with member function is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99859
--- Comment #7 from Patrick Palka ---
constexpr void foo(int* x) { ++*x; }
constexpr int bar() {
int* x = new int(0);
foo(x);
foo(x);
int y = *x;
delete x;
return y;
}
static_assert(bar() == 2);
We reject the above testcase for seemingly the same reason -- we cache the call
to foo(x) when we shouldn't have, because cxx_bind_parameters_in_call considers
the call's argument to be TREE_CONSTANT.
We accept the analogous testcase that doesn't use constexpr new/delete:
constexpr void foo(int* x) { ++*x; }
constexpr int bar() {
int x = 0;
foo();
foo();
return x;
}
static_assert(bar() == 2);
[Bug c++/99859] constexpr evaluation with member function is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99859 --- Comment #6 from Jakub Jelinek --- The argument is a pointer. Now, I bet a pointer to an automatic variable will be seen as non-constant and so in that case we might be ok. If the argument is a pointer to some global constexpr variable, dunno. And, on this testcase the argument is a heap pointer which during constexpr evaluation we pretend it is constant. So maybe cxx_bind_parameters_in_call should set *non_constant_args also when arg is ADDR_EXPR of something with heap_*identifier* VAR_DECL as base?
[Bug c++/99859] constexpr evaluation with member function is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99859 --- Comment #5 from Patrick Palka --- (In reply to Jakub Jelinek from comment #4) > So, on the #c3 testcase, if I put a breakpoint before and after > fold_nondependent_expr in finish_static_assert and temporarily in between > those two breakpoints put a breakpoint on cxx_eval_call_expression and > cxx_eval_increment_expression, it is clear that while > cxx_eval_call_expression is called on > ... > intrusive_ptr::~intrusive_ptr (); > Foo::dec (NON_LVALUE_EXPR <((struct intrusive_ptr *) this)->ptr>); > intrusive_ptr::~intrusive_ptr (); > Foo::dec (NON_LVALUE_EXPR <((struct intrusive_ptr *) this)->ptr>); Shouldn't cxx_bind_parameters_in_call have noticed that the argument to these Foo::dec calls is non-constant, which would inhibit their caching?
[Bug c++/99859] constexpr evaluation with member function is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99859 Jakub Jelinek changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org, ||ppalka at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- So, on the #c3 testcase, if I put a breakpoint before and after fold_nondependent_expr in finish_static_assert and temporarily in between those two breakpoints put a breakpoint on cxx_eval_call_expression and cxx_eval_increment_expression, it is clear that while cxx_eval_call_expression is called on ... intrusive_ptr::~intrusive_ptr (); Foo::dec (NON_LVALUE_EXPR <((struct intrusive_ptr *) this)->ptr>); intrusive_ptr::~intrusive_ptr (); Foo::dec (NON_LVALUE_EXPR <((struct intrusive_ptr *) this)->ptr>); where during the first Foo::dec call evaluation cxx_eval_increment_expression is called on --((struct Foo *) this)->count_ during the second Foo::dec call we use cached result (1) and don't evaluate the body at all. But the body of the constexpr method has side-effects on the class it is called on (and the result is incorrect too), on the testcase when not evaluating at compile time but runtime the first Foo::dec shall predecrement count_ from 2 to 1 (thus return 1) and the second one should predecrement count_ from 1 to 0 (thus return 0). For the constexpr new I had to add the /* If the call allocated some heap object that hasn't been deallocated during the call, or if it deallocated some heap object it has not allocated, the call isn't really stateless for the constexpr evaluation and should not be cached. It is fine if the call allocates something and deallocates it too. */ setting of cacheable to false in some cases, but this PR let's me wonder if it is ever ok to cache constexpr results and what the standard actually says (if constexpr/consteval functions can have side-effects besides computing a return value (I believe they can't just change some unrelated constexpr variable, right?) and ditto for constexpr/consteval methods. So, e.g. shall we remember during the constexpr evaluation if the currently evaluated constexpr function has side-effects to something other than its automatic variables or return value and if so, make it effectively non-cacheable?
[Bug c++/99940] segmentation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99940 --- Comment #2 from timburk at live dot co.uk --- Reading package lists... Done Building dependency tree Reading state information... Done gcc is already the newest version (4:6.3.0-4). gcc set to manually installed. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
