[Bug libstdc++/95788] std::ranges::construct_at's placement new not intercepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95788 --- Comment #4 from Patrick Palka --- (In reply to Johel Ernesto Guerrero Peña from comment #3) > Thank you. Sorry for my laziness, but did you confirm this from the OP? > > Other stuff in `bits/ranges_uninitialized.h` may be similarly affected. IIUC only ranges::construct_at is affected, since it's the only constexpr function in [specialized.algorithms] that uses placement new.
[Bug middle-end/95189] [9/10 Regression] memcmp being wrongly stripped like strcmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189 --- Comment #26 from Rich Felker --- Is that complete, or is it unclear whether there are code paths other than builtin memcmp by which this is hit? Am I correct in assuming that with builtin memcmp expansion returning NULL_RTX, GCC always expands it to a function call?
[Bug debug/97344] aarch64 tls debuginfo missing location info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97344 --- Comment #2 from Stan Cox --- tls variables on aarch64 lack location info: [6e]variable abbrev: 5 name (strp) "rage" decl_file(data1) tlsdwarf.c (1) decl_line(data1) 3 decl_column (data1) 24 type (ref4) [2d] external (flag_present) yes unlike e.g. ppcle [ 10e]variable abbrev: 12 name (strp) "rage" decl_file(data1) get_fs.c (1) decl_line(data1) 23 decl_column (data1) 24 type (ref4) [39] external (flag_present) yes location (exprloc) [ 0] const8u 0 [ 9] GNU_push_tls_address
[Bug debug/97344] aarch64 tls debuginfo missing location info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97344 --- Comment #1 from Stan Cox --- Created attachment 49335 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49335=edit tls test program
[Bug debug/97344] New: aarch64 tls debuginfo missing location info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97344 Bug ID: 97344 Summary: aarch64 tls debuginfo missing location info Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: scox at redhat dot com Target Milestone: ---
[Bug c++/85576] A template union containing a friend function causes non-template type used as a template error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85576 --- Comment #1 from Luke Dalessandro --- Just ran into this today while testing 11. https://godbolt.org/z/37G7P5 Any possibility we'll see a fix soon?
[Bug middle-end/95189] [9/10 Regression] memcmp being wrongly stripped like strcmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189 --- Comment #25 from Luke Dashjr --- Created attachment 49334 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49334=edit Hacky patch to workaround the bug by disabling builtin memcmp always I wrote and am rebuilding my own systems with a very minimal patch that essentially disables the builtin memcmp entirely. It's probably overkill and bad for performance, but it should at least produce sane code and apply to pretty much any GCC (warning: including unaffected versions).
[Bug target/97329] POWER9 default cache and line sizes appear to be wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97329 --- Comment #7 from Kip Warner --- So it looks like even with GCC 11 in trunk it's still sometimes wrong on power9. Wrong L2 cache size when no -mcpu specified: $ gcc -Q --help=param | grep -i cache --param=l1-cache-line-size= 128 --param=l1-cache-size=32 --param=l2-cache-size=256 Correct when manually specifying native (power9) cpu: $ gcc -Q -mcpu=native --help=param | grep -i cache --param=l1-cache-line-size= 128 --param=l1-cache-size=32 --param=l2-cache-size=512 Correct when manually specifying power9 cpu: $ gcc -Q -mcpu=power9 --help=param | grep -i cache --param=l1-cache-line-size= 128 --param=l1-cache-size=32 --param=l2-cache-size=512 Wrong L2 cache size when powerpc64le is selected in place of power9: $ gcc -Q -mcpu=powerpc64le --help=param | grep -i cach --param=l1-cache-line-size= 128 --param=l1-cache-size=32 --param=l2-cache-size=256 Looks like this might be a clue. GCC did not identify the host/build/target as power9 automatically: $ gcc -dumpmachine powerpc64le-unknown-linux-gnu I built it from trunk last night on a power9 machine. I've attached my config.log. $ gcc --version gcc (GCC) 11.0.0 20201008 (experimental) (...)
[Bug target/97329] POWER9 default cache and line sizes appear to be wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97329 --- Comment #6 from Kip Warner --- Created attachment 49333 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49333=edit Autoconf configuration log on POWER9.
[Bug libstdc++/95788] std::ranges::construct_at's placement new not intercepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95788 --- Comment #3 from Johel Ernesto Guerrero Peña --- Thank you. Sorry for my laziness, but did you confirm this from the OP? > Other stuff in `bits/ranges_uninitialized.h` may be similarly affected.
[Bug libstdc++/97273] [8/9 Regression] Strange behaviour of unordered_set when vector is included (i686)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97273 Patrick Palka changed: What|Removed |Added Summary|[8/9/10/11 Regression] |[8/9 Regression] Strange |Strange behaviour of|behaviour of unordered_set |unordered_set when vector |when vector is included |is included (i686) |(i686) --- Comment #6 from Patrick Palka --- Fixed for GCC 11 and 10.3 so far.
[Bug c++/88115] Incorrect result from alignof in templates, if also using __alignof__.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88115 --- Comment #2 from CVS Commits --- The releases/gcc-10 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:aeb69dda51e93379fce10fb03ec57650fbf73f31 commit r10-8872-gaeb69dda51e93379fce10fb03ec57650fbf73f31 Author: Patrick Palka Date: Thu Oct 8 19:31:57 2020 -0400 c++: Distinguish alignof and __alignof__ in cp_tree_equal [PR97273] cp_tree_equal currently considers alignof the same as __alignof__, but these operators are semantically different ever since r8-7957. In the testcase below, this causes the second static_assert to fail on targets where alignof(double) != __alignof__(double) because the specialization table (which uses cp_tree_equal as its equality predicate) conflates the two dependent specializations integral_constant<__alignof__(T)> and integral_constant. This patch makes cp_tree_equal distinguish between these two operators by inspecting the ALIGNOF_EXPR_STD_P flag. gcc/cp/ChangeLog: PR c++/88115 PR libstdc++/97273 * tree.c (cp_tree_equal) : Return false if ALIGNOF_EXPR_STD_P differ. gcc/testsuite/ChangeLog: PR c++/88115 PR libstdc++/97273 * g++.dg/template/alignof3.C: New test. (cherry picked from commit 592fe221735bdaa375b1834dd49ce125d0b600d8)
[Bug libstdc++/97273] [8/9/10/11 Regression] Strange behaviour of unordered_set when vector is included (i686)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97273 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:aeb69dda51e93379fce10fb03ec57650fbf73f31 commit r10-8872-gaeb69dda51e93379fce10fb03ec57650fbf73f31 Author: Patrick Palka Date: Thu Oct 8 19:31:57 2020 -0400 c++: Distinguish alignof and __alignof__ in cp_tree_equal [PR97273] cp_tree_equal currently considers alignof the same as __alignof__, but these operators are semantically different ever since r8-7957. In the testcase below, this causes the second static_assert to fail on targets where alignof(double) != __alignof__(double) because the specialization table (which uses cp_tree_equal as its equality predicate) conflates the two dependent specializations integral_constant<__alignof__(T)> and integral_constant. This patch makes cp_tree_equal distinguish between these two operators by inspecting the ALIGNOF_EXPR_STD_P flag. gcc/cp/ChangeLog: PR c++/88115 PR libstdc++/97273 * tree.c (cp_tree_equal) : Return false if ALIGNOF_EXPR_STD_P differ. gcc/testsuite/ChangeLog: PR c++/88115 PR libstdc++/97273 * g++.dg/template/alignof3.C: New test. (cherry picked from commit 592fe221735bdaa375b1834dd49ce125d0b600d8)
[Bug libstdc++/95788] std::ranges::construct_at's placement new not intercepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95788 --- Comment #2 from Patrick Palka --- Fixed for GCC 11 so far.
[Bug libstdc++/95788] std::ranges::construct_at's placement new not intercepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95788 --- Comment #1 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:9158a4d2a6cd58d6bb591d5ce64e766b399e4aef commit r11-3739-g9158a4d2a6cd58d6bb591d5ce64e766b399e4aef Author: Patrick Palka Date: Thu Oct 8 18:10:05 2020 -0400 libstdc++: Make ranges::construct_at constexpr-friendly [PR95788] This rewrites ranges::construct_at in terms of std::construct_at so that we can piggyback on the compiler's existing support for intercepting placement new within std::construct_at during constexpr evaluation, instead of having to additionally teach the compiler about ranges::construct_at. While we're making changes to ranges::construct_at, this patch also declares it conditionally noexcept and qualifies the calls to declval in its requires-clause. libstdc++-v3/ChangeLog: PR libstdc++/95788 * include/bits/ranges_uninitialized.h: (__construct_at_fn::operator()): Rewrite in terms of std::construct_at. Declare it conditionally noexcept. Qualify calls to declval in its requires-clause. * testsuite/20_util/specialized_algorithms/construct_at/95788.cc: New test.
[Bug tree-optimization/97317] [11 Regression] ICE in verify_range, at value-range.cc:369
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97317 --- Comment #6 from Andrew Macleod --- Thanks, yeah this is the same issue and the patch should fix it..? the precision difference of one this time is 1 bit (bool) and a 2 bit object... _5; bool _6; <..> _6 = (bool) _5;
[Bug target/97343] New: AVX2 vectorizer generates extremely strange and slow code for AoSoA complex dot product
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97343
Bug ID: 97343
Summary: AVX2 vectorizer generates extremely strange and slow
code for AoSoA complex dot product
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: already5chosen at yahoo dot com
Target Milestone: ---
Let's continue our complex dot product series started here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96854
This time I have no code generation bugs for your pleasure, just "interesting"
optimization issues.
All examples below, unless stated otherwise were compiled with gcc.10.2 for
x86-64 with following sets
of flags:
set1: -Wall -mavx2 -mfma -march=skylake -O3 -ffast-math -fno-associative-math
set2: -Wall -mavx2 -mfma -march=skylake -O3 -ffast-math
The kernel in question is an example of complex dot product in so-called
"hybrid AoS" layout a.k.a. AoSoA.
https://en.wikipedia.org/wiki/AoS_and_SoA#Array_of_Structures_of_Arrays
In my experience it's quite rare when in dense complex linear algebra and
similar computational fields AoSoA is *not* the optimal internal form.
So, practically, I consider these kernels as more important than AoS kernel
presented in bug 96854.
More specifically, the layout can be described as struct { double re[4], im[4];
};
But for purpose of simplicity I omitted the type definition fro code examples
and coded it directly over flat arrays of doubles.
Part 1.
void cdot(double* res, const double* a, const double* b, int N)
{
double acc_re = 0;
double acc_im = 0;
for (int c = 0; c < N; ++c) {
for (int k = 0; k < 4; ++k) {
acc_re = acc_re + a[c*8+k+0]*b[c*8+k+0] + a[c*8+k+4]*b[c*8+k+4];
acc_im = acc_im - a[c*8+k+0]*b[c*8+k+4] + a[c*8+k+4]*b[c*8+k+0];
}
}
res[0] = acc_re;
res[4] = acc_im;
}
That's how we want to code it in the ideal world and let to compiles to care
about dirty details.
In less ideal world, gcc is not the only compiler that can't cope with it.
MSVC (-W4 -O2 -fp:fast -arch:AVX2) also can't vectorize it. Even mighty icc
generates code that it's not quite bad, but somewhat suboptimal.
So, let's it pass. I don't want to blame gcc for not being smart enough. It's
just normal.
Except that when we use set2 the code generated by gcc becomes not just
non-smart, but quite crazy.
I am ignoring it in the hope that it would be magically fixed by the change
made by Richard Biener 2020-08-31
Part 2.
void cdot(double* res, const double* a, const double* b, int N)
{
double acc_rere = 0;
double acc_imim = 0;
double acc_reim = 0;
double acc_imre = 0;
for (int c = 0; c < N; ++c) {
for (int k = 0; k < 4; ++k) {
acc_rere += a[c*8+k+0]*b[c*8+k+0];
acc_imim += a[c*8+k+4]*b[c*8+k+4];
acc_reim += a[c*8+k+0]*b[c*8+k+4];
acc_imre += a[c*8+k+4]*b[c*8+k+0];
}
}
res[0] = acc_rere+acc_imim;
res[4] = acc_imre-acc_reim;
}
We are explaining it to compiler slowly.
For icc and MSVC it's enough. They understood.
icc generates near-perfect code. I can write it nicer, but do not expect my
variant to be any faster.
MSVC generates near-perfect inner loop and epilogue that is not great, but not
really much slower.
gcc still didn't get it. It still tries to implement 4 accumulators literally,
as if -ffast-math were not here.
But, sad as it is, it's still a case of not being smart enough. So, I am not
complaining.
Part 3.
static inline double sum4(double x[]) {
return x[0]+x[1]+x[2]+x[3];
}
void cdot(double* res, const double* a, const double* b, int N)
{
double acc_re[4] = {0};
double acc_im[4] = {0};
for (int c = 0; c < N; ++c) {
for (int k = 0; k < 4; ++k) {
acc_re[k] = acc_re[k] + a[c*8+k+0]*b[c*8+k+0] + a[c*8+k+4]*b[c*8+k+4];
acc_im[k] = acc_im[k] - a[c*8+k+0]*b[c*8+k+4] + a[c*8+k+4]*b[c*8+k+0];
}
}
res[0] = sum4(acc_re);
res[4] = sum4(acc_im);
}
Attempt to feed compiler by teaspoon.
That's not a way I want to write code in HLL.
icc copes, producing about the same code as in Part 1
MSVC doesn't understand a Kunststück (I am sympathetic) and generates literal
scalar code with local arrays on stack.
gcc with set1 is a little better than MSVC - the code is fully scalar, but at
least accumulators kept in registers.
gcc with set2 is the most interesting. It vectorizes, but how?
Here is an inner loop:
.L3:
vpermpd $27, (%r8,%rax), %ymm2
vpermpd $27, 32(%rdx,%rax), %ymm3
vpermpd $27, (%rdx,%rax), %ymm1
vpermpd $27, 32(%r8,%rax), %ymm0
vmulpd %ymm2, %ymm1, %ymm6
vmulpd %ymm2, %ymm3, %ymm2
addq$64, %rax
vfnmadd132pd%ymm0, %ymm2, %ymm1
vfmadd132pd %ymm3, %ymm6, %ymm0
vaddpd %ymm1, %ymm5, %ymm5
vaddpd %ymm0, %ymm4, %ymm4
cmpq%rcx, %rax
jne .L3
What all this vpermpd business about?
[Bug middle-end/95189] [9/10 Regression] memcmp being wrongly stripped like strcmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189 --- Comment #24 from Rich Felker --- The fixes do not seem trivial to backport; lots of conflicts. It would be really helpful to have versions of the patch that are minified and applicable to all affected versions that might be shipping in distros (looks like 9.2, 9.3, 10.1, and 10.2) since this is a critical codegen regression.
[Bug tree-optimization/97317] [11 Regression] ICE in verify_range, at value-range.cc:369
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97317
--- Comment #5 from David Binderman ---
Reduced C++ source code is
class a {
public:
struct b {
int *c;
};
enum { j = 1 } e : 2;
struct {
b c;
} d;
bool f() const { return e & j; }
int *g() const;
};
int *a::g() const { return f() ? d.c.c : 0; }
a h;
void i() {
h.g();
h.f();
}
Flag -O2 required.
[Bug c++/97328] [10/11 Regression] ICE in verify_ctor_sanity, at cp/constexpr.c:3995 since r10-7313-gb599bf9d6d1e180d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97328 --- Comment #5 from Patrick Palka --- https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555850.html
[Bug middle-end/97342] New: bogus -Wstringop-overflow with nonzero signed and unsigned offsets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97342
Bug ID: 97342
Summary: bogus -Wstringop-overflow with nonzero signed and
unsigned offsets
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The combination of signed and unsigned offsets into an array of elements larger
than 1 triggers a false positive -Wstringop-overflow.
$ cat q.c && gcc -O2 -S q.c
void sink (void*, ...);
void f (unsigned i, int j)
{
i |= 1; // [1, UINT_MAX]
j |= 1; // [INT_MIN + 1, -1] U [1, INT_MAX]
int a[5];// index
int *p1 = a + i; // 1-5
int *p2 = p1 + j;// 0-5
__builtin_memset (p2, 0, 5 * sizeof *a);
sink (p1, p2);
}
q.c: In function ‘f’:
q.c:12:3: warning: ‘__builtin_memset’ writing 20 bytes into a region of size 16
overflows the destination [-Wstringop-overflow=]
12 | __builtin_memset (p2, 0, 5 * sizeof *a);
| ^~~
q.c:8:7: note: at offset [4, 17179869176] into destination object ‘a’
8 | int a[5];// index
| ^
The optimized dump below suggests the "anti-range" the signed offset is in
isn't being handled correctly.
f (unsigned intD.9 iD.1932, intD.6 jD.1933)
{
unsigned intD.9 i_5(D) = iD.1932;
intD.6 j_7(D) = jD.1933;
intD.6 * p2D.1938;
intD.6 * p1D.1937;
intD.6 aD.1936[5];
long unsigned intD.10 _1;
long unsigned intD.10 _2;
long unsigned intD.10 _3;
long unsigned intD.10 _4;
;; basic block 2, loop depth 0, count 1073741824 (estimated locally), maybe
hot
;;prev block 0, next block 1, flags: (NEW, REACHABLE, VISITED)
;;pred: ENTRY [always] count:1073741824 (estimated locally)
(FALLTHRU,EXECUTABLE)
# RANGE [1, 4294967295]
i_6 = i_5(D) | 1;
# RANGE [-2147483647, 2147483647]
j_8 = j_7(D) | 1;
# RANGE [1, 4294967295] NONZERO 4294967295
_1 = (long unsigned intD.10) i_6;
# RANGE [4, 17179869180] NONZERO 17179869180
_2 = _1 * 4;
# PT = { D.1936 } (escaped)
# ALIGN = 4, MISALIGN = 0
p1_9 = + _2;
# RANGE ~[2147483648, 18446744071562067968]
_3 = (long unsigned intD.10) j_8;
# RANGE [0, 18446744073709551612] NONZERO 18446744073709551612
_4 = _3 * 4;
# PT = { D.1936 } (escaped)
# ALIGN = 4, MISALIGN = 0
p2_10 = p1_9 + _4;
# .MEM_12 = VDEF <.MEM_11(D)>
# USE = nonlocal null { D.1936 } (escaped)
# CLB = nonlocal null { D.1936 } (escaped)
memsetD.894 (p2_10, 0, 20);
[Bug fortran/97272] Wrong answer from MAXLOC with character arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97272 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from anlauf at gcc dot gnu.org --- Fixed on master for gcc-11, and on 10- and 9-branch. Not applied to 8-branch, which did not support the back argument, so not considered worth it. Thanks for the report!
[Bug c++/96805] [10/11 Regression] ICE: Segmentation fault in instantiate_template / pop_nested_class()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96805 --- Comment #11 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:1c56c143b2011080d8a4516f37f78f647b0ee258 commit r11-3738-g1c56c143b2011080d8a4516f37f78f647b0ee258 Author: Jason Merrill Date: Thu Oct 8 15:43:26 2020 -0400 c++: Fix member alias template in C++17 and up. [PR96805] Here we're trying to push into a::c in order to instantiate t, but were building a TYPENAME_TYPE for it because a isn't open yet. Don't do that when we know we're trying to enter the scope. gcc/cp/ChangeLog: PR c++/96805 PR c++/96199 * pt.c (tsubst_aggr_type): Don't build a TYPENAME_TYPE when entering_scope. (tsubst_template_decl): Use tsubst_aggr_type. gcc/testsuite/ChangeLog: PR c++/96805 * g++.dg/cpp0x/alias-decl-pr96805.C: New test.
[Bug c++/96199] [10/11 Regression] internal compiler error: in tsubst_copy with CTAD for alias templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96199 --- Comment #8 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:1c56c143b2011080d8a4516f37f78f647b0ee258 commit r11-3738-g1c56c143b2011080d8a4516f37f78f647b0ee258 Author: Jason Merrill Date: Thu Oct 8 15:43:26 2020 -0400 c++: Fix member alias template in C++17 and up. [PR96805] Here we're trying to push into a::c in order to instantiate t, but were building a TYPENAME_TYPE for it because a isn't open yet. Don't do that when we know we're trying to enter the scope. gcc/cp/ChangeLog: PR c++/96805 PR c++/96199 * pt.c (tsubst_aggr_type): Don't build a TYPENAME_TYPE when entering_scope. (tsubst_template_decl): Use tsubst_aggr_type. gcc/testsuite/ChangeLog: PR c++/96805 * g++.dg/cpp0x/alias-decl-pr96805.C: New test.
[Bug fortran/97272] Wrong answer from MAXLOC with character arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97272 --- Comment #8 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:83967508034454425dfce7fe0ea33a153c34e7cb commit r9-8985-g83967508034454425dfce7fe0ea33a153c34e7cb Author: Harald Anlauf Date: Sun Oct 4 20:24:29 2020 +0200 PR fortran/97272 - Wrong answer from MAXLOC with character arg The optional KIND argument to the MINLOC/MAXLOC intrinsic must not be passed to the library function, as the kind conversion of the result is treated explicitly elsewhere. gcc/fortran/ChangeLog: PR fortran/97272 * trans-intrinsic.c (strip_kind_from_actual): Helper function for removal of KIND argument. (gfc_conv_intrinsic_minmaxloc): Ignore KIND argument here, as it is treated elsewhere. gcc/testsuite/ChangeLog: PR fortran/97272 * gfortran.dg/pr97272.f90: New test. (cherry picked from commit 35d2c6b6e8a7448a84abbf967feeb78a29117014)
[Bug target/97329] POWER9 default cache and line sizes appear to be wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97329 --- Comment #5 from Segher Boessenkool --- So both the cache line size and the cache size are wrong for GCC 10 and before, but okay on trunk, on all compiler I tested (I tested on Linux only so far).
[Bug target/97329] POWER9 default cache and line sizes appear to be wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97329 --- Comment #4 from Kip Warner --- I'm going to do some more testing tonight and report back after.
[Bug target/97329] POWER9 default cache and line sizes appear to be wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97329 Segher Boessenkool changed: What|Removed |Added Last reconfirmed||2020-10-08 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||segher at gcc dot gnu.org --- Comment #3 from Segher Boessenkool --- At least as far back as GCC 5 we report D-L1 size 64kB (for most CPUs, not just p9). Confirmed.
[Bug c++/97328] [10/11 Regression] ICE in verify_ctor_sanity, at cp/constexpr.c:3995 since r10-7313-gb599bf9d6d1e180d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97328
--- Comment #4 from Patrick Palka ---
(In reply to Marek Polacek from comment #3)
> (In reply to Patrick Palka from comment #2)
> > When 'storage' is a struct instead of a union, i.e. for the testcase
> >
> > template
> > struct vector {
> > struct storage {
> > T t;
> > constexpr storage() {}
> > } data[N];
> > };
> >
> > constexpr auto foo() {
> > vector i;
> > return i;
> > }
> > auto f = foo();
> >
> > we started to ICE earlier, since r279019:
> >
> >PR c++/91353 - P1331R2: Allow trivial default init in constexpr contexts.
>
> Ah. Feel free to hand this PR to me then (that is, if you don't want it
> anymore).
I have a fix, I think :) Will post it to the ML soon.
[Bug c++/97341] New: Implicit casting from char** to const char* const* in template argument failing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97341
Bug ID: 97341
Summary: Implicit casting from char** to const char* const* in
template argument failing
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reikdas at gmail dot com
Target Milestone: ---
Created attachment 49332
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49332=edit
preprocessed file
Implicit casting of char** to a const char* const* by passing a char** variable
to a class template's argument like -
char *bar = (char*)"Hello1";
constexpr char** baz =
template class foo {};
int main()
{
foo Foo;
return 1;
}
gives a compilation error -
test.cpp:7:12: error: the address of the ‘const char* const’ subobject of ‘bar’
is not a valid template argument
7 | foo Foo;
|^
Output of g++ -v -save-temps -std=c++17 test.cpp -
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl
--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-install-libiberty --enable-linker-build-id
--enable-lto --enable-multilib --enable-plugin --enable-shared
--enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-libunwind-exceptions --disable-werror
gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++17' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/cc1plus -E -quiet -v -D_GNU_SOURCE
test.cpp -mtune=generic -march=x86-64 -std=c++17 -fpch-preprocess -o test.ii
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0/x86_64-pc-linux-gnu
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0/backward
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include
/usr/local/include
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++17' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/cc1plus -fpreprocessed test.ii -quiet
-dumpbase test.cpp -mtune=generic -march=x86-64 -auxbase test -std=c++17
-version -o test.s
GNU C++17 (GCC) version 10.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 10.2.0, GMP version 6.2.0, MPFR version
4.1.0, MPC version 1.1.0, isl version isl-0.21-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++17 (GCC) version 10.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 10.2.0, GMP version 6.2.0, MPFR version
4.1.0, MPC version 1.1.0, isl version isl-0.21-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 2affcd71b0797e2421aae734ab600c81
test.cpp: In function ‘int main()’:
test.cpp:7:12: error: the address of the ‘const char* const’ subobject of ‘bar’
is not a valid template argument
7 | foo Foo;
|^
[Bug c++/97341] Implicit casting from char** to const char* const* in template argument failing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97341 --- Comment #1 from Pratyush Das --- I should add, that this works in Clang.
[Bug rtl-optimization/97313] [11 Regression] ICE in lra_set_insn_recog_data, at lra.c:1004 since r11-937-g5261cf8ce824bfc7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97313 --- Comment #1 from Vladimir Makarov --- Thank you for reporting this. I am trying to find the best place to fix this: either in memory subreg elimination or in match_reload itself. I hope the fix will be ready tomorrow.
[Bug c++/97328] [10/11 Regression] ICE in verify_ctor_sanity, at cp/constexpr.c:3995 since r10-7313-gb599bf9d6d1e180d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97328
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #3 from Marek Polacek ---
(In reply to Patrick Palka from comment #2)
> When 'storage' is a struct instead of a union, i.e. for the testcase
>
> template
> struct vector {
> struct storage {
> T t;
> constexpr storage() {}
> } data[N];
> };
>
> constexpr auto foo() {
> vector i;
> return i;
> }
> auto f = foo();
>
> we started to ICE earlier, since r279019:
>
>PR c++/91353 - P1331R2: Allow trivial default init in constexpr contexts.
Ah. Feel free to hand this PR to me then (that is, if you don't want it
anymore).
[Bug c++/97328] [10/11 Regression] ICE in verify_ctor_sanity, at cp/constexpr.c:3995 since r10-7313-gb599bf9d6d1e180d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97328
--- Comment #2 from Patrick Palka ---
When 'storage' is a struct instead of a union, i.e. for the testcase
template
struct vector {
struct storage {
T t;
constexpr storage() {}
} data[N];
};
constexpr auto foo() {
vector i;
return i;
}
auto f = foo();
we started to ICE earlier, since r279019:
PR c++/91353 - P1331R2: Allow trivial default init in constexpr contexts.
[Bug fortran/95979] [10/11 Regression] ICE in get_kind, at fortran/simplify.c:129
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95979 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Known to work||7.4.1, 8.4.1, 9.3.1 Status|NEW |ASSIGNED Known to fail||10.2.1, 11.0 --- Comment #5 from anlauf at gcc dot gnu.org --- Patch: https://gcc.gnu.org/pipermail/fortran/2020-October/055162.html
[Bug libgomp/97212] [OpenMP] 'depend' clause with 'target nowait' (!) + 'task' does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97212 Jakub Jelinek changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #3 from Jakub Jelinek --- Several people on omp-lang agreed on this, so closing as invalid. I've notified the test author.
[Bug middle-end/95189] [9/10 Regression] memcmp being wrongly stripped like strcmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189 Martin Sebor changed: What|Removed |Added Known to fail|10.1.0 | --- Comment #23 from Martin Sebor --- Backported to 10-branch via r10-8871.
[Bug middle-end/95886] suboptimal memcpy with embedded zero bytes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95886 --- Comment #8 from CVS Commits --- The releases/gcc-10 branch has been updated by Martin Sebor : https://gcc.gnu.org/g:e4c9aac98611f63847ef6c57916808d9a2d7abcb commit r10-8871-ge4c9aac98611f63847ef6c57916808d9a2d7abcb Author: Martin Sebor Date: Thu Oct 8 12:35:01 2020 -0600 Correct handling of constant representations containing embedded nuls (backport from trunk). Resolves: PR middle-end/95189 - memcmp being wrongly stripped like strcm PR middle-end/95886 - suboptimal memcpy with embedded zero bytes gcc/ChangeLog: PR middle-end/95189 PR middle-end/95886 * builtins.c (inline_expand_builtin_string_cmp): Rename... (inline_expand_builtin_bytecmp): ...to this. (builtin_memcpy_read_str): Don't expect data to be nul-terminated. (expand_builtin_memory_copy_args): Handle object representations with embedded nul bytes. (expand_builtin_memcmp): Same. (expand_builtin_strcmp): Adjust call to naming change. (expand_builtin_strncmp): Same. * expr.c (string_constant): Create empty strings with nonzero size. * fold-const.c (c_getstr): Rename locals and update comments. * tree.c (build_string): Accept null pointer argument. (build_string_literal): Same. * tree.h (build_string): Provide a default. (build_string_literal): Same. gcc/testsuite/ChangeLog: PR middle-end/95189 PR middle-end/95886 * gcc.dg/memcmp-pr95189.c: New test. * gcc.dg/strncmp-3.c: New test. * gcc.target/i386/memcpy-pr95886.c: New test.
[Bug middle-end/95189] [9/10 Regression] memcmp being wrongly stripped like strcmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189 --- Comment #22 from CVS Commits --- The releases/gcc-10 branch has been updated by Martin Sebor : https://gcc.gnu.org/g:e4c9aac98611f63847ef6c57916808d9a2d7abcb commit r10-8871-ge4c9aac98611f63847ef6c57916808d9a2d7abcb Author: Martin Sebor Date: Thu Oct 8 12:35:01 2020 -0600 Correct handling of constant representations containing embedded nuls (backport from trunk). Resolves: PR middle-end/95189 - memcmp being wrongly stripped like strcm PR middle-end/95886 - suboptimal memcpy with embedded zero bytes gcc/ChangeLog: PR middle-end/95189 PR middle-end/95886 * builtins.c (inline_expand_builtin_string_cmp): Rename... (inline_expand_builtin_bytecmp): ...to this. (builtin_memcpy_read_str): Don't expect data to be nul-terminated. (expand_builtin_memory_copy_args): Handle object representations with embedded nul bytes. (expand_builtin_memcmp): Same. (expand_builtin_strcmp): Adjust call to naming change. (expand_builtin_strncmp): Same. * expr.c (string_constant): Create empty strings with nonzero size. * fold-const.c (c_getstr): Rename locals and update comments. * tree.c (build_string): Accept null pointer argument. (build_string_literal): Same. * tree.h (build_string): Provide a default. (build_string_literal): Same. gcc/testsuite/ChangeLog: PR middle-end/95189 PR middle-end/95886 * gcc.dg/memcmp-pr95189.c: New test. * gcc.dg/strncmp-3.c: New test. * gcc.target/i386/memcpy-pr95886.c: New test.
[Bug c++/96805] [10/11 Regression] ICE: Segmentation fault in instantiate_template / pop_nested_class()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96805 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug libgomp/97212] [OpenMP] 'depend' clause with 'target nowait' (!) + 'task' does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97212 --- Comment #2 from Jakub Jelinek --- I believe the testcase is invalid. As the explicit task doesn't have if(false) clause, the task isn't undeferred, so it is up to the implementation whether it waits for its completion or just continues (defers it). And there is no task synchronization point before the if (sum != N) __builtin_abort (); statement, so if the implementation decides to defer it, then there is no guarantee it completes before that statement. Without the target nowait task gcc wouldn't defer it because there is just an implicit parallel region rather than explicit (e.g. if you add parallel num_threads(1) around most of main and change target nowait to task, you'd get the same behavior), but in order to support async target tasks we do create intentionally a team and thus defer the task. So, the testcase needs something like #pragma omp taskwait or taskwait with depend or add if(false) to the task.
[Bug ipa/97292] [11 Regression] dealII from SPECCPU 2006 no longer terminates after g:c34db4b6f8a5d80367c709309f9b00cb32630054
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292 --- Comment #15 from Jan Hubicka --- So it seems that problem is that store in operator++ is TriaObjectAcessor while read is DoFCellAccessor. I am however not sure where the type puning happens :(
[Bug ipa/97292] [11 Regression] dealII from SPECCPU 2006 no longer terminates after g:c34db4b6f8a5d80367c709309f9b00cb32630054
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292
--- Comment #14 from Jan Hubicka ---
So this really seems that the alias set 6 is not conflicting with alias sets
11 or 13. active_cell is
struct active_cell_iterator active_cell;
and the code around seems SRA injected
MEM[(struct TriaRawIterator *)_cell] ={v} {CLOBBER};
MEM [(struct DoFCellAccessor *)_cell] =
cell$dof_handler_253;
MEM [(struct DoFCellAccessor *)_cell + 8B] =
cell$8$present_level_242;
MEM [(struct DoFCellAccessor *)_cell + 12B] =
cell$8$present_index_245;
MEM [(struct DoFCellAccessor *)_cell +
16B] = cell$8$tria_244;
operator++ (_cell);
MEM[(struct TriaRawIterator *)].accessor = MEM[(const struct
TriaRawIterator &)_cell].accessor;
and we CSE is acrss the call
Honza
[Bug ipa/97292] [11 Regression] dealII from SPECCPU 2006 no longer terminates after g:c34db4b6f8a5d80367c709309f9b00cb32630054
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292 --- Comment #13 from Jan Hubicka --- OK, I can reproduce it even though the propagation happens in different function in dom rather than pre. The callee is again the operator++ so I start to suspect aliasing violation there. I get: ipa-modref: in build_patches.constprop/375859, call to operator++/33005 does not clobber MEM [(struct DoFCellAccessor *)_cell] 6->6 parameter of call is _cell so we disambiguate param0 with while the summary for ipa-modref stores: Limits: 32 bases, 16 refs Base 0: alias set 11 Ref 0: alias set 13 access: Parm 0 param offset:64 offset:32 size:32 max_size:32 access: Parm 0 param offset:64 offset:0 size:32 max_size:32 So this really seems that the alias set 6 is not conflicting with alias sets 11 or 13. Honza
[Bug middle-end/97336] False positive -Wstring-compare warning for strncmp()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97336
Martin Sebor changed:
What|Removed |Added
Resolution|--- |INVALID
CC||msebor at gcc dot gnu.org
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Martin Sebor ---
The warning works as intended: unless n > 4, the strncmp call will return
nonzero because the length of buf is less than 5. GCC partially unrolls the
loop and the first iteration of it is what triggers the warning. It disappears
when the buffer is cleared with memset only because GCC (as a limitation) loses
track of the length of the string in buf after that. Handling the case when n
is zero or less (e.g., via if (n <= 0) return 0;) does as well.
The IL that leads up to the warning can be seen in the output of the
-fdump-tree-dom4 option (below).
f (const char * p, int n)
{
sizetype ivtmp.6;
int i;
char buf[10];
char _3;
_Bool _4;
_Bool _5;
_Bool _6;
int _7;
int _10;
char prephitmp_20;
int _21;
unsigned int _25;
char pretmp_33;
[local count: 118111600]:
buf = ""; <<< strlen(buf) == 0
if (n_15(D) > 0)
goto ; [89.00%]
else
goto ; [11.00%]
...
[local count: 12992276]: <<< n == 0
_21 = __builtin_strncmp (, "12345", 5); <<< warning here
if (_21 == 0) <<< folded to false
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 6496138]:
# prephitmp_20 = PHI <0(4)>
[local count: 95940523]:
goto ; [100.00%]
[local count: 105119324]:
_7 = __builtin_strncmp (, "12345", 5);<<< second strncmp call
if (_7 == 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 52559662]:
if (i_19 == 5)
goto ; [23.93%]
else
goto ; [76.07%]
[local count: 40175661]:
pretmp_33 = buf[5];
if (pretmp_33 == 32)
goto ; [25.01%]
else
goto ; [74.99%]
[local count: 118111600]:
# _10 = PHI <1(9), 0(6), 1(8)>
buf ={v} {CLOBBER};
return _10;
}
Rewriting the code in a way that avoids the loop (e.g., by using memcpy
instead) also avoids the warning.
[Bug target/96313] [AArch64] vqmovun* return types should be unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96313 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from ktkachov at gcc dot gnu.org --- Fixed on GCC 8.5 onwards.
[Bug target/97150] [AArch64] 2nd parameter of unsigned Neon scalar shift intrinsics should be signed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97150 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from ktkachov at gcc dot gnu.org --- Fixed on GCC 8.5 onwards.
[Bug target/97150] [AArch64] 2nd parameter of unsigned Neon scalar shift intrinsics should be signed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97150 --- Comment #7 from CVS Commits --- The releases/gcc-8 branch has been updated by Kyrylo Tkachov : https://gcc.gnu.org/g:311183d74e4f3fd5a37749cfbb0960e655e715fb commit r8-10576-g311183d74e4f3fd5a37749cfbb0960e655e715fb Author: Kyrylo Tkachov Date: Wed Sep 30 12:01:23 2020 +0100 PR target/97150 AArch64: 2nd parameter of unsigned Neon scalar shift intrinsics should be signed In this PR the second argument to the intrinsics should be signed but we use an unsigned one erroneously. The corresponding builtins are already using the correct types so it's just a matter of correcting the signatures in arm_neon.h gcc/ PR target/97150 * config/aarch64/arm_neon.h (vqrshlb_u8): Make second argument signed. (vqrshlh_u16): Likewise. (vqrshls_u32): Likewise. (vqrshld_u64): Likewise. (vqshlb_u8): Likewise. (vqshlh_u16): Likewise. (vqshls_u32): Likewise. (vqshld_u64): Likewise. (vshld_u64): Likewise. gcc/testsuite/ PR target/97150 * gcc.target/aarch64/pr97150.c: New test. (cherry picked from commit 2d8fbebdb1eaca8de557ab3052535a8e4b8f8972) (cherry picked from commit 11af9c329ae528abb8c69ae8fae96a0f3fc6ed87) (cherry picked from commit d5c6ea22fe6db1ee19a178941a8c7f8ff5d0538c)
[Bug target/96313] [AArch64] vqmovun* return types should be unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96313 --- Comment #9 from CVS Commits --- The releases/gcc-8 branch has been updated by Kyrylo Tkachov : https://gcc.gnu.org/g:7f8115b305f1a1a2ddec4f59bc08a3415359dda6 commit r8-10575-g7f8115b305f1a1a2ddec4f59bc08a3415359dda6 Author: Kyrylo Tkachov Date: Wed Sep 30 12:00:20 2020 +0100 PR target/96313 AArch64: vqmovun* return types should be unsigned In this PR we have the wrong return type for some intrinsics. It should be unsigned, but we implement it as signed. Fix this by adjusting the type qualifiers used when creating the builtins and fixing the type in the arm_neon.h intrinsic. With the adjustment in qualifiers we now don't need to cast the result when returning. Bootstrapped and tested on aarch64-none-linux-gnu. gcc/ PR target/96313 * config/aarch64/aarch64-simd-builtins.def (sqmovun): Use UNOPUS qualifiers. * config/aarch64/arm_neon.h (vqmovun_s16): Adjust builtin call. Remove unnecessary result cast. (vqmovun_s32): Likewise. (vqmovun_s64): Likewise. (vqmovunh_s16): Likewise. Fix return type. (vqmovuns_s32): Likewise. (vqmovund_s64): Likewise. gcc/testsuite/ PR target/96313 * gcc.target/aarch64/pr96313.c: New test. * gcc.target/aarch64/scalar_intrinsics.c (test_vqmovunh_s16): Adjust return type. (test_vqmovuns_s32): Likewise. (test_vqmovund_s64): Likewise. (cherry picked from commit 135b043196b5575c690ef1e07bcbb49bf037c3a2) (cherry picked from commit 7d177b142dcbe841124fe023cb592914d4200e57) (cherry picked from commit 18d980d94f8d7187ce30bf23ddd365fa54189c36)
[Bug c++/97340] Spurious rejection of member variable template of reference type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97340 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-10-08 Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Confirmed.
[Bug target/97324] -mcpu= isn't validated on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97324 --- Comment #9 from Kip Warner --- Yup. Agreed.
[Bug target/97324] -mcpu= isn't validated on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97324 --- Comment #8 from Jakub Jelinek --- Except for native supported on a subset of the architectures, no values are the same, so this is highly target specific anyway. And yes, were it designed all now, we'd use the same options, but some of these choices are 33 years old, others 10, 20, 30 etc., so it is difficult to adjust it now without breaking stuff too much.
[Bug target/97324] -mcpu= isn't validated on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97324 --- Comment #7 from Kip Warner --- I understand what you mean from a maintainer's standpoint. But from a user's standpoint, that's an inconsistency.
[Bug target/97324] -mcpu= isn't validated on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97324 --- Comment #6 from Jakub Jelinek --- There is no consistency. Targets that have all of -march=, -mcpu= and -mtune=: aarch64, arm, cris, i386 (-mcpu= deprecated and treated as -mtune=), m68k Targets that have just -march= and -mtune=: gcn, mips, riscv, s390 Targets that have just -march= and -mcpu=: csky, iq2000, nds32 Targets that have just -mcpu= and -mtune=: alpha, arc, rs6000, sparc, visium Targets that have just -mcpu=: bfin, frv, m32c, microblaze, msp430, rl78, rx, tilegx, tilepro Targets that have just -mtune=: ia64, mn10300 Targets that have just -march=: c6x, nios2, pa
[Bug fortran/97272] Wrong answer from MAXLOC with character arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97272 --- Comment #7 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:d4ec0a15afb7538247206aa9936071544fd860f8 commit r10-8870-gd4ec0a15afb7538247206aa9936071544fd860f8 Author: Harald Anlauf Date: Sun Oct 4 20:24:29 2020 +0200 PR fortran/97272 - Wrong answer from MAXLOC with character arg The optional KIND argument to the MINLOC/MAXLOC intrinsic must not be passed to the library function, as the kind conversion of the result is treated explicitly elsewhere. gcc/fortran/ChangeLog: PR fortran/97272 * trans-intrinsic.c (strip_kind_from_actual): Helper function for removal of KIND argument. (gfc_conv_intrinsic_minmaxloc): Ignore KIND argument here, as it is treated elsewhere. gcc/testsuite/ChangeLog: PR fortran/97272 * gfortran.dg/pr97272.f90: New test. (cherry picked from commit 35d2c6b6e8a7448a84abbf967feeb78a29117014)
[Bug target/97324] -mcpu= isn't validated on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97324 --- Comment #5 from Kip Warner --- The reason I asked is because of that inconsistency in the -mcpu usage on targets. Thanks for clarifying.
[Bug c++/97340] New: Spurious rejection of member variable template of reference type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97340
Bug ID: 97340
Summary: Spurious rejection of member variable template of
reference type
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: herring at lanl dot gov
Target Milestone: ---
In many recent versions of GCC, the following valid code
struct A {
template
static constexpr const int =0;
};
template
struct B {
static constexpr int y=A::template x;
};
template struct B<>;
produces
error: ''indirect_ref' not supported by dump_decl' is not a
template [-fpermissive]
7 | static constexpr int y=A::template x;
| ^~
The 'template' after '::' here is unnecessary; removing it avoids the error,
but the error also appears if A is a class template (so that it's necessary to
write "A::template x"). Making A::x not be a reference also avoids the
error, as does referring to it from a non-templated context.
[Bug target/97324] -mcpu= isn't validated on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97324 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- -m* options are target specific, so each target can and often does have its own. -mcpu= is deprecated just on x86, but many other targets don't even have -mcpu= and never had, etc. On the other side, some targets like powerpc do use -mcpu= where other targets use -march= instead, or some have even more complicated handling (arm/aarch64).
[Bug target/97324] -mcpu= isn't validated on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97324 --- Comment #3 from Kip Warner --- Martin, is -mcpu deprecated for all architectures or just x86?
[Bug libstdc++/97339] New: std::async sometimes prevents std::current_exception from working properly in the terminate handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97339
Bug ID: 97339
Summary: std::async sometimes prevents std::current_exception
from working properly in the terminate handler
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: m101010a at gmail dot com
Target Milestone: ---
If std::async is called with a noexcept function that throws an exception and
contains a catch block which catches exceptions of a different type,
std::current_exception returns an empty exception pointer when called from the
terminate handler.
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl
--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-install-libiberty --enable-linker-build-id
--enable-lto --enable-multilib --enable-plugin --enable-shared
--enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-libunwind-exceptions --disable-werror
gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.0 (GCC)
$ cat y.cpp
#include
#include
void term_handler() {
auto e = std::current_exception();
if (e)
std::cout << "Died with exception" << std::endl;
else
std::cout << "Died without exception" << std::endl;
std::abort();
}
void bar() noexcept {
try {
throw "";
}
catch (int) { }
}
int main() {
std::set_terminate(_handler);
std::async(std::launch::async, ).get();
}
$ g++ y.cpp -pthread
$ ./a.out
Died without exception
Aborted (core dumped)
$
This happens regardless of whether launch::async or launch::deferred is used,
but does not happen if the function is called directly or is run by a
std::thread.
[Bug tree-optimization/97317] [11 Regression] ICE in verify_range, at value-range.cc:369
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97317 David Binderman changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #4 from David Binderman --- I see this one also. I am reducing some C++ code from a build of the qt3 package on x86_64 linux.
[Bug target/97338] New: [nvptx] Convergence checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97338
Bug ID: 97338
Summary: [nvptx] Convergence checking
Product: gcc
Version: 11.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: ---
With ptx, we have insns that need to be executed in convergent mode, that is,
all threads in the warp active.
We can unfortunately not enforce this, but we could check it, which could help
pinpoint problems.
A ptx insn:
...
vote.ballot.b32 %rbla, 1;
...
gives us the regmask of active threads, so we could check:
...
{
.reg .u32 %rwarp_active_mask;
vote.ballot.b32 %rwarp_active_mask, 1;
.reg .pred %pconvergent;
setp.eq.u32 %pconvergent,%rwarp_active_mask,-1;
@ ! %pconvergent trap;
}
...
[Bug target/97150] [AArch64] 2nd parameter of unsigned Neon scalar shift intrinsics should be signed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97150 --- Comment #6 from CVS Commits --- The releases/gcc-9 branch has been updated by Kyrylo Tkachov : https://gcc.gnu.org/g:d5c6ea22fe6db1ee19a178941a8c7f8ff5d0538c commit r9-8983-gd5c6ea22fe6db1ee19a178941a8c7f8ff5d0538c Author: Kyrylo Tkachov Date: Wed Sep 30 12:01:23 2020 +0100 PR target/97150 AArch64: 2nd parameter of unsigned Neon scalar shift intrinsics should be signed In this PR the second argument to the intrinsics should be signed but we use an unsigned one erroneously. The corresponding builtins are already using the correct types so it's just a matter of correcting the signatures in arm_neon.h gcc/ PR target/97150 * config/aarch64/arm_neon.h (vqrshlb_u8): Make second argument signed. (vqrshlh_u16): Likewise. (vqrshls_u32): Likewise. (vqrshld_u64): Likewise. (vqshlb_u8): Likewise. (vqshlh_u16): Likewise. (vqshls_u32): Likewise. (vqshld_u64): Likewise. (vshld_u64): Likewise. gcc/testsuite/ PR target/97150 * gcc.target/aarch64/pr97150.c: New test. (cherry picked from commit 2d8fbebdb1eaca8de557ab3052535a8e4b8f8972) (cherry picked from commit 11af9c329ae528abb8c69ae8fae96a0f3fc6ed87)
[Bug target/96313] [AArch64] vqmovun* return types should be unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96313 --- Comment #8 from CVS Commits --- The releases/gcc-9 branch has been updated by Kyrylo Tkachov : https://gcc.gnu.org/g:18d980d94f8d7187ce30bf23ddd365fa54189c36 commit r9-8982-g18d980d94f8d7187ce30bf23ddd365fa54189c36 Author: Kyrylo Tkachov Date: Wed Sep 30 12:00:20 2020 +0100 PR target/96313 AArch64: vqmovun* return types should be unsigned In this PR we have the wrong return type for some intrinsics. It should be unsigned, but we implement it as signed. Fix this by adjusting the type qualifiers used when creating the builtins and fixing the type in the arm_neon.h intrinsic. With the adjustment in qualifiers we now don't need to cast the result when returning. Bootstrapped and tested on aarch64-none-linux-gnu. gcc/ PR target/96313 * config/aarch64/aarch64-simd-builtins.def (sqmovun): Use UNOPUS qualifiers. * config/aarch64/arm_neon.h (vqmovun_s16): Adjust builtin call. Remove unnecessary result cast. (vqmovun_s32): Likewise. (vqmovun_s64): Likewise. (vqmovunh_s16): Likewise. Fix return type. (vqmovuns_s32): Likewise. (vqmovund_s64): Likewise. gcc/testsuite/ PR target/96313 * gcc.target/aarch64/pr96313.c: New test. * gcc.target/aarch64/scalar_intrinsics.c (test_vqmovunh_s16): Adjust return type. (test_vqmovuns_s32): Likewise. (test_vqmovund_s64): Likewise. (cherry picked from commit 135b043196b5575c690ef1e07bcbb49bf037c3a2) (cherry picked from commit 7d177b142dcbe841124fe023cb592914d4200e57)
[Bug testsuite/97337] New: new test case gcc.dg/pr97315-1.c fails with excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97337 Bug ID: 97337 Summary: new test case gcc.dg/pr97315-1.c fails with excess errors Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:214d514fafcd78cd54e4a4aa9ae08c89abf9cc57, r11-3717 make -k check-gcc RUNTESTFLAGS=dg.exp=gcc.dg/pr97315-1.c FAIL: gcc.dg/pr97315-1.c (test for excess errors) # of unexpected failures1 Excess errors: /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/pr97315-1.c:6:23: error: empty enum is invalid /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/pr97315-1.c:8:3: error: unknown type name 'tree_code' /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/pr97315-1.c:11:3: error: unknown type name 'tree_base' /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/pr97315-1.c:13:8: error: unknown type name 'tree_code_class' /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/pr97315-1.c:15:28: error: unknown type name 'tree_code' /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/pr97315-1.c:15:44: error: unknown type name 'tree_code' /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/pr97315-1.c:22:51: error: request for member 'code' in something not a structure or union /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/pr97315-1.c:23:38: error: request for member 'code' in something not a structure or union /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/pr97315-1.c:25:12: warning: implicit declaration of function 'tree_check3' [-Wimplicit-function-declaration]
[Bug ipa/97292] [11 Regression] dealII from SPECCPU 2006 no longer terminates after g:c34db4b6f8a5d80367c709309f9b00cb32630054
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292 --- Comment #12 from Tamar Christina --- (In reply to Martin Liška from comment #11) > (In reply to Tamar Christina from comment #0) > > With just -Ofast the benchmark doesn't seem to ever terminate until it is > > eventually killed. > > > > Can't reproduce the stuck without -flto. You're right, had the timeout set too low in the CI. it does work without lto. Sorry about that.
[Bug target/97203] [nvptx] 'illegal memory access was encountered' with 'omp simd'/SIMT and cexpf call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97203 --- Comment #5 from Tom de Vries --- FWIW, another aspect here is convergence (as usual). Looking at the SASS code for main$_omp_fn$0$impl, I don't find evidence for the usual divergence/convergence ops (SSY/SYNC), which might mean that the following shfl is executed in divergent mode, so, even if we would not get the memory access error, we would not get correct results.
[Bug tree-optimization/97317] [11 Regression] ICE in verify_range, at value-range.cc:369
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97317 --- Comment #3 from Andrew Macleod --- Created attachment 49331 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49331=edit patch to calculate negative side properly This is actually due to not handling a cast very well when the precision of the RHS is only 1 greater than the precision of the LHS. lhs = (cast) RHS we calculate the value of RHS by treating LHS as an unsigned, and 1) adding in all the ranges of LHS as positive ranges 2) adding in all the LHS values as negative values 3) filling in all the other ranges in RHS between those negative and positive values. ie, all the various upper bits in RHS can be on or off... THe code breaks down when the precision of the RHS is off by one. when calculating those negative values in 3), there wasn't a expectation that the sign bit *is* basically the entire range, so when it was trying to calculate the range o fthose bits, it was trying to create a nonsensical range. This patch fixes that particular problem, but further examination shows we arent producing ranges as good as we could.. so I will continue delving into it.
[Bug ipa/97335] [11 Regression] 525.x264_r fails with -Ofast -g -march=znver2 -flto=16 since r11-3641-gc34db4b6f8a5d803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97335 --- Comment #3 from Martin Liška --- One needs -flto here.
[Bug ipa/97292] [11 Regression] dealII from SPECCPU 2006 no longer terminates after g:c34db4b6f8a5d80367c709309f9b00cb32630054
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292 --- Comment #11 from Martin Liška --- (In reply to Tamar Christina from comment #0) > With just -Ofast the benchmark doesn't seem to ever terminate until it is > eventually killed. > Can't reproduce the stuck without -flto.
[Bug ipa/97335] [11 Regression] 525.x264_r fails with -Ofast -g -march=znver2 -flto=16 since r11-3641-gc34db4b6f8a5d803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97335 --- Comment #2 from Martin Liška --- With the current master (g:3e1123e52f8eca2650efa0bc81768792d328961f) one needs only one IPA modref transform to trigger the wrong code: -fdbg-cnt=ipa_mod_ref:778-778 where one needs to copy the input file to benchspec/CPU/525.x264_r/build/build_peak_gcc7-m64. folder: cp ../../../525.x264_r/data/test/input/BuckBunny.264 . One can see the difference in PRE dump file.
[Bug target/97203] [nvptx] 'illegal memory access was encountered' with 'omp simd'/SIMT and cexpf call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97203 --- Comment #4 from Tom de Vries --- So, I think calling functions from simd code is atm not supported for nvptx. Stack variables in simd code are mapped on a per-thread stack rather than on the usual per-warp stack. The functions are compiled with the usual per-warp stack, so calling those functions from simd might mean the different lanes are gonna disagree about what the value in a stack variable should be. Having said that, for the example in comment 2, there only should be one thread executing the call, so this doesn't explain the illegal memory access.
[Bug other/97309] Improve documentation of -fallow-store-data-races
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97309 qinzhao at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from qinzhao at gcc dot gnu.org --- fixed.
[Bug other/97309] Improve documentation of -fallow-store-data-races
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97309 --- Comment #2 from CVS Commits --- The master branch has been updated by Qing Zhao : https://gcc.gnu.org/g:baf4750feaa6a5fa502ae7bc0b90f31640af6f47 commit r11-3732-gbaf4750feaa6a5fa502ae7bc0b90f31640af6f47 Author: qing zhao Date: Thu Oct 8 17:01:07 2020 +0200 Improve documentation of -fallow-store-data-races 2020-10-08 John Henning gcc/ PR other/97309 * doc/invoke.texi: Improve documentation of -fallow-store-data-races.
[Bug target/97150] [AArch64] 2nd parameter of unsigned Neon scalar shift intrinsics should be signed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97150 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Kyrylo Tkachov : https://gcc.gnu.org/g:11af9c329ae528abb8c69ae8fae96a0f3fc6ed87 commit r10-8869-g11af9c329ae528abb8c69ae8fae96a0f3fc6ed87 Author: Kyrylo Tkachov Date: Wed Sep 30 12:01:23 2020 +0100 PR target/97150 AArch64: 2nd parameter of unsigned Neon scalar shift intrinsics should be signed In this PR the second argument to the intrinsics should be signed but we use an unsigned one erroneously. The corresponding builtins are already using the correct types so it's just a matter of correcting the signatures in arm_neon.h gcc/ PR target/97150 * config/aarch64/arm_neon.h (vqrshlb_u8): Make second argument signed. (vqrshlh_u16): Likewise. (vqrshls_u32): Likewise. (vqrshld_u64): Likewise. (vqshlb_u8): Likewise. (vqshlh_u16): Likewise. (vqshls_u32): Likewise. (vqshld_u64): Likewise. (vshld_u64): Likewise. gcc/testsuite/ PR target/97150 * gcc.target/aarch64/pr97150.c: New test. (cherry picked from commit 2d8fbebdb1eaca8de557ab3052535a8e4b8f8972)
[Bug target/96313] [AArch64] vqmovun* return types should be unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96313 --- Comment #7 from CVS Commits --- The releases/gcc-10 branch has been updated by Kyrylo Tkachov : https://gcc.gnu.org/g:7d177b142dcbe841124fe023cb592914d4200e57 commit r10-8868-g7d177b142dcbe841124fe023cb592914d4200e57 Author: Kyrylo Tkachov Date: Wed Sep 30 12:00:20 2020 +0100 PR target/96313 AArch64: vqmovun* return types should be unsigned In this PR we have the wrong return type for some intrinsics. It should be unsigned, but we implement it as signed. Fix this by adjusting the type qualifiers used when creating the builtins and fixing the type in the arm_neon.h intrinsic. With the adjustment in qualifiers we now don't need to cast the result when returning. Bootstrapped and tested on aarch64-none-linux-gnu. gcc/ PR target/96313 * config/aarch64/aarch64-simd-builtins.def (sqmovun): Use UNOPUS qualifiers. * config/aarch64/arm_neon.h (vqmovun_s16): Adjust builtin call. Remove unnecessary result cast. (vqmovun_s32): Likewise. (vqmovun_s64): Likewise. (vqmovunh_s16): Likewise. Fix return type. (vqmovuns_s32): Likewise. (vqmovund_s64): Likewise. gcc/testsuite/ PR target/96313 * gcc.target/aarch64/pr96313.c: New test. * gcc.target/aarch64/scalar_intrinsics.c (test_vqmovunh_s16): Adjust return type. (test_vqmovuns_s32): Likewise. (test_vqmovund_s64): Likewise. (cherry picked from commit 135b043196b5575c690ef1e07bcbb49bf037c3a2)
[Bug libstdc++/82584] div by zero in random distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82584 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |11.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jonathan Wakely --- $ g++11 rando.cc -D_GLIBCXX_ASSERTIONS $ ./a.out /home/jwakely/gcc/11/include/c++/11.0.0/bits/random.tcc:2633: void std::discrete_distribution<_IntType>::param_type::_M_initialize() [with _IntType = int]: Assertion '__sum > 0' failed. Aborted (core dumped)
[Bug libstdc++/82584] div by zero in random distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82584 --- Comment #3 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:b2a96bf9dce41ee777b1669e4a8b4c6df3ff3613 commit r11-3731-gb2a96bf9dce41ee777b1669e4a8b4c6df3ff3613 Author: Jonathan Wakely Date: Thu Oct 8 15:14:58 2020 +0100 libstdc++: Add assertions for preconditions in sampling distributions [PR 82584] These three distributions all require 0 < S where S is the sum of the weights. When the sum is zero there's an undefined FP division by zero. Add assertions to help users diagnose the problem. libstdc++-v3/ChangeLog: PR libstdc++/82584 * include/bits/random.tcc (discrete_distribution::param_type::_M_initialize) (piecewise_constant_distribution::param_type::_M_initialize) (piecewise_linear_distribution::param_type::_M_initialize): Add assertions for positive sums.. * testsuite/26_numerics/random/pr60037-neg.cc: Adjust dg-error line.
[Bug gcov-profile/90439] [GCOV] multiple expression across different lines in if statement is inconsistent when the body is empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90439 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Yes, it behaves the same also in GCC 7.x.
[Bug libstdc++/82584] div by zero in random distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82584 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Jonathan Wakely --- This is user error. [rand.dist.samp.discrete] p2 says: > Moreover, the following relation shall hold: 0 < S = w0 + · · · + wn−1 . So there must be at least one non-zero weight. I'll add an assertion.
[Bug target/96914] missing MVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96914 Christophe Lyon changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Christophe Lyon --- Fixed on trunk
[Bug target/96914] missing MVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96914 --- Comment #9 from CVS Commits --- The master branch has been updated by Christophe Lyon : https://gcc.gnu.org/g:5a448362da6133c3b16ffdb0c795b657af7fa5a4 commit r11-3730-g5a448362da6133c3b16ffdb0c795b657af7fa5a4 Author: Christophe Lyon Date: Mon Oct 5 09:52:59 2020 + arm: [MVE] Add missing __arm_vcvtnq_u32_f32 intrinsic (PR 96914) __arm_vcvtnq_u32_f32 was missing from arm_mve.h, although the s32_f32 and [su]16_f16 versions were present. This patch adds the missing version and testcase, which are cut-and-paste from the other versions. 2020-10-08 Christophe Lyon gcc/ PR target/96914 * config/arm/arm_mve.h (__arm_vcvtnq_u32_f32): New. gcc/testsuite/ PR target/96914 * gcc.target/arm/mve/intrinsics/vcvtnq_u32_f32.c: New test.
[Bug libstdc++/86402] Several targets missing AC_DEFINE(_GLIBCXX_USE_RANDOM_TR1) in crossconfig.m4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86402 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2020-10-08 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug libstdc++/70358] Several 26_numerics/random/binomial_distribution/operators etc. tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70358 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2020-10-08 Target Milestone|5.5 |--- Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- Rainer, what's the status of this one? Are those tests still UNSUPPORTED, or now PASSing?
[Bug libstdc++/82584] div by zero in random distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82584 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-10-08 Status|UNCONFIRMED |NEW
[Bug libstdc++/63332] problem with VERIFY in ext/random/k_distribution/operators/serialize.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63332 Jonathan Wakely changed: What|Removed |Added Target||i386-pc-solaris2.11 CC||ro at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2020-10-08 --- Comment #10 from Jonathan Wakely --- Looks like this is still failing for solaris 11: https://gcc.gnu.org/pipermail/gcc-testresults/2020-October/610818.html
[Bug go/92564] libgo regression in runtime test resulting in SIGSEGV on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92564 --- Comment #3 from boger at gcc dot gnu.org --- Yes, I tried the value of 0x8 and the test passed. In the issue Ian mentioned that 0x10 was the default on x86. If we want the same default on x86 and ppc64 then 0x10 would work since the value I tested with is smaller.
[Bug c++/97328] [10/11 Regression] ICE in verify_ctor_sanity, at cp/constexpr.c:3995 since r10-7313-gb599bf9d6d1e180d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97328 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug target/97203] [nvptx] 'illegal memory access was encountered' with 'omp simd'/SIMT and cexpf call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97203
--- Comment #3 from Tom de Vries ---
[ Note, this is with GOMP_NVPTX_JIT=-O0. ]
In sinf, we have:
...
45:return -__kernel_cosf(y[0],y[1]);
...
which translates to:
...
.loc 1 45 12
ld.f32 %r67,[%frame+4];
ld.f32 %r65,[%frame];
{
.param .f32 %value_in;
.param .f32 %out_arg1;
st.param.f32 [%out_arg1],%r65;
.param .f32 %out_arg2;
st.param.f32 [%out_arg2],%r67;
call (%value_in),__kernel_cosf,(%out_arg1,%out_arg2);
ld.param.f32 %r68,[%value_in];
}
.loc 1 45 11
neg.f32 %r37,%r68;
...
If I place (using GOMP_NVPTX_PTXRW) a trap before the first load:
...
.loc 1 45 12
+trap
ld.f32 %r67,[%frame+4];
...
I get:
...
libgomp: cuCtxSynchronize error: an illegal instruction was encountered
...
If I place it after the first load, I get:
...
libgomp: cuCtxSynchronize error: an illegal memory access was encountered
...
[Bug ipa/97335] [11 Regression] 525.x264_r fails with -Ofast -g -march=znver2 -flto=16 since r11-3641-gc34db4b6f8a5d803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97335 --- Comment #1 from Martin Liška --- With -O3 -g -flto=16 --param=lto-partitions=1, the first bad binary is with -fdbg-cnt=ipa_mod_ref:1046. It seems a misc tool fails with: ./ldecod_r -i BuckBunny.264 -o BuckBunny.yuv Setting Default Parameters... Parsing Configfile decoder.cfg - JM 17.1 (FRExt) - -- Input H.264 bitstream : BuckBunny.264 Output decoded YUV : BuckBunny.yuv Input reference file : test_rec.yuv -- POC must = frame# or field# for SNRs to be correct -- Frame POC Pic# QPSnrY SnrU SnrV Y:U:V Time(ms) -- Input reference file : test_rec.yuv does not exist SNR values are not available 0(IDR)0 028 4:2:0 0 2( P )4 131 4:2:0 0 1( b )2 231 4:2:0 0 3( I )6 228 4:2:0 0 6( P ) 12 428 4:2:0 0 mb_qp_delta is out of range PRE dump files: https://drive.google.com/file/d/1GzqkYP4PRtXVkVbvGGJUukz8-9ay-uMy/view?usp=sharing
[Bug gcov-profile/90439] [GCOV] multiple expression across different lines in if statement is inconsistent when the body is empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90439 Sunil Kumar changed: What|Removed |Added CC||sunil.kumar3 at ltts dot com --- Comment #1 from Sunil Kumar --- I have a query. Will this issue is applicable for GCC 7.4.0 ?
[Bug ipa/97292] [11 Regression] dealII from SPECCPU 2016 no longer terminates after g:c34db4b6f8a5d80367c709309f9b00cb32630054
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292 --- Comment #10 from Martin Liška --- Good PRE dump file with details: https://drive.google.com/file/d/114AAhbNKeiJ7w3FYOcumdpnnMCNvdjiy/view?usp=sharing Bad PRE dump file with details: https://drive.google.com/file/d/14_dV-FYSe1j0Sx-zIc8d_6ypuFcmPnZl/view?usp=sharing
[Bug tree-optimization/97330] [11 Regression] ice for stmt with wrong VUSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97330 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:629e0547af33221a925f38757b52a9284148b68a commit r11-3726-g629e0547af33221a925f38757b52a9284148b68a Author: Richard Biener Date: Thu Oct 8 13:18:57 2020 +0200 tree-optimization/97330 - fix bad load sinking This fixes bad placement of sunk loads. 2020-10-08 Richard Biener PR tree-optimization/97330 * tree-ssa-sink.c (statement_sink_location): Avoid skipping PHIs when they dominate the insert location. * gcc.dg/torture/pr97330-1.c: New testcase. * gcc.dg/torture/pr97330-2.c: Likewise.
[Bug tree-optimization/97330] [11 Regression] ice for stmt with wrong VUSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97330 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Biener --- Fixed.
[Bug ipa/97292] [11 Regression] dealII from SPECCPU 2016 no longer terminates after g:c34db4b6f8a5d80367c709309f9b00cb32630054
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292 --- Comment #9 from Martin Liška --- Created attachment 49330 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49330=edit Bad PRE dump file
[Bug ipa/97292] [11 Regression] dealII from SPECCPU 2016 no longer terminates after g:c34db4b6f8a5d80367c709309f9b00cb32630054
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292 --- Comment #8 from Martin Liška --- Created attachment 49329 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49329=edit Good PRE dump file
[Bug tree-optimization/97330] [11 Regression] ice for stmt with wrong VUSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97330 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #4 from Martin Liška --- Just for the record, started with r11-3705-gdae673abd37d4004.
[Bug c++/97328] [10/11 Regression] ICE in verify_ctor_sanity, at cp/constexpr.c:3995 since r10-7313-gb599bf9d6d1e180d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97328 Martin Liška changed: What|Removed |Added Last reconfirmed||2020-10-08 Status|UNCONFIRMED |NEW Summary|[ICE] internal compiler |[10/11 Regression] ICE in |error: in |verify_ctor_sanity, at |verify_ctor_sanity, at |cp/constexpr.c:3995 since |cp/constexpr.c:3995 |r10-7313-gb599bf9d6d1e180d CC||marxin at gcc dot gnu.org, ||ppalka at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with r10-7313-gb599bf9d6d1e180d.
[Bug c++/97328] [10/11 Regression] ICE in verify_ctor_sanity, at cp/constexpr.c:3995 since r10-7313-gb599bf9d6d1e180d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97328 Martin Liška changed: What|Removed |Added Target Milestone|--- |10.3 Known to work||9.3.0 Known to fail||10.2.0, 11.0
[Bug target/97324] -mcpu= isn't validated on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97324 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED CC||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Well for GCC 11 we provide: gcc: warning: ‘-mcpu=’ is deprecated; use ‘-mtune=’ or ‘-march=’ instead cc1: error: bad value (‘sdfdsf’) for ‘-mtune=’ switch cc1: note: valid arguments to ‘-mtune=’ switch are: nocona core2 nehalem corei7 westmere sandybridge corei7-avx ivybridge core-avx-i haswell core-avx2 broadwell skylake skylake-avx512 cannonlake icelake-client icelake-server cascadelake tigerlake cooperlake sapphirerapids alderlake bonnell atom silvermont slm goldmont goldmont-plus tremont knl knm intel x86-64 eden-x2 nano nano-1000 nano-2000 nano-3000 nano-x2 eden-x4 nano-x4 k8 k8-sse3 opteron opteron-sse3 athlon64 athlon64-sse3 athlon-fx amdfam10 barcelona bdver1 bdver2 bdver3 bdver4 znver1 znver2 btver1 btver2 generic native So -mcpu is deprecated and we print valid values for -mtune argument. Fixed on master with r11-2755-ga7bbb5b1b1eb09db.
