[Bug target/54412] minimal 32-byte stack alignment with -mavx on 64-bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412 Dmitry Kazakov changed: What|Removed |Added CC||dimula73 at gmail dot com --- Comment #31 from Dmitry Kazakov --- Hi, all! Just wanted to note that the bug is still present in GCC 10.3.0 on Windows (from MSYS-MinGW64 packages). > gcc (Rev5, Built by MSYS2 project) 10.3.0
[Bug target/98934] Very poor code generation for SSE 8-bit vector right shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98934 --- Comment #3 from Andrew Pinski --- *** Bug 98399 has been marked as a duplicate of this bug. ***
[Bug target/98399] x86: Awful code generation for shifting vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98399 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Andrew Pinski --- This is a dup of bug 98934. The issues are the same except for &1. *** This bug has been marked as a duplicate of bug 98934 ***
[Bug target/98934] Very poor code generation for SSE 8-bit vector right shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98934
--- Comment #2 from Andrew Pinski ---
This is really poor with -mavx512f even. We should be able to do it like (which
is what LLVM does):
vpmovzxbd %xmm1, %zmm1
vpmovzxbd %xmm0, %zmm0
vpsravd %zmm1, %zmm0, %zmm0
vpmovdb %zmm0, %xmm0
Basically zero extend it out to from char to int and then do the shift and then
truncate back down to char.
Which we can emulate:
typedef char __attribute__((vector_size(16))) v16i8;
typedef int __attribute__((vector_size(16*sizeof(int v16i32;
typedef int __attribute__((vector_size(4*sizeof(int v4i32;
typedef char __attribute__((vector_size(4))) v4i8;
v16i8 f1(v16i8 x, v16i8 y)
{
v16i32 x1, y1;
x1 = __builtin_convertvector(x, __typeof(x1));
y1 = __builtin_convertvector(y, __typeof(y1));
x1 = x1 >> y1;
x = __builtin_convertvector(x1, __typeof(x));
return x;
}
[Bug tree-optimization/101895] [11/12 Regression] SLP Vectorizer change pushes VEC_PERM_EXPR into bad location spoiling further optimization opportunities
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101895 --- Comment #3 from Jeffrey A. Law --- Understood WRT phase ordering. That was fully expected. What I still don't understand is why moving the permute down is profitable here or generally why moving a permute into a dependency chain is profitable. ISTM that hoisting a permute up a dependency chain so that it's fed by a load is profitable. Similarly sinking a permute to the end of a dependency chain so that it feeds a store is profitable. Moving a permute so that it feeds or is fed by another permute is probably profitable too. Otherwise moving a permute into the middle of a dependency chain seems like a pessimization.
[Bug target/77287] Much worse code generated compared to clang (stack alignment and spills)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77287 --- Comment #12 from Hongtao.liu --- (In reply to Hongtao.liu from comment #11) > (In reply to Andrew Pinski from comment #10) > > (In reply to Andrew Pinski from comment #9) > > > (In reply to Hongtao.liu from comment #8) > > > > Do we have IR for unsigned/signed saturation in gimple level? > > > > > > Not yet. I was just looking for that today due because of PR 51492. > > > > But there is a RFC out for it: > > https://gcc.gnu.org/pipermail/gcc/2021-May/236015.html > > Oh, VEC_PACK_SAT_EXPR is exact what i needed for _mm256_packus_epi16, thanks > for the pointer. And ‘vec_pack_ssat_m’, ‘vec_pack_usat_m’ for optab.
[Bug target/77287] Much worse code generated compared to clang (stack alignment and spills)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77287 --- Comment #11 from Hongtao.liu --- (In reply to Andrew Pinski from comment #10) > (In reply to Andrew Pinski from comment #9) > > (In reply to Hongtao.liu from comment #8) > > > Do we have IR for unsigned/signed saturation in gimple level? > > > > Not yet. I was just looking for that today due because of PR 51492. > > But there is a RFC out for it: > https://gcc.gnu.org/pipermail/gcc/2021-May/236015.html Oh, VEC_PACK_SAT_EXPR is exact what i needed for _mm256_packus_epi16, thanks for the pointer.
[Bug tree-optimization/51492] vectorizer does not support saturated arithmetic patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51492 --- Comment #6 from Andrew Pinski --- https://gcc.gnu.org/pipermail/gcc/2021-May/236015.html
[Bug target/77287] Much worse code generated compared to clang (stack alignment and spills)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77287 --- Comment #10 from Andrew Pinski --- (In reply to Andrew Pinski from comment #9) > (In reply to Hongtao.liu from comment #8) > > Do we have IR for unsigned/signed saturation in gimple level? > > Not yet. I was just looking for that today due because of PR 51492. But there is a RFC out for it: https://gcc.gnu.org/pipermail/gcc/2021-May/236015.html
[Bug target/77287] Much worse code generated compared to clang (stack alignment and spills)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77287 --- Comment #9 from Andrew Pinski --- (In reply to Hongtao.liu from comment #8) > Do we have IR for unsigned/signed saturation in gimple level? Not yet. I was just looking for that today due because of PR 51492.
[Bug target/77287] Much worse code generated compared to clang (stack alignment and spills)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77287 --- Comment #8 from Hongtao.liu --- (In reply to Hongtao.liu from comment #7) > (In reply to Andrew Pinski from comment #5) > > clang can now produce: > > mov eax, dword ptr [esp + 16] > > mov ecx, dword ptr [esp + 28] > > vmovdqu xmm0, xmmword ptr [ecx + 32] > > vmovdqu xmm1, xmmword ptr [eax] > > vpackuswb xmm2, xmm1, xmm0 > > vpsubw xmm0, xmm1, xmm0 > > vpaddw xmm0, xmm0, xmm2 > > vpackuswb xmm0, xmm0, xmm0 > > vpackuswb xmm0, xmm0, xmm0 > > vpextrd eax, xmm0, 1 > > ret > > > > I suspect if the back-end is able to "fold" at the gimple level the builtins > > into gimple, GCC will do a much better job. > > Currently we have stuff like: > > _27 = __builtin_ia32_vextractf128_si256 (_28, 0); > > _26 = __builtin_ia32_vec_ext_v4si (_27, 1); [tail call] > > > > I think both are just a BIT_FIELD_REF really and even more can be simplified > > to just one bitfield extraction rather than what we do now: > > vpackuswb %ymm1, %ymm0, %ymm0 > > vpextrd $1, %xmm0, %eax > > > > Plus it looks like with __builtin_ia32_vextractf128_si256 (_28, 0), clang is > > able to remove half of the code due to only needing 128 bytes stuff :). > > Yes, let's me try this. Do we have IR for unsigned/signed saturation in gimple level?
[Bug tree-optimization/101434] vector-by-vector left shift expansion for char/short is not optimal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101434 --- Comment #4 from Andrew Pinski --- (In reply to Uroš Bizjak from comment #3) > (In reply to Richard Biener from comment #1) > > Probably low priority if not doable nicely w/o XOP. > > -mxop can be substituted with -mavx512bw -mavx512vl for the same effect. or -mavx2.
[Bug target/77287] Much worse code generated compared to clang (stack alignment and spills)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77287 --- Comment #7 from Hongtao.liu --- (In reply to Andrew Pinski from comment #5) > clang can now produce: > mov eax, dword ptr [esp + 16] > mov ecx, dword ptr [esp + 28] > vmovdqu xmm0, xmmword ptr [ecx + 32] > vmovdqu xmm1, xmmword ptr [eax] > vpackuswb xmm2, xmm1, xmm0 > vpsubw xmm0, xmm1, xmm0 > vpaddw xmm0, xmm0, xmm2 > vpackuswb xmm0, xmm0, xmm0 > vpackuswb xmm0, xmm0, xmm0 > vpextrd eax, xmm0, 1 > ret > > I suspect if the back-end is able to "fold" at the gimple level the builtins > into gimple, GCC will do a much better job. > Currently we have stuff like: > _27 = __builtin_ia32_vextractf128_si256 (_28, 0); > _26 = __builtin_ia32_vec_ext_v4si (_27, 1); [tail call] > > I think both are just a BIT_FIELD_REF really and even more can be simplified > to just one bitfield extraction rather than what we do now: > vpackuswb %ymm1, %ymm0, %ymm0 > vpextrd $1, %xmm0, %eax > > Plus it looks like with __builtin_ia32_vextractf128_si256 (_28, 0), clang is > able to remove half of the code due to only needing 128 bytes stuff :). Yes, let's me try this.
[Bug rtl-optimization/82356] auto-vectorizing pack of 16->8 has a redundant AND after a shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82356
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2021-08-14 00:00:00 |2021-8-24
--- Comment #2 from Andrew Pinski ---
With -O3 -fno-move-loop-invariants -fno-gcse
We get
Trying 38, 34 -> 39:
38: r160:V8HI=[`*.LC0']
REG_EQUAL const_vector
34: r154:V8HI=r153:V8HI 0>>0x8
REG_DEAD r153:V8HI
39: r158:V8HI=r160:V8HI:V8HI
REG_DEAD r154:V8HI
Failed to match this instruction:
(parallel [
(set (reg:V8HI 158)
(and:V8HI (lshiftrt:V8HI (reg:V8HI 153 [ vect__1.12 ])
(const_int 8 [0x8]))
(const_vector:V8HI [
(const_int 255 [0xff]) repeated x8
])))
(set (reg:V8HI 160)
(mem/u/c:V8HI (symbol_ref/u:DI ("*.LC0") [flags 0x2]) [0 S16
A128]))
])
Failed to match this instruction:
(parallel [
(set (reg:V8HI 158)
(and:V8HI (lshiftrt:V8HI (reg:V8HI 153 [ vect__1.12 ])
(const_int 8 [0x8]))
(const_vector:V8HI [
(const_int 255 [0xff]) repeated x8
])))
(set (reg:V8HI 160)
(mem/u/c:V8HI (symbol_ref/u:DI ("*.LC0") [flags 0x2]) [0 S16
A128]))
])
Successfully matched this instruction:
(set (reg:V8HI 160)
(mem/u/c:V8HI (symbol_ref/u:DI ("*.LC0") [flags 0x2]) [0 S16 A128]))
Failed to match this instruction:
(set (reg:V8HI 158)
(and:V8HI (lshiftrt:V8HI (reg:V8HI 153 [ vect__1.12 ])
(const_int 8 [0x8]))
(const_vector:V8HI [
(const_int 255 [0xff]) repeated x8
])))
Which we don't recongize the and part is not needed.
Also since we don't emit REG_EQUAL when using vector_csts, we needed to use
"-fno-move-loop-invariants -fno-gcse ".
[Bug middle-end/56873] vector shift lowered to scalars for -mxop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56873 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |5.0 Summary|vector shift lowered to |vector shift lowered to |scalars |scalars for -mxop
[Bug tree-optimization/100696] mult_higpart is not vectorized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100696 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug middle-end/101950] __builtin_clrsb is never inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101950 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug tree-optimization/101373] PRE hoists trapping instructions over possibly throwing calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101373 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.3
[Bug middle-end/101596] vect_recog_mulhs_pattern could use incorrect precision to check shift count
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101596 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |12.0
[Bug tree-optimization/86723] not optimizing with bswap, that casts to int aftwards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86723 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug target/101865] _ARCH_PWR8 is not defined when using -mcpu=power8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101865 --- Comment #6 from HaoChen Gui --- (In reply to Segher Boessenkool from comment #5) > (In reply to HaoChen Gui from comment #4) > > I wonder if it's a Power8 architecture when those 6 options are all > > disabled. Or it is regressed to Power7? The "_ARCH_PWR8" represents the > > hardware architecture or the ISA it can be taken? > > It says what version of the ISA is effective. It should correspond to the > -mcpu= used. > > Even if it would be possible to use -mcpu=power8 and then other command line > flags that set everything back to it being just like Power7 (architecturally > that is, ignoring scheduling etc.), we should still define _ARCH_PWR8. Thanks for your comments. If it's architecturally Power7, why we still need to define _ARCH_PWR8. Does _ARCH_PWR8 impact anything during the compiling? Could we just use mcpu instead? Seems _ARCH_PWR8 only affects instruction selection right now.
[Bug tree-optimization/101801] vect_worthwhile_without_simd_p is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101801 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug target/101989] Fail to optimize (a & b) | (c & ~b) to vpternlog instruction.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101989 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug target/101609] no right shift pattern for vector(2) long long on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101609 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug analyzer/102052] New: analyser testsuite failures with LLP64 model
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102052
Bug ID: 102052
Summary: analyser testsuite failures with LLP64 model
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
Additional details here:
https://gcc.gnu.org/pipermail/gcc/2021-August/237158.html
pr98969.c:9:19: warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
* This fails because the function arguments are "long int", and that tries to
hold a pointer. It should be uintptr_t or similar.
Something like this should work:
diff --git a/gcc/testsuite/gcc.dg/analyzer/pr98969.c
b/gcc/testsuite/gcc.dg/analyzer/pr98969.c
index 7e1587d..770e6d2 100644
--- a/gcc/testsuite/gcc.dg/analyzer/pr98969.c
+++ b/gcc/testsuite/gcc.dg/analyzer/pr98969.c
@@ -4,14 +4,14 @@ struct foo
};
void
-test_1 (long int i)
+test_1 (__UINTPTR_TYPE__ i)
{
struct foo *f = (struct foo *)i;
f->expr = __builtin_malloc (1024);
} /* { dg-bogus "leak" } */
void
-test_2 (long int i)
+test_2 (__UINTPTR_TYPR__ i)
{
__builtin_free (((struct foo *)i)->expr);
__builtin_free (((struct foo *)i)->expr); /* { dg-warning "double-'free' of
'\\*\\(\\(struct foo \\*\\)i\\)\\.expr'" } */
pr99716-2.c:13:30: warning: implicit declaration of function 'random';did you
mean 'rand'? [-Wimplicit-function-declaration]
* The C function is rand(), so it's not clear to me at least why the code is
using random. I have no idea what the test is testing, so I don't know if
rand() is a drop in replacement, but here you go:
index 7c9881c..adc9819 100644
--- a/gcc/testsuite/gcc.dg/analyzer/pr99716-2.c
+++ b/gcc/testsuite/gcc.dg/analyzer/pr99716-2.c
@@ -10,7 +10,7 @@ extern int foo (void);
void
test_mountpoint (const char *mp)
{
- const int nr_passes = 5 + (random () & 31);
+ const int nr_passes = 5 + (rand () & 31);
int pass;
int ret = 1;
FILE *fp;
pr99774-1.c:12:14: warning: conflicting types for built-in function 'calloc';
expected 'void *(long long unsigned int, long long unsigned int)'
[-Wbuiltin-declaration-mismatch]
zlib-5.c:10:15: warning: conflicting types for built-in function 'strlen';
expected 'long long unsigned int(const char *)'
[-Wbuiltin-declaration-mismatch]
zlib-5.c:16:14: warning: conflicting types for built-in function 'calloc';
expected 'void *(long long unsigned int, long long unsigned int)'
[-Wbuiltin-declaration-mismatch]
* These are all examples of hardcoding a size_t typedef that is incorrect for
an LLP64 model. Something like this would probably be enough to fix it:
diff --git a/gcc/testsuite/gcc.dg/analyzer/pr99774-1.c
b/gcc/testsuite/gcc.dg/analyzer/pr99774-1.c
index 620cf65..a2138d9 100644
--- a/gcc/testsuite/gcc.dg/analyzer/pr99774-1.c
+++ b/gcc/testsuite/gcc.dg/analyzer/pr99774-1.c
@@ -7,9 +7,8 @@ typedef unsigned char uint8_t;
typedef unsigned short uint16_t;
typedef unsigned long uint64_t;
typedef unsigned long uint64_t;
-typedef long unsigned int size_t;
-extern void *calloc(size_t __nmemb, size_t __size)
+extern void *calloc(__SIZE_TYPE__ __nmemb, __SIZE_TYPE__ __size)
__attribute__((__nothrow__, __leaf__))
__attribute__((__malloc__))
__attribute__((__alloc_size__(1, 2)))
diff --git a/gcc/testsuite/gcc.dg/analyzer/zlib-5.c
b/gcc/testsuite/gcc.dg/analyzer/zlib-5.c
index afb6102..93df2b1 100644
--- a/gcc/testsuite/gcc.dg/analyzer/zlib-5.c
+++ b/gcc/testsuite/gcc.dg/analyzer/zlib-5.c
@@ -2,18 +2,17 @@
#include "analyzer-decls.h"
-typedef long unsigned int size_t;
typedef unsigned char Byte;
typedef unsigned int uInt;
typedef unsigned long uLong;
-extern size_t strlen(const char *__s) __attribute__((__nothrow__, __leaf__))
+extern __SIZE_TYPE__ strlen(const char *__s) __attribute__((__nothrow__,
__leaf__))
__attribute__((__pure__)) __attribute__((__nonnull__(1)));
extern void exit(int __status) __attribute__((__nothrow__, __leaf__))
__attribute__((__noreturn__));
extern char *strcpy(char *__restrict __dest, const char *__restrict __src)
__attribute__((__nothrow__, __leaf__)) __attribute__((__nonnull__(1, 2)));
-extern void *calloc(size_t __nmemb, size_t __size)
+extern void *calloc(__SIZE_TYPE__ __nmemb, __SIZE_TYPE__ __size)
__attribute__((__nothrow__, __leaf__)) __attribute__((__malloc__));
extern int compress(Byte *dest, uLong *destLen, const Byte *source,
strndup-1.c:9:13: warning: incompatible implicit declaration of built-in
function 'strndup' [-Wbuiltin-declaration-mismatch]
* This function doesn't exist on windows. So, either we add it to libmingwex
if it isn't already there and then link that library in to
the test, or just mark it as unsupported. I'd probably prefer the former, but
it's not up to me. Let me know what I should do here.
gcc.dg/analyzer/gzio-3.c:
gcc.dg/analyzer/gzio-3a.c:
* For some
[Bug target/101989] Fail to optimize (a & b) | (c & ~b) to vpternlog instruction.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101989 --- Comment #6 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:4f5391dde1a83086b451f7534c815ab1267bb6bc commit r12-3133-g4f5391dde1a83086b451f7534c815ab1267bb6bc Author: liuhongt Date: Wed Aug 25 09:45:25 2021 +0800 Adjust testcases to avoid new failures brought by r12-3108 when compiled w -march=cascadelake. gcc/testsuite/ChangeLog: PR target/101989 * gcc.target/i386/avx2-shiftqihi-constant-1.c: Add -mno-avx512f. * gcc.target/i386/sse2-shiftqihi-constant-1.c: Add -mno-avx
[Bug c++/102049] Extend attribute deprecated to allow optional 2nd argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102049 Martin Sebor changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-08-25 CC||msebor at gcc dot gnu.org --- Comment #1 from Martin Sebor --- Supporting the two-argument form for compatibility with Clang makes sense to me. I'm not sure I understand what letting the empty string as the second argument suppress warnings would be useful for. The only purpose of declaring something deprecated that I know of is to trigger a warning when it's used, so unless I'm missing something, that doesn't seem necessary or a good idea (if no warning is wanted then remove the attribute).
[Bug tree-optimization/82426] Missed tree-slp-vectorization on -O2 and -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82426 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Severity|normal |enhancement Last reconfirmed||2021-08-25 --- Comment #4 from Andrew Pinski --- Hmm, on aarch64 we do a decent job at vectorizing this (since GCC 11): ldp d4, d0, [x1] ldr d7, [x0, 16] ldp d6, d5, [x0] fmulv3.2s, v0.2s, v7.s[1] ldr d1, [x1, 16] fmulv2.2s, v0.2s, v6.s[1] fmulv0.2s, v0.2s, v5.s[1] fmlav3.2s, v4.2s, v7.s[0] fmlav2.2s, v4.2s, v6.s[0] fmlav0.2s, v4.2s, v5.s[0] faddv1.2s, v1.2s, v3.2s stp d2, d0, [x8] str d1, [x8, 16] I suspect this is because V2SF does not exist on x86_64. Using -Dfloat=double seems to get better for x86_64 (with -mavx2): vmovupd (%rdx), %ymm0 vpermilpd $0, (%rsi), %ymm1 movq%rdi, %rax vmovsd 32(%rsi), %xmm5 vmovsd 40(%rsi), %xmm4 vpermpd $68, %ymm0, %ymm2 vpermpd $238, %ymm0, %ymm3 vmulpd %ymm2, %ymm1, %ymm2 vpermilpd $15, (%rsi), %ymm1 vmulpd %ymm3, %ymm1, %ymm1 vaddpd %ymm1, %ymm2, %ymm1 vmulsd %xmm5, %xmm0, %xmm2 vmovupd %ymm1, (%rdi) vmovapd %xmm0, %xmm1 vextractf128$0x1, %ymm0, %xmm0 vmulsd %xmm4, %xmm0, %xmm3 vunpckhpd %xmm1, %xmm1, %xmm1 vunpckhpd %xmm0, %xmm0, %xmm0 vmulsd %xmm5, %xmm1, %xmm1 vmulsd %xmm4, %xmm0, %xmm0 vaddsd %xmm3, %xmm2, %xmm2 vaddsd 32(%rdx), %xmm2, %xmm2 vaddsd %xmm0, %xmm1, %xmm1 vaddsd 40(%rdx), %xmm1, %xmm1 vmovsd %xmm2, 32(%rdi) vmovsd %xmm1, 40(%rdi)
[Bug tree-optimization/101977] [12 Regression] array subscript 0 is outside array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101977 --- Comment #6 from Alan Modra --- (In reply to Martin Sebor from comment #5) > The -Warray-bounds for section.c is gone Thanks for fixing that. > but last night's build still shows > a large number of -Warray-bounds instances as well as other warnings for > Binutils & GDB. I built gcc and binutils+gdb just now and see that these are all in sim/ with the exception of -Wconflicts-sr and -Wconflicts-rr bison warnings, and this libstdc++ warning: home/alan/build/gcc-virgin/prev-x86_64-linux/libstdc++-v3/include/bits/stl_algo.h:1869:32: error: array subscript 19 is outside array bounds of ‘void [136]’ [-Werror=array-bounds]
[Bug tree-optimization/43543] Reorder the statements in the loop can vectorize it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43543 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/51492] vectorizer does not support saturated arithmetic patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51492
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2016-01-04 00:00:00 |2021-8-24
--- Comment #5 from Andrew Pinski ---
We do slightly better but not close:
movdqa (%rax), %xmm0
addq$16, %rax
psubusw %xmm1, %xmm0
paddw %xmm1, %xmm0
paddw %xmm2, %xmm0
movaps %xmm0, -16(%rax)
Which is expanded from:
vect__1.6_15 = MAX_EXPR ;
vect__2.7_17 = vect__1.6_15 + { 65472, 65472, 65472, 65472, 65472, 65472,
65472, 65472 };
-mavx2 we get:
vpmaxuw (%rax), %ymm2, %ymm0
addq$32, %rax
vpaddw %ymm1, %ymm0, %ymm0
vmovdqa %ymm0, -32(%rax)
Just note 65472 is -64.
This shouldn't be too hard to detect and add and even lower back to
MAX_EXPR/PLUS_EXPR if us_minus does not exist.
[Bug tree-optimization/58359] __builtin_unreachable prevents vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58359 Andrew Pinski changed: What|Removed |Added Depends on||101993 --- Comment #13 from Andrew Pinski --- In the original testcase, it is very similar to PR 101993 where it is a check for pointer being null. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101993 [Bug 101993] Potential vectorization opportunity when condition checks array address
[Bug target/77287] Much worse code generated compared to clang (stack alignment and spills)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77287 --- Comment #6 from Petr --- Yes, the code is not really doing anything useful, I only wrote it to demonstrate the spills problem. Clang actually outsmarted me by removing half of the code :) I think this issue can be closed, I cannot repro this with the newest GCC.
[Bug analyzer/101980] [12 regressions] many test case failures after r12-3002
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101980 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #4 from Hans-Peter Nilsson --- (In reply to Ankur Saini from comment #3) > Fixed after the following commits: > e92d0ff6b5e6d4b95c04fc3e326d40efeb136086 > 537878152ded8b7d271333b803b36c27a9aea8d2 g++.dg/analyzer/pr96641.C, a regression introduced by this commit (or unlikely, another commit in the series 640df4ef815a..f0fca213bc52), remains to be fixed. It seems to fail everywhere: s390x-ibm-linux-gnu https://gcc.gnu.org/pipermail/gcc-testresults/2021-August/716425.html x86_64-pc-linux-gnu 3c496e92d795a8fe5c527e3c5b5a6606669ae50d https://gcc.gnu.org/pipermail/gcc-testresults/2021-August/716406.html powerpc64-unknown-linux-gnu 6d692ef43b2b3368c92c3fb757c7884fc94ee627 https://gcc.gnu.org/pipermail/gcc-testresults/2021-August/716400.html powerpc64le-unknown-linux-gnu 3c496e92d795a8fe5c527e3c5b5a6606669ae50d https://gcc.gnu.org/pipermail/gcc-testresults/2021-August/716428.html i686-pc-linux-gnu 6e5401e87d02919b0594e04f828892deef956407 https://gcc.gnu.org/pipermail/gcc-testresults/2021-August/716332.html powerpc-ibm-aix7.2.3.0 0312e263b6afa5b545c2d3b7c7ac5295ecaa7fa8 https://gcc.gnu.org/pipermail/gcc-testresults/2021-August/716308.html m68k-unknown-linux-gnu 192d4edd15c https://gcc.gnu.org/pipermail/gcc-testresults/2021-August/716297.html For cris-elf, I see this in g++.log: /X/gcc/testsuite/g++.dg/analyzer/pr96641.C:8:3: warning: analysis bailed out early (91 'after-snode' enodes; 228 enodes) [-Wanalyzer-too-complex]
[Bug target/63330] vector shuffle resembling vector shift not expanded optimally
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63330 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2014-09-22 00:00:00 |2021-8-24 Severity|normal |enhancement
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 54803, which changed state. Bug 54803 Summary: Rotates are not vectorized https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54803 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/54803] Rotates are not vectorized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54803 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |4.9.0 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Andrew Pinski --- Fixed for GCC 4.9.0 by r0-123435.
[Bug c++/102039] another case of template function signature incorrectly dropping top-level cv-qualifier with function parameter dependent on template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102039
Andrew Pinski changed:
What|Removed |Added
Blocks||24666
--- Comment #1 from Andrew Pinski ---
This is another one where the arrays decay too fast to pointers in the
argument.
Or rather not fast enough:
struct A{
typedef int Arr3[3];
};
template
void f(const typename T::Arr3){}
template<>
void f(const int*){}
Or maybe not, I will leave this more to C++ standards expert because ICC (EDG)
also rejects both of these testcases for the same reason as GCC.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24666
[Bug 24666] [meta-bug] array decaying to pointers
[Bug c++/102051] [coroutines] ICE in gimplify_var_or_parm_decl, at gimplify.c:2848
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102051 --- Comment #1 from Vitali --- Tested via godbolt on 11 & 12.
[Bug c++/102051] New: [coroutines] ICE in gimplify_var_or_parm_decl, at gimplify.c:2848
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102051
Bug ID: 102051
Summary: [coroutines] ICE in gimplify_var_or_parm_decl, at
gimplify.c:2848
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vlovich at gmail dot com
Target Milestone: ---
Created attachment 51353
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51353=edit
The preprocessed file that causes the ICE
We're adding co-routine support to KJ futures
(https://github.com/capnproto/capnproto/pull/1104). I tried enabling coroutines
on G++ by adjusting async-prelude.h:
-#if __cpp_coroutines && __has_include()
+#if __cpp_impl_coroutine && __has_include()
+// Standardized coroutines detected.
+#include
+#define KJ_HAS_COROUTINE 1
+#define KJ_COROUTINE_STD_NAMESPACE std
+#elif __cpp_coroutines && __has_include()
This results in an ICE in our test case:
# g++ -std=c++20 -fcoroutines
./c++/src/kj/CMakeFiles/kj-heavy-tests.dir/async-coroutine-test.c++.ii
c++/src/kj/async-coroutine-test.c++: In function ‘kj::Promise
kj::{anonymous}::identity(const char*)’:
c++/src/kj/async-coroutine-test.c++:40:1: internal compiler error: in
gimplify_var_or_parm_decl, at gimplify.c:2840
40 | }
| ^
0x1797368 internal_error(char const*, ...)
???:0
0x67f8f9 fancy_abort(char const*, int, char const*)
???:0
0xab710f gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xab7130 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xab7a2c gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xab81dd gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xab7417 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xab852d gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xab86ea gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xab852d gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xab723e gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xab852d gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xab86ea gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xabac7a gimplify_body(tree_node*, bool)
???:0
0xabb022 gimplify_function_tree(tree_node*)
???:0
0x949a87 cgraph_node::analyze()
???:0
0x94cc2d symbol_table::finalize_compilation_unit()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/92293] No reason given for template argument deduction failure with zero-length array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92293 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-08-24 Status|UNCONFIRMED |NEW --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug c++/91235] Array size expression is implicitly casted to unsigned long type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91235 --- Comment #3 from Andrew Pinski --- I think the warning is correct. there is no negative sizes; only size_t sizes for array.
[Bug c++/88829] Failure to deduce size of array of 2^31 chars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88829
--- Comment #2 from Andrew Pinski ---
The error is now:
:4:19: error: no matching function for call to 'foo(int [2147483648])'
4 | auto x = foo(a);
| ^
:3:48: note: candidate: 'template T*
foo(T (&)[N])'
3 | template T* foo(T()[N]) {return
t;}
|^~~
:3:48: note: template argument deduction/substitution failed:
: In substitution of 'template T*
foo(T (&)[N]) [with T = int; long long unsigned int N = 18446744071562067968]':
:4:19: required from here
:3:48: error: size of array exceeds maximum object size
'9223372036854775807'
:3:55: error: size of array exceeds maximum object size
'9223372036854775807'
3 | template T* foo(T()[N]) {return
t;}
|~~~^
But still emitted twice but then again MSVC also emits the error message twice
too:
(2): error C2148: total size of array must not exceed 0x7fff bytes
(2): error C2148: total size of array must not exceed 0x7fff bytes
[Bug c++/72842] non-type template-parameter of type void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72842 --- Comment #9 from Andrew Pinski --- For the original testcase, GCC, ICC, clang and MSVC all accept it.
[Bug c++/102044] another case of template function signature incorrectly dropping top-level cv-qualifier with function parameter of array of template function pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102044 Andrew Pinski changed: What|Removed |Added Blocks||24666 --- Comment #1 from Andrew Pinski --- This looks like another case where arrays are not decaying correctly; either too soon or too late. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24666 [Bug 24666] [meta-bug] array decaying to pointers
[Bug tree-optimization/102046] [12 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.c:87 with -O3 -march=btver2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102046
--- Comment #2 from Andrew Pinski ---
else if (!useless_type_conversion_p (elt_t, TREE_TYPE (elt_v)))
{
error ("incorrect type of vector CONSTRUCTOR elements");
debug_generic_stmt (rhs1);
return true;
}
_16 = {_2, _12};
Maybe introduced by r12-1294.
[Bug tree-optimization/102046] [12 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.c:87 with -O3 -march=btver2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102046 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-08-24 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug tree-optimization/102046] [12 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.c:87 with -O3 -march=btver2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102046 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug c/89153] internal compiler error: in assign_stack_local_1, at function.c:409
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89153 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #4 from Andrew Pinski --- Can't reproduce it on a stock GCC 6.3.0. In fact a stock GCC 6.3.0 rejects the code: /usr/include/x86_64-linux-gnu/bits/mathcalls-helper-functions.h:21:30: error: unknown type name '_Float128'
[Bug target/102024] [12 Regression] zero width bitfields and ABIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #9 from Segher Boessenkool ---
(In reply to Michael Matz from comment #8)
> So, I think, not removing those members from the FE makes sense, they contain
> crucial information. Unfortunately that means that they need to be dealt
> with
> in code dealing with layout (correct) or argument/return-value passing
> (seemingly
> fishy right now for some platforms?).
>
> Also, all else being equal I think the C language defines the de-facto
> psABI, so any difference between C and C++ should be resolved towards C.
Yeah. In the case of Power homogeneous arguments, removing the bitfield
from { float a; int:0; float b; } is fine to do *later*, when the backend
already knows it is an homogeneous argument, when all decisions have been made
and the results recorded. It would be good if this was documented somewhere,
where that spot is?
[Bug rtl-optimization/83545] ICE at -O3 on x86_64-linux-gnu: in smallest_mode_for_size, at stor-layout.c:355
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83545 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |8.0
[Bug rtl-optimization/83545] ICE at -O3 on x86_64-linux-gnu: in smallest_mode_for_size, at stor-layout.c:355
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83545 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=85431 --- Comment #2 from Andrew Pinski --- Fixed maybe related to PR 85431.
[Bug c++/102050] New: Nonempty list-initialization rejects constructor with defaulted std::initializer_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102050
Bug ID: 102050
Summary: Nonempty list-initialization rejects constructor with
defaulted std::initializer_list
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: johelegp at gmail dot com
CC: johelegp at gmail dot com
Target Milestone: ---
See https://godbolt.org/z/5PGza1o8e.
```C++
#include
struct S { S( std::initializer_list = {} ) {} };
int main() { S{0}; }
```
```
: In function 'int main()':
:3:17: error: no matching function for call to 'S::S()'
3 | int main() { S{0}; }
| ^
:2:12: note: candidate: 'S::S(std::initializer_list)'
2 | struct S { S( std::initializer_list = {} ) {} };
|^
:2:15: note: no known conversion for argument 1 from 'int' to
'std::initializer_list'
2 | struct S { S( std::initializer_list = {} ) {} };
| ^~~
:2:8: note: candidate: 'constexpr S::S(const S&)'
2 | struct S { S( std::initializer_list = {} ) {} };
|^
:2:8: note: no known conversion for argument 1 from 'int' to 'const
S&'
:2:8: note: candidate: 'constexpr S::S(S&&)'
:2:8: note: no known conversion for argument 1 from 'int' to 'S&&'
Compiler returned: 1
```
This came up at https://cpplang.slack.com/archives/C2SLQATS9/p1629835850325200.
[Bug bootstrap/61326] bootstrap failure of gcc-4.8.3 on ia64-hpux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61326 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #5 from Andrew Pinski --- No feedback in almsot 5 years so closing.
[Bug c++/63907] libitm/config/posix/rwlock.cc doesn't compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63907
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING |RESOLVED
Known to work||11.1.0
Target Milestone|--- |11.0
Component|libitm |c++
--- Comment #14 from Andrew Pinski ---
GCC 11+ accepts this code now:
#define PTHREAD_COND_INITIALIZER {{ 0, 0 }, 0, "", 0}
struct _pthread_fastlock
{
long int __status;
int __spinlock;
};
typedef struct _pthread_descr_struct *_pthread_descr;
__extension__ typedef long long __pthread_cond_align_t;
typedef struct
{
struct _pthread_fastlock __c_lock;
_pthread_descr __c_waiting;
char __padding[48 - sizeof (struct _pthread_fastlock)
- sizeof (_pthread_descr) - sizeof (__pthread_cond_align_t)];
__pthread_cond_align_t __align;
} pthread_cond_t;
struct S{
pthread_cond_t x;
/* g++ 7.3: error: no matching function for call to
'pthread_cond_t::pthread_cond_t()'
* g++ 4.5.3: error: could not convert '{{0, 0}, 0, "", 0}' to
'pthread_cond_t'
*/
S() : x (PTHREAD_COND_INITIALIZER) {}
};
So I think we can close this as fixed for GCC 11.
Also I doubt anyone has the older glibc around either.
[Bug c++/87032] incorrect nested structure with union initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87032 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.0
[Bug testsuite/90381] New test case gcc.dg/tree-ssa/pr88676-2.c fails with its introduction in r270934
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90381 --- Comment #6 from Segher Boessenkool --- (In reply to Andrew Pinski from comment #5) > (In reply to Segher Boessenkool from comment #4) > > Are bitfields allocated right to left on all LE configs? > > I think the majority of them, I have not used one which does the opposite. Of course. But my point was, the testcase is somewhat fragile as written. Perhaps we should have a selector for the bitfield allocation direction. Or, alternatively, if this testcase is the only one using this that would be overkill of course. A comment that explains things will help then!
[Bug libstdc++/102048] __gnu_cxx::rope.erase(size_t __p) implementation seems to be wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102048 --- Comment #4 from Jonathan Wakely --- That function was not part of the SGI rope so I think we should just remove it: https://www.boost.org/sgi/stl/Rope.html
[Bug rtl-optimization/102031] [12 Regression] ICE in simplify_truncation, at simplify-rtx.c:620 since r12-3074-g7e5f9ead16d7514b3baa0254084de94f0bfcd216
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102031 --- Comment #3 from CVS Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:81e1894456bc6214c0c42148ff2b1bed142a3545 commit r12-3130-g81e1894456bc6214c0c42148ff2b1bed142a3545 Author: Roger Sayle Date: Tue Aug 24 22:07:41 2021 +0100 [Committed] PR middle-end/102031: Fix typo/mistake in simplify_truncation patch. My apologies again. My patch to simplify truncations of SUBREGs in simplify-rtx.c contained an error where I'd accidentally compared against a mode instead of the precision of that mode. Grr! It even survived regression testing on two platforms. Fixed below, and committed as obvious, after a full "make bootstrap" and "make -k check" on x86_64-pc-linux-gnu with no new regressions. 2021-08-24 Roger Sayle gcc/ChangeLog PR middle-end/102031 * simplify-rtx.c (simplify_truncation): When comparing precisions use "subreg_prec" variable, not "subreg_mode".
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 91290, which changed state. Bug 91290 Summary: pragma maybe-uninitialized does not propagate to lambda https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91290 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/91290] pragma maybe-uninitialized does not propagate to lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91290 Martin Sebor changed: What|Removed |Added Target Milestone|--- |12.0 CC||msebor at gcc dot gnu.org Resolution|--- |FIXED Blocks||24639 Status|NEW |RESOLVED Known to fail||10.3.0, 11.2.0, 9.3.0 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #3 from Martin Sebor --- Fixed in GC 12, most likely by r12-1805. The patch is not suitable for backporting. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 [Bug 24639] [meta-bug] bug to track all Wuninitialized issues
[Bug lto/48180] '-fuse-linker-plugin' doesn't work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48180 Andrew Pinski changed: What|Removed |Added CC||malcolm2190 at att dot net --- Comment #7 from Andrew Pinski --- *** Bug 81326 has been marked as a duplicate of this bug. ***
[Bug other/81326] gcc-ar: Cannot find plugin 'liblto_plugin.so' Mac Sierra Xcode 8.3.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81326 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Andrew Pinski --- The liblto_plugin is not supported on darwin as lld plugin API is not the same the GNU LD plugin API. So this is expected. *** This bug has been marked as a duplicate of bug 48180 ***
[Bug c++/81237] Cannot link when class methods compiled with different levels of abi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81237 Andrew Pinski changed: What|Removed |Added Keywords||ABI Status|WAITING |RESOLVED Resolution|--- |WONTFIX Summary|Cannot link when class |Cannot link when class |methods compiled with |methods compiled with |different levels of |different levels of abi |vectorization | --- Comment #6 from Andrew Pinski --- Since that is exactly what the ABI switches are supposed to do this is not a bug. You might be able to add some aliases to get this working but I highly doubt that will always work.
[Bug rtl-optimization/80715] NULL pointer dereferenced in find_costs_and_classes, at ira-costs.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80715 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Target Milestone|--- |8.0 Resolution|--- |FIXED --- Comment #5 from Andrew Pinski --- Fixed in GCC 8 by r8-1500. https://gcc.gnu.org/pipermail/gcc-patches/2017-June/477204.html
[Bug bootstrap/51742] 4.6.2 v. HP-UX 11.11, PA-RISC: "make bootstrap-lean" fails: "internal compiler error: Segmentation fault" (In function '__fixunssfdi')
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51742 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #6 from Andrew Pinski --- hppa-hpux is known to work with GCC 5 so closing.
[Bug c++/102049] Extend attribute deprecated to allow optional 2nd argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102049 Marek Polacek changed: What|Removed |Added Severity|normal |enhancement Keywords||diagnostic
[Bug c++/102049] New: Extend attribute deprecated to allow optional 2nd argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102049
Bug ID: 102049
Summary: Extend attribute deprecated to allow optional 2nd
argument
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
Clang implements something we don't have:
__attribute__((deprecated("message", "replacement")));
which we reject. We probably could allow it for the [[gnu::deprecated]]
form too (but not [[deprecated]]).
I wonder if we want some tweak that if the replacement argument is an
empty string, we don't warn -- this should allow code bases to gradually move
away from deprecated functions only when there's an actual replacement.
[[gnu::deprecated("insecure", "")]] void f(); // no replacement yet, don't warn
[[gnu::deprecated("slow", "add2")]] void add(); // warn, use add2
Does this seem worthwhile?
[Bug fortran/93834] [9/10/11/12 Regression] ICE in trans_caf_is_present, at fortran/trans-intrinsic.c:8469
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93834 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org CC||anlauf at gcc dot gnu.org --- Comment #6 from anlauf at gcc dot gnu.org --- Patch: https://gcc.gnu.org/pipermail/fortran/2021-August/056440.html
[Bug bootstrap/43748] build machinery insufficient for installing target specific .def files as plugin headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43748 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Iain Sandoe --- This seems to have been fixed by: commit 8b0210047962c7342d23a333703203690b76ba3d Author: Mike Stump Date: 2011-02-19 04:54:55 + t-darwin (TM_H): Add dependency on on darwin-sections.def. * config/t-darwin (TM_H): Add dependency on on darwin-sections.def. I can confirm that darwin-sections.def is installed in the plugin include dir for and ---enable-plugin build on x86_64-darwin19, of gcc-9.4.1 which is the oldest open branch. closing as fixed.
[Bug middle-end/19987] [meta-bug] fold missing optimizations in general
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987 Bug 19987 depends on bug 95176, which changed state. Bug 95176 Summary: Failure to optimize division followed by multiplication to modulo followed by subtraction https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95176 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/95176] Failure to optimize division followed by multiplication to modulo followed by subtraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95176 Arjun Shankar changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |12.0 Resolution|--- |FIXED --- Comment #3 from Arjun Shankar --- This should make it to GCC 12 when it's released, so I'm closing it accordingly.
[Bug other/82648] libiberty/regex.c:2364]: pointless test ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82648 --- Comment #4 from Andrew Pinski --- This happens only when WCHAR is defined. This code is old and has changed a lot in glibc. Most likely when gcc moves over to gnulib from libiberty for this code, this most likely will fix itself.
[Bug other/89863] [meta-bug] Issues in gcc that other static analyzers (cppcheck, clang-static-analyzer, PVS-studio) find that gcc misses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863 Bug 89863 depends on bug 80049, which changed state. Bug 80049 Summary: gcc/genmodes.c: PVS-Studio: NULL Pointer Dereference (CWE-476) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80049 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
[Bug other/80049] gcc/genmodes.c: PVS-Studio: NULL Pointer Dereference (CWE-476)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80049 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- The static analysis tool is not tracking m->cl through the switch before that well. There is a check for component being non-zero here: case MODE_COMPLEX_INT: case MODE_COMPLEX_FLOAT: /* Complex modes should have a component indicated, but no more. */ validate_mode (m, UNSET, UNSET, SET, UNSET, UNSET); Which is before the access of m->component in the if statement.
[Bug tree-optimization/97223] Failure to optimize comparison of char arithmetic to single comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97223 Arjun Shankar changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |11.0 Resolution|--- |FIXED CC||arjun.is at lostca dot se --- Comment #5 from Arjun Shankar --- Looks like this was fixed by the time GCC 11 was released. I'm closing this bug out.
[Bug libstdc++/102048] __gnu_cxx::rope.erase(size_t __p) implementation seems to be wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102048 --- Comment #3 from Zonghan Yang --- I couldn't find document explicitly states how the function works but only the line of comment above it shows the idea. So I guess it's just a small typo but not found for years since no one really document it. In my opinion, it'd be better if it is consistent with std::string. Since current implementation is totally wrong, it's very unlikely that somebody really use this function historically (except unlucky wretches like me), it would be acceptable if we change the API. Or, deleting the function erase(size_t) itself instead of whole rope is also a good choice. From my point of view, rope is somehow useful in some specific tasks, so it'd be awesome if it can be kept it in libstdc++.
[Bug middle-end/99486] Feature request: -fstack-check option for embedded processors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99486 Andrew Pinski changed: What|Removed |Added Component|other |middle-end Severity|normal |enhancement
[Bug libgcc/12955] Incorrect rounding of soft float denorm mul/div
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12955 Andrew Pinski changed: What|Removed |Added Assignee|eager at mvista dot com|unassigned at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #16 from Andrew Pinski --- Michael has not been with mvista for years too so unassinging.
[Bug libstdc++/102048] __gnu_cxx::rope.erase(size_t __p) implementation seems to be wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102048
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2021-08-24
Status|UNCONFIRMED |NEW
--- Comment #2 from Jonathan Wakely ---
This would fix it, and provide the API that was apparently intended:
--- a/libstdc++-v3/include/ext/rope
+++ b/libstdc++-v3/include/ext/rope
@@ -2401,11 +2401,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
this->_M_tree_ptr = __result;
}
- // Erase, single character
- void
- erase(size_type __p)
- { erase(__p, __p + 1); }
-
// Insert, iterator variants.
iterator
insert(const iterator& __p, const rope& __r)
If we want to retain an erase function that erases a single character, we could
do:
@@ -2393,7 +2393,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
// Erase, (position, size) variant.
void
- erase(size_type __p, size_type __n)
+ erase(size_type __p, size_type __n = 1)
{
_RopeRep* __result = replace(this->_M_tree_ptr, __p,
__p + __n, 0);
But to be consistent with std::string it should erase from that position to the
end of the string:
@@ -2393,7 +2393,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
// Erase, (position, size) variant.
void
- erase(size_type __p, size_type __n)
+ erase(size_type __p, size_type __n = npos)
{
_RopeRep* __result = replace(this->_M_tree_ptr, __p,
__p + __n, 0);
So maybe we should just remove it, since it's currently broken and "fixing" it
would be inconsistent with std::string.
[Bug bootstrap/81458] Misdetection of gcc_cv_as_cfi_advance_working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81458 Andrew Pinski changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #3 from Andrew Pinski --- Detecting gcc_cv_as_cfi_advance_working detecting as no even though it is actually working but objdump not working is still decent thing to do as we are trying to detect if it was working correctly and use cfi directives only then. So if they are not working we output the correct thing even though we can't detect if it was working correctly or not.
[Bug fortran/98411] [10/11/12 Regression] Pointless: Array larger than ‘-fmax-stack-var-size=’, moved from stack to static storage for main program variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98411 --- Comment #15 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:f95946afd160e2a1f4beac4ee5e6d5633307f39a commit r12-3129-gf95946afd160e2a1f4beac4ee5e6d5633307f39a Author: Harald Anlauf Date: Tue Aug 24 21:07:50 2021 +0200 Fortran: fix pointless warning for static variables gcc/fortran/ChangeLog: PR fortran/98411 * trans-decl.c (gfc_finish_var_decl): Adjust check to handle implicit SAVE as well as variables in the main program. Improve warning message text. gcc/testsuite/ChangeLog: PR fortran/98411 * gfortran.dg/pr98411.f90: Adjust testcase options to restrict to F2008, and verify case of implicit SAVE.
[Bug libstdc++/102048] __gnu_cxx::rope.erase(size_t __p) implementation seems to be wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102048 --- Comment #1 from Jonathan Wakely --- We should just delete this class, so I don't have to keep fixing bugs in code that nobody uses or cares about.
[Bug other/85898] I receive a segmentation fault due to an "internal compiler error"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85898 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|WAITING |RESOLVED --- Comment #3 from Andrew Pinski --- No testcase in 3 years so closing as invalid.
[Bug other/67457] segfault in libbacktrace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67457 Andrew Pinski changed: What|Removed |Added CC||tobias at stoeckmann dot org --- Comment #7 from Andrew Pinski --- *** Bug 67392 has been marked as a duplicate of this bug. ***
[Bug other/67392] Invalid mmap return value check in libbacktrace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67392 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Dup of bug 67457. *** This bug has been marked as a duplicate of bug 67457 ***
[Bug libstdc++/102048] New: __gnu_cxx::rope.erase(size_t __p) implementation seems to be wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102048
Bug ID: 102048
Summary: __gnu_cxx::rope.erase(size_t __p) implementation seems
to be wrong
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: fstqwq at foxmail dot com
Target Milestone: ---
In ext/rope from all versions of gcc I could refer to (see
https://github.com/gcc-mirror/gcc/blame/master/libstdc%2B%2B-v3/include/ext/rope#L2407,
the last change is made 17 years ago), the implementation of
__gnu_cxx::rope.erase(size_t) is:
// Erase, single character
void
erase(size_type __p)
{ erase(__p, __p + 1); }
The comment said it will erase a single character from rope. However, the
function actually erase (__p + 1) characters starting from position __p by
calling erase(size_t, size_t) commented as "Erase, (position, size) variant.",
which is just defined above the erase(size_t) version.
You can test the function by the following code:
#include
#include
int main() {
__gnu_cxx::rope R;
for (int i = 0; i < 9; i++) R.push_back(i);
R.erase(2);
for (int i = 0; i < 4; i++) std::cout << R[i] << std::endl;
}
If erase functions normally or replace erase(2) with erase(2, 1), it's expected
to see 0 1 3 4. It turned out to be 0 1 5 6, that erases 3 elements starting
from 2.
[Bug c++/102012] GCC accepts any non-bool atomic constraint type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102012 --- Comment #4 from Patrick Palka --- (In reply to 康桓瑋 from comment #3) > (In reply to Patrick Palka from comment #1) > > Hmm, I think this might actually be well-formed according to [temp.names]/9. > > I don't see why we'd need to check satisfaction of a concept-id inside > > decltype if its type is already prescribed to be bool. > > "The standard requires MSVC/Clang's behavior of erroring out." from > https://stackoverflow.com/a/68910627/11638718. Yes, evaluation of the concept-id should produce an error during satisfaction due to the non-bool constraint. But why should we evaluate a concept-id inside decltype in the first place, when the type of a concept-id is always prescribed to be bool?
[Bug c++/102045] [11/12 regression] constructor is not being instantiated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102045
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #4 from Patrick Palka ---
Slightly more reduced:
struct span {
template constexpr span(T) { }
};
struct byte_writer : span { };
void f(char *p) {
byte_writer w{p};
}
int main() { }
Removing 'constexpr' makes the the link succeed
[Bug tree-optimization/101977] [12 Regression] array subscript 0 is outside array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101977 --- Comment #5 from Martin Sebor --- The -Warray-bounds for section.c is gone but last night's build still shows a large number of -Warray-bounds instances as well as other warnings for Binutils & GDB. I haven't analyzed any of them. The breakdown is below: DiagnosticCount UniqueFiles -Wimplicit-function-declaration 99 70 15 -Warray-bounds 7911 -Wpointer-sign 54 548 -Wmaybe-uninitialized43 37 22 -Wmissing-prototypes 42 329 -Wincompatible-pointer-types 42 421 -Wpointer-to-int-cast11 112 -Wparentheses11 113 -Wint-to-pointer-cast 991 -Wformat= 632 -Walloc-zero 622 -Wconflicts-sr555 -Wunused-value311 -Wunused-function 331 -Wstrict-aliasing 331 -Wdangling-else 221 -Wmisleading-indentation 111 -Wconflicts-rr111
[Bug c++/102012] GCC accepts any non-bool atomic constraint type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102012 --- Comment #3 from 康桓瑋 --- (In reply to Patrick Palka from comment #1) > Hmm, I think this might actually be well-formed according to [temp.names]/9. > I don't see why we'd need to check satisfaction of a concept-id inside > decltype if its type is already prescribed to be bool. "The standard requires MSVC/Clang's behavior of erroring out." from https://stackoverflow.com/a/68910627/11638718.
[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 101977, which changed state. Bug 101977 Summary: [12 Regression] array subscript 0 is outside array bounds https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101977 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/101977] [12 Regression] array subscript 0 is outside array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101977 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Sebor --- Fixed.
[Bug tree-optimization/101977] [12 Regression] array subscript 0 is outside array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101977 Bug 101977 depends on bug 101600, which changed state. Bug 101600 Summary: [12 Regression] Spurious -Warray-bounds downcasting a polymorphic pointer https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101600 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 101600, which changed state. Bug 101600 Summary: [12 Regression] Spurious -Warray-bounds downcasting a polymorphic pointer https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101600 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/101600] [12 Regression] Spurious -Warray-bounds downcasting a polymorphic pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101600 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Martin Sebor --- Fixed.
[Bug middle-end/101600] [12 Regression] Spurious -Warray-bounds downcasting a polymorphic pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101600 --- Comment #4 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:820f0940d7ace1306430a9dcf1bd9577508a7a7e commit r12-3124-g820f0940d7ace1306430a9dcf1bd9577508a7a7e Author: Martin Sebor Date: Tue Aug 24 10:49:11 2021 -0600 Reset PHI base0 flag if it's clear in any argument [PR101977, ...] Resolves: PR middle-end/101600 - Spurious -Warray-bounds downcasting a polymorphic pointer PR middle-end/101977 - bogus -Warray-bounds on a negative index into a parameter in conditional with null gcc/ChangeLog: PR middle-end/101600 PR middle-end/101977 * gimple-ssa-warn-access.cc (maybe_warn_for_bound): Tighten up the phrasing of a warning. (check_access): Use the remaining size after subtracting any offset rather than the whole object size. * pointer-query.cc (access_ref::get_ref): Clear BASE0 flag if it's clear for any nonnull PHI argument. (compute_objsize): Clear argument. gcc/testsuite/ChangeLog: PR middle-end/101600 PR middle-end/101977 * g++.dg/pr100574.C: Prune out valid warning. * gcc.dg/pr20126.c: Same. * gcc.dg/Wstringop-overread.c: Adjust text of expected warnings. Add new instances. * gcc.dg/warn-strnlen-no-nul.c: Same. * g++.dg/warn/Warray-bounds-26.C: New test. * gcc.dg/Warray-bounds-88.c: New test.
[Bug tree-optimization/101977] [12 Regression] array subscript 0 is outside array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101977 --- Comment #3 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:820f0940d7ace1306430a9dcf1bd9577508a7a7e commit r12-3124-g820f0940d7ace1306430a9dcf1bd9577508a7a7e Author: Martin Sebor Date: Tue Aug 24 10:49:11 2021 -0600 Reset PHI base0 flag if it's clear in any argument [PR101977, ...] Resolves: PR middle-end/101600 - Spurious -Warray-bounds downcasting a polymorphic pointer PR middle-end/101977 - bogus -Warray-bounds on a negative index into a parameter in conditional with null gcc/ChangeLog: PR middle-end/101600 PR middle-end/101977 * gimple-ssa-warn-access.cc (maybe_warn_for_bound): Tighten up the phrasing of a warning. (check_access): Use the remaining size after subtracting any offset rather than the whole object size. * pointer-query.cc (access_ref::get_ref): Clear BASE0 flag if it's clear for any nonnull PHI argument. (compute_objsize): Clear argument. gcc/testsuite/ChangeLog: PR middle-end/101600 PR middle-end/101977 * g++.dg/pr100574.C: Prune out valid warning. * gcc.dg/pr20126.c: Same. * gcc.dg/Wstringop-overread.c: Adjust text of expected warnings. Add new instances. * gcc.dg/warn-strnlen-no-nul.c: Same. * g++.dg/warn/Warray-bounds-26.C: New test. * gcc.dg/Warray-bounds-88.c: New test.
[Bug target/102035] arm/m-profile/cmse add mitigation for CVE-2021-35465
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102035 Richard Earnshaw changed: What|Removed |Added Target Milestone|10.5|10.4
[Bug target/102035] arm/m-profile/cmse add mitigation for CVE-2021-35465
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102035 Richard Earnshaw changed: What|Removed |Added Target Milestone|--- |10.5
