[Bug target/87598] [8/9 Regression] Rejects "%a0" with constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87598 --- Comment #4 from rguenther at suse dot de --- On Sat, 20 Oct 2018, segher at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87598 > > --- Comment #2 from Segher Boessenkool --- > rs6000.c print_operand_address does not like (const_int 0) or any other > const_int. Power *can* actually have constant numbers as data addresses, > but only for instructions that have some D form; and GCC does not support > such constant addresses currently. > > We could do output_operand_lossage, or we could do as most targets do here: > call output_addr_const and hope for the best (it will output just "0" with > this testcase). Is that preferred? I guess either variant is OK. output_addr_const would be OK as well as that matches generic handling for the constant address letter.
[Bug target/87598] [8/9 Regression] Rejects "%a0" with constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87598 --- Comment #5 from rguenther at suse dot de --- On Sat, 20 Oct 2018, segher at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87598 > > --- Comment #3 from Segher Boessenkool --- > GCC 7 fails for me like the rest, and according to history it should have > failed since day 1, over 28 years ago. Is that "works with 7.3.1" for > aarch64 only? Yes. Sorry for lumping the ppc64 ICE into this very same bug...
[Bug target/72782] AVX512: No support for scalar broadcasts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72782 --- Comment #12 from hjl at gcc dot gnu.org --- Author: hjl Date: Mon Oct 22 07:25:51 2018 New Revision: 265368 URL: https://gcc.gnu.org/viewcvs?rev=265368&root=gcc&view=rev Log: i386: Enable AVX512 memory broadcast for INT add Many AVX512 vector operations can broadcast from a scalar memory source. This patch enables memory broadcast for INT add operations. gcc/ PR target/72782 * config/i386/sse.md (avx512bcst): Updated for V4SI, V2DI, V8SI, V4DI, V16SI and V8DI. (*sub3_bcst): New. (*add3_bcst): Likewise. gcc/testsuite/ PR target/72782 * gcc.target/i386/avx512f-add-di-zmm-1.c: New test. * gcc.target/i386/avx512f-add-si-zmm-1.c: Likewise. * gcc.target/i386/avx512f-add-si-zmm-2.c: Likewise. * gcc.target/i386/avx512f-add-si-zmm-3.c: Likewise. * gcc.target/i386/avx512f-add-si-zmm-4.c: Likewise. * gcc.target/i386/avx512f-add-si-zmm-5.c: Likewise. * gcc.target/i386/avx512f-add-si-zmm-6.c: Likewise. * gcc.target/i386/avx512f-sub-di-zmm-1.c: Likewise. * gcc.target/i386/avx512f-sub-si-zmm-1.c: Likewise. * gcc.target/i386/avx512f-sub-si-zmm-2.c: Likewise. * gcc.target/i386/avx512f-sub-si-zmm-3.c: Likewise. * gcc.target/i386/avx512f-sub-si-zmm-4.c: Likewise. * gcc.target/i386/avx512f-sub-si-zmm-5.c: Likewise. * gcc.target/i386/avx512vl-add-si-xmm-1.c: Likewise. * gcc.target/i386/avx512vl-add-si-ymm-1.c: Likewise. * gcc.target/i386/avx512vl-sub-si-xmm-1.c: Likewise. * gcc.target/i386/avx512vl-sub-si-ymm-1.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/i386/avx512f-add-di-zmm-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-add-si-zmm-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-add-si-zmm-2.c trunk/gcc/testsuite/gcc.target/i386/avx512f-add-si-zmm-3.c trunk/gcc/testsuite/gcc.target/i386/avx512f-add-si-zmm-4.c trunk/gcc/testsuite/gcc.target/i386/avx512f-add-si-zmm-5.c trunk/gcc/testsuite/gcc.target/i386/avx512f-add-si-zmm-6.c trunk/gcc/testsuite/gcc.target/i386/avx512f-sub-di-zmm-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-sub-si-zmm-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-sub-si-zmm-2.c trunk/gcc/testsuite/gcc.target/i386/avx512f-sub-si-zmm-3.c trunk/gcc/testsuite/gcc.target/i386/avx512f-sub-si-zmm-4.c trunk/gcc/testsuite/gcc.target/i386/avx512f-sub-si-zmm-5.c trunk/gcc/testsuite/gcc.target/i386/avx512vl-add-si-xmm-1.c trunk/gcc/testsuite/gcc.target/i386/avx512vl-add-si-ymm-1.c trunk/gcc/testsuite/gcc.target/i386/avx512vl-sub-si-xmm-1.c trunk/gcc/testsuite/gcc.target/i386/avx512vl-sub-si-ymm-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sse.md trunk/gcc/testsuite/ChangeLog
[Bug target/72782] AVX512: No support for scalar broadcasts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72782 --- Comment #13 from hjl at gcc dot gnu.org --- Author: hjl Date: Mon Oct 22 07:29:03 2018 New Revision: 265369 URL: https://gcc.gnu.org/viewcvs?rev=265369&root=gcc&view=rev Log: i386: Enable AVX512 memory broadcast for INT logic Many AVX512 vector operations can broadcast from a scalar memory source. This patch enables memory broadcast for INT logic operations. gcc/ PR target/72782 * config/i386/sse.md (*3_bcst): New. gcc/testsuite/ PR target/72782 * gcc.target/i386/avx512f-and-di-zmm-1.c: New test. * gcc.target/i386/avx512f-and-si-zmm-1.c: Likewise. * gcc.target/i386/avx512f-and-si-zmm-2.c: Likewise. * gcc.target/i386/avx512f-and-si-zmm-3.c: Likewise. * gcc.target/i386/avx512f-and-si-zmm-4.c: Likewise. * gcc.target/i386/avx512f-and-si-zmm-5.c: Likewise. * gcc.target/i386/avx512f-and-si-zmm-6.c: Likewise. * gcc.target/i386/avx512f-or-di-zmm-1.c: Likewise. * gcc.target/i386/avx512f-or-si-zmm-1.c: Likewise. * gcc.target/i386/avx512f-or-si-zmm-2.c: Likewise. * gcc.target/i386/avx512f-or-si-zmm-3.c: Likewise. * gcc.target/i386/avx512f-or-si-zmm-4.c: Likewise. * gcc.target/i386/avx512f-or-si-zmm-5.c: Likewise. * gcc.target/i386/avx512f-or-si-zmm-6.c: Likewise. * gcc.target/i386/avx512f-xor-di-zmm-1.c: Likewise. * gcc.target/i386/avx512f-xor-si-zmm-1.c: Likewise. * gcc.target/i386/avx512f-xor-si-zmm-2.c: Likewise. * gcc.target/i386/avx512f-xor-si-zmm-3.c: Likewise. * gcc.target/i386/avx512f-xor-si-zmm-4.c: Likewise. * gcc.target/i386/avx512f-xor-si-zmm-5.c: Likewise. * gcc.target/i386/avx512f-xor-si-zmm-6.c: Likewise. * gcc.target/i386/avx512vl-and-si-xmm-1.c: Likewise. * gcc.target/i386/avx512vl-and-si-ymm-1.c: Likewise. * gcc.target/i386/avx512vl-or-si-xmm-1.c: Likewise. * gcc.target/i386/avx512vl-or-si-ymm-1.c: Likewise. * gcc.target/i386/avx512vl-xor-si-xmm-1.c: Likewise. * gcc.target/i386/avx512vl-xor-si-ymm-1.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/i386/avx512f-and-di-zmm-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-and-si-zmm-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-and-si-zmm-2.c trunk/gcc/testsuite/gcc.target/i386/avx512f-and-si-zmm-3.c trunk/gcc/testsuite/gcc.target/i386/avx512f-and-si-zmm-4.c trunk/gcc/testsuite/gcc.target/i386/avx512f-and-si-zmm-5.c trunk/gcc/testsuite/gcc.target/i386/avx512f-and-si-zmm-6.c trunk/gcc/testsuite/gcc.target/i386/avx512f-or-di-zmm-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-or-si-zmm-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-or-si-zmm-2.c trunk/gcc/testsuite/gcc.target/i386/avx512f-or-si-zmm-3.c trunk/gcc/testsuite/gcc.target/i386/avx512f-or-si-zmm-4.c trunk/gcc/testsuite/gcc.target/i386/avx512f-or-si-zmm-5.c trunk/gcc/testsuite/gcc.target/i386/avx512f-or-si-zmm-6.c trunk/gcc/testsuite/gcc.target/i386/avx512f-xor-di-zmm-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-xor-si-zmm-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-xor-si-zmm-2.c trunk/gcc/testsuite/gcc.target/i386/avx512f-xor-si-zmm-3.c trunk/gcc/testsuite/gcc.target/i386/avx512f-xor-si-zmm-4.c trunk/gcc/testsuite/gcc.target/i386/avx512f-xor-si-zmm-5.c trunk/gcc/testsuite/gcc.target/i386/avx512f-xor-si-zmm-6.c trunk/gcc/testsuite/gcc.target/i386/avx512vl-and-si-xmm-1.c trunk/gcc/testsuite/gcc.target/i386/avx512vl-and-si-ymm-1.c trunk/gcc/testsuite/gcc.target/i386/avx512vl-or-si-xmm-1.c trunk/gcc/testsuite/gcc.target/i386/avx512vl-or-si-ymm-1.c trunk/gcc/testsuite/gcc.target/i386/avx512vl-xor-si-xmm-1.c trunk/gcc/testsuite/gcc.target/i386/avx512vl-xor-si-ymm-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sse.md trunk/gcc/testsuite/ChangeLog
[Bug target/72782] AVX512: No support for scalar broadcasts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72782 --- Comment #14 from hjl at gcc dot gnu.org --- Author: hjl Date: Mon Oct 22 07:35:48 2018 New Revision: 265370 URL: https://gcc.gnu.org/viewcvs?rev=265370&root=gcc&view=rev Log: i386: Enable AVX512 memory broadcast for INT andnot Many AVX512 vector operations can broadcast from a scalar memory source. This patch enables memory broadcast for INT andnot operations. gcc/ PR target/72782 * config/i386/sse.md (*andnot3_bcst): New. gcc/testsuite/ PR target/72782 * gcc.target/i386/avx512f-andn-di-zmm-1.c: New test. * gcc.target/i386/avx512f-andn-si-zmm-1.c: Likewise. * gcc.target/i386/avx512f-andn-si-zmm-2.c: Likewise. * gcc.target/i386/avx512f-andn-si-zmm-3.c: Likewise. * gcc.target/i386/avx512f-andn-si-zmm-4.c: Likewise. * gcc.target/i386/avx512f-andn-si-zmm-5.c: Likewise. * gcc.target/i386/avx512vl-andn-si-xmm-1.c: Likewise. * gcc.target/i386/avx512vl-andn-si-ymm-1.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/i386/avx512f-andn-di-zmm-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-andn-si-zmm-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-andn-si-zmm-2.c trunk/gcc/testsuite/gcc.target/i386/avx512f-andn-si-zmm-3.c trunk/gcc/testsuite/gcc.target/i386/avx512f-andn-si-zmm-4.c trunk/gcc/testsuite/gcc.target/i386/avx512f-andn-si-zmm-5.c trunk/gcc/testsuite/gcc.target/i386/avx512vl-andn-si-xmm-1.c trunk/gcc/testsuite/gcc.target/i386/avx512vl-andn-si-ymm-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sse.md trunk/gcc/testsuite/ChangeLog
[Bug target/87678] Redundant vmovss with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87678
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-10-22
CC||segher at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Uroš Bizjak ---
This is due to combine, which only tries to propagate REG_EQUAL to the user.
Consider this slightly simpler test:
--cut here--
float
foo (float x, float y)
{
float z = x + y;
return z * 2.387f;
}
--cut here--
gcc -O2 -m32 -fpic -mfpmath=sse -msse:
movss .LC0@GOTOFF(%eax), %xmm1
mulss %xmm1, %xmm0
Where combine tries to combine:
(insn 8 7 9 2 (set (reg:SF 89)
(mem/u/c:SF (plus:SI (reg:SI 82)
(const:SI (unspec:SI [
(symbol_ref/u:SI ("*.LC0") [flags 0x2])
] UNSPEC_GOTOFF))) [0 S4 A32])) "pic.c":5:12 112
{*movsf_internal}
(expr_list:REG_DEAD (reg:SI 82)
(expr_list:REG_EQUAL (const_double:SF 2.3878392333984375e+0
[0x0.98c49cp+2])
(nil
(insn 9 8 14 2 (set (reg:SF 87)
(mult:SF (reg:SF 88 [ z ])
(reg:SF 89))) "pic.c":5:12 815 {*fop_sf_comm}
(expr_list:REG_DEAD (reg:SF 89)
(expr_list:REG_DEAD (reg:SF 88 [ z ])
(nil
Trying 8 -> 9:
8: r89:SF=[r82:SI+const(unspec[`*.LC0'] 1)]
REG_DEAD r82:SI
REG_EQUAL 2.3878392333984375e+0
9: r87:SF=r88:SF*r89:SF
REG_DEAD r89:SF
REG_DEAD r88:SF
Failed to match this instruction:
(set (reg:SF 87)
(mult:SF (reg:SF 88 [ z ])
(const_double:SF 2.3878392333984375e+0 [0x0.98c49cp+2])))
Combine should retry with the original source insn.
[Bug target/72782] AVX512: No support for scalar broadcasts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72782 H.J. Lu changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #15 from H.J. Lu --- I checked in a set of patches to enable AVX512 scalar broadcast. Please open a new bug if there are missing broadcasts.
[Bug target/63351] Optimization: contract broadcast intrinsics when AVX512 is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63351 Bug 63351 depends on bug 72782, which changed state. Bug 72782 Summary: AVX512: No support for scalar broadcasts https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72782 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug bootstrap/87640] [9 regression] internal compiler error: in check, at tree-vrp.c:155
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87640 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|aldyh at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #8 from Richard Biener --- Testing patch.
[Bug target/63351] Optimization: contract broadcast intrinsics when AVX512 is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63351
H.J. Lu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #6 from H.J. Lu ---
AVX512 scalar broadcast only works on memory operand. GCC 9 now generates:
[hjl@gnu-efi-2 gcc]$ cat x.c
#include
void dummyx(__m128 a, __m128 b);
void broadcastx(__m128 a, float *b) {
__m128 bb = _mm_set1_ps(*b);
__m128 ab = _mm_add_ps(a,bb);
__m128 cc = _mm_set1_ps(5.0);
__m128 ac = _mm_add_ps(a,cc);
dummyx(ab, ac);
}
[hjl@gnu-efi-2 gcc]$ cat y.c
#include
void dummyz(__m512i a, __m512i b);
void broadcastz(__m512i a, int *b) {
__m512i bb = _mm512_set1_epi32(*b);
__m512i ab = _mm512_add_epi32(a,bb);
__m512i cc = _mm512_set1_epi32(5);
__m512i ac = _mm512_add_epi32(a,cc);
dummyz(ab, ac);
}
[hjl@gnu-efi-2 gcc]$ ./xgcc -B./ -S -Ofast -mavx512vl x.c
[hjl@gnu-efi-2 gcc]$ ./xgcc -B./ -S -Ofast -mavx512f y.c
[hjl@gnu-efi-2 gcc]$ cat x.s
.file "x.c"
.text
.p2align 4
.globl broadcastx
.type broadcastx, @function
broadcastx:
.LFB5186:
.cfi_startproc
vmovaps %xmm0, %xmm1
vaddps (%rdi){1to4}, %xmm0, %xmm0
vaddps .LC0(%rip), %xmm1, %xmm1
jmp dummyx
.cfi_endproc
.LFE5186:
.size broadcastx, .-broadcastx
.section.rodata.cst16,"aM",@progbits,16
.align 16
.LC0:
.long 1084227584
.long 1084227584
.long 1084227584
.long 1084227584
.ident "GCC: (GNU) 9.0.0 20181022 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-efi-2 gcc]$ cat y.s
.file "y.c"
.text
.p2align 4
.globl broadcastz
.type broadcastz, @function
broadcastz:
.LFB5186:
.cfi_startproc
movl$5, %eax
vmovdqa64 %zmm0, %zmm2
vpaddd (%rdi){1to16}, %zmm0, %zmm0
vpbroadcastd%eax, %zmm1
vpaddd %zmm2, %zmm1, %zmm1
jmp dummyz
.cfi_endproc
.LFE5186:
.size broadcastz, .-broadcastz
.ident "GCC: (GNU) 9.0.0 20181022 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-efi-2 gcc]$
With PR 87537 fix, I got
[hjl@gnu-efi-2 gcc]$ cat x.s
.file "x.c"
.text
.p2align 4
.globl broadcastx
.type broadcastx, @function
broadcastx:
.LFB5186:
.cfi_startproc
vmovaps %xmm0, %xmm1
vaddps (%rdi){1to4}, %xmm0, %xmm0
vaddps .LC1(%rip){1to4}, %xmm1, %xmm1
jmp dummyx
.cfi_endproc
.LFE5186:
.size broadcastx, .-broadcastx
.section.rodata.cst4,"aM",@progbits,4
.align 4
.LC1:
.long 1084227584
.ident "GCC: (GNU) 9.0.0 20181022 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-efi-2 gcc]$
[Bug c/87683] New: Inline asm input/output operand does not prevent compiler optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87683
Bug ID: 87683
Summary: Inline asm input/output operand does not prevent
compiler optimization
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Target Milestone: ---
I use this macro since 2016 to prevent certain compiler optimizations:
#define OBFUSCATE_VARIABLE(var) __asm__("" : "+r" (var))
This was suggested by:
https://gcc.gnu.org/ml/gcc/2016-09/msg00115.html
It seems that it doesn't prevent some compiler optimizations in combination
with the non-null attribute. Consider the following test case:
#include
#define OBFUSCATE_VARIABLE(var) __asm__("" : "+r" (var))
int posix_memalign(void **, size_t, size_t) __attribute__((__nonnull__(1)))
__attribute__((__alloc_align__(2))) __attribute__((__alloc_size__(3)))
__attribute__((__warn_unused_result__));
void a(void);
void b(void);
void c(void)
{
int s;
void **p;
p = 0;
OBFUSCATE_VARIABLE(p);
s = posix_memalign(p, 16, 16);
if (s != 22) {
a();
} else {
b();
}
}
GCC 7, 8, 9 unconditionally calls a() with -O2 without any warnings:
gcc -O2 -S -Wall -Wextra -pedantic test.c -o -
.file "test.c"
.text
.p2align 4,,15
.globl c
.type c, @function
c:
.LFB0:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
movl$16, %edx
movl$16, %esi
xorl%edi, %edi
callposix_memalign
addq$8, %rsp
.cfi_def_cfa_offset 8
jmp a
.cfi_endproc
.LFE0:
.size c, .-c
.ident "GCC: (SUSE Linux) 7.3.1 20180920 [gcc-7-branch revision
264438]"
.section.note.GNU-stack,"",@progbits
If I remove the inline asm, then I get a warning:
test.c: In function ‘c’:
test.c:19:4: warning: argument 1 null where non-null expected [-Wnonnull]
s = posix_memalign(p, 16, 16);
~~^~~
[Bug target/87674] AVX512: incorrect intrinsic signature
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87674
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
Untested patch:
--- gcc/config/i386/avx512pfintrin.h.jj 2018-01-03 10:20:06.095535707 +0100
+++ gcc/config/i386/avx512pfintrin.h2018-10-22 09:49:52.647874664 +0200
@@ -174,16 +174,16 @@ _mm512_prefetch_i64scatter_ps (void *__a
extern __inline void
__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
-_mm512_mask_prefetch_i64scatter_pd (void *__addr, __mmask16 __mask,
+_mm512_mask_prefetch_i64scatter_pd (void *__addr, __mmask8 __mask,
__m512i __index, int __scale, int __hint)
{
__builtin_ia32_scatterpfqpd (__mask, (__v8di) __index, __addr, __scale,
- __hint);
+ __hint);
}
extern __inline void
__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
-_mm512_mask_prefetch_i64scatter_ps (void *__addr, __mmask16 __mask,
+_mm512_mask_prefetch_i64scatter_ps (void *__addr, __mmask8 __mask,
__m512i __index, int __scale, int __hint)
{
__builtin_ia32_scatterpfqps (__mask, (__v8di) __index, __addr, __scale,
--- gcc/config/i386/avx512vlintrin.h.jj 2018-10-22 09:28:21.843398728 +0200
+++ gcc/config/i386/avx512vlintrin.h2018-10-22 09:52:39.432092006 +0200
@@ -9095,7 +9095,7 @@ _mm_maskz_mullo_epi32 (__mmask8 __M, __m
extern __inline __m128i
__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
-_mm_mask_mullo_epi32 (__m128i __W, __mmask16 __M, __m128i __A,
+_mm_mask_mullo_epi32 (__m128i __W, __mmask8 __M, __m128i __A,
__m128i __B)
{
return (__m128i) __builtin_ia32_pmulld128_mask ((__v4si) __A,
--- gcc/config/i386/avx512vlbwintrin.h.jj 2018-07-11 22:55:44.663456512
+0200
+++ gcc/config/i386/avx512vlbwintrin.h 2018-10-22 09:55:24.784333238 +0200
@@ -4346,7 +4346,7 @@ _mm_maskz_packus_epi32 (__mmask8 __M, __
extern __inline __m128i
__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
-_mm_mask_packus_epi32 (__m128i __W, __mmask16 __M, __m128i __A,
+_mm_mask_packus_epi32 (__m128i __W, __mmask8 __M, __m128i __A,
__m128i __B)
{
return (__m128i) __builtin_ia32_packusdw128_mask ((__v4si) __A,
@@ -4389,7 +4389,7 @@ _mm_maskz_packs_epi32 (__mmask8 __M, __m
extern __inline __m128i
__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
-_mm_mask_packs_epi32 (__m128i __W, __mmask16 __M, __m128i __A,
+_mm_mask_packs_epi32 (__m128i __W, __mmask8 __M, __m128i __A,
__m128i __B)
{
return (__m128i) __builtin_ia32_packssdw128_mask ((__v4si) __A,
[Bug go/87661] [9 Regression] libgo bootstrap failure on arm-linux-gnueabihf (redefinition of constants)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87661 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.0
[Bug c++/87663] Exorbitant compile times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87663 Richard Biener changed: What|Removed |Added Keywords||compile-time-hog Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-22 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Confirmed.
[Bug rtl-optimization/87664] invariant in loop after optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87664 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-22 Ever confirmed|0 |1
[Bug c++/87665] [8/9 Regression] gcc HEAD (svn: 265340) breaks elements on resize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87665 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.3
[Bug c/87683] Inline asm input/output operand does not prevent compiler optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87683
--- Comment #1 from Sebastian Huber ---
It seems it has nothing to do with the non-null attribute. This function
void d(void)
{
int s;
void *p;
s = posix_memalign(&p, 16, 16);
if (s != 22) {
a();
} else {
b();
}
}
is optimized to:
d:
.LFB1:
.cfi_startproc
subq$24, %rsp
.cfi_def_cfa_offset 32
movl$16, %edx
movl$16, %esi
leaq8(%rsp), %rdi
callposix_memalign
addq$24, %rsp
.cfi_def_cfa_offset 8
jmp a
.cfi_endproc
.LFE1:
.size d, .-d
Why does GCC assume that s != 22? Memory allocation may fail, in this case
posix_memalign() may return ENOMEM which could be 22.
[Bug middle-end/86336] [9 regression] ICE in omp-low.c:7879
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86336 Rainer Orth changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Rainer Orth --- At least on my targets I'm not seeing it any longer after 20180911.
[Bug web/87684] New: -Woverloaded-virtual is not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87684 Bug ID: 87684 Summary: -Woverloaded-virtual is not documented Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: bugzi...@poradnik-webmastera.com Target Milestone: --- -Woverloaded-virtual is not documented at https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html . I found this option when clang reported this kind of issue in my code, and then I tried to use it with gcc to get similar warning. BTW, clang includes -Woverloaded-virtual in -Werror. Consider doing the same for gcc.
[Bug web/87684] -Woverloaded-virtual is not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87684 --- Comment #1 from Daniel Fruzynski --- Last paragraph should be "clang includes -Woverloaded-virtual in -Wall", I noticed this too late to correct it.
[Bug bootstrap/87672] [9 regression] 81512c36 causes ICE in bootstrap stage 3 using "-D_FORTIFY_SOURCE=2" (invalid operand in unary operation, incorrect sharing of tree nodes, verify_gimple failed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87672
--- Comment #11 from jamespharvey20 at gmail dot com ---
I can confirm applying Bernd Edlinger's "2018-10-21 18:16:41 UTC" patch on
current trunk prevents all 3 reported errors, and allows using
CPPFLAGS="-D_FORTIFY_SOURCE=2" and the additions of "-O2" into
{libiberty,gcc}/configure.
Obviously, no one is obligated to provide me any insight. (Of course, no one
was even obligated to fix this, thanks Bernd for doing so!) I'd love hearing:
(1) how stage 2 was succeeding but stage 3 was failing, in a short "explain it
to me like I can compile and use gcc and know the theory of bootstrapping, but
have no idea what this patch is really doing"; and (2) if this patch fixes a
somewhat "hidden/silent" bug that needed to be fixed even for people not
compiling using these compilation flags, or if the fix is limited in scope to
those using these flags who would run into the compilation error.
[Bug bootstrap/87640] [9 regression] internal compiler error: in check, at tree-vrp.c:155
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87640 Richard Biener changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #9 from Richard Biener --- *** Bug 87670 has been marked as a duplicate of this bug. ***
[Bug middle-end/87670] [9 Regression] CPU2006 401.bzip2 failed to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87670 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE Target Milestone|--- |9.0 --- Comment #2 from Richard Biener --- dup *** This bug has been marked as a duplicate of bug 87640 ***
[Bug libstdc++/79433] __has_include() is true but #include gives #error when -std=old
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79433 --- Comment #29 from Jonathan Wakely --- Author: redi Date: Mon Oct 22 08:47:52 2018 New Revision: 265374 URL: https://gcc.gnu.org/viewcvs?rev=265374&root=gcc&view=rev Log: PR libstdc++/79433 no #error for including TS headers with wrong -std Backport from mainline 2017-09-12 Jonathan Wakely PR libstdc++/79433 * include/Makefile.am: Remove . * include/Makefile.in: Regenerate. * include/bits/c++14_warning.h: Remove. * include/experimental/algorithm: Do not include . * include/experimental/any: Likewise. * include/experimental/array: Likewise. * include/experimental/bits/erase_if.h: Likewise. * include/experimental/bits/lfts_config.h: Likewise. * include/experimental/bits/shared_ptr.h: Likewise. * include/experimental/bits/string_view.tcc: Likewise. * include/experimental/chrono: Likewise. * include/experimental/deque: Likewise. * include/experimental/filesystem: Do not include . * include/experimental/forward_list: Do not include . * include/experimental/functional: Likewise. * include/experimental/iterator: Likewise. * include/experimental/list: Likewise. * include/experimental/map: Likewise. * include/experimental/memory: Likewise. * include/experimental/numeric: Likewise. * include/experimental/optional: Likewise. * include/experimental/propagate_const: Likewise. * include/experimental/ratio: Likewise. * include/experimental/regex: Likewise. * include/experimental/set: Likewise. * include/experimental/string: Likewise. * include/experimental/string_view: Likewise. * include/experimental/system_error: Likewise. * include/experimental/tuple: Likewise. * include/experimental/type_traits: Likewise. * include/experimental/unordered_map: Likewise. * include/experimental/unordered_set: Likewise. * include/experimental/vector: Likewise. * testsuite/experimental/any/misc/any_cast_neg.cc: Adjust dg-error line number. * testsuite/experimental/array/neg.cc: Likewise. * testsuite/experimental/propagate_const/assignment/move_neg.cc: Likewise. * testsuite/experimental/propagate_const/cons/move_neg.cc: Likewise. * testsuite/experimental/propagate_const/requirements2.cc: Likewise. * testsuite/experimental/propagate_const/requirements3.cc: Likewise. * testsuite/experimental/propagate_const/requirements4.cc: Likewise. * testsuite/experimental/propagate_const/requirements5.cc: Likewise. Removed: branches/gcc-7-branch/libstdc++-v3/include/bits/c++14_warning.h Modified: branches/gcc-7-branch/libstdc++-v3/ChangeLog branches/gcc-7-branch/libstdc++-v3/include/Makefile.am branches/gcc-7-branch/libstdc++-v3/include/Makefile.in branches/gcc-7-branch/libstdc++-v3/include/experimental/algorithm branches/gcc-7-branch/libstdc++-v3/include/experimental/any branches/gcc-7-branch/libstdc++-v3/include/experimental/array branches/gcc-7-branch/libstdc++-v3/include/experimental/bits/erase_if.h branches/gcc-7-branch/libstdc++-v3/include/experimental/bits/lfts_config.h branches/gcc-7-branch/libstdc++-v3/include/experimental/bits/shared_ptr.h branches/gcc-7-branch/libstdc++-v3/include/experimental/bits/string_view.tcc branches/gcc-7-branch/libstdc++-v3/include/experimental/chrono branches/gcc-7-branch/libstdc++-v3/include/experimental/deque branches/gcc-7-branch/libstdc++-v3/include/experimental/filesystem branches/gcc-7-branch/libstdc++-v3/include/experimental/forward_list branches/gcc-7-branch/libstdc++-v3/include/experimental/functional branches/gcc-7-branch/libstdc++-v3/include/experimental/iterator branches/gcc-7-branch/libstdc++-v3/include/experimental/list branches/gcc-7-branch/libstdc++-v3/include/experimental/map branches/gcc-7-branch/libstdc++-v3/include/experimental/memory branches/gcc-7-branch/libstdc++-v3/include/experimental/numeric branches/gcc-7-branch/libstdc++-v3/include/experimental/optional branches/gcc-7-branch/libstdc++-v3/include/experimental/propagate_const branches/gcc-7-branch/libstdc++-v3/include/experimental/ratio branches/gcc-7-branch/libstdc++-v3/include/experimental/regex branches/gcc-7-branch/libstdc++-v3/include/experimental/set branches/gcc-7-branch/libstdc++-v3/include/experimental/string branches/gcc-7-branch/libstdc++-v3/include/experimental/string_view branches/gcc-7-branch/libstdc++-v3/include/experimental/system_error branches/gcc-7-branch/libstdc++-v3/include/experimental/tuple branches/gcc-7-branch/libstdc++-v3/include/experimental/type_traits branches/gcc-7-branch/libstdc++-v3/include/experimental/unordered_map branches/gcc-7-branch/libstdc++-v3/include/experimental/uno
[Bug c++/87671] Incorrect debugging information for unique_ptr passed to a constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87671 Richard Biener changed: What|Removed |Added Keywords||wrong-debug CC||vries at gcc dot gnu.org --- Comment #1 from Richard Biener --- Does this only happen when sanitizers are active?
[Bug c++/87680] Small program produces 160 meg .o file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87680 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-22 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed. I believe we have dups of this bug.
[Bug c++/87676] Presence of variadic constructor template breaks overload resolution for other constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87676
--- Comment #1 from Jonathan Wakely ---
The template constructor allows s({1, 2, 3}) to mean s(S2{1,2,3}) which tries
to use the deleted copy constructor.
Without the template constructor it can only mean s(S1{1,2,3}) which uses the
move constructor.
So I think GCC is correct.
[Bug c/87682] gcc/mem-stats.h:172: possible broken comparison operator ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87682 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-10-22 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Yes.
[Bug c++/87676] Presence of variadic constructor template breaks overload resolution for other constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87676
--- Comment #2 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #1)
> The template constructor allows s({1, 2, 3}) to mean s(S2{1,2,3}) which
> tries to use the deleted copy constructor.
Or more precisely, overload resolution means that the deleted constructor is
viable, because there's a conversion sequence from the braced-init-list to the
parameter type of the deleted copy constructor. The S2(S1&&) function is also
viable, and neither is a better match, so it's ambiguous.
The S2(const S1&) constructor is also viable, but is a worse match than
S2(S1&&) and so would not actually get chosen, but is still shown as one of the
candidates.
[Bug c++/87680] Small program produces 160 meg .o file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87680 --- Comment #2 from Jonathan Wakely --- Yes, there are dups. IIRC the problem is that every element of the array introduces a new try/finally block so that if one of the Foo objects throws an exception, all the earlier elements in the array get destroyed. That shouldn't be needed here, because Foo can never throw on construction.
[Bug c/87683] Inline asm input/output operand does not prevent compiler optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87683
Richard Biener changed:
What|Removed |Added
Keywords||accepts-invalid,
||diagnostic, documentation
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-10-22
Ever confirmed|0 |1
--- Comment #2 from Richard Biener ---
You cannot use alloc_align on posix_memalign, alloc_align only works for
functions that _return_ the allocated pointer (likewise alloc_size).
We should probably diagnose this based on the return value being 'int'
and not a pointer. Confirmed as diagnostic issue.
Quoting docs:
item alloc_size
@cindex @code{alloc_size} function attribute
The @code{alloc_size} attribute is used to tell the compiler that the
function return value points to memory, where the size is given by
@item alloc_align
@cindex @code{alloc_align} function attribute
The @code{alloc_align} attribute is used to tell the compiler that the
function return value points to memory, where the returned pointer minimum
^^
[Bug c++/87671] Incorrect debugging information for unique_ptr passed to a constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87671 --- Comment #2 from Anton Barkovsky --- No, without sanitizers also, although I'm getting a different value (1433833072 in my latest run) in the debugger instead of 16.
[Bug c++/87680] Small program produces 160 meg .o file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87680 --- Comment #3 from Jonathan Wakely --- PR 70277 is the one I was thinking of, and there's PR 55402 too.
[Bug fortran/68800] Fortran FE produces many memory leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68800 --- Comment #4 from Martin Liška --- Thank you for working on that!
[Bug bootstrap/87672] [9 regression] 81512c36 causes ICE in bootstrap stage 3 using "-D_FORTIFY_SOURCE=2" (invalid operand in unary operation, incorrect sharing of tree nodes, verify_gimple failed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87672
--- Comment #12 from Bernd Edlinger ---
(In reply to jamespharvey20 from comment #11)
> I can confirm applying Bernd Edlinger's "2018-10-21 18:16:41 UTC" patch on
> current trunk prevents all 3 reported errors, and allows using
> CPPFLAGS="-D_FORTIFY_SOURCE=2" and the additions of "-O2" into
> {libiberty,gcc}/configure.
>
Then you are lucky, because current trunk does not compile for me.
I had to roll back to r265240 first.
>
> Obviously, no one is obligated to provide me any insight. (Of course, no
> one was even obligated to fix this, thanks Bernd for doing so!) I'd love
> hearing: (1) how stage 2 was succeeding but stage 3 was failing, in a short
> "explain it to me like I can compile and use gcc and know the theory of
> bootstrapping, but have no idea what this patch is really doing"; and (2) if
> this patch fixes a somewhat "hidden/silent" bug that needed to be fixed even
> for people not compiling using these compilation flags, or if the fix is
> limited in scope to those using these flags who would run into the
> compilation error.
I think stage 2 uses -fno-checking while stage 3 does -fchecking=1,
that explains why only stage 3 runs into the assertions.
My patch does two things, first it gimplifies the expression
"(long unsigned int) ((ssizetype) _19 <= 7 ? 7 - (ssizetype) _19 : 0);"
This fixes the ICE that was exposed by my patch.
And secondly it fixes the length parameter of the transformation
strcat_chk => strcpy_chk. This wrong transformation is likely
already there in 8.0.
So yes, this is a real bug, and thanks for reporting, by the way.
[Bug libbacktrace/87653] Calling null pointer in multi-threaded applications
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87653 --- Comment #2 from Antony Polukhin --- Hmm... I can not reproduce the problem if I build the libbacktrace from sources (even without the patch). The problem appears only if I use libbacktrace from Ubuntu. I'll double check and will try to find the cause of the problem.
[Bug c++/87685] New: [Regression] Calling a static method from inside a generic lambda requires to capture 'this'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87685
Bug ID: 87685
Summary: [Regression] Calling a static method from inside a
generic lambda requires to capture 'this'
Product: gcc
Version: 8.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: abun.lp at gmail dot com
Target Milestone: ---
Created attachment 44877
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44877&action=edit
preprocessed file
Hello,
We've stumbled upon what seems to be a regression in GCC 8 compared to 7.3. It
involves calling a static class method from inside a generic lambda. If the
static method is overloaded by a another non-static method, GCC complains that
'this' is not captured.
It looks like a slightly more complex version of bug 51494.
Here's an example that fails to compile on GCC 8.1.1 but compiles on 7.3 and
previous versions:
struct A
{
template static void f(T) {}
void f() {}
void foo()
{
[] (auto&& v) { A::f(v); }; // OK if parameter type is specified
}
};
Compiler output:
$ gcc -std=c++14 -v -save-temps -Wall -Wextra test.cpp
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array --with-isl --enable-libmpx
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-gnu-indirect-function --enable-cet --with-tune=generic
--with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 8.1.1 20180712 (Red Hat 8.1.1-5) (GCC)
COLLECT_GCC_OPTIONS='-std=c++14' '-v' '-save-temps' '-Wall' '-Wextra'
'-mtune=generic' '-march=x86-64'
/usr/libexec/gcc/x86_64-redhat-linux/8/cc1plus -E -quiet -v -D_GNU_SOURCE
test.cpp -mtune=generic -march=x86-64 -std=c++14 -Wall -Wextra -fpch-preprocess
-o test.ii
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/8/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/8/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-redhat-linux/8/../../../../include/c++/8
/usr/lib/gcc/x86_64-redhat-linux/8/../../../../include/c++/8/x86_64-redhat-linux
/usr/lib/gcc/x86_64-redhat-linux/8/../../../../include/c++/8/backward
/usr/lib/gcc/x86_64-redhat-linux/8/include
/usr/local/include
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-std=c++14' '-v' '-save-temps' '-Wall' '-Wextra'
'-mtune=generic' '-march=x86-64'
/usr/libexec/gcc/x86_64-redhat-linux/8/cc1plus -fpreprocessed test.ii -quiet
-dumpbase test.cpp -mtune=generic -march=x86-64 -auxbase test -Wall -Wextra
-std=c++14 -version -o test.s
GNU C++14 (GCC) version 8.1.1 20180712 (Red Hat 8.1.1-5) (x86_64-redhat-linux)
compiled by GNU C version 8.1.1 20180712 (Red Hat 8.1.1-5), GMP version
6.1.2, MPFR version 3.1.6-p2, MPC version 1.0.2, isl version isl-0.16.1-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++14 (GCC) version 8.1.1 20180712 (Red Hat 8.1.1-5) (x86_64-redhat-linux)
compiled by GNU C version 8.1.1 20180712 (Red Hat 8.1.1-5), GMP version
6.1.2, MPFR version 3.1.6-p2, MPC version 1.0.2, isl version isl-0.16.1-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 29634e2139b669a6563cdc7cebcf60bd
test.cpp: In lambda function:
test.cpp:8:27: error: ‘this’ was not captured for this lambda function
[] (auto&& v) { A::f(v); }; // OK if parameter type is specified
Remarks:
- It is important that the static method is overloaded by another non-static
method of the class.
- Specifying the type of v (i.e. making the lambda non-generic) solves the
problem.
- If A:: is omitted when calling f, then GCC 7 also fails to compile with the
same error, but GCC 6 works just fine according to godbolt.org.
Thanks,
Guillaume
[Bug ipa/87624] improve interprocedural clean up of null pointer checks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87624 Martin Liška changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||jamborm at gcc dot gnu.org --- Comment #2 from Martin Liška --- I guess Martin and Honza can provide more informations. I know that they use predicates for inlining and CP hints. Can it handle that?
[Bug sanitizer/81275] [6/7 Regression] -fsanitize=thread produce incorrect -Wreturn-type warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81275
--- Comment #13 from Martin Liška ---
(In reply to Tom de Vries from comment #12)
> (In reply to Dmitry G. Dyachenko from comment #0)
> > -fsanitize={address,undefined} unaffected
>
> FWIW, I've run into this with -fsanitize=address and gcc 7.3 (minimized from
> gdb/gdbtypes.c):
> ...
> $ cat test.c
> struct i
> {
> unsigned int i;
> };
> typedef struct i si;
> extern const si const1;
> extern const si const2;
>
> si
> foo (int c, int d)
> {
> si var = { 0 };
>
> switch (c)
> {
> case 1:
> switch (d)
> {
> case 2:
> return var;
> default:
> return const1;
> }
> break;
> default:
> return const2;
> }
> }
> $ g++-7 -O0 test.c -c -Wreturn-type -fsanitize=address
> test.c: In function ‘si foo(int, int)’:
> test.c:28:1: warning: control reaches end of non-void function
> [-Wreturn-type]
> }
> ^
> $ g++-7 -O0 test.c -c -Wreturn-type
> $
> ...
Confirmed and fixed on trunk by my commit r254437, so please use a newer GCC.
[Bug gcov-profile/87442] Add options to filter files we want to instrument for code coverage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87442 --- Comment #7 from Martin Liška --- Good then, maybe I'll do that in next weeks. It should not be so difficult from implementation point of view.
[Bug c/60440] Bogus -Wreturn-type warning after error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60440 --- Comment #10 from Martin Liška --- Agree with Joseph, but it's a low priority on my list. It's kind of error recovery and as soon you fix the first warning you should not see the second one.
[Bug lto/85132] ffmpeg runtime segfault with lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85132 --- Comment #13 from Martin Liška --- (In reply to Carl Eugen Hoyos from comment #12) > Should be fixed: > http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=10f46815 > https://trac.ffmpeg.org/ticket/7491 > > I wonder a little how the FFmpeg developers were supposed to find out about > this bug... Good, thanks for mainline fix!
[Bug web/87684] -Woverloaded-virtual is not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87684 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jonathan Wakely --- It's documented here: https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html You can always find all options for C and C++ compilers on this page, with links to the relevant part of the manual: https://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html *** This bug has been marked as a duplicate of bug 71283 ***
[Bug c++/71283] Inconsistent location for C++ warning options in the manual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71283 Jonathan Wakely changed: What|Removed |Added CC||bugzilla@poradnik-webmaster ||a.com --- Comment #8 from Jonathan Wakely --- *** Bug 87684 has been marked as a duplicate of this bug. ***
[Bug web/87684] -Woverloaded-virtual is not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87684 --- Comment #3 from Jonathan Wakely --- (In reply to Daniel Fruzynski from comment #0) > BTW, clang includes -Woverloaded-virtual in -Werror. Consider doing the same > for gcc. I suggest a separate bug for that.
[Bug target/87674] AVX512: incorrect intrinsic signature
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87674 --- Comment #2 from Jakub Jelinek --- Note, there are differences in intrinsic prototypes for many intrinsics between GCC and ICC and it isn't that big a deal e.g. in this case, it is unspecified if the intrinsics are implemented using macros or inlines and so programs really can't in these cases notice the difference. That said, I've compared prototypes of ICC and GCC intrinsics and found differences for: _bzhi_u64 second arg is unsigned int in ICC, unsigned long long in GCC _encls_u32 first arg is int in ICC, unsigned int in GCC _enclu_u32 _mm256_extract_epi16 these extract or insert short or char in ICC, int in GCC _mm256_extract_epi8 _mm256_insert_epi16 _mm256_insert_epi8 _mm256_mask_slli_epi16 the shift argument is unsigned in ICC, int in GCC _mm256_mask_slli_epi32 _mm256_mask_slli_epi64 _mm256_mask_srai_epi16 _mm256_mask_srai_epi32 _mm256_mask_srai_epi64 _mm256_mask_srli_epi32 _mm256_mask_srli_epi64 _mm256_maskz_slli_epi16 _mm256_maskz_slli_epi32 _mm256_maskz_slli_epi64 _mm256_maskz_srai_epi16 _mm256_maskz_srai_epi32 _mm256_maskz_srai_epi64 _mm256_maskz_srli_epi32 _mm256_maskz_srli_epi64 _mm256_srai_epi64 _mm512_mask_slli_epi16 _mm512_mask_srai_epi16 _mm512_mask_srli_epi16 _mm512_maskz_slli_epi16 _mm512_maskz_srai_epi16 _mm512_slli_epi16 _mm512_srai_epi16 _mm512_srli_epi16 _mm_mask_slli_epi16 _mm_mask_slli_epi32 _mm_mask_slli_epi64 _mm_mask_srai_epi16 _mm_mask_srai_epi32 _mm_mask_srai_epi64 _mm_mask_srli_epi32 _mm_mask_srli_epi64 _mm_maskz_slli_epi16 _mm_maskz_slli_epi32 _mm_maskz_slli_epi64 _mm_maskz_srai_epi16 _mm_maskz_srai_epi32 _mm_maskz_srai_epi64 _mm_maskz_srli_epi32 _mm_maskz_srli_epi64 _mm_srai_epi64 _mm512_mask_prefetch_i64scatter_pd fixed by this PR _mm512_mask_prefetch_i64scatter_ps _mm_mask_mullo_epi32 _mm_mask_packs_epi32 _mm_mask_packus_epi32 _mm512_stream_load_si512argument is const void * in ICC, void * in GCC _mm512_stream_pd argument is void * in ICC, double * in GCC _mm512_stream_ps argument is void * in ICC, float * in GCC _mm512_stream_si512 argument is void * in ICC, __m512i * in GCC _mm_stream_load_si128argument is const __m128i * in ICC, __m128i * in GCC _mm_clflushopt argument is const void * in ICC, void * in GCC _mm_clwb _mm_prefetch argument is const char * in ICC, const void * in GCC _mm_shuffle_ps last argument is unsigned int in ICC, int in GCC _xgetbv sign differences in return type or argument types _xrstor _xrstor64 _xrstors _xrstors64 _xsave _xsave64 _xsavec _xsavec64 _xsaveopt _xsaveopt64 _xsaves _xsaves64 _xsetbv _xtest returns unsigned char in ICC, int in GCC Dunno if we want to change anything from the above beyond the above patch, perhaps the const type * vs. type * differences might be highest on the list to change.
[Bug libstdc++/87666] Memory access errors when using c++ 17 filesystem library and "-mcpu=cortex-a53"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87666 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jonathan Wakely --- I think this is caused by inconsistent values of the __gnu_cxx::__default_lock_policy constant in the code in libstdc++fs.a and your object file, caused by the different -march option. *** This bug has been marked as a duplicate of bug 67843 ***
[Bug libstdc++/67843] experimental/filesystem/iterators/directory_iterator.cc fails on armv5t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67843 Jonathan Wakely changed: What|Removed |Added CC||christian_hoff at gmx dot net --- Comment #10 from Jonathan Wakely --- *** Bug 87666 has been marked as a duplicate of this bug. ***
[Bug c++/87667] -Wformat + typed enum class - difference with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87667 --- Comment #1 from Jonathan Wakely --- It's a warning, why do you think either compiler is wrong?
[Bug c++/87671] Incorrect debugging information for unique_ptr passed to a constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87671 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-22 Known to work||9.0 Ever confirmed|0 |1 Known to fail||4.9.4, 5.5.0, 6.4.0, 7.3.0, ||8.2.0 --- Comment #3 from Jonathan Wakely --- I see this with old releases but not on current trunk.
[Bug c++/87685] [8/9 Regression] Calling a static method from inside a generic lambda requires to capture 'this'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87685 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-22 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |8.3 Summary|[Regression] Calling a |[8/9 Regression] Calling a |static method from inside a |static method from inside a |generic lambda requires to |generic lambda requires to |capture 'this' |capture 'this' Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r251438.
[Bug c++/87667] -Wformat + typed enum class - difference with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87667 --- Comment #2 from Roman Lebedev --- (In reply to Jonathan Wakely from comment #1) > It's a warning, why do you think either compiler is wrong? Either it is incorrect to pass `enum class Enum : unsigned short` when the format specifier is %hx (i.e. `unsigned short`), and then the warning is justified; or the other way around, it is correct to pass `Enum`, and the warning is not justified, or needs different wording.
[Bug c++/87671] Incorrect debugging information for unique_ptr passed to a constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87671
--- Comment #4 from Jonathan Wakely ---
The problem is that GDB sees a stack address for the int* member of the
unique_ptr, but it should be a pointer to the 'int' on the heap:
Breakpoint 1, A::A (this=0x7fffd2b7, ptr=std::unique_ptr = {...}) at
up.cc:7
(gdb) p &ptr
$6 = (std::unique_ptr > *) 0x7fffd290
(gdb) p ptr._M_t._M_t._M_head_impl
$7 = (int *) 0x7fffd2b8
The Incorrect value for *ptr is just because it dereferences that bad address.
If you step into the operator* function you see that the right address is
returned from get()
(gdb) step
std::unique_ptr >::operator*
(this=0x7fffd2b8) at
/home/jwakely/gcc/8/include/c++/8.2.1/bits/unique_ptr.h:329
std::unique_ptr >::get (this=0x7fffd2b8) at
/home/jwakely/gcc/8/include/c++/8.2.1/bits/unique_ptr.h:343
(gdb) finish
Run till exit from #0 std::unique_ptr >::get
(this=0x7fffd2b8) at
/home/jwakely/gcc/8/include/c++/8.2.1/bits/unique_ptr.h:343
std::unique_ptr >::operator*
(this=0x7fffd2b8) at
/home/jwakely/gcc/8/include/c++/8.2.1/bits/unique_ptr.h:330
Value returned is $8 = (int *) 0x614e70
(gdb) p *$8
$9 = 42
I don't know why GDB sees a bad value for the unique_ptr's data member.
[Bug fortran/87495] Warning: ‘fastcall’ attribute ignored [-Wattributes] for !GCC$ ATTRIBUTES
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87495
Martin Liška changed:
What|Removed |Added
Status|WAITING |REOPENED
--- Comment #7 from Martin Liška ---
OK, the fastcall is a special one, but I see it for all of:
const ext_attr_t ext_attr_list[] = {
{ "dllimport",EXT_ATTR_DLLIMPORT,"dllimport" },
{ "dllexport",EXT_ATTR_DLLEXPORT,"dllexport" },
{ "cdecl",EXT_ATTR_CDECL,"cdecl" },
{ "stdcall", EXT_ATTR_STDCALL, "stdcall" },
{ "fastcall", EXT_ATTR_FASTCALL, "fastcall" },
{ "no_arg_check", EXT_ATTR_NO_ARG_CHECK, NULL},
{ NULL, EXT_ATTR_LAST, NULL}
};
gfortran f.f90
f.f90:1:0:
elemental real function sin(arg)
Warning: ‘cdecl’ attribute ignored [-Wattributes]
[Bug fortran/87495] Warning: ‘fastcall’ attribute ignored [-Wattributes] for !GCC$ ATTRIBUTES
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87495
--- Comment #8 from rguenther at suse dot de ---
On Mon, 22 Oct 2018, marxin at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87495
>
> Martin Liška changed:
>
>What|Removed |Added
>
> Status|WAITING |REOPENED
>
> --- Comment #7 from Martin Liška ---
> OK, the fastcall is a special one, but I see it for all of:
>
> const ext_attr_t ext_attr_list[] = {
> { "dllimport",EXT_ATTR_DLLIMPORT,"dllimport" },
> { "dllexport",EXT_ATTR_DLLEXPORT,"dllexport" },
> { "cdecl",EXT_ATTR_CDECL,"cdecl" },
> { "stdcall", EXT_ATTR_STDCALL, "stdcall" },
> { "fastcall", EXT_ATTR_FASTCALL, "fastcall" },
> { "no_arg_check", EXT_ATTR_NO_ARG_CHECK, NULL},
> { NULL, EXT_ATTR_LAST, NULL}
> };
>
> gfortran f.f90
> f.f90:1:0:
>
> elemental real function sin(arg)
>
> Warning: ‘cdecl’ attribute ignored [-Wattributes]
But that's in the same ballpark. All of them seem to be...
(just check on a C testcase with -Wall).
[Bug fortran/87495] Warning: ‘fastcall’ attribute ignored [-Wattributes] for !GCC$ ATTRIBUTES
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87495 Dominique d'Humieres changed: What|Removed |Added Status|REOPENED|NEW --- Comment #9 from Dominique d'Humieres --- This PR has never been closed.
[Bug tree-optimization/87686] New: [9 regression] internal error in expand, at tree-switch-conversion.c:916
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87686
Bug ID: 87686
Summary: [9 regression] internal error in expand, at
tree-switch-conversion.c:916
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ebotcazou at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-linux
Created attachment 44878
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44878&action=edit
Testcase
It's a doubly-reduced testcase (reduced for this PR after having being reduced
for another issue) so it might be borderline, but it should not ICE anyway:
t.cpp: In member function 'k k::l()':
t.cpp:16:18: warning: no return statement in function returning non-void
[-Wreturn-type]
16 | k l() { j.i(); }
| ^
t.cpp: In member function 'a a::i()':
t.cpp:12:3: warning: control reaches end of non-void function [-Wreturn-type]
12 | }
| ^
during GIMPLE pass: switchconv
t.cpp: In member function 'k k::l()':
t.cpp:18:22: internal compiler error: in expand, at
tree-switch-conversion.c:916
18 | void m(k h) { h.l(); }
| ^
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug fortran/87495] Warning: ‘fastcall’ attribute ignored [-Wattributes] for !GCC$ ATTRIBUTES
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87495
--- Comment #10 from Martin Liška ---
(In reply to rguent...@suse.de from comment #8)
> On Mon, 22 Oct 2018, marxin at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87495
> >
> > Martin Liška changed:
> >
> >What|Removed |Added
> >
> > Status|WAITING |REOPENED
> >
> > --- Comment #7 from Martin Liška ---
> > OK, the fastcall is a special one, but I see it for all of:
> >
> > const ext_attr_t ext_attr_list[] = {
> > { "dllimport",EXT_ATTR_DLLIMPORT,"dllimport" },
> > { "dllexport",EXT_ATTR_DLLEXPORT,"dllexport" },
> > { "cdecl",EXT_ATTR_CDECL,"cdecl" },
> > { "stdcall", EXT_ATTR_STDCALL, "stdcall" },
> > { "fastcall", EXT_ATTR_FASTCALL, "fastcall" },
> > { "no_arg_check", EXT_ATTR_NO_ARG_CHECK, NULL},
> > { NULL, EXT_ATTR_LAST, NULL}
> > };
> >
> > gfortran f.f90
> > f.f90:1:0:
> >
> > elemental real function sin(arg)
> >
> > Warning: ‘cdecl’ attribute ignored [-Wattributes]
>
> But that's in the same ballpark. All of them seem to be...
> (just check on a C testcase with -Wall).
Ah, sorry, now I see it!
[Bug bootstrap/87640] [9 regression] internal compiler error: in check, at tree-vrp.c:155
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87640 --- Comment #10 from Richard Biener --- Author: rguenth Date: Mon Oct 22 10:22:48 2018 New Revision: 265375 URL: https://gcc.gnu.org/viewcvs?rev=265375&root=gcc&view=rev Log: 2018-10-22 Richard Biener PR tree-optimization/87640 * tree-vrp.c (set_value_range_with_overflow): Decompose incomplete result. (extract_range_from_binary_expr_1): Adjust. * gcc.dg/torture/pr87640.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr87640.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug bootstrap/87640] [9 regression] internal compiler error: in check, at tree-vrp.c:155
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87640 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Richard Biener --- Fixed.
[Bug c/87682] gcc/mem-stats.h:172: possible broken comparison operator ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87682 --- Comment #2 from Richard Biener --- Author: rguenth Date: Mon Oct 22 10:25:28 2018 New Revision: 265376 URL: https://gcc.gnu.org/viewcvs?rev=265376&root=gcc&view=rev Log: 2018-10-22 Richard Biener PR middle-end/87682 * mem-stats.h (mem_usage::operator==): Fix pasto. Modified: trunk/gcc/ChangeLog trunk/gcc/mem-stats.h
[Bug c/87682] gcc/mem-stats.h:172: possible broken comparison operator ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87682 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed.
[Bug c++/87676] Presence of variadic constructor template breaks overload resolution for other constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87676
--- Comment #3 from Harald van Dijk ---
(In reply to Jonathan Wakely from comment #1)
> The template constructor allows s({1, 2, 3}) to mean s(S2{1,2,3}) which
> tries to use the deleted copy constructor.
Thanks, I think you're right about that. The diagnostic didn't help me
understand what was going on, but now that I do understand it, I do not see how
it could be improved.
But all other things equal, aren't rvalue reference overloads preferred over
lvalue reference overloads, so shouldn't S1 && still be preferred over const S2
&? That appears to be the logic Intel is using, and in a similar example,
struct S1 {};
struct S2 {};
void f(const S1 &);
void f(S2 &&);
void g() { f({}); }
clang does agree that this calls f(S2 &&) as well, but GCC still rejects it as
ambiguous.
The relevant bit in the standard seems to be [over.ics.rank]p3.2.3
: (yes, I know it's a draft, but
this text is also present in the actual standard)
> - Standard conversion sequence S1 is a better conversion sequence than
> standard conversion sequence S2 if
> [...]
> - S1 and S2 are reference bindings and neither refers to an implicit object
> parameter of a non-static member function declared without a ref-qualifier,
> and S1 binds an rvalue reference to an rvalue and S2 binds an lvalue reference
This appears to not just disambiguate between lvalue and rvalue references to
the same type, it also disambiguates between lvalue and rvalue references to
different types.
[Bug tree-optimization/87686] [9 regression] internal error in expand, at tree-switch-conversion.c:916
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87686 Richard Biener changed: What|Removed |Added CC||mliska at suse dot cz Target Milestone|--- |9.0
[Bug tree-optimization/87686] [9 regression] internal error in expand, at tree-switch-conversion.c:916
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87686 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-22 CC||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Mine.
[Bug target/87674] AVX512: incorrect intrinsic signature
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87674 --- Comment #3 from Wenzel Jakob --- Thanks -- this patch works for me. With regards to the signature difference: I had already stumbled about the (float *) vs (some value *) difference in some intrinsics. In the best case differences cause warnings (ok, but still annoying :)), in the worst case special casts are needed for GCC, making intrinsics code less portable between compilers. So my vote would definitely matching ICC behavior 1:1.
[Bug tree-optimization/87686] [9 regression] internal error in expand, at tree-switch-conversion.c:916
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87686 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #2 from Martin Liška --- Started with r263947, which is where I added just a new assert.
[Bug tree-optimization/87687] New: s390x gcc 9 ICE in value_range::check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87687
Bug ID: 87687
Summary: s390x gcc 9 ICE in value_range::check
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: iii at linux dot ibm.com
Target Milestone: ---
Target: s390x-redhat-linux
SVN r265373 / git f9fd74d64e9:
$ f9fd74d64e9-install/bin/gcc -x c -O2 -c -
void b() {
int c = 1, d, e = 4096;
for (; c; c--) {
d = 1;
for (; d; d--)
e--;
}
}
during GIMPLE pass: evrp
: In function ‘b’:
:8:1: internal compiler error: in check, at tree-vrp.c:155
0x1ab6019 value_range::check()
/home/iii/ibm/gcc-bisect/src/gcc/tree-vrp.c:155
0x1ab9a35 value_range::value_range(value_range_kind, tree_node*, tree_node*,
bitmap_head*)
/home/iii/ibm/gcc-bisect/src/gcc/tree-vrp.c:110
0x1ab9a35 set_value_range_with_overflow
/home/iii/ibm/gcc-bisect/src/gcc/tree-vrp.c:1422
0x1ab9a35 extract_range_from_binary_expr_1(value_range*, tree_code, tree_node*,
value_range const*, value_range const*)
/home/iii/ibm/gcc-bisect/src/gcc/tree-vrp.c:1679
0x1b48af7 vr_values::extract_range_from_binary_expr(value_range*, tree_code,
tree_node*, tree_node*, tree_node*)
/home/iii/ibm/gcc-bisect/src/gcc/vr-values.c:734
0x1b4b0d1 vr_values::extract_range_from_assignment(value_range*, gassign*)
/home/iii/ibm/gcc-bisect/src/gcc/vr-values.c:1389
0x1f03e29 evrp_range_analyzer::record_ranges_from_stmt(gimple*, bool)
/home/iii/ibm/gcc-bisect/src/gcc/gimple-ssa-evrp-analyze.c:285
0x1f0228f evrp_dom_walker::before_dom_children(basic_block_def*)
/home/iii/ibm/gcc-bisect/src/gcc/gimple-ssa-evrp.c:139
0x1edb47d dom_walker::walk(basic_block_def*)
/home/iii/ibm/gcc-bisect/src/gcc/domwalk.c:353
0x1f02dc9 execute_early_vrp
/home/iii/ibm/gcc-bisect/src/gcc/gimple-ssa-evrp.c:311
0x1f02dc9 execute
/home/iii/ibm/gcc-bisect/src/gcc/gimple-ssa-evrp.c:348
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug web/87684] -Woverloaded-virtual is not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87684 --- Comment #4 from Daniel Fruzynski --- Thanks for the link. I have tried to google for "gcc Woverloaded-virtual" and it did not show on the top, so I assumed that option is undocumented. I will open new issue to add it to -Wall.
[Bug c++/87667] -Wformat + typed enum class - difference with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87667 --- Comment #3 from Jonathan Wakely --- I think the warning is correct. A scoped enumeration type is not subject to integral promotion, so the argument is not promoted to int. When the body of printf tries to read an int from the argument the behaviour is undefined.
[Bug tree-optimization/87687] s390x gcc 9 ICE in value_range::check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87687 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Richard Biener --- dup *** This bug has been marked as a duplicate of bug 87640 ***
[Bug bootstrap/87640] [9 regression] internal compiler error: in check, at tree-vrp.c:155
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87640 Richard Biener changed: What|Removed |Added CC||iii at linux dot ibm.com --- Comment #12 from Richard Biener --- *** Bug 87687 has been marked as a duplicate of this bug. ***
[Bug c++/87676] Presence of variadic constructor template breaks overload resolution for other constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87676
--- Comment #4 from Jonathan Wakely ---
Before the conversion sequence that binds a reference you need to initialize
the underlying temporary, which is a list-initialization sequence. You have
list-initialization sequence L1 from {1,2,3} to S1 and list-initialization
sequence L2 from {1,2,3} to S2. Neither L1 nor L2 is better than the other
according to http://eel.is/c++draft/over.match.best#over.ics.rank-3.1
[Bug c++/87676] Presence of variadic constructor template breaks overload resolution for other constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87676 --- Comment #5 from Jonathan Wakely --- That's how I interpret it anyway, but I could be convinced otherwise. And maybe the standard isn't clear enough here.
[Bug tree-optimization/87613] Non-reachable default required in switch statement to get optimal code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87613
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |WORKSFORME
--- Comment #2 from Martin Liška ---
Yes, it was fixed by Jakub in GCC 8 in r247538. As Richi said, to suppress the
warning, please use __builtin_unreachable () like:
template int foo();
typedef int (*int_fun)();
inline int_fun get_fun(unsigned int x)
{
switch(x&7)
{
case 0: return foo<0>;
case 1: return foo<1>;
case 2: return foo<2>;
case 3: return foo<3>;
case 4: return foo<4>;
case 5: return foo<5>;
case 6: return foo<6>;
case 7: return foo<7>;
default: __builtin_unreachable (); // never happens
}
// alternative to default case:
// return 0; // never happens
}
int bla(unsigned int x)
{
return get_fun(x)();
}
[Bug c++/87671] Incorrect debugging information for unique_ptr passed to a constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87671 --- Comment #5 from Jonathan Wakely --- Compiled with GCC 8 the debuginfo has: DW_TAG_formal_parameter DW_AT_abstract_origin (0x3cfb "ptr") DW_AT_location( [0x, 0x0010): DW_OP_reg4 RSI [0x0010, 0x007b): 01 54 9f) Compiled with GCC 9: DW_TAG_formal_parameter DW_AT_abstract_origin (0x3cfb "ptr") DW_AT_location( [0x, 0x0010): DW_OP_breg4 RSI+0 [0x0010, 0x007b): 01 54) That's the only difference I see in the outputs of `llvm-dwarfdump --diff`.
[Bug c++/87676] Presence of variadic constructor template breaks overload resolution for other constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87676
--- Comment #6 from Harald van Dijk ---
(In reply to Jonathan Wakely from comment #4)
> Before the conversion sequence that binds a reference you need to initialize
> the underlying temporary, which is a list-initialization sequence. You have
> list-initialization sequence L1 from {1,2,3} to S1 and list-initialization
> sequence L2 from {1,2,3} to S2. Neither L1 nor L2 is better than the other
> according to http://eel.is/c++draft/over.match.best#over.ics.rank-3.1
True, which is why I think it falls back to the subsequent binding to the
temporary. If you take an ambiguous list-init sequence as sufficient reason to
not look at the rest, then would not even
struct S {};
void f(const S &);
void f(S &&);
void g() { f({}); }
be ambiguous? Both start with the same list-init sequence, so neither is better
than the other. But here, GCC does look beyond that and prefer f(S &&).
I'll be happy to agree that the standard isn't clear, and that I might well be
wrong.
[Bug ada/87688] New: [9.0 regression] ACATS cb1010a cb1010d failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87688 Bug ID: 87688 Summary: [9.0 regression] ACATS cb1010a cb1010d failure Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: simon at pushface dot org Target Milestone: --- Host: x86_64-apple-darwin15 Created attachment 44879 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44879&action=edit Extract from acats suite With r265267, the two tests noted fail. OK with r264669. The build command is (effectively) gnatmake -gnatws -O2 -gnat95 -fstack-check cb1010a.adb and the output is ,.,. CB1010A ACATS 2.5 18-10-19 17:40:00 CB1010A CHECK THAT STORAGE_ERROR IS RAISED WHEN STORAGE ALLOCATED TO A TASK IS EXCEEDED. - CB1010A CHECK TASKS THAT DO NOT HANDLE STORAGE_ERROR PRIOR TO RENDEZVOUS. raised STORAGE_ERROR : stack overflow Should be: ,.,. CB1010A ACATS 4.1 18-10-22 11:15:25 CB1010A CHECK THAT STORAGE_ERROR IS RAISED WHEN STORAGE ALLOCATED TO A TASK IS EXCEEDED. - CB1010A CHECK TASKS THAT DO NOT HANDLE STORAGE_ERROR PRIOR TO RENDEZVOUS. - CB1010A CHECK TASKS THAT DO HANDLE STORAGE_ERROR PRIOR TO RENDEZVOUS. - CB1010A CHECK TASKS THAT DO NOT HANDLE STORAGE_ERROR DURING RENDEZVOUS. CB1010A PASSED . Removing either -O2 or -fstack-check makes the tests execute correctly. (Note, the build was configured --without-isl because of PR87640, now fixed.)
[Bug ada/87688] [9.0 regression] ACATS cb1010a cb1010d failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87688 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-22 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed, it appeared between revisions r264819 (OK) and r264901 (FAIL).
[Bug target/86677] popcount builtin detection is breaking some kernel build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86677
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #9 from Martin Liška ---
Taking look at ../drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
file:
The __builtin_popcount is generated from:
static int brcmf_setup_wiphybands(struct brcmf_cfg80211_info *cfg)
{
...
} else {
for (nchain = 0; rxchain; nchain++)
rxchain = rxchain & (rxchain - 1);
}
...
}
It started from r262486. I would that in this situation it's maybe unexpected
that a popcount call will be eventually generated. So I'm for an option what
will disable the pattern recognition.
[Bug debug/86687] Wrong debug information for string types passed as parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86687 Jonathan Wakely changed: What|Removed |Added CC||anton at swarmer dot me --- Comment #14 from Jonathan Wakely --- *** Bug 87671 has been marked as a duplicate of this bug. ***
[Bug c++/87671] Incorrect debugging information for unique_ptr passed to a constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87671 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Jonathan Wakely --- That does seem to explain the difference. With GCC 8 GDB thinks that 'ptr' is passed in the register %rsi so the value in the register is the value of the unique_ptr's member. With GCC 9 it correctly knows that the param is passed by invisible reference, and so the value in the register is the address of the unique_ptr on the stack. This was fixed on trunk by r263164 so is a dup of PR 86687 *** This bug has been marked as a duplicate of bug 86687 ***
[Bug tree-optimization/87686] [9 regression] internal error in expand, at tree-switch-conversion.c:916
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87686 --- Comment #3 from Martin Liška --- Author: marxin Date: Mon Oct 22 13:09:33 2018 New Revision: 265388 URL: https://gcc.gnu.org/viewcvs?rev=265388&root=gcc&view=rev Log: Revert r263947. 2018-10-22 Martin Liska PR tree-optimization/87686 Revert 2018-08-29 Martin Liska * tree-switch-conversion.c (switch_conversion::expand): Strenghten assumption about gswitch statements. 2018-10-22 Martin Liska PR tree-optimization/87686 * g++.dg/tree-ssa/pr87686.C: New test. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr87686.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-switch-conversion.c
[Bug c++/87671] Incorrect debugging information for unique_ptr passed to a constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87671 --- Comment #7 from Anton Barkovsky --- (In reply to Jonathan Wakely from comment #6) > That does seem to explain the difference. With GCC 8 GDB thinks that 'ptr' > is passed in the register %rsi so the value in the register is the value of > the unique_ptr's member. With GCC 9 it correctly knows that the param is > passed by invisible reference, and so the value in the register is the > address of the unique_ptr on the stack. > > This was fixed on trunk by r263164 so is a dup of PR 86687 > > *** This bug has been marked as a duplicate of bug 86687 *** Thank you very much for the timely analysis. Is there a chance this fix will be backported to 8.2.2? This is quite disruptive for development.
[Bug c++/87671] Incorrect debugging information for unique_ptr passed to a constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87671 --- Comment #8 from Jonathan Wakely --- There's no such thing as 8.2.2, the next release will be 8.3.0, see https://gcc.gnu.org/develop.html#num_scheme Tom, is it time to backport this from trunk to gcc-7-branch and gcc-8-branch?
[Bug tree-optimization/87686] [9 regression] internal error in expand, at tree-switch-conversion.c:916
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87686 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Liška --- Fixed.
[Bug target/86677] popcount builtin detection is breaking some kernel build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86677
--- Comment #10 from Wilco ---
(In reply to Martin Liška from comment #9)
> Taking look at
> ../drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c file:
>
> The __builtin_popcount is generated from:
>
> static int brcmf_setup_wiphybands(struct brcmf_cfg80211_info *cfg)
> {
> ...
> } else {
> for (nchain = 0; rxchain; nchain++)
>rxchain = rxchain & (rxchain - 1);
> }
> ...
> }
>
> It started from r262486. I would that in this situation it's maybe
> unexpected that a popcount call will be eventually generated. So I'm for an
> option what will disable the pattern recognition.
I'd say this is exactly a case where using a faster popcount instruction helps
- if available of course.
Is there any reason -fno-builtin-popcount can't also block automatic generation
of popcount?
[Bug c++/87665] [8/9 Regression] gcc HEAD (svn: 265340) breaks elements on resize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87665 Jonathan Wakely changed: What|Removed |Added CC||ville at gcc dot gnu.org Target Milestone|8.3 |--- --- Comment #4 from Jonathan Wakely --- Bisecting on powerpc64le shows it regressed with r254694 which makes a bit more sense (as std::vector reallocation does use placement new to move the values): Remove the null check from placement new in all modes gcc/cp/ Remove the null check from placement new in all modes * init.c (build_new_1): Don't do a null check for a namespace-scope non-replaceable placement new in any mode unless -fcheck-new is provided. testsuite/ Remove the null check from placement new in all modes * g++.dg/init/pr35878_1.C: Adjust. * g++.dg/init/pr35878_4.C: New. * g++.dg/torture/pr48695.C: Adjust. * g++.dg/tree-ssa/pr31146-2.C: Likewise. * g++.dg/tree-ssa/pr41428.C: Adjust.
[Bug fortran/87689] New: Memory corruption on Power 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87689 Bug ID: 87689 Summary: Memory corruption on Power 8 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: judicael.grasset at stfc dot ac.uk Target Milestone: --- Hello, I am compiling this code with gfortran 7.1.0 on a power 8 machine: main.f: program main implicit none character :: c character(len=20) :: res, doesntwork_p8 external doesntwork_p8 c = 'o' res = doesntwork_p8(c,1,2,3,4,5,6) write(*,*)res end program main doesnwork_p8.f: function doesntwork_p8(c,a1,a2,a3,a4,a5,a6) implicit none character(len=20) :: doesntwork_p8 character :: c integer :: a1,a2,a3,a4,a5,a6 write(*,*)a1,a2,a3,a4,a5,a6 write(*,*)c doesntwork_p8 = 'foo' return end And when I run it, it prints: 1 2 3 4 5 0 � foo But I expect: 1 2 3 4 5 6 o foo Also if compiled with fcheck=all, a runtime message say: At line 1 of file doesntwork_p8.f Fortran runtime error: Actual string length is shorter than the declared one for dummy argument 'c' (0/1) gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/gpfs/paragon/local/apps/gcc/gcc/7.1.0/bin/../libexec/gcc/powerpc64le-unknown-linux-gnu/7.1.0/lto-wrapper Target: powerpc64le-unknown-linux-gnu Configured with: ./configure --prefix=/gpfs/panther/local/apps/gcc/gcc/7.1.0 --enable-languages=c,c++,fortran --disable-multilib --disable-bootstrap --with-system-zlib --enable-__cxa_atexit --disable-nls --disable-linux-futex Thread model: posix gcc version 7.1.0 (GCC)
[Bug c++/87665] [8/9 Regression] gcc HEAD (svn: 265340) breaks elements on resize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87665 --- Comment #5 from Jonathan Wakely --- Confirmed that -fcheck-null fixes the miscompilation.
[Bug target/86677] popcount builtin detection is breaking some kernel build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86677
--- Comment #11 from Martin Liška ---
(In reply to Wilco from comment #10)
> (In reply to Martin Liška from comment #9)
> > Taking look at
> > ../drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c file:
> >
> > The __builtin_popcount is generated from:
> >
> > static int brcmf_setup_wiphybands(struct brcmf_cfg80211_info *cfg)
> > {
> > ...
> > } else {
> > for (nchain = 0; rxchain; nchain++)
> >rxchain = rxchain & (rxchain - 1);
> > }
> > ...
> > }
> >
> > It started from r262486. I would that in this situation it's maybe
> > unexpected that a popcount call will be eventually generated. So I'm for an
> > option what will disable the pattern recognition.
>
> I'd say this is exactly a case where using a faster popcount instruction
> helps - if available of course.
Yes, but as seen in PR87528, using a libgcc can slow down a SPEC benchmark. But
it's related to generic tuning.
>
> Is there any reason -fno-builtin-popcount can't also block automatic
> generation of popcount?
Do we really have such option?
[Bug target/86677] popcount builtin detection is breaking some kernel build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86677
--- Comment #12 from Richard Biener ---
(In reply to Martin Liška from comment #11)
> (In reply to Wilco from comment #10)
> > (In reply to Martin Liška from comment #9)
> > > Taking look at
> > > ../drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c file:
> > >
> > > The __builtin_popcount is generated from:
> > >
> > > static int brcmf_setup_wiphybands(struct brcmf_cfg80211_info *cfg)
> > > {
> > > ...
> > > } else {
> > > for (nchain = 0; rxchain; nchain++)
> > >rxchain = rxchain & (rxchain - 1);
> > > }
> > > ...
> > > }
> > >
> > > It started from r262486. I would that in this situation it's maybe
> > > unexpected that a popcount call will be eventually generated. So I'm for
> > > an
> > > option what will disable the pattern recognition.
> >
> > I'd say this is exactly a case where using a faster popcount instruction
> > helps - if available of course.
>
> Yes, but as seen in PR87528, using a libgcc can slow down a SPEC benchmark.
> But it's related to generic tuning.
>
> >
> > Is there any reason -fno-builtin-popcount can't also block automatic
> > generation of popcount?
>
> Do we really have such option?
None that would work in the way intended.
Note that as I said in the referenced thread a fix could boil down to
adjusting expression_expensive_p to return true if there's no optab
for the builtin/IFN and/or adjusting is_inexpensive_builtin in that way
(with wider effect).
Note that number_of_iterations_popcount might as well create IFN_POPCOUNT
for the case there _is_ an optab. I'm not sure whether we only have/allow
the IFN in case there's an optab.
So let's discuss the efficiency issue in PR87528. PR86677 is really
invalid given you cannot elide providing libgcc.
[Bug c++/87671] Incorrect debugging information for unique_ptr passed to a constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87671 --- Comment #9 from Richard Biener --- (In reply to Jonathan Wakely from comment #8) > There's no such thing as 8.2.2, the next release will be 8.3.0, see > https://gcc.gnu.org/develop.html#num_scheme > > Tom, is it time to backport this from trunk to gcc-7-branch and gcc-8-branch? Yeah, I think so.
[Bug fortran/87689] Memory corruption on Power 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87689 Richard Biener changed: What|Removed |Added Target||powerpc64le Status|UNCONFIRMED |WAITING Last reconfirmed||2018-10-22 Version|unknown |7.1.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Please try newer versions like 7.3.0 and provide the compiler options you are using.
[Bug middle-end/63155] [6/7 Regression] memory hog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63155 --- Comment #51 from Richard Biener --- Author: rguenth Date: Mon Oct 22 13:54:23 2018 New Revision: 265390 URL: https://gcc.gnu.org/viewcvs?rev=265390&root=gcc&view=rev Log: 2018-10-22 Steven Bosscher Richard Biener * bitmap.h: Update data structure documentation, including a description of bitmap views as either linked-lists or splay trees. (struct bitmap_element_def): Update comments for splay tree bitmaps. (struct bitmap_head_def): Likewise. (bitmap_list_view, bitmap_tree_view): New prototypes. (bitmap_initialize_stat): Initialize a bitmap_head's indx and tree_form fields. (bmp_iter_set_init): Assert the iterated bitmaps are in list form. (bmp_iter_and_init, bmp_iter_and_compl_init): Likewise. * bitmap.c (bitmap_elem_to_freelist): Unregister overhead of a released bitmap element here. (bitmap_element_free): Remove. (bitmap_elt_clear_from): Work on splay tree bitmaps. (bitmap_list_link_element): Renamed from bitmap_element_link. Move this function similar ones such that linked-list bitmap implementation functions are grouped. (bitmap_list_unlink_element): Renamed from bitmap_element_unlink, and moved for grouping. (bitmap_list_insert_element_after): Renamed from bitmap_elt_insert_after, and moved for grouping. (bitmap_list_find_element): New function spliced from bitmap_find_bit. (bitmap_tree_link_left, bitmap_tree_link_right, bitmap_tree_rotate_left, bitmap_tree_rotate_right, bitmap_tree_splay, bitmap_tree_link_element, bitmap_tree_unlink_element, bitmap_tree_find_element): New functions for splay-tree bitmap implementation. (bitmap_element_link, bitmap_element_unlink, bitmap_elt_insert_after): Renamed and moved, see above entries. (bitmap_tree_listify_from): New function to convert part of a splay tree bitmap to a linked-list bitmap. (bitmap_list_view): Convert a splay tree bitmap to linked-list form. (bitmap_tree_view): Convert a linked-list bitmap to splay tree form. (bitmap_find_bit): Remove. (bitmap_clear, bitmap_clear_bit, bitmap_set_bit, bitmap_single_bit_set_p, bitmap_first_set_bit, bitmap_last_set_bit): Handle splay tree bitmaps. (bitmap_copy, bitmap_count_bits, bitmap_and, bitmap_and_into, bitmap_elt_copy, bitmap_and_compl, bitmap_and_compl_into, bitmap_compl_and_into, bitmap_elt_ior, bitmap_ior, bitmap_ior_into, bitmap_xor, bitmap_xor_into, bitmap_equal_p, bitmap_intersect_p, bitmap_intersect_compl_p, bitmap_ior_and_compl, bitmap_ior_and_compl_into, bitmap_set_range, bitmap_clear_range, bitmap_hash): Reject trying to act on splay tree bitmaps. Make corresponding changes to use linked-list specific bitmap_element manipulation functions as applicable for efficiency. (bitmap_tree_to_vec): New function. (debug_bitmap_elt_file): New function split out from ... (debug_bitmap_file): ... here. Handle splay tree bitmaps. (bitmap_print): Likewise. PR tree-optimization/63155 * tree-ssa-propagate.c (ssa_prop_init): Use tree-view for the SSA edge worklists. * tree-ssa-coalesce.c (coalesce_ssa_name): Populate used_in_copies in tree-view. Modified: trunk/gcc/ChangeLog trunk/gcc/bitmap.c trunk/gcc/bitmap.h trunk/gcc/tree-ssa-coalesce.c trunk/gcc/tree-ssa-propagate.c
[Bug ada/87688] [9.0 regression] ACATS cb1010a cb1010d failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87688 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.0
[Bug target/87598] [8/9 Regression] Rejects "%a0" with constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87598 --- Comment #6 from Segher Boessenkool --- No problem, and thanks for finding and reporting the bug :-) This bug is over 25 years old... I'm committing a fix for the rs6000 part.
[Bug target/87598] [8/9 Regression] Rejects "%a0" with constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87598 --- Comment #7 from Segher Boessenkool --- Author: segher Date: Mon Oct 22 14:03:22 2018 New Revision: 265392 URL: https://gcc.gnu.org/viewcvs?rev=265392&root=gcc&view=rev Log: rs6000: Handle print_operand_address for unexpected RTL (PR87598) As the PR shows, the user can force this to be called on at least some RTL that is not a valid address. Most targets treat this as if the user knows best; let's do the same. PR target/87598 * config/rs6000/rs6000.c (print_operand_address): For unexpected RTL call output_addr_const and hope for the best. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c
[Bug fortran/87689] Memory corruption on Power 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87689 --- Comment #2 from Judicaël Grasset --- I have tried with gfortran 8.2.0 I have compiled with: gfortran -g main.f doesntwork_p8.f -Wall -Wextra -o exe When running I get: 1 2 3 4 5 0 � foo So it seems the problem still exist. If I add fcheck=all at the compilation, I do not get any run-time error message when executing the program, but the result is still wrong: 1 2 3 4 5 -46855 o foo
[Bug rtl-optimization/87678] Redundant vmovss with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87678 --- Comment #2 from Segher Boessenkool --- This is a much more general problem in combine. In general it only tries once, and it only tries the fully simplified form, including known bit values etc.
