[Bug target/91103] New: AVX512 vector element extract uses more than 1 shuffle instruction; VALIGND can grab any element
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91103
Bug ID: 91103
Summary: AVX512 vector element extract uses more than 1 shuffle
instruction; VALIGND can grab any element
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: peter at cordes dot ca
Target Milestone: ---
Target: x86_64-*-*, i?86-*-*
GCC9.1 and current trunk aren't good at extracting high elements, whether it's
with GNU C native vector syntax, or when auto-vectorizing something that ends
with the result in the high element.
Using VALIGND we can get any element with one immediate instruction, but its
better to use AVX2 VPERMPD(immediate) when possible. Or inside loops,
VPERMPS(vector), or VPERMT2PS(vector). Or of course vextractf32x4 if possible
(element at the bottom of a 128-bit lane).
Or with only AVX2 available, VPERMPD(immediate) for high elements in __m256 and
__m256d vectors is still a big win.
#include
float elem12(__m512 v) { return v[12]; }
float elem15(__m512 v) { return v[15]; }
gcc -Ofast -march=skylake-avx512
https://godbolt.org/z/241r8p
elem15:
vextractf32x8 ymm0, zmm0, 0x1
vextractf128xmm0, ymm0, 0x1# elem12 ends here, after these 2
insns
vshufps xmm0, xmm0, xmm0, 255
# no vzeroupper I guess because the caller must have __m512 vars too,
recent optimization
ret
But AVX512F has vextractf32x4 to extract a 128-bit lane, which would preclude
the need for AVX2 vextractf128. That's what clang does.
Obviously inside a loop it would be *much* better to use a single lane-crossing
VPERMPS to also avoid the shufps. Intel Skylake easily bottlenecks on shuffle
throughput. We'd need a 15 in an XMM register as a control vector, but loading
it would be off the latency critical path. (If we needed the scalar
zero-extended instead of garbage in high elements, we could VPERMI2PS or
VPERMT2PS with a zeroed vector and a shuffle-control.)
---
If the element we want is an even element in the low 256 bits, we can get it
with a VPERMPD-immediate. GCC does this:
elem6(float __vector(16)): # GCC 10 trunk
vextractf128xmm0, ymm0, 0x1
vunpckhps xmm0, xmm0, xmm0
ret
Instead it should be AVX2 vpermpd ymm0, ymm0, 3
This bug also applies to __m256, not just __m512
https://www.felixcloutier.com/x86/vpermpd
VPERMPD is a 64-bit granularity lane-crossing shuffle. The AVX512F immediate
version reuses the immediate for another 256-bit wide shuffle in the upper
half; only the vector-control version can bring an element from the top half of
a ZMM down to the bottom. But if we're going to use a vector control, we might
as well use VPERMPS.
For the integer version of this bug, use VPERMQ
--
But we can do even better by using an integer VALIGND (AVX512F) shuffle on FP
data. There unfortunately isn't an FP flavour of VALIGND, just integer.
AFAIK, Skylake-AVX512 still has no bypass-delay penalty for integer shuffles
between FP math instructions, i.e. the shift unit is connected to both FP and
integer forwarding networks. Intel's optimization manual for Skylake (client)
has a bypass-latency table that shows 0 extra latency cycles for SHUF/5/1,3
reading from anything, or anything reading from it.
https://www.felixcloutier.com/x86/valignd:valignq It's a 4 or 8-byte
granularity version of palignr, except that it's lane-crossing so the 256 and
512-bit versions are actually useful. The immediate shift count can thus bring
*any* element down to the bottom. (Using the same input twice makes it a
rotate).
VALIGND is good on Knight's Landing, too: unlike most 2-input shuffles, it has
1 per clock throughput.
For *any* compile-time-constant index, we can always compile v[i] to this:
extract15:
valigndzmm0, zmm0, zmm0, 15 # I think this is right.
ret
The only downside I'm aware of is that some future AVX512 CPU might not run
VALIGND as efficiently as SKX and KNL.
For vector elements narrower than 32 bits, we may need 2 shuffles even if we
consider using a shuffle-control vector. On Skylake-AVX512, AVX512BW vpermw
will get the job done, but costs 2 shuffle uops. On CannonLake (and presumably
other future Intel), it and AVX512VBMI vpermb are only 1 uop, so it's
definitely worth creating a shuffle-control vector if it can be reused.
Also worth considering instead of 2 shuffles: *unaligned* spill / reload like
ICC does for GNU C native vector indexing. Store-forwarding latency is only 6
or 7 cycles I think, and it avoids any port 5 pressure. Not generally a good
choice IMO when we can get the job done in one shuffle, but worth considering
if we need multiple elements. If the function doesn't need the stack aligned,
an unaligned spill is generally
[Bug rtl-optimization/90756] [7/8/9 Regression] g++ ICE in convert_move, at expr.c:218 on i686 and s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90756 --- Comment #18 from Mike Hommey --- And similar ICE as comment 14 with 8.3 too. 9.1 works with the patch.
[Bug tree-optimization/40073] Vector short/char shifts generate sub-optimal code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40073
--- Comment #16 from Jorn Wolfgang Rennecke ---
Going from gcc 8.2 to gcc 9.1, I find the following two test cases are now
autovectorized:
/* { dg-do compile } */
/* { dg-options "-O3" } */
/* Test auto-vectorization */
#include "vector-types.h"
#define LENGTH 256
__attribute__((aligned (VECTOR_SIZE))) short a[LENGTH], b[LENGTH];
short c;
void foo (void) {
int i;
for (i=0; i> (c & 0xf);
}
}
/* { dg-do compile } */
/* { dg-options "-O3" } */
/* Test auto-vectorization */
#include "vector-types.h"
#define LENGTH 256
__attribute__((aligned (VECTOR_SIZE))) unsigned short a[LENGTH], b[LENGTH];
unsigned short c;
void foo (void) {
int i;
for (i=0; i> (c & 0xf);
}
}
[Bug c++/85746] Premature evaluation of __builtin_constant_p?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85746 --- Comment #5 from Marc Glisse --- The patch breaks 3 tests on a bootstrapped compiler: c-c++-common/Warray-bounds-2.c c-c++-common/ubsan/ptr-overflow-sanitization-1.c gcc.dg/Warray-bounds-30.c The last one in particular shows that the compiler is miscompiled (it works with the stage 1 compiler but breaks with stage 2 or 3). From the dumps, the compilation seems to diverge in FRE1, so the miscompiled function might be in a function called from FRE. I find it suspicious that just refusing to fold __builtin_constant_p can cause this. The 2 explanations I can think of are: - latent bug uncovered by the change - a variable that needs to be statically initialized (order of initialization?) and ends up dynamically initialized because of the change
[Bug target/91102] [9/10 Regression] aarch64 ICE on Linux kernel with -Os starting with r270266
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91102
--- Comment #3 from Segher Boessenkool ---
Before combine there were also
(insn 8 7 9 3 (set (reg/v:DI 95 [ c ])
(reg:DI 92 [ b$h ])) "91102.c":18:15 47 {*movdi_aarch64}
(nil))
(insn 11 10 12 3 (set (reg:DI 100)
(subreg:DI (reg:SI 99) 0)) "91102.c":19:12 47 {*movdi_aarch64}
(expr_list:REG_DEAD (reg:SI 99)
(nil)))
making in total
insn_cost 4 for 8: r95:DI=r92:DI
insn_cost 4 for11: r100:DI=r99:SI#0
REG_DEAD r99:SI
insn_cost 4 for12: zero_extract(r95:DI,0x20,0x20)=r100:DI
REG_DEAD r100:DI
insn_cost 4 for15: x2:DI=r95:DI
REG_DEAD r95:DI
becoming
replacement cost 12
modifying insn i315: x2:DI=r92:DI&0x|r99:SI#0<<0x20
REG_DEAD r92:DI
REG_DEAD r99:SI
which is just fine afaics.
Or do we want to not have hard regs on outputs either? Do we get better
register allocation that way, for example?
[Bug target/91102] [9/10 Regression] aarch64 ICE on Linux kernel with -Os starting with r270266
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91102 --- Comment #2 from Segher Boessenkool --- 91102.c: In function 'foo': 91102.c:7:1: warning: control reaches end of non-void function [-Wreturn-type] 7 | } | ^ so ice-on-invalid-code? Although, hrm, inserting "return 3;" there still ICEs.
[Bug sanitizer/91101] Possible performance regression in libasan with detect_stack_use_after_return=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91101 --- Comment #3 from Frantisek Sumsal --- ltrace stastistics: # WITH sanitizers and detect_stack_use_after_return=1 [vagrant@arch build]$ export ASAN_OPTIONS=strict_string_checks=1:detect_stack_use_after_return=1:check_initialization_order=1:strict_init_order=1 [vagrant@arch build]$ ltrace -c build-gcc-9.1.0-sanitizers-tempfiles/test-conf-parser <...snip...> ==25291==LeakSanitizer has encountered a fatal error. ==25291==HINT: For debugging, try setting environment variable LSAN_OPTIONS=verbosity=1:log_threads=1 ==25291==HINT: LeakSanitizer does not work under ptrace (strace, gdb, etc) % time seconds usecs/call calls function -- --- --- - 99.86 28.250721 166180717 config_parse 0.030.0072813640 2 __asan_init 0.010.003920 23017 log_internal_realm 0.010.003716 5073 __asan_stack_malloc_0 0.010.002837 16617 fmkostemp_safe 0.010.002085 12217 fwrite 0.010.001718 10117 unlink_tempfilep 0.010.001490 8717 rewind 0.000.001354 7917 safe_fclose 0.000.001311 7717 strlen 0.000.001208 5024 free 0.000.001191 170 7 config_parse_mode 0.000.000998 142 7 config_parse_unsigned 0.000.000984 140 7 config_parse_path 0.000.000946 135 7 config_parse_int 0.000.000941 5218 __asan_stack_malloc_3 0.000.000921 102 9 config_parse_iec_size 0.000.000901 128 7 config_parse_sec 0.000.000850 5615 strcmp 0.000.000850 121 7 config_parse_nsec 0.000.000826 91 9 config_parse_si_size 0.000.000800 4717 log_get_max_level_realm 0.000.000460 460 1 log_parse_environment_realm 0.000.000381 63 6 config_parse_strv 0.000.000348 49 7 strcmp_ptr 0.000.000336 112 3 config_parse_log_facility 0.000.000314 104 3 config_parse_log_level 0.000.000299 49 6 strv_equal 0.000.000282 56 5 strv_free 0.000.000154 154 1 __asan_unregister_globals 0.000.000109 54 2 config_parse_iec_uint64 0.000.79 79 1 __asan_register_globals 0.000.57 57 1 log_open 0.000.47 47 1 __asan_version_mismatch_check_v8 -- --- --- - 100.00 28.290715 382 total # WITH sanitizers and detect_stack_use_after_return=0 [vagrant@arch build]$ export ASAN_OPTIONS=strict_string_checks=1:detect_stack_use_after_return=0:check_initialization_order=1:strict_init_order=1 [vagrant@arch build]$ ltrace -c build-gcc-9.1.0-sanitizers-tempfiles/test-conf-parser <...snip...> ==25301==LeakSanitizer has encountered a fatal error. ==25301==HINT: For debugging, try setting environment variable LSAN_OPTIONS=verbosity=1:log_threads=1 ==25301==HINT: LeakSanitizer does not work under ptrace (strace, gdb, etc) % time seconds usecs/call calls function -- --- --- - 98.902.914199 17142317 config_parse 0.230.0067493374 2 __asan_init 0.100.002973 17417 log_internal_realm 0.090.002646 15517 fmkostemp_safe 0.070.002095 12317 fwrite 0.050.001416 8317 unlink_tempfilep 0.050.001406 8217 rewind 0.040.001317 5424 free 0.040.001257 7317 strlen 0.040.001225 7217 safe_fclose 0.040.001060 151 7 config_parse_mode 0.030.000891 5217 log_get_max_level_realm 0.030.000877 97 9 config_parse_iec_size 0.030.000862 5715 strcmp 0.030.000851 121 7 config_parse_int 0.030.000846 120 7 config_parse_unsigned 0.030.000841 120 7 config_parse_path 0.030.000838 93 9 config_parse_si_size 0.020.000692 98 7 config_parse_sec 0.020.000679 97 7 config_parse_nsec 0.010.000395 395 1 log_parse_environment_realm 0.010.000364 60 6 config_parse_strv 0.010.000359 51 7 strcmp_ptr 0.010.000324 108 3 config_parse_log_facility 0.010.000309 51 6 strv_equal 0.010.000282 56 5 strv_free 0.010.000266
[Bug sanitizer/91101] Possible performance regression in libasan with detect_stack_use_after_return=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91101 --- Comment #2 from Frantisek Sumsal --- Created attachment 46569 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46569=edit test-conf-parser.i tempfile from GCC 9.1.0 (compressed due to size)
[Bug sanitizer/91101] Possible performance regression in libasan with detect_stack_use_after_return=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91101 --- Comment #1 from Frantisek Sumsal --- Created attachment 46568 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46568=edit hwdb.i tempfile from GCC 9.1.0
[Bug target/91102] [9/10 Regression] aarch64 ICE on Linux kernel with -Os starting with r270266
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91102
Jakub Jelinek changed:
What|Removed |Added
Target||aarch64-linux
Priority|P3 |P2
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-07-06
CC||segher at gcc dot gnu.org,
||sje at gcc dot gnu.org,
||vmakarov at gcc dot gnu.org
Target Milestone|--- |9.2
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek ---
Before combine we have:
(insn 12 11 14 3 (set (zero_extract:DI (reg/v:DI 95 [ c ])
(const_int 32 [0x20])
(const_int 32 [0x20]))
(reg:DI 100)) "rh1727453.i":18:12 782 {*insv_regdi}
(expr_list:REG_DEAD (reg:DI 100)
(nil)))
(insn 14 12 15 3 (set (reg/v:DI 1 x1 [ e ])
(reg:DI 92 [ b$h ])) "rh1727453.i":4:17 47 {*movdi_aarch64}
(expr_list:REG_DEAD (reg:DI 92 [ b$h ])
(nil)))
(insn 15 14 16 3 (set (reg/v:DI 2 x2 [ f ])
(reg/v:DI 95 [ c ])) "rh1727453.i":5:17 47 {*movdi_aarch64}
(expr_list:REG_DEAD (reg/v:DI 95 [ c ])
(nil)))
Combine makes it into:
(insn 14 12 15 3 (set (reg/v:DI 1 x1 [ e ])
(reg:DI 92 [ b$h ])) "rh1727453.i":4:17 47 {*movdi_aarch64}
(nil))
(insn 15 14 16 3 (set (reg/v:DI 2 x2 [ f ])
(ior:DI (and:DI (reg:DI 92 [ b$h ])
(const_int 4294967295 [0x]))
(ashift:DI (subreg:DI (reg:SI 99) 0)
(const_int 32 [0x20] "rh1727453.i":5:17 794
{*aarch64_bfidi4_noand}
(expr_list:REG_DEAD (reg:DI 92 [ b$h ])
(expr_list:REG_DEAD (reg:SI 99)
(nil
(note the hard reg output, but still no input).
But then something during IRA decides to replace that reg:DI 92 with reg:DI 1
x1:
(insn 14 12 15 3 (set (reg/v:DI 1 x1 [ e ])
(reg:DI 92 [ b$h ])) "rh1727453.i":4:17 47 {*movdi_aarch64}
(expr_list:REG_DEAD (reg:DI 92 [ b$h ])
(nil)))
(insn 15 14 16 3 (set (reg/v:DI 2 x2 [ f ])
(ior:DI (and:DI (reg/v:DI 1 x1 [ e ])
(const_int 4294967295 [0x]))
(ashift:DI (subreg:DI (reg:SI 99) 0)
(const_int 32 [0x20] "rh1727453.i":5:17 794
{*aarch64_bfidi4_noand}
(expr_list:REG_DEAD (reg:SI 99)
(nil)))
And LRA can't deal with that, because the pattern is:
(define_insn ("*aarch64_bfidi4_noand")
[
(set (match_operand:DI 0 ("register_operand") ("=r"))
(ior:DI (and:DI (match_operand:DI 1 ("register_operand") ("0"))
(match_operand:DI 2 ("const_int_operand") ("n")))
(ashift:DI (match_operand:DI 3 ("register_operand") ("r"))
(match_operand:DI 4 ("aarch64_simd_shift_imm_di") ("n")
] ("aarch64_masks_and_shift_for_bfi_p (DImode, UINTVAL (operands[2]),
UINTVAL (operands[4]),
HOST_WIDE_INT_M1U << UINTVAL
(operands[4]) )") ("*{
operands[5] = GEN_INT (GET_MODE_BITSIZE (DImode) - UINTVAL (operands[4]));
return "bfi\t%x0, %x3, %4, %5";
}")
[
(set_attr ("type") ("bfm"))
])
and thus wants LRA to reload the operand 1 into the same register as operand 0.
I think "register_operand" "=r" and "register_operand" "0" operands are
extremely common in all backends, so I don't see an obvious bug on the aarch64
backend size here.
Vlad, could you please have a look?
[Bug target/91102] New: [9/10 Regression] aarch64 ICE on Linux kernel with -Os starting with r270266
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91102
Bug ID: 91102
Summary: [9/10 Regression] aarch64 ICE on Linux kernel with -Os
starting with r270266
Product: gcc
Version: 9.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
int
foo (long d, long l)
{
register long e asm ("x1") = d;
register long f asm("x2") = l;
asm ("" : : "r" (e), "r" (f));
}
struct T { int i; int j; };
union S { long h; struct T t; };
void
bar (union S b)
{
while (1)
{
union S c = b;
c.t.j++;
b.h = foo (b.h, c.h);
}
}
ICEs with -Os on aarch64-linux starting with r270266:
rh1727453.i: In function ‘bar’:
rh1727453.i:21:1: error: unable to generate reloads for:
21 | }
| ^
(insn 15 14 16 3 (set (reg/v:DI 2 x2 [ f ])
(ior:DI (and:DI (reg/v:DI 1 x1 [ e ])
(const_int 4294967295 [0x]))
(ashift:DI (subreg:DI (reg:SI 99) 0)
(const_int 32 [0x20] "rh1727453.i":5:17 794
{*aarch64_bfidi4_noand}
(expr_list:REG_DEAD (reg:SI 99)
(nil)))
during RTL pass: reload
rh1727453.i:21:1: internal compiler error: in curr_insn_transform, at
lra-constraints.c:3962
0xfa3363 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/rtl-error.c:108
0xe09d9f curr_insn_transform
../../gcc/lra-constraints.c:3962
0xe0d788 lra_constraints(bool)
../../gcc/lra-constraints.c:4978
0xdf5639 lra(_IO_FILE*)
../../gcc/lra.c:2472
0xd9d0c2 do_reload
../../gcc/ira.c:5516
0xd9d550 execute
../../gcc/ira.c:5700
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug sanitizer/91101] New: Possible performance regression in libasan with detect_stack_use_after_return=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91101 Bug ID: 91101 Summary: Possible performance regression in libasan with detect_stack_use_after_return=1 Product: gcc Version: 9.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: frantisek at sumsal dot cz CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- Hello, in systemd we recently noticed[0], that certain CI's started timeouting after upgrade to gcc 9.1.0 and 9.1.1. After a bit of investigation it seems that the runtime of instrumented binaries with ASan is more than doubled. (The GitHub thread contains claims about the performance issue being present even without sanitizers, but that hasn't been confirmed yet, so please ignore it). Also, I apologize if this report is useless for upstream, since it's not using the trunk GCC, but I'd really like to know if we're doing something fundamentally wrong or if this is an actual issue. The following report is from Arch Linux with GCC 9.1.0, but I also managed to reproduce this on Fedora Rawhide with GCC 9.1.1[1]. As this thread is without any response so far, I've been trying to collect as much information as possible regarding this issue, as testing systemd with bleeding-edge software is particularly important for us. The following statistics provide comparison between two particular systemd test cases compiled with GCC 8.3.0 (with and without ASan and UBSan) and the same statistics for GCC 9.1.0: [vagrant@arch build]$ pacman -Q gcc gcc-libs gcc 8.3.0-1 gcc-libs 8.3.0-1 [vagrant@arch build]$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --enable-libmpx --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib --disable-werror --enable-checking=release --enable-default-pie --enable-default-ssp --enable-cet=auto Thread model: posix gcc version 8.3.0 (GCC) # Basically git clone https://github.com/systemd/systemd /build [vagrant@arch build]$ meson build-gcc-8.3.0-sanitizers -Db_sanitize=address,undefined <...snip...> [vagrant@arch build]$ meson build-gcc-8.3.0 <...snip...> [vagrant@arch build]$ ninja -C build-gcc-8.3.0-sanitizers <...snip...> [vagrant@arch build]$ ninja -C build-gcc-8.3.0 <...snip...> # Sanitizer-specific options [vagrant@arch build]$ export ASAN_OPTIONS=strict_string_checks=1:detect_stack_use_after_return=1:check_initialization_order=1:strict_init_order=1 [vagrant@arch build]$ export UBSAN_OPTIONS=print_stacktrace=1:print_summary=1:halt_on_error=1 # WITHOUT sanitizers [vagrant@arch build]$ /bin/time -v build-gcc-8.3.0/test-conf-parser >/dev/null <...snip...> Command being timed: "build-gcc-8.3.0/test-conf-parser" User time (seconds): 1.25 System time (seconds): 0.01 Percent of CPU this job got: 99% Elapsed (wall clock) time (h:mm:ss or m:ss): 0:01.28 Average shared text size (kbytes): 0 Average unshared data size (kbytes): 0 Average stack size (kbytes): 0 Average total size (kbytes): 0 Maximum resident set size (kbytes): 9944 Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 0 Minor (reclaiming a frame) page faults: 930 Voluntary context switches: 12 Involuntary context switches: 107 Swaps: 0 File system inputs: 0 File system outputs: 0 Socket messages sent: 0 Socket messages received: 0 Signals delivered: 0 Page size (bytes): 4096 Exit status: 0 [vagrant@arch build]$ cd build-gcc-8.3.0 && /bin/time -v ../test/hwdb-test.sh >/dev/null Command being timed: "../test/hwdb-test.sh" User time (seconds): 0.40 System time (seconds): 0.01 Percent of CPU this job got: 98% Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.41 Average shared text size (kbytes): 0 Average unshared data size (kbytes): 0 Average stack size (kbytes): 0 Average total size (kbytes): 0 Maximum resident set size (kbytes): 25752 Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 0 Minor (reclaiming a frame) page faults: 7264 Voluntary context
[Bug tree-optimization/91096] Openmp vector max reduction incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91096 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Target Milestone|--- |10.0 --- Comment #6 from Jakub Jelinek --- Should be fixed now.
[Bug middle-end/84877] Local stack copy of BLKmode parameter on the stack is not aligned when the requested alignment exceeds MAX_SUPPORTED_STACK_ALIGNMENT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84877 Jorn Wolfgang Rennecke changed: What|Removed |Added CC||amylaar at gcc dot gnu.org --- Comment #10 from Jorn Wolfgang Rennecke --- Created attachment 46567 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46567=edit Fix for targets that pass the argument by invisible reference I also observe this problem on esirisc. assign_parm is only relevant for the testcase if the argument is passed by value, where the copy is made in foo. If the argument is passed by invisible reference, we have instead during compilation of main expand_call calling initialize_argument_information, which calls assign_temp, which calls assign_temp_for_type, which calls assign_stack_local_1 . The attached patch changes initialize_argument_information to use the same code path as for variable-sized arguments; it's a bit more overhead, but I would think that excess alignment is a relatively rare case. If performance for this alignment were really important, you could change the stack management so that the alignment can be provided more cheaply. Since the esirisc port is not in the FSF tree, it doesn't really count for testing; also, the behaviour will vary depending on argument passing of the target, so we need to test a variety of targets.
[Bug ada/91100] New: [9,10 Regression] FAIL: gnat.dg/socket1.adb execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91100 Bug ID: 91100 Summary: [9,10 Regression] FAIL: gnat.dg/socket1.adb execution test Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa2.0w-hp-hpux11.11 Target: hppa2.0w-hp-hpux11.11 Build: hppa64-hp-hpux11.11 ADA_INCLUDE_PATH=/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libada/adainclude ADA_OBJECTS_PATH=/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libada/adainclude Executing on host: /test/gnu/gcc/objdir/gcc/gnatmake --GCC=/test/gnu/gcc/objdir/ gcc/xgcc --GNATBIND=/test/gnu/gcc/objdir/gcc/gnatbind --GNATLINK=/test/gnu/gcc/o bjdir/gcc/gnatlink -cargs -B/test/gnu/gcc/objdir/gcc -largs --GCC=/test/gnu/gcc/objdir/gcc/xgcc\ -B/test/gnu/gcc/objdir/gcc\ -margs --RTS=/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libada -q -f /test/gnu/gcc/gcc/gcc/testsuite/gnat.dg/socket1.adb -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -lm -o ./socket1.exe(timeout = 300) spawn /test/gnu/gcc/objdir/gcc/gnatmake --GCC=/test/gnu/gcc/objdir/gcc/xgcc --GNATBIND=/test/gnu/gcc/objdir/gcc/gnatbind --GNATLINK=/test/gnu/gcc/objdir/gcc/gnatlink -cargs -B/test/gnu/gcc/objdir/gcc -largs --GCC=/test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc -margs --RTS=/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libada -q -f /test/gnu/gcc/gcc/gcc/testsuite/gnat.dg/socket1.adb -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -lm -o ./socket1.exe Executing on host: /test/gnu/gcc/objdir/gcc/gnatclean -c -q -n ./socket1 (timeout = 300) spawn /test/gnu/gcc/objdir/gcc/gnatclean -c -q -n ./socket1 ./socket1.ali ./socket1.o PASS: gnat.dg/socket1.adb (test for excess errors) Setting LD_LIBRARY_PATH to :/test/gnu/gcc/objdir/gcc::/test/gnu/gcc/objdir/gcc spawn [open ...] raised GNAT.SOCKETS.SOCKET_ERROR : [0] Error 0 FAIL: gnat.dg/socket1.adb execution test Revision 272748 was okay with gcc-10. Fail seen with revision 273142. Revision 272827 was okay with gcc-9. Fail seen with revision 272908. Not sure how to debug (i.e., keep testsuite executable).
[Bug c/89072] -Wall -Werror should be defaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89072 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #1 from Segher Boessenkool --- -Werror should *never* be the default. Warnings are warnings, and errors are errors. Warnings are for situations where the compiler cannot tell whether what you did is wrong, and errors are for when it *can* tell unambiguously that your program is incorrect. Many warnings are *wrong*. That is in the nature of warnings. Refusing to build a correct program is a disservice. Warnings change frequently, with every release of GCC. On the other hand, errors do not change (ignoring compiler bugs): incorrect programs stay incorrect, and if we failed to diagnose an incorrect program before, that does not change the fact that it was incorrect. Making -Wall the default will potentially break the build of very many projects, *especially* those that misguidedly use -Werror. I don't see any less painful path to enabling -Wall by default. I don't really see the point: there are other gcc command line mistakes that are made more often, certainly by beginners (like forgetting -Wextra, or putting -l's before the object files, or or or). Beginners are better off not invoking the compiler driver directly.
[Bug c/91093] Error on implicit int by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91093 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=91092, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=89072 --- Comment #1 from Martin Sebor --- See also pr89072 for a request to enable -Wall -Werror by default.
[Bug c/91092] Error on implicit function declarations by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=89072 --- Comment #10 from Martin Sebor --- See also pr89072 for a request to enable -Wall -Werror by default.
[Bug c++/91099] New: constexpr vs -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91099
Bug ID: 91099
Summary: constexpr vs -frounding-math
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
constexpr double d = 1. / 3.;
currently fails to compile with -frounding-math. This behavior makes sense: we
do not know in what direction to round. However, -frounding-math is about the
dynamic rounding mode, while the above expression must be evaluated at compile
time, where there is no dynamic rounding mode (pragma fenv_round from C2a may
eventually provide a way to specify a relevant rounding mode). An alternative
to refusing to perform any inexact math at compile time would be, when the
computation is absolutely required to be performed at compile time, to use the
default rounding mode.
I tried adding:
Save save_frm(flag_rounding_math, flag_rounding_math &
!ctx->manifestly_const_eval);
near the beginning of cxx_eval_constant_expression, where Save is
template struct Save {
T& ref; T old;
Save(T& t, T newval): ref(t), old(t) { ref = newval; }
~Save() { ref = old; }
};
which kind of works on trivial examples, but is defeated by constexpr-caching
if we change flag_rounding_math in the middle of a translation unit: if we have
previously (-fno-rounding-math) managed to fold a function computing 1./3, we
blindly reuse the result even if we now have -frounding-math. I don't know if
it would be acceptable to say that -frounding-math may not be changed in the
middle of a translation unit. (for pragma fenv_access, I currently think I
should use a different flag)
[Bug tree-optimization/91090] A suspicious code in tree-ssa-dom.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91090 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com Assignee|unassigned at gcc dot gnu.org |law at redhat dot com --- Comment #2 from Jeffrey A. Law --- I think that if (i > j) case should be at the same level as the (i == j) case. It probably got goof'd up during reindention when the code was copied from tree-vrp.c.
[Bug c++/56248] [DR 580] access checking of template parameters done too early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56248 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-07-06 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/67017] [DR1265] Mixing init-declarator for variables and functions in declaration with auto type-specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67017 Marek Polacek changed: What|Removed |Added Status|NEW |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #7 from Marek Polacek --- Resolved in r244071.
[Bug rtl-optimization/90813] [10 regression] gfortran.dg/proc_ptr_51.f90 fails (SIGSEGV) after 272084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813
--- Comment #25 from Segher Boessenkool ---
At expand time, the assignment is
;; c_ = c;
(insn 35 34 36 (set (reg/f:DI 140)
(unspec:DI [
(symbol_ref:DI ("*.LANCHOR1") [flags 0x182])
(reg:DI 2 2)
] UNSPEC_TOCREL)) "proc_ptr_51.f90":26:0 -1
(expr_list:REG_EQUAL (symbol_ref:DI ("*.LANCHOR1") [flags 0x182])
(nil)))
(insn 36 35 37 (set (reg/f:DI 141)
(unspec:DI [
(symbol_ref:DI ("__f_MOD_c") [flags 0x3] )
(reg:DI 2 2)
] UNSPEC_TOCREL)) "proc_ptr_51.f90":26:0 -1
(expr_list:REG_EQUAL (symbol_ref:DI ("__f_MOD_c") [flags 0x3]
)
(nil)))
(insn 37 36 0 (set (mem/f/c:DI (reg/f:DI 140) [13 c_+0 S8 A64])
(reg/f:DI 141)) "proc_ptr_51.f90":26:0 -1
(nil))
while the use is (immediately after that!)
;; rhs.2 = c_.5_12 (); [return slot optimization]
(insn 38 37 39 (set (reg:DI 142)
(plus:DI (reg/f:DI 112 virtual-stack-vars)
(const_int 48 [0x30]))) "proc_ptr_51.f90":35:0 -1
(nil))
(insn 39 38 40 (set (reg/f:DI 143)
(mem/u/c:DI (unspec:DI [
(symbol_ref/u:DI ("*.LC1") [flags 0x2])
(reg:DI 2 2)
] UNSPEC_TOCREL) [21 S8 A8])) "proc_ptr_51.f90":35:0 -1
(expr_list:REG_EQUAL (symbol_ref:DI ("__f_MOD_c_") [flags 0xc0] )
(nil)))
(insn 40 39 41 (set (reg/f:DI 144)
(mem/f/c:DI (reg/f:DI 143) [13 c_+0 S8 A64])) "proc_ptr_51.f90":35:0 -1
(nil))
(insn 41 40 42 (set (reg:DI 3 3)
(reg:DI 142)) "proc_ptr_51.f90":35:0 -1
(nil))
(insn 42 41 43 (set (reg:DI 145)
(mem:DI (reg/f:DI 144) [0 S8 A8])) "proc_ptr_51.f90":35:0 -1
(nil))
(insn 43 42 44 (set (reg:DI 97 ctr)
(reg:DI 145)) "proc_ptr_51.f90":35:0 -1
(nil))
(insn 44 43 45 (set (reg:DI 11 11)
(mem:DI (plus:DI (reg/f:DI 144)
(const_int 16 [0x10])) [0 S8 A8])) "proc_ptr_51.f90":35:0 -1
(nil))
(call_insn 45 44 46 (parallel [
(call (mem:SI (reg:DI 97 ctr) [0 *c_.5_12 S4 A8])
(const_int 64 [0x40]))
(use (mem:DI (plus:DI (reg/f:DI 144)
(const_int 8 [0x8])) [0 S8 A8]))
(set (reg:DI 2 2)
(unspec:DI [
(const_int 40 [0x28])
] UNSPEC_TOCSLOT))
(clobber (reg:DI 96 lr))
]) "proc_ptr_51.f90":35:0 -1
(expr_list:REG_CALL_DECL (nil)
(nil))
(expr_list (use (reg:DI 11 11))
(expr_list:DI (use (reg:DI 3 3))
(nil
(insn 46 45 47 (set (reg:DI 146)
(plus:DI (reg/f:DI 112 virtual-stack-vars)
(const_int 48 [0x30]))) "proc_ptr_51.f90":35:0 -1
(nil))
(insn 47 46 0 (set (reg:TI 127 [ rhs.2 ])
(mem:TI (reg:DI 146) [7 S16 A64])) "proc_ptr_51.f90":35:0 -1
(nil))
so it is wrong (if this is wrong!) at expand already.
In gimple this was:
c_ = c;
c_.5_12 = c_;
rhs.2 = c_.5_12 (); [return slot optimization]
[Bug c++/91098] [10 Regression] internal compiler error: tree check: expected var_decl or field_decl or function_decl or type_decl or template_decl, have using_decl in build_deduction_guide, at cp/pt.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91098 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-07-06 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |10.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Started with r270765.
[Bug rtl-optimization/90813] [10 regression] gfortran.dg/proc_ptr_51.f90 fails (SIGSEGV) after 272084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813 --- Comment #24 from Segher Boessenkool --- Is that disallowed? Is there any way to prevent that from happening, in general?
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #56 from dave.anglin at bell dot net --- On 2019-07-05 7:57 p.m., elowe at elowe dot com wrote: > Doing some more testing on my "gprel unfixed fix" 32-bit gcc, I found out that > it seems to be missing the 32-bit pointer swizzling needed to make 32bit > executables on 64-bit IA-64. The test program assembler is missing an addp4 > instruction - when I add in this instruction, my second test program also > works. Could be. The default hpux compiler generates ILP32 code and it's supposed to be big-endian. Could you compile hello world with "-c" option and run "objdump -r" on resulting object? Pointers are 32-bit in the ILP32 model. I think we should have GPREL32MSB relocation but maybe we have 64-bit reloc. https://refspecs.linuxfoundation.org/elf/IA64-SysV-psABI.pdf
[Bug rtl-optimization/90813] [10 regression] gfortran.dg/proc_ptr_51.f90 fails (SIGSEGV) after 272084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813
--- Comment #23 from rguenther at suse dot de ---
On July 6, 2019 12:18:47 AM GMT+02:00, "pthaugen at linux dot ibm.com"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813
>
>Pat Haugen changed:
>
> What|Removed |Added
>
> CC||pthaugen at linux dot ibm.com,
> ||rguenth at gcc dot gnu.org
>
>--- Comment #22 from Pat Haugen ---
>So the problem appears to be alias.c:true_dependence() telling
>sched-deps.c:sched_analyze_2() that the following two instructions'
>memory
>references don't alias.
>
>Breakpoint 11, sched_analyze_2 (deps=0x7fffdbf8, x=0x759a1a40,
>insn=0x757f16c0)
>at /home/pthaugen/src/gcc/temp/gcc/gcc/sched-deps.c:2671
>2671if (true_dependence (pending_mem->element (),
>VOIDmode,
>t)
>(gdb) pr pending->insn()
>(insn 37 36 38 4 (set (mem/f/c:DI (unspec:DI [
>(symbol_ref:DI ("*.LANCHOR1") [flags 0x182])
>(reg:DI 2 2)
>] UNSPEC_TOCREL) [8 c_+0 S8 A64])
>(reg/f:DI 141)) "proc_ptr_51.f90":28:0 609 {*movdi_internal64}
> (expr_list:REG_DEAD (reg/f:DI 141)
>(nil)))
>
>(gdb) pr insn
>(insn 39 38 40 4 (set (reg/f:DI 143 [ c_ ])
>(mem/f/c:DI (reg/f:DI 142) [8 c_+0 S8 A64])) "proc_ptr_51.f90":37:0 609
>{*movdi_internal64}
> (expr_list:REG_DEAD (reg/f:DI 142)
> (expr_list:REG_EQUAL (mem/f/c:DI (symbol_ref:DI ("__f_MOD_c_") [flags
>0xc0] ) [8 c_+0 S8 A64])
>(nil
>
>Which then lets the scheduler move the load above the store. Since they
>really
>are referring to the same location, we load up garbage (null) and
>branch to it.
>
>Including some additional detail from a couple various spots in the
>debug
>chain. Hoping someone with more alias.c knowledge can chime in.
>
>
>Breakpoint 13, true_dependence_1 (mem=0x759a4878,
>mem_mode=E_VOIDmode,
>mem_addr=0x0, x=0x759a8e08,
>x_addr=0x0, mem_canonicalized=false) at
>/home/pthaugen/src/gcc/temp/gcc/gcc/alias.c:2902
>2902{
>(gdb) pr mem
>(mem/f/c:DI (unspec:DI [
>(symbol_ref:DI ("*.LANCHOR1") [flags 0x182])
>(reg:DI 2 2)
>] UNSPEC_TOCREL) [8 c_+0 S8 A64])
>(gdb) pr x
>(mem/f/c:DI (symbol_ref:DI ("__f_MOD_c_") [flags 0xc0] 0x77f70990
>c_>) [8 c_+0 S8 A64])
>
>...
>
>(gdb) pr x_addr
>(symbol_ref:DI ("__f_MOD_c_") [flags 0xc0] c_>)
>(gdb) pr true_mem_addr
>(unspec:DI [
>(symbol_ref:DI ("*.LANCHOR1") [flags 0x182])
>(reg:DI 2 2)
>] UNSPEC_TOCREL)
>(gdb) pr mem_base
>(symbol_ref:DI ("*.LANCHOR1") [flags 0x182])
>
>2958 if (! base_alias_check (x_addr, base, true_mem_addr,
>mem_base,
>(gdb) p base_alias_check (x_addr, base, true_mem_addr, mem_base,
>GET_MODE (x),
>mem_mode)
>$18 = 0
>
>(gdb) s
>base_alias_check (x=0x75992990, x_base=0x75992990,
>y=0x759a4890,
>y_base=0x75990ac8,
>x_mode=E_DImode, y_mode=E_DImode) at
>/home/pthaugen/src/gcc/temp/gcc/gcc/alias.c:2174
>2174 if (x_base == 0)
>(gdb) pr x
>(symbol_ref:DI ("__f_MOD_c_") [flags 0xc0] c_>)
>(gdb) pr x_base
>(symbol_ref:DI ("__f_MOD_c_") [flags 0xc0] c_>)
>(gdb) pr y
>(unspec:DI [
>(symbol_ref:DI ("*.LANCHOR1") [flags 0x182])
>(reg:DI 2 2)
>] UNSPEC_TOCREL)
>(gdb) pr y_base
>(symbol_ref:DI ("*.LANCHOR1") [flags 0x182])
>
>2221return compare_base_symbol_refs (x_base, y_base) != 0;
>(gdb) p compare_base_symbol_refs (x_base, y_base)
>$19 = 0
>
>2136 if (!x_node->definition)
>(gdb) n
>2137return 0;
We seem to access the same decl (see MEM_EXPR) once via section anchor and once
not. We seem to be confused about this in this very place?
[Bug debug/78685] -Og generates too many ""s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78685 rsandifo at gcc dot gnu.org changed: What|Removed |Added URL||https://gcc.gnu.org/ml/gcc- ||patches/2019-06/msg01394.ht ||ml --- Comment #18 from rsandifo at gcc dot gnu.org --- (In reply to Eric Gallager from comment #17) > Richard Sandiford had a series of patches radically overhauling how -Og > works in general that might affect this bug: > https://gcc.gnu.org/ml/gcc-patches/2019-06/msg01392.html > cc-ing him so he can comment on if it does in fact affect this bug. Yeah, part 2 of the series fixes this PR: https://gcc.gnu.org/ml/gcc-patches/2019-06/msg01394.html
[Bug c++/85746] Premature evaluation of __builtin_constant_p?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85746 --- Comment #4 from Marc Glisse --- Created attachment 46566 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46566=edit untested patch to fold _bcp only when necessary
[Bug preprocessor/90581] provide an option to adjust the maximum depth of nested #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90581 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |10.0
[Bug tree-optimization/91096] Openmp vector max reduction incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91096 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Sat Jul 6 07:50:44 2019 New Revision: 273156 URL: https://gcc.gnu.org/viewcvs?rev=273156=gcc=rev Log: PR tree-optimization/91096 * gcc.dg/vect/vect-simd-10.c (FLT_MIN_VALUE): Define. (bar, main): Use it instead of -__builtin_inff (). * gcc.dg/vect/vect-simd-14.c (FLT_MIN_VALUE): Define. (bar, main): Use it instead of -__builtin_inff (). Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/vect-simd-10.c trunk/gcc/testsuite/gcc.dg/vect/vect-simd-14.c
