[Bug target/96857] [11 Regression] FAIL: gcc.target/i386/avx512bw-pr95488-1.c scan-assembler-times vpmullw[^\n]*zmm 2 on Linux/x86_64 (-m64 -march=cascadelake)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96857 Richard Biener changed: What|Removed |Added Summary|[r11-1301 Regression] FAIL: |[11 Regression] FAIL: |gcc.target/i386/avx512bw-pr |gcc.target/i386/avx512bw-pr |95488-1.c |95488-1.c |scan-assembler-times|scan-assembler-times |vpmullw[^\n]*zmm 2 on |vpmullw[^\n]*zmm 2 on |Linux/x86_64 (-m64 |Linux/x86_64 (-m64 |-march=cascadelake) |-march=cascadelake) Target Milestone|--- |11.0
[Bug target/96855] [11 Regression] r11-571 regression FAIL: gcc.target/i386/pr92658-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96855 Richard Biener changed: What|Removed |Added Summary|r11-571 regression FAIL:|[11 Regression] r11-571 |gcc.target/i386/pr92658-1.c |regression FAIL: ||gcc.target/i386/pr92658-1.c Target Milestone|--- |11.0
[Bug target/96856] [11 Regression] FAIL: gcc.target/i386/pr92645-4.c scan-tree-dump-times optimized "VEC_PACK_TRUNC" 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96856 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0 Summary|[r11-571 Regression] FAIL: |[11 Regression] FAIL: |gcc.target/i386/pr92645-4.c |gcc.target/i386/pr92645-4.c |scan-tree-dump-times|scan-tree-dump-times |optimized "VEC_PACK_TRUNC" |optimized "VEC_PACK_TRUNC" |1 |1
[Bug fortran/94672] [10/11 Regression] gfortran/OpenMP chokes on PRESENT(array) despite of SHARED(array): Error: ‘array’ not specified in enclosing ‘parallel’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94672 --- Comment #15 from Tobias Burnus --- (In reply to Tomáš Trnka from comment #12) > The fix for this broke assumed length optional character arguments. I have > noticed this on 10.2.1 20200723, which is currently used by Fedora 32. Thanks for the report – this follow-up regression has now been fixed for mainline (GCC 11) and on the GCC 10 branch. → FIXED. (Bug state actually unchanged as it wasn't reopened.)
[Bug target/96854] [10 Regression] avx vectorizer breaks complex arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96854
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords||needs-bisection
Known to fail||10.1.0, 10.2.0
Known to work||11.0, 9.3.0
Ever confirmed|0 |1
Target Milestone|--- |10.3
Last reconfirmed||2020-08-31
Target||x86_64-*-* i?86-*-*
Summary|avx vectorizer breaks |[10 Regression] avx
|complex arithmetic |vectorizer breaks complex
||arithmetic
CC||rguenth at gcc dot gnu.org
--- Comment #1 from Richard Biener ---
#include
double complex __attribute__((noipa))
foo(double complex acc, const double complex *x, const double complex* y, int
N)
{
for (int c = 0; c < N; ++c)
acc -= x[c] * y[c];
return acc;
}
int main(void)
{
static const double complex y[] = { 1, 2, };
static const double complex x[] = { 1, 3, };
double complex ref = foo(0, x, y, 2); // reference
if (creal(ref) != -7.)
__builtin_abort ();
return 0;
}
Confirmed with GCC 10.2, it works on trunk and with GCC 9.3.0.
It doesn't need any -march for me, just -Ofast -mavx is enough.
[Bug fortran/96859] New: Wrong answer with intrinsic merge_bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96859 Bug ID: 96859 Summary: Wrong answer with intrinsic merge_bits Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: zhen...@compiler-dev.com Target Milestone: --- wrong result with compiled code such as: merge_bits(32767_2, o'1234567', 32767_2) merge_bits(o'1234567', 32767_2, o'1234567') merge_bits(32767_2, o'1234567', b'010101') merge_bits(32767_2, o'1234567', z'12345678')
[Bug c++/96840] [11 Regression] Recursive substitution in constrained commutative operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96840 Richard Biener changed: What|Removed |Added Keywords||rejects-valid Target Milestone|--- |11.0 Summary|Recursive substitution in |[11 Regression] Recursive |constrained commutative |substitution in constrained |operator|commutative operator
[Bug analyzer/96841] [11 Regression] ICE: tree check: expected integer_cst, have nop_expr in to_wide, at tree.h:5904
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96841 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |11.0
[Bug fortran/94672] [10/11 Regression] gfortran/OpenMP chokes on PRESENT(array) despite of SHARED(array): Error: ‘array’ not specified in enclosing ‘parallel’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94672 --- Comment #14 from CVS Commits --- The releases/gcc-10 branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:ac4f77d2563828324bb6a4f08b52aae3410702ea commit r10-8691-gac4f77d2563828324bb6a4f08b52aae3410702ea Author: Tobias Burnus Date: Fri Aug 28 13:54:10 2020 +0200 Fortran: Fix absent-optional handling for nondescriptor arrays (PR94672) gcc/fortran/ChangeLog: PR fortran/94672 * trans-array.c (gfc_trans_g77_array): Check against the parm decl and set the nonparm decl used for the is-present check to NULL if absent. gcc/testsuite/ChangeLog: PR fortran/94672 * gfortran.dg/optional_assumed_charlen_2.f90: New test. (cherry picked from commit cb3c3d63315ceb4dc262e5efb83b42c73c43387d)
[Bug c/96858] New: Many i386 testcases failed with different configured gcc on different hosts.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96858 Bug ID: 96858 Summary: Many i386 testcases failed with different configured gcc on different hosts. Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: crazylht at gmail dot com CC: hjl.tools at gmail dot com Target Milestone: --- Created attachment 49158 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49158&action=edit compare_tests result for default arch -march=skylake-avx512 vs -march=x86-64 on i386 backend testcases For gcc version 11.0.0 20200831 (experimental) (GCC) If gcc is built with default config, there's no unexpected failures for all i386 backend testcases. but when gcc is built with --with-arch=skylake-avx512, there would be lots of unexpected failures --- Tests that now fail, but worked before (469 tests): --- It would be nice to adjust those testcases as we have regression tests for i386 backend with different gcc config.
[Bug target/96789] x264: sub4x4_dct() improves when vectorization is disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96789
Kewen Lin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
--- Comment #6 from Kewen Lin ---
(In reply to Richard Biener from comment #4)
> This delays some checks to eventually support part of the BB vectorization
> which is what succeeds here. I suspect that w/o vectorization we manage
> to elide the tmp[] array but with the part vectorization that occurs we
> fail to do that.
>
> On the cost side there would be a lot needed to make the vectorization
> not profitable:
>
> Vector inside of basic block cost: 8
> Vector prologue cost: 36
> Vector epilogue cost: 0
> Scalar cost of basic block: 64
>
> the thing to double-check is
>
> 0x123b1ff0 1 times vec_construct costs 17 in prologue
>
> that is the cost of the V16QI construct
>
> _813 = {_437, _448, _459, _470, _490, _501, _512, _523, _543, _554, _565,
> _576, _125, _143, _161, _179};
>
Thanks Richard! I did some cost adjustment experiment last year and the cost
for v16qi looks off indeed, but at that time with the cost tweaking for this
the SPEC performance doesn't change, I guessed it's just we happened not have
this kind of case to trap into. I'll have a look and re-evaluate it for this.
[Bug target/96855] r11-571 regression FAIL: gcc.target/i386/pr92658-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96855 --- Comment #2 from Hongtao.liu --- (In reply to Hongtao.liu from comment #1) > Add -mprefer-vector-width=512 to avoid impact of different failure. Typo: different mtune.
[Bug target/96855] r11-571 regression FAIL: gcc.target/i386/pr92658-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96855 --- Comment #1 from Hongtao.liu --- Add -mprefer-vector-width=512 to avoid impact of different failure.
[Bug target/96857] New: [r11-1301 Regression] FAIL: gcc.target/i386/avx512bw-pr95488-1.c scan-assembler-times vpmullw[^\n]*zmm 2 on Linux/x86_64 (-m64 -march=cascadelake)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96857
Bug ID: 96857
Summary: [r11-1301 Regression] FAIL:
gcc.target/i386/avx512bw-pr95488-1.c
scan-assembler-times vpmullw[^\n]*zmm 2 on
Linux/x86_64 (-m64 -march=cascadelake)
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: crazylht at gmail dot com
Target Milestone: ---
Target: x86_64-*-* i?86-*-*
On Linux/x86_64,
54cdb2f5a5b01a482d7cbce30e7b738558eecf59 is the first bad commit commit
54cdb2f5a5b01a482d7cbce30e7b738558eecf59
Author: liuhongt
Date: Wed Jun 3 17:25:47 2020 +0800
Optimize multiplication for V8QI,V16QI,V32QI under TARGET_AVX512BW.
caused
FAIL: gcc.target/i386/avx512bw-pr95488-1.c scan-assembler-times vpmovwb 2
FAIL: gcc.target/i386/avx512bw-pr95488-1.c scan-assembler-times vpmovzxbw 4
FAIL: gcc.target/i386/avx512bw-pr95488-1.c scan-assembler-times
vpmullw[^\n]*zmm 2
with GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-1301/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl
--enable-libmpx x86_64-linux --disable-bootstrap
To reproduce:
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx512bw-pr95488-1.c
--target_board='unix{-m64\ -march=cascadelake}'"
(Please do not reply to this email, for question about this report, contact me
at skpgkp2 at gmail dot com)
[Bug target/96856] New: [r11-571 Regression] FAIL: gcc.target/i386/pr92645-4.c scan-tree-dump-times optimized "VEC_PACK_TRUNC" 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96856
Bug ID: 96856
Summary: [r11-571 Regression] FAIL: gcc.target/i386/pr92645-4.c
scan-tree-dump-times optimized "VEC_PACK_TRUNC" 1
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: crazylht at gmail dot com
Target Milestone: ---
Target: x86_64-*-* i?86-*-*
On Linux/x86_64,
e740f3d73144abbca1ad98a04825c6bd63314a0b is the first bad commit commit
e740f3d73144abbca1ad98a04825c6bd63314a0b
Author: liuhongt
Date: Wed May 20 15:53:14 2020 +0800
Add missing vector truncmn2 expanders [PR92658]
caused
FAIL: gcc.target/i386/pr92645-4.c scan-tree-dump-times optimized
"BIT_FIELD_REF" 2
FAIL: gcc.target/i386/pr92645-4.c scan-tree-dump-times optimized
"VEC_PACK_TRUNC" 1
with GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-571/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl
--enable-libmpx x86_64-linux --disable-bootstrap
To reproduce:
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/pr92645-4.c --target_board='unix{-m64\
-march=cascadelake}'"
(Please do not reply to this email, for question about this report, contact me
at skpgkp2 at gmail dot com)
[Bug target/96855] New: r11-571 regression FAIL: gcc.target/i386/pr92658-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96855
Bug ID: 96855
Summary: r11-571 regression FAIL: gcc.target/i386/pr92658-1.c
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: crazylht at gmail dot com
Target Milestone: ---
Target: x86_64-*-* i?86-*-*
On Linux/x86_64,
e740f3d73144abbca1ad98a04825c6bd63314a0b is the first bad commit commit
e740f3d73144abbca1ad98a04825c6bd63314a0b
Author: liuhongt
Date: Wed May 20 15:53:14 2020 +0800
Add missing vector truncmn2 expanders [PR92658]
caused
FAIL: gcc.target/i386/pr92658-avx512f.c scan-assembler-times vpmovdb 1
FAIL: gcc.target/i386/pr92658-avx512f.c scan-assembler-times vpmovdw 1
FAIL: gcc.target/i386/pr92658-avx512f.c scan-assembler-times vpmovqd 1
FAIL: gcc.target/i386/pr92658-avx512f.c scan-assembler-times vpmovqw 1
with GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-571/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl
--enable-libmpx x86_64-linux --disable-bootstrap
To reproduce:
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/pr92658-avx512f.c
--target_board='unix{-m64\ -march=cascadelake}'"
[Bug target/96551] [10/11 Regression] FAIL: gcc.target/i386/vectorize8.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96551 --- Comment #3 from Hongtao.liu --- a patch is posted at https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552230.html
[Bug target/96849] [11 Regression] ICE: in extract_insn, at recog.c:2294 (error: unrecognizable insn) since r11-2623
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96849 Hongtao.liu changed: What|Removed |Added CC||crazylht at gmail dot com --- Comment #3 from Hongtao.liu --- I think it's duplicated as PR96551, a patch is posted at https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552230.html same fix.
[Bug tree-optimization/96669] Failure to optimize shift by variable+and by 1 to test for 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96669 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/96672] Missing -Wclobbered diagnostic, or: __attribute__((returns_twice)) does not inhibit constant folding across call site
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96672 --- Comment #3 from Andrew Pinski --- Most likely the patch which moves the warning to gimple would help here: https://gcc.gnu.org/pipermail/gcc-patches/2019-October/530995.html But I have not seen any movement on it since last year but I could be wrong.
[Bug tree-optimization/96674] Failure to optimize combination of comparisons to dec+compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96674 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Keywords||easyhack
[Bug tree-optimization/96807] Division by zero produces zero with gcc -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96807 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- >Instead of giving division by zero or infinity, it gives zero. Is that even defined in Fortran, I think the answer is NO. so closing as invalid.
[Bug target/96854] New: avx vectorizer breaks complex arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96854
Bug ID: 96854
Summary: avx vectorizer breaks complex arithmetic
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: ---
'-Ofast -mavx -march=ivybridge' miscompiles this simple loop:
double complex foo(double complex acc, const double complex *x, const double
complex* y, int N)
{
for (int c = 0; c < N; ++c)
acc -= x[c] * y[c];
return acc;
}
The bug appears to be triggered by -fassociative-math, but it could be a
trigger rather than the reason.
You can find a reproducer here:
https://github.com/already5chosen/others/tree/master/cholesky_solver/gcc-bug
I only tried with MSYS2 variant of gcc 10.2.0
[Bug c++/96853] New: Explicit template instantiation & thread_local interaction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96853
Bug ID: 96853
Summary: Explicit template instantiation & thread_local
interaction
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tobias.bruell at gmail dot com
Target Milestone: ---
Compiling the below with
> g++-10 main.cpp library.cpp -o main
in gcc 10.1 leads to an executable "main" that segfaults. The problem seems to
be that the out-commented "extern" declarations in library.hpp are missing.
So, the program might be UB, but it would be nice to get an error message from
the compiler (as Clang does).
Otherwise, the linker could give an error: the final executable "main" contains
a "callq 0x0" instruction (on x86_64) if you also add "-static" to the above
command-line. I think the problem is that "_ZTHN7library3FooIiE1fE" (TLS init
function for library::Foo::f) is missing from any of the intermediate
object files.
- library.hpp --
#ifndef INCLUDE_GUARD_LIBRARY_H_
#define INCLUDE_GUARD_LIBRARY_H_
namespace library
{
template
struct Foo
{
using Func = T (*) (T);
static thread_local Func f;
};
//extern template struct Foo;
//extern template struct Foo;
//extern template struct Foo;
}
#endif
---
- library.cpp -
#include "library.hpp"
namespace library
{
template
T core_function (T val)
{
return val * 2;
}
template
thread_local
typename Foo::Func
Foo::f = &core_function;
template struct Foo;
template struct Foo;
template struct Foo;
}
--- main.cpp ---
#include "library.hpp"
int main () {
return library::Foo::f(2);
}
[Bug libgomp/96837] A false if clause in "omp parallel" seriously affects the performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96837 --- Comment #3 from Jakub Jelinek --- The standard describes in detail what parallel if (false) creates, and what the various APIs should return for that. It does create a parallel region, albeit an inactive one. So, e.g. for the question whether threadprivate needs to be preserved between parallel regions with the same number of threads etc. if they are nested in an explicit inactive parallel, the answer is no.
[Bug libgomp/96837] A false if clause in "omp parallel" seriously affects the performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96837 --- Comment #2 from Olaf Krzikalla --- This raises the question, if a false "if" clause creates a parallel region anyway. I haven't found a explicit statement in the OpenMP standard. However note, that the assertion "!omp_in_parallel()" in my example holds for a false if-clause. Thus, for an observer there is no nested parallelism involved. Conclusion: in one way or another libgomp does something wrong here. Either it creates a parallel region but returns false for omp_in_parallel(), or it doesn't create a parallel region, but doesn't behave like it. >From a user perspective I'd like to have a behavior, which just ignores a openmp statement, if the "if" clause resolves to false. This means for the current case, that no parallel region is created (and nothing happens internally, too) and omp_in_parallel() returns false.
[Bug c++/66360] thread_local variable needs copy constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66360 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #3 from Eric Gallager --- (In reply to Andrew Pinski from comment #1) > This has nothing to do with thread_local. That is removing static > thread_local still causes it to produce an error. > OK so how would you suggest retitling this, then?
[Bug c++/67135] [thread_local] heap-use-after-free (OS X 10.10.4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67135 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Eric Gallager --- (In reply to Toby Brull from comment #1) > This seems to be fixed from version 5.3 on. > > Was able to confirm the bug in gcc 5.2 via wandbox.org (although it failed > there with a different ASAN error). > > Testing on wandbox.org, this worked for gcc version: > 5.3, > 6.1, 6.2, 6.3, > 7.1, 7.3, > 8.1, 8.3, > 9.3, > 10.1 > > Also worked on my local ubuntu gcc installs (6.5, 7.5, 8.4, 10.1). > > So should probably be closed? Pretty sure my last compile of gcc was without sanitizer support, so I can't confirm for myself, but I'll take your word for it and close it anyways.
[Bug c++/59994] [meta-bug] thread_local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59994 Bug 59994 depends on bug 67135, which changed state. Bug 67135 Summary: [thread_local] heap-use-after-free (OS X 10.10.4) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67135 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c/96842] enhancement: copy clang Wheader-guard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96842 Eric Gallager changed: What|Removed |Added Keywords||diagnostic Blocks||87403 Last reconfirmed||2020-08-30 CC||egallager at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Eric Gallager --- confirmed that this warning would be nice to have. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 [Bug 87403] [Meta-bug] Issues that suggest a new warning
[Bug middle-end/96838] missing warning on integer overflow in calls to allocation functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96838
Eric Gallager changed:
What|Removed |Added
Last reconfirmed||2020-08-30
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
CC||egallager at gcc dot gnu.org
--- Comment #1 from Eric Gallager ---
Hm, I thought by enabling more warning options I could get a warning from one
of the other ones, but, I guess not:
$ /usr/local/bin/gcc -O2 -S -Wall -Wextra -pedantic -Wlarger-than=12345
-Walloc-size-larger-than=12345 -Wformat-overflow=2 -Wstringop-overflow=4
-Wshift-overflow=2 -Wstrict-overflow=5 -fdump-tree-optimized=/dev/stdout
96838.c
;; Function f (f, funcdef_no=0, decl_uid=1913, cgraph_uid=1, symbol_order=0)
f (size_t n)
{
void * p;
int _1;
[local count: 1073741824]:
n_3 = MAX_EXPR ;
_1 = (int) n_3;
p_6 = salloc (_1);
__builtin_memset (p_6, 0, n_3);
return p_6;
}
;; Function g (g, funcdef_no=1, decl_uid=1917, cgraph_uid=2, symbol_order=1)
g (size_t n)
{
void * p;
unsigned int _1;
[local count: 1073741824]:
n_3 = MAX_EXPR ;
_1 = (unsigned int) n_3;
p_6 = ualloc (_1);
__builtin_memset (p_6, 0, n_3);
return p_6;
}
$
So, confirmed.
[Bug c++/81880] thread_local static member template initialisation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81880
Toby Brull changed:
What|Removed |Added
CC||tobias.bruell at gmail dot com
--- Comment #3 from Toby Brull ---
I played around a bit with gcc, and it looks like the example can be made to
work via the following diff:
---
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 639b00264d8..f6b10174f1b 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -3898,6 +3898,8 @@ finish_id_expression_1 (tree id_expression,
decl = finish_template_variable (decl);
mark_used (decl);
decl = convert_from_reference (decl);
+ if (tree wrap = maybe_get_tls_wrapper_call (decl))
+ decl = wrap;
}
else if (concept_check_p (decl))
{
---
Not sure if this makes sense, though, in the greater scheme of things. So I'll
just leave that here FYI.
[Bug libstdc++/96850] format missing from std
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96850 --- Comment #2 from Jonathan Wakely --- Yes, as documented. And also stated at https://en.cppreference.com/w/cpp/compiler_support
[Bug c++/96852] New: Missing diagnostic message for friend declaration with wrong number of template arguments.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96852
Bug ID: 96852
Summary: Missing diagnostic message for friend declaration with
wrong number of template arguments.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Program (main.cpp):
template
class A
{
};
class B
{
template
friend class ::A;
};
int main()
{
}
Compilation command line:
g++ -std=c++17 -pedantic-errors main.cpp
Observed behaviour:
No compilation errors.
Expected behaviour:
Compilation error about using the wrong number of template arguments in the
firend declaration.
Note:
clang++ gives the expected error message.
[Bug target/96849] [11 Regression] ICE: in extract_insn, at recog.c:2294 (error: unrecognizable insn) since r11-2623
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96849 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 49157 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49157&action=edit gcc11-pr96849.patch Untested fix.
[Bug target/96849] [11 Regression] ICE: in extract_insn, at recog.c:2294 (error: unrecognizable insn) since r11-2623
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96849 Jakub Jelinek changed: What|Removed |Added Summary|[11 Regression] ICE: in |[11 Regression] ICE: in |extract_insn, at|extract_insn, at |recog.c:2294 (error:|recog.c:2294 (error: |unrecognizable insn)|unrecognizable insn) since ||r11-2623 Target Milestone|--- |11.0 CC||jakub at gcc dot gnu.org, ||liuhongt at gcc dot gnu.org Last reconfirmed||2020-08-30 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r11-2623-g99e4891ed552aca4ca147671701edd0b31015f66
[Bug tree-optimization/96820] ICE in verify_sra_access_forest with array and out of bounds reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96820 Martin Jambor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot gnu.org --- Comment #6 from Martin Jambor --- I proposed a fix on the mailing list: https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552900.html
[Bug d/96157] d: No NRVO when returning an array of a non-POD struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96157 --- Comment #4 from CVS Commits --- The releases/gcc-10 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:b30aeaa173b6886cda15570a2e23eac1136665bf commit r10-8689-gb30aeaa173b6886cda15570a2e23eac1136665bf Author: Iain Buclaw Date: Tue Aug 25 00:39:17 2020 +0200 d: Fix no NRVO when returning an array of a non-POD struct TREE_ADDRESSABLE was not propagated from the RECORD_TYPE to the ARRAY_TYPE, so NRVO code generation was not being triggered. gcc/d/ChangeLog: PR d/96157 * d-codegen.cc (d_build_call): Handle TREE_ADDRESSABLE static arrays. * types.cc (make_array_type): Propagate TREE_ADDRESSABLE from base type to static array. gcc/testsuite/ChangeLog: PR d/96157 * gdc.dg/pr96157a.d: New test. * gdc.dg/pr96157b.d: New test. (cherry picked from commit 312ad889e99ff9458c01518325775e75ab57f272)
[Bug libstdc++/96851] operator< on std::array does not work in constexpr, for sizeof(T) == 1, and N > 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96851 --- Comment #1 from milasudril at gmail dot com --- Apparently, std::lexicographical_compare works https://gcc.godbolt.org/z/E1ETh1
[Bug libstdc++/96851] New: operator< on std::array does not work in constexpr, for sizeof(T) == 1, and N > 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96851
Bug ID: 96851
Summary: operator< on std::array does not work in
constexpr, for sizeof(T) == 1, and N > 1
Product: gcc
Version: 10.1.0
URL: https://gcc.godbolt.org/z/vjvYE5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: milasudril at gmail dot com
Target Milestone: ---
It appears that `operator<` on `std::array` does not work in constexpr
context, for `sizeof(T) == 1`, and `N > 1`. I tried different `T`and `N`
combinations, and it appears that these work.
MWE:
#include
#include
#include
template
constexpr bool test(std::array const& a, std::array const& b)
{
return a < b;
}
using Type = int8_t;
constexpr auto Count = 2;
// Below does not compile
constexpr auto value = test(std::array{}, std::array{});
The problem exists in gcc 10.1 and trunk.
/opt/compiler-explorer/gcc-trunk-20200830/include/c++/11.0.0/array:262:32:
error: '__builtin_memcmp(((std::array::const_pointer)(&.std::array::_M_elems)),
((std::array::const_pointer)(&.std::array::_M_elems)), 2)' is not a constant expression
262 | return __builtin_memcmp(__a.data(), __b.data(), _Nm) <=> 0;
Godbolt url: https://gcc.godbolt.org/z/vjvYE5
[Bug c++/96850] format missing from std
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96850 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- As documented in https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2020 ?
[Bug c++/96850] New: format missing from std
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96850
Bug ID: 96850
Summary: format missing from std
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: michel at lebihan dot pl
Target Milestone: ---
Hello,
std::format (https://en.cppreference.com/w/cpp/utility/format/format) was added
in C++20. When I try to compile the provided example:
```
#include
#include
int main() {
std::cout << std::format("Hello {}!\n", "world");
}
```
I get the error:
```
g++ -std=c++20 main.cpp
main.cpp:2:10: fatal error: format: No such file or directory
2 | #include
| ^~~~
compilation terminated.
```
It seems that this feature hasn't been implemented in gcc yet.
[Bug target/96847] Code size increase +42% depending on memory size allocated on stack for ARM Cortex-M3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96847 --- Comment #1 from Andrew Pinski --- Looks like there is some IV-OPTs issue and that the limited registers is causing spilling and that add range is causing the need for more register usage.
