[Bug c++/97772] New: Wording of GCC's error message when calling lvalue-ref qualified member function on temporary object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97772
Bug ID: 97772
Summary: Wording of GCC's error message when calling lvalue-ref
qualified member function on temporary object
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: enricomaria.dean6elis at gmail dot com
Target Milestone: ---
Long story short, write this source file
struct A {
void doWork() & {}
};
int main() {
A{}.doWork();
}
compile it with
g++ -std=c++17 that_file.cpp
and the error will be
error: passing ‘A’ as ‘this’ argument discards qualifiers [-fpermissive]
There's really no discarded qualifier; it's just that `A{}` cannot bind to the
`&`-qualified overload.
The full discussion is on StackOverflow at
https://stackoverflow.com/q/64705932/5825294
[Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417 Levy changed: What|Removed |Added Attachment #49533|0 |1 is obsolete|| --- Comment #28 from Levy --- Created attachment 49534 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49534=edit V4 patch for QI/HI/SI/DI zero/sign-extend for RV32/64/128 Suggest by Kito, The V4 patch moved the gen_extend_insn_auto() to riscv.c and was included in riscv-protos.h since it handles riscv backend only.
[Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417 --- Comment #27 from Levy --- (In reply to Kito Cheng from comment #25) > Seem like you have add code to gcc/optabs.h and gcc/optabs.c, however those > functions are RISC-V specific, so I would suggest you put in riscv.c and > riscv-protos.h. No problem, I'll make a new patch.
[Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417 Levy changed: What|Removed |Added Attachment #49532|0 |1 is obsolete|| --- Comment #26 from Levy --- Created attachment 49533 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49533=edit QI/HI/SI/DI zero/sign-extend for RV32/64/128 BUG fix for unimplemented code
[Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417 --- Comment #25 from Kito Cheng --- Seem like you have add code to gcc/optabs.h and gcc/optabs.c, however those functions are RISC-V specific, so I would suggest you put in riscv.c and riscv-protos.h.
[Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417 Levy changed: What|Removed |Added Attachment #49524|0 |1 is obsolete|| --- Comment #24 from Levy --- Created attachment 49532 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49532=edit QI/HI/SI/DI zero/sign-extend for RV32/64/128 Rewrote the third proposed patch.
[Bug c++/97771] New: gcc/g++ failed to generate proper .init_array entries for local scope function, should create "axG", .init_array comdat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97771
Bug ID: 97771
Summary: gcc/g++ failed to generate proper .init_array entries
for local scope function, should create "axG",
.init_array comdat
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: erstrauss at gmail dot com
Target Milestone: ---
The the program below creates a local function inside a Local structure, and
adds the
local function address into the .init_array section in order to call that local
function at process start.
The localFunc template function is using a source_location const static
variable as template parameter.
g++ fails to place the address of the Local::init() functions inside the
.init_array.
$ cat init_array5.cpp
#include
#include
using namespace std::experimental;
template
void localFunc(const char* name)
{
static int count{0};
volatile ::std::ios_base::Init dummy{};
std::cout << "post-main-start: " << name << " " << X.file_name() << " " <<
X.line()
<< " : " << (void*) << " count: " << (++count) << " "
<< __PRETTY_FUNCTION__ << std::endl;
struct Local
{
static void init()
{
volatile ::std::ios_base::Init dummy{};
std::cout << "pre-main-start init from localFunc: " <<
X.file_name() << " "
<< X.line() << " : " << (void*)
<< " count: " << (++count) << " " << X.function_name() <<
" / " << __PRETTY_FUNCTION__
<< std::endl;
}
};
static void* volatile initp
__attribute__((__used__, section(".init_array"))){(void*)::init};
// not places into .init_array.
}
#define LOCAL_FUNC(NAME) \
do\
{ \
constexpr static auto s = source_location::current(); \
localFunc((const char*)&(NAME)[0]);\
} while (0)
void okFunc1() { LOCAL_FUNC("X1"); }
void okFunc2() { LOCAL_FUNC("X2"); }
int main()
{
std::cout << "main() started" << std::endl;
okFunc1();
okFunc2();
return 0;
}
==
output of the g++ compiled code, without the calls to the Local::init()
functions.
$ g++ -O2 -std=c++20 init_array5.cpp -o init_array5
$ ./init_array5
main() started
post-main-start: X1 init_array5.cpp 38 : 0x4041d8 count: 1 void
localFunc(const char*) [with const
std::experimental::fundamentals_v2::source_location& X = s]
post-main-start: X2 init_array5.cpp 39 : 0x4041d4 count: 1 void
localFunc(const char*) [with const
std::experimental::fundamentals_v2::source_location& X = s]
In case the same code is compiled using clang++, the pre-main local functions
are being called.
$ clang++ -O2 -std=c++20 init_array5.cpp -o init_array5
$ ./init_array5
pre-main-start init from localFunc: init_array5.cpp 38 : 0x4041d8 count:
1 okFunc1 / static void localFunc(const char *)::Local::init()
pre-main-start init from localFunc: init_array5.cpp 39 : 0x4041dc count:
1 okFunc2 / static void localFunc(const char *)::Local::init()
main() started
post-main-start: X1 init_array5.cpp 38 : 0x4041d8 count: 2 void
localFunc(const char *) [X = s]
post-main-start: X2 init_array5.cpp 39 : 0x4041dc count: 2 void
localFunc(const char *) [X = s]
g++ version information:
$ g++ --version -v
Using built-in specs.
COLLECT_AS_OPTIONS='--version'
COLLECT_GCC=/usr/bin/g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/10/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
g++ (GCC) 10.2.1 20201016 (Red Hat 10.2.1-6)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,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-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
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.1 20201016 (Red Hat 10.2.1-6) (GCC)
COLLECT_GCC_OPTIONS='--version' '-v'
[Bug target/97770] [ICELAKE]Missing vectorization for vpopcnt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97770
--- Comment #3 from Hongtao.liu ---
> But for vector byte/word/quadword, vectorizer still use vpopcntd, but not
> vpopcnt{b,w,q}, missing corresponding ifn?
We don't have __builtin_popcount{w,b}, but we have __builtin_popcountl.
for testcase
---
void
fooq(unsigned long long* __restrict dest, unsigned long long* src)
{
for (int i = 0; i != 4; i++)
dest[i] = __builtin_popcountl (src[i]);
}
icc/clang generate
---
_Z4fooqPxS_:# @_Z4fooqPxS_
vpopcntqymm0, ymmword ptr [rsi]
vmovdqu ymmword ptr [rdi], ymm0
vzeroupper
ret
---
But gcc generate
---
fooq:
.LFB0:
.cfi_startproc
vpopcntq16(%rsi), %xmm1
vpopcntq(%rsi), %xmm0
vshufps $136, %xmm1, %xmm0, %xmm0
vpmovsxdq %xmm0, %xmm1
vpsrldq $8, %xmm0, %xmm0
vpmovsxdq %xmm0, %xmm0
vmovdqu %xmm1, (%rdi)
vmovdqu %xmm0, 16(%rdi)
ret
.cfi_endproc
---
dump for 164.vect
---
;; Function fooq (fooq, funcdef_no=0, decl_uid=4228, cgraph_uid=1,
symbol_order=0)
Merging blocks 2 and 6
fooq (long long unsigned int * restrict dest, long long unsigned int * src)
{
vector(2) long long unsigned int * vectp_dest.10;
vector(2) long long unsigned int * vectp_dest.9;
vector(2) long long unsigned int vect__7.8;
vector(4) int vect__5.7;
vector(2) long long unsigned int vect__4.6;
vector(2) long long unsigned int vect__4.5;
vector(2) long long unsigned int * vectp_src.4;
vector(2) long long unsigned int * vectp_src.3;
int i;
long unsigned int _1;
long unsigned int _2;
long long unsigned int * _3;
long long unsigned int _4;
int _5;
long long unsigned int * _6;
long long unsigned int _7;
vector(2) long long unsigned int _8;
vector(2) long long unsigned int _26;
unsigned int ivtmp_30;
unsigned int ivtmp_31;
unsigned int ivtmp_36;
unsigned int ivtmp_37;
[local count: 214748368]:
[local count: 214748371]:
# i_18 = PHI
# ivtmp_31 = PHI
# vectp_src.3_20 = PHI
# vectp_dest.9_24 = PHI
# ivtmp_36 = PHI
_1 = (long unsigned int) i_18;
_2 = _1 * 8;
_3 = src_11(D) + _2;
vect__4.5_16 = MEM [(long long unsigned
int *)vectp_src.3_20];
vectp_src.3_15 = vectp_src.3_20 + 16;
vect__4.6_9 = MEM [(long long unsigned int
*)vectp_src.3_15];
_4 = *_3;
_8 = .POPCOUNT (vect__4.5_16);
_26 = .POPCOUNT (vect__4.6_9);
vect__5.7_22 = VEC_PACK_TRUNC_EXPR <_8, _26>; --- Why do we do this?
_5 = 0;
_6 = dest_12(D) + _2;
vect__7.8_23 = [vec_unpack_lo_expr] vect__5.7_22;
vect__7.8_25 = [vec_unpack_hi_expr] vect__5.7_22;
_7 = (long long unsigned int) _5;
MEM [(long long unsigned int
*)vectp_dest.9_24] = vect__7.8_23;
vectp_dest.9_34 = vectp_dest.9_24 + 16;
MEM [(long long unsigned int
*)vectp_dest.9_34] = vect__7.8_25;
i_14 = i_18 + 1;
ivtmp_30 = ivtmp_31 - 1;
vectp_src.3_17 = vectp_src.3_15 + 16;
vectp_dest.9_32 = vectp_dest.9_34 + 16;
ivtmp_37 = ivtmp_36 + 1;
if (ivtmp_37 < 1)
goto ; [0.00%]
else
goto ; [100.00%]
[local count: 0]:
goto ; [100.00%]
[local count: 214748368]:
return;
}
---
[Bug target/97770] [ICELAKE]Missing vectorization for vpopcnt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97770
--- Comment #2 from Hongtao.liu ---
After adding expander, successfully vectorize the loop.
---
diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index b153a87fb98..e8159997c40 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -22678,6 +22678,12 @@ (define_insn "avx5124vnniw_vp4dpwssds_maskz"
(set_attr ("prefix") ("evex"))
(set_attr ("mode") ("TI"))])
+(define_expand "popcount2"
+ [(set (match_operand:VI48_AVX512VL 0 "register_operand")
+ (popcount:VI48_AVX512VL
+ (match_operand:VI48_AVX512VL 1 "nonimmediate_operand")))]
+ "TARGET_AVX512VPOPCNTDQ")
+
(define_insn "vpopcount"
[(set (match_operand:VI48_AVX512VL 0 "register_operand" "=v")
(popcount:VI48_AVX512VL
@@ -22722,6 +22728,12 @@ (define_insn "*restore_multiple_leave_return"
"TARGET_SSE && TARGET_64BIT"
"jmp\t%P1")
+(define_insn "popcount2"
+ [(set (match_operand:VI12_AVX512VL 0 "register_operand" "=v")
+ (popcount:VI12_AVX512VL
+ (match_operand:VI12_AVX512VL 1 "nonimmediate_operand" "vm")))]
+ "TARGET_AVX512BITALG")
+
(define_insn "vpopcount"
[(set (match_operand:VI12_AVX512VL 0 "register_operand" "=v")
(popcount:VI12_AVX512VL
---
But for vector byte/word/quadword, vectorizer still use vpopcntd, but not
vpopcnt{b,w,q}, missing corresponding ifn?
void
fooq(long long* __restrict dest, long long* src)
{
for (int i = 0; i != 4; i++)
dest[i] = __builtin_popcount (src[i]);
}
void
foow(short* __restrict dest, short* src)
{
for (int i = 0; i != 16; i++)
dest[i] = __builtin_popcount (src[i]);
}
void
foob(char* __restrict dest, char* src)
{
for (int i = 0; i != 32; i++)
dest[i] = __builtin_popcount (src[i]);
}
dump of test.c.164.vect
;; Function foow (foow, funcdef_no=0, decl_uid=4228, cgraph_uid=1,
symbol_order=0)
Merging blocks 2 and 6
foow (short int * restrict dest, short int * src)
{
vector(8) short int * vectp_dest.10;
vector(8) short int * vectp_dest.9;
vector(8) short int vect__8.8;
vector(4) int vect__6.7;
vector(4) unsigned int vect__5.6;
vector(8) short int vect__4.5;
vector(8) short int * vectp_src.4;
vector(8) short int * vectp_src.3;
int i;
long unsigned int _1;
long unsigned int _2;
short int * _3;
short int _4;
unsigned int _5;
int _6;
short int * _7;
short int _8;
unsigned int ivtmp_26;
unsigned int ivtmp_28;
unsigned int ivtmp_34;
unsigned int ivtmp_35;
[local count: 119292720]:
[local count: 119292719]:
# i_19 = PHI
# ivtmp_35 = PHI
# vectp_src.3_24 = PHI
# vectp_dest.9_9 = PHI
# ivtmp_26 = PHI
_1 = (long unsigned int) i_19;
_2 = _1 * 2;
_3 = src_12(D) + _2;
vect__4.5_22 = MEM [(short int *)vectp_src.3_24];
_4 = *_3;
vect__5.6_21 = [vec_unpack_lo_expr] vect__4.5_22;
vect__5.6_18 = [vec_unpack_hi_expr] vect__4.5_22;
_5 = (unsigned int) _4;
vect__6.7_17 = .POPCOUNT (vect__5.6_21);
vect__6.7_16 = .POPCOUNT (vect__5.6_18);
_6 = 0;
_7 = dest_13(D) + _2;
vect__8.8_10 = VEC_PACK_TRUNC_EXPR ;
_8 = (short int) _6;
MEM [(short int *)vectp_dest.9_9] = vect__8.8_10;
i_15 = i_19 + 1;
ivtmp_34 = ivtmp_35 - 1;
vectp_src.3_23 = vectp_src.3_24 + 16;
vectp_dest.9_29 = vectp_dest.9_9 + 16;
ivtmp_28 = ivtmp_26 + 1;
if (ivtmp_28 < 1)
goto ; [0.00%]
else
goto ; [100.00%]
[local count: 0]:
goto ; [100.00%]
[local count: 119292720]:
return;
}
[Bug libstdc++/97759] Could std::has_single_bit be faster?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97759 --- Comment #11 from Hongtao.liu --- (In reply to gcc-bugs from comment #10) > And maybe a related question: > > I know that an arithmetic implementation might auto-vectorize, but would a > popcount implementation do that too? > > Since AVX512_BITALG > (https://software.intel.com/sites/landingpage/IntrinsicsGuide/ > #text=popcnt=4350) retro-introduced popcount for smaller vector > lengths, what is with instruction sets like AVX2 and lower? I open a bugzilla for it in 97770.
[Bug target/97770] Missing vectorization for vpopcnt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97770 --- Comment #1 from Hongtao.liu --- For target side, we need to add expander for popcountm2 with m vector mode
[Bug target/97770] New: Missing vectorization for vpopcnt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97770
Bug ID: 97770
Summary: Missing vectorization for vpopcnt
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: crazylht at gmail dot com
Target Milestone: ---
cat test.c
---
void
foo(int* __restrict dest, int* src, int n)
{
for (int i = 0; i != 8; i++)
dest[i] = __builtin_popcount (src[i]);
}
---
gcc -O3 -march=icelake-server -S -fopt-info-all
Inlined 0 calls, eliminated 0 functions
test.c:4:3: missed: couldn't vectorize loop
test.c:5:15: missed: not vectorized: relevant stmt not supported: _7 =
__builtin_popcount (_5);
test.c:2:1: note: vectorized 0 loops in function.
test.c:4:3: note: * Analysis failed with vector mode VOID
test.c:4:3: note: * Analysis failed with vector mode V8SI
test.c:4:3: note: * Skipping vector mode V32QI, which would repeat the
analysis for V8SI
test.c:6:1: note: * Analysis failed with vector mode VOID
This loop could be vectorized by ICC and Clang:
foo(int*, int*, int):
vpopcntd ymm0, YMMWORD PTR [rsi] #5.15
vmovdqu YMMWORD PTR [rdi], ymm0 #5.5
vzeroupper #6.1
ret
[Bug tree-optimization/97567] [11 Regression] wrong code at -Os and above on x86_64-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97567 --- Comment #8 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:7d26a337bfa1135d95caa3c213e82f2a97f18a01 commit r11-4862-g7d26a337bfa1135d95caa3c213e82f2a97f18a01 Author: Andrew MacLeod Date: Mon Nov 9 19:38:22 2020 -0500 Fix logical_combine OR operation. Again. The original fix was incorrect and results in loss of opportunities. Revert the original fix. When processing logical chains, do not follow chains outside of the current basic block. Use the import value instead. gcc/ PR tree-optimization/97567 * gimple-range-gori.cc: (gori_compute::logical_combine): False OR operations should intersect the 2 results. (gori_compute::compute_logical_operands_in_chain): If def chains are outside the current basic block, don't follow them. gcc/testsuite/ * gcc.dg/pr97567-2.c: New.
[Bug tree-optimization/97567] [11 Regression] wrong code at -Os and above on x86_64-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97567 --- Comment #7 from Andrew Macleod --- The original fix was incorrect. It papered over a problem by reducing opportunities it could find. Given if (c_2 || c_3) If the FALSE edge is taken, this is ! (c_2 || c_3) which is equivalent to !c_2 && !c_3.. so performing the intersection as combine_logical was originally doing was correct. I found this by examining cases we were missing because this was no longer being combined properly. which sent be back to this PR to figure out what the real reason for the failure was. The GORI design specification calculates outgoing ranges using dependency chains, but as soon as the chain goes outside the current block, we are suppose to revert to using the on-entry range since control flow could dictate further range changes. I had noticed that on certain occasions we'd peek into other blocks, and each time I saw it, it was beneficial and seemed like a harmless recalculation, So I let it go. In this particular case, during the on-entry cache propagation we were peeking into another block to pick up a value used in the logical OR operation. Unfortunately, the on-entry cache hadn't finished propagating and the incomplete range was picked up from that other block instead of the current one, and we ended up calculating a [0,0] range on an outgoing edge that should have been VARYING. And bad things happened. The fix is to patch the logical evaluation code to do the same thing as the non-logical code, follow the spec, and simply use the range-on-entry value for the block if the def chain leads out of the current block
[Bug libstdc++/97759] Could std::has_single_bit be faster?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97759 --- Comment #10 from gcc-bugs at marehr dot dialup.fu-berlin.de --- And maybe a related question: I know that an arithmetic implementation might auto-vectorize, but would a popcount implementation do that too? Since AVX512_BITALG (https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=popcnt=4350) retro-introduced popcount for smaller vector lengths, what is with instruction sets like AVX2 and lower?
[Bug c++/94404] [meta-bug] C++ core issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404 Bug 94404 depends on bug 97453, which changed state. Bug 97453 Summary: Implement CWG issue 2303 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97453 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/97453] Implement CWG issue 2303
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97453 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Marek Polacek --- Implemented in GCC 11.
[Bug libstdc++/97759] Could std::has_single_bit be faster?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97759 --- Comment #9 from gcc-bugs at marehr dot dialup.fu-berlin.de --- Thank you for so many responses (In reply to Thomas Koenig from comment #1) > Could you post the benchmark and the exact architecture where the arithmetic > version is faster? ``` > cat /proc/cpuinfo rocessor: 0 vendor_id : GenuineIntel cpu family : 6 model : 158 model name : Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz stepping: 9 microcode : 0xd6 cpu MHz : 3489.761 cache size : 8192 KB physical id : 0 siblings: 8 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 22 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d vmx flags : vnmi preemption_timer invvpid ept_x_only ept_ad ept_1gb flexpriority tsc_offset vtpr mtf vapic ept vpid unrestricted_guest ple shadow_vmcs pml ept_mode_based_exec bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs taa itlb_multihit srbds bogomips: 5802.42 clflush size: 64 cache_alignment : 64 address sizes : 39 bits physical, 48 bits virtual power management: ``` I added the sources. You can execute it by putting it into one folder and execute ``` > cmake -DCMAKE_BUILD_TYPE=Release ./ > make VERBOSE=1 /usr/bin/c++ -I/benchmark/_deps/gbenchmark_fetch_content-src/src/../include -O3 -DNDEBUG -std=gnu++2a -o CMakeFiles/has_single_bit_benchmark.dir/has_single_bit_benchmark.cpp.o -c /benchmark/has_single_bit_benchmark.cpp ``` ``` > ./has_single_bit_benchmark --benchmark_repetitions=9 --benchmark_min_time=2 2020-11-10T00:32:52+01:00 Running ./has_single_bit_benchmark Run on (8 X 3900 MHz CPU s) CPU Caches: L1 Data 32 KiB (x4) L1 Instruction 32 KiB (x4) L2 Unified 256 KiB (x4) L3 Unified 8192 KiB (x1) Load Average: 0.57, 0.82, 1.35 ***WARNING*** CPU scaling is enabled, the benchmark real time measurements may be noisy and will incur extra overhead. --- Benchmark Time CPU Iterations --- has_single_bit_arithmetic_mean 6.45 ns 6.44 ns9 has_single_bit_arithmetic_median 6.44 ns 6.44 ns9 has_single_bit_arithmetic_stddev 0.113 ns0.111 ns9 has_single_bit_popcount_mean 8.84 ns 8.82 ns9 has_single_bit_popcount_median 8.84 ns 8.82 ns9 has_single_bit_popcount_stddev0.060 ns0.061 ns9 has_single_bit_std_mean9.23 ns 9.21 ns9 has_single_bit_std_median 9.23 ns 9.20 ns9 has_single_bit_std_stddev 0.046 ns0.048 ns9 ``` I thought about it and tried the same again with `-march=native` and noticed that popcount was now (slightly) more efficient. Some more testing showed that `-mpopcnt` is everything needed to make this test fly. --- Benchmark Time CPU Iterations --- has_single_bit_arithmetic_mean 6.81 ns 6.81 ns9 has_single_bit_arithmetic_median 6.81 ns 6.80 ns9 has_single_bit_arithmetic_stddev 0.201 ns0.200 ns9 has_single_bit_popcount_mean 6.47 ns 6.47 ns9 has_single_bit_popcount_median 6.46 ns 6.46 ns9 has_single_bit_popcount_stddev0.043 ns0.042 ns9 has_single_bit_std_mean6.50 ns 6.50 ns9 has_single_bit_std_median 6.51 ns 6.50 ns9 has_single_bit_std_stddev 0.031 ns0.031 ns9 So the use case would be generic builds like debian binaries.
[Bug libstdc++/97759] Could std::has_single_bit be faster?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97759 --- Comment #7 from gcc-bugs at marehr dot dialup.fu-berlin.de --- Created attachment 49530 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49530=edit CMakeLists.txt
[Bug libstdc++/97759] Could std::has_single_bit be faster?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97759 --- Comment #8 from gcc-bugs at marehr dot dialup.fu-berlin.de --- Created attachment 49531 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49531=edit has_single_bit_benchmark.cpp
[Bug c++/93907] [10 Regression] internal compiler error: in hashtab_chk_error, at hash-table.c:137
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93907 --- Comment #7 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:71a8040716c1342547a19c25bd0203ac29258ef3 commit r11-4856-g71a8040716c1342547a19c25bd0203ac29258ef3 Author: Patrick Palka Date: Mon Nov 9 18:12:42 2020 -0500 c++: Fix ICE with variadic concepts and aliases [PR93907] This patch (naively) extends the PR93907 fix to also apply to variadic concepts invoked with a type argument pack. Without this, we ICE on the below testcase (a variadic version of concepts-using2.C) in the same manner as we used to on concepts-using2.C before r10-7133. gcc/cp/ChangeLog: PR c++/93907 * constraint.cc (tsubst_parameter_mapping): Also canonicalize the type arguments of a TYPE_ARGUMENT_PACk. gcc/testsuite/ChangeLog: PR c++/93907 * g++.dg/cpp2a/concepts-using3.C: New test, based off of concepts-using2.C.
[Bug fortran/97589] Segementation fault when allocating coarrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589 Thomas Koenig changed: What|Removed |Added Status|NEW |WAITING --- Comment #6 from Thomas Koenig --- After https://gcc.gnu.org/pipermail/gcc-cvs/2020-November/336787.html the simplified test case seems to be fixed. What I now get with the original test case is Decomposition information on image 4 : there are 2 * 4 slabs; the slab on this image has 45 * 21 grid cells. Decomposition information on image 6 : there are 2 * 4 slabs; the slab on this image has 45 * 23 grid cells. Decomposition information on image 2 : there are 2 * 4 slabs; the slab on this image has 45 * 23 grid cells. Decomposition information on image 8 : there are 2 * 4 slabs; the slab on this image has 45 * 21 grid cells. Decomposition information on image 5 : there are 2 * 4 slabs; the slab on this image has 45 * 23 grid cells. Decomposition information on image 1 : there are 2 * 4 slabs; the slab on this image has 45 * 23 grid cells. Decomposition information on image 7 : there are 2 * 4 slabs; the slab on this image has 45 * 23 grid cells. Decomposition information on image 3 : there are 2 * 4 slabs; the slab on this image has 45 * 23 grid cells. Size mismatch for coarray allocation id 0x608460: found = 30240 != size = 33120 where the error message seems to be correct; I think all coarrays on different images must have the same size. Toon, could you maybe comment?
[Bug fortran/97589] Segementation fault when allocating coarrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589 Thomas Koenig changed: What|Removed |Added Status|REOPENED|NEW --- Comment #5 from Thomas Koenig --- Really reduced test case, no derived types are needed to expose the bug. program random_weather implicit none real, allocatable :: my_ps(:,:) [:,:] integer :: i, npx, nxlocal, nylocal, nzglobal nxlocal = 23 nylocal = 23 nzglobal = 30 npx = 4 allocate (my_ps(0:nxlocal-1, 0:nylocal-1) [0:npx-1,0:*]) end program random_weather
[Bug fortran/97589] Segementation fault when allocating coarrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589 --- Comment #4 from Thomas Koenig --- (In reply to Thomas Koenig from comment #3) > Simplified test case: > > program main > type foo > real, allocatable, dimension(:) :: a[:] > end type foo > type (foo) :: x > sync all > allocate (x%a(10)[*]) > end program main Correction: That does not always segfault.
[Bug fortran/97768] [10/11 Regression] 32-bit f951 ICE on code from OpenMolcas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97768 --- Comment #7 from Jakub Jelinek --- Created attachment 49529 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49529=edit gcc11-pr97768.patch More complete (but still untested) patch.
[Bug c++/97762] [11 Regression] ICE: Segmentation fault (in warn_about_ambiguous_parse)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97762 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Marek Polacek --- Fixed.
[Bug c++/97762] [11 Regression] ICE: Segmentation fault (in warn_about_ambiguous_parse)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97762 --- Comment #4 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:3a5f8d745f8e26d973218b088788f22ad197ca67 commit r11-4850-g3a5f8d745f8e26d973218b088788f22ad197ca67 Author: Marek Polacek Date: Mon Nov 9 10:19:07 2020 -0500 c++: Fix -Wvexing-parse ICE with omitted int [PR97762] For declarations like long f(); decl_specifiers->type will be NULL, but I neglected to handle this case, therefore we ICE. So handle this case by pretending we've seen 'int', which is good enough for -Wvexing-parse's purposes. gcc/cp/ChangeLog: PR c++/97762 * parser.c (warn_about_ambiguous_parse): Handle the case when there is no type in the decl-specifiers. gcc/testsuite/ChangeLog: PR c++/97762 * g++.dg/warn/Wvexing-parse8.C: New test.
[Bug fortran/97768] [10/11 Regression] 32-bit f951 ICE on code from OpenMolcas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97768 --- Comment #6 from Jakub Jelinek --- I'd have thought doing it inside of if (ex->ts.u.cl && ex->ts.u.cl->length) conditional and testing for ex->ts.u.cl->length->expr_type instead. Plus for the CHARACTER case, it doesn't need to use buffer and can just return "CHARACTER";
[Bug fortran/97768] [10/11 Regression] 32-bit f951 ICE on code from OpenMolcas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97768
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2020-11-09
Ever confirmed|0 |1
CC||anlauf at gcc dot gnu.org
Priority|P3 |P4
--- Comment #5 from anlauf at gcc dot gnu.org ---
So sth. technically similar to
diff --git a/gcc/fortran/misc.c b/gcc/fortran/misc.c
index 65bcfa6162f..1338f7e3114 100644
--- a/gcc/fortran/misc.c
+++ b/gcc/fortran/misc.c
@@ -224,6 +224,14 @@ gfc_typename (gfc_expr *ex)
if (ex->ts.type == BT_CHARACTER)
{
+ if (ex->expr_type != EXPR_CONSTANT)
+ {
+ if (ex->ts.kind == gfc_default_character_kind)
+ sprintf (buffer, "CHARACTER");
+ else
+ sprintf (buffer, "CHARACTER(KIND=%d)", ex->ts.kind);
+ return buffer;
+ }
if (ex->ts.u.cl && ex->ts.u.cl->length)
length = gfc_mpz_get_hwi (ex->ts.u.cl->length->value.integer);
else
(or a cleaned up version of that function) would solve this?
[Bug tree-optimization/97736] [9/10/11 Regression] switch codegen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97736 --- Comment #6 from ncm at cantrip dot org --- The referenced patch seems to have also deleted a fair bit of explanatory comment text, including a list of possible refinements for selected targets.
[Bug c/97769] [11 Regression] vectorizer ICE when building perlbench in SPECCPU 2017
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97769 --- Comment #1 from Tamar Christina --- This seems to go away if you initialize a in `int a`.
[Bug c/97769] New: [11 Regression] vectorizer ICE when building perlbench in SPECCPU 2017
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97769
Bug ID: 97769
Summary: [11 Regression] vectorizer ICE when building perlbench
in SPECCPU 2017
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tnfchris at gcc dot gnu.org
Target Milestone: ---
Created attachment 49528
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49528=edit
reproducer for ice
With vectorizer enabled the perlbench benchmark ICEs if you bump up the inliner
limit:
during GIMPLE pass: vect
tmp.i: In function 'fn3':
tmp.i:25:1: internal compiler error: in vect_update_misalignment_for_peel, at
tree-vect-data-refs.c:1196
25 | fn3() { fn2(&()->otmp); }
| ^~~
0x19f9b43 vect_update_misalignment_for_peel
../../gcc-fsf/gcc/tree-vect-data-refs.c:1193
0x19f9def vect_get_peeling_costs_all_drs
../../gcc-fsf/gcc/tree-vect-data-refs.c:1481
0x19fb83b vect_peeling_hash_get_lowest_cost(_vect_peel_info**,
_vect_peel_extended_info*)
../../gcc-fsf/gcc/tree-vect-data-refs.c:1508
0x1a068cb void hash_table::traverse_noresize<_vect_peel_extended_info*,
&(vect_peeling_hash_get_lowest_cost(_vect_peel_info**,
_vect_peel_extended_info*))>(_vect_peel_extended_info*)
../../gcc-fsf/gcc/hash-table.h:1081
0x1a068cb void hash_table::traverse<_vect_peel_extended_info*,
&(vect_peeling_hash_get_lowest_cost(_vect_peel_info**,
_vect_peel_extended_info*))>(_vect_peel_extended_info*)
../../gcc-fsf/gcc/hash-table.h:1102
0x1a068cb vect_peeling_hash_choose_best_peeling
../../gcc-fsf/gcc/tree-vect-data-refs.c:1557
0x1a068cb vect_enhance_data_refs_alignment(_loop_vec_info*)
../../gcc-fsf/gcc/tree-vect-data-refs.c:2058
0x10ef27f vect_analyze_loop_2
../../gcc-fsf/gcc/tree-vect-loop.c:2351
0x10f03b3 vect_analyze_loop(loop*, vec_info_tmpred*)
../../gcc-fsf/gcc/tree-vect-loop.c:2895
0x1118d83 try_vectorize_loop_1
../../gcc-fsf/gcc/tree-vectorizer.c:995
0x11194ff vectorize_loops()
../../gcc-fsf/gcc/tree-vectorizer.c:1230
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug debug/97441] gcc writes absolute path to .stabstr section even if fdebug-prefix-map is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97441 Denys Zahorui changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Denys Zahorui --- This is assembler util (binutils) related issue. Fixed there https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=0541201782c006c09d029d18a45c6e743cfea906
[Bug fortran/97768] [10/11 Regression] 32-bit f951 ICE on code from OpenMolcas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97768 --- Comment #4 from Jakub Jelinek --- Or the length could be e.g. local variable: subroutine baz (lens) use fortran_strings, only : to_upper, operator(.in.) integer :: lens character(len=lens) str logical l str = '' l = 32 .in. to_upper(str) end subroutine baz Either we should come up with some syntax how to print the length not known at compile time (but normally * stands for assumed and : for deferred length), or another option is just not to print the length if it isn't known integer constant except for the * the gfc_dummy_typename prints - e.g. print just CHARACTER for default kind and CHARACTER(KIND=4) for kind 4.
[Bug fortran/97768] [10/11 Regression] 32-bit f951 ICE on code from OpenMolcas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97768 Jakub Jelinek changed: What|Removed |Added CC||markeggleston at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Apparently broken with r10-3605-gf61e54e59cda5a2e281d525d3f87ffa179fae1ae
[Bug pch/56549] #pragma once ineffective with BOM in include file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56549
Julien Ruffin changed:
What|Removed |Added
CC||julien.ruffin at ivu dot de
--- Comment #6 from Julien Ruffin ---
I have been having the same issue with GCC 9.2.0 for a while and ended up
finding the cause of this error. It can be traced back to function
_cpp_save_file_entries in gcc/libcpp/files.c.
Short explanation: the function saves the sizes and MD5 checksums of files
without any encoding conversion or BOM removal into the PCH's file list, even
though it should.
Long explanation: the function fills the PCH's files list which contains, among
other things, the sizes and MD5 checksums of all files in the PCH. Later, when
using the PCH, the compiler compares the files it loads with the files in that
list. If it finds an entry with the same size and checksum as the loaded file,
it is in the PCH and the compiler skips processing it: see
check_file_against_entries for the implementation, also in files.c.
The issue here is that the matching never succeeds for headers that contain a
BOM. The PCH entry is always 3 Bytes longer than the file loaded by the
compiler and the checksums always differ. The following code in
_cpp_save_file_entries is why:
if (f->buffer_valid)
md5_buffer ((const char *)f->buffer,
f->st.st_size, result->entries[count].sum);
else
{
FILE *ff;
int oldfd = f->fd;
if (!open_file (f))
{
open_file_failed (pfile, f, 0, 0);
free (result);
return false;
}
ff = fdopen (f->fd, "rb");
md5_stream (ff, result->entries[count].sum);
fclose (ff);
f->fd = oldfd;
}
result->entries[count].size = f->st.st_size;
libcpp caches the contents of the files it reads into their own buffers, here
f->buffer. The read_file function implements this loading and converts the
file's encoding on the fly with _cpp_convert_input. *This conversion strips the
BOM,* so the contents of f->buffer differ from those of the file whenever a BOM
is used.
If f->buffer_valid is not true, which seems to always be the case in the code
above as far as I could test it, the function reopens the file by hand and
computes the MD5 checksum directly from it, without any conversion. open_file()
also overwrites the data size in f->st.st_size with the size of the unconverted
file. That is why the checksum and size of the unconverted file end up in the
PCH's file list.
The compiler later compares those with the files it loads through read_files.
There never is a match because the checksums and sizes differ and the compiler
thinks it it has loaded a different file, so it processes the header with the
BOM a second time and the error we have been observing happens.
I have managed to solve this issue by replacing the manual loading of the
unconverted file in the else block above with a loading through read_file,
yielding the converted buffer and the correct size and, in the end, the correct
checksum. I do not have a patch to offer yet for various reasons but my
amateurish attempt at a fix made me able to build a large C++ code base
successfully with precompiled headers, so it is rather encouraging.
Somebody with more experience in the preprocessor might want to take a look at
this.
[Bug fortran/97768] [10/11 Regression] 32-bit f951 ICE on code from OpenMolcas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97768 --- Comment #2 from Jakub Jelinek --- If in the testcase I change the penultimate line to: l = 32 .in. to_upper(str) so that an error is emitted, the 64-bit little-endian f951 emits: Error: Operands of user operator ‘in’ at (1) are INTEGER(4)/CHARACTER(0) where the (0) doesn't really reflect the reality either, it is CHARACTER(8) if it would see through the call. Another case where 64-bit little-endian f951 reports CHARACTER(0), for assumed length, etc.: subroutine bar (str) use fortran_strings, only : to_upper, operator(.in.) character(len=*) str logical l l = 32 .in. to_upper(str) end subroutine bar
[Bug fortran/97768] [10/11 Regression] 32-bit f951 ICE on code from OpenMolcas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97768 --- Comment #1 from Jakub Jelinek --- Seems this is only in the pretty-printing for message that would be printed if there was an error later on (which there is not). So I guess it really doesn't matter that much what exactly it prints, but it should have a way how to say that the CHARACTER length is not known at compile time (dunno, write * instead of a number or something similar).
[Bug testsuite/97117] [11 regression] location-overflow-test-1.c FAILs after r11-3266
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97117 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Patrick Palka --- Fixed.
[Bug testsuite/97117] [11 regression] location-overflow-test-1.c FAILs after r11-3266
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97117 --- Comment #2 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:4394b1ce7731b04446555e034163b14b4f4a7f8d commit r11-4848-g4394b1ce7731b04446555e034163b14b4f4a7f8d Author: Patrick Palka Date: Mon Nov 9 11:09:42 2020 -0500 c-family: Fix regression in location-overflow-test-1.c [PR97117] The r11-3266 patch that added macro support to -Wmisleading-indentation accidentally suppressed the column-tracking diagnostic in get_visual_column in some cases, e.g. in the location-overflow-test-1.c testcase. More generally, when all three tokens are on the same line and we've run out of locations with column info, then their location_t values will be equal, and we exit early from should_warn_for_misleading_indentation due to the new check /* Give up if the loci are not all distinct. */ if (guard_loc == body_loc || body_loc == next_stmt_loc) return false; before we ever call get_visual_column. [ This new check is needed to detect and give up on analyzing code fragments where exactly two out of the three tokens come from the same macro expansion, e.g. #define MACRO \ if (a) \ foo (); MACRO; bar (); Here, guard_loc and body_loc will be equal and point to the macro expansion point (and next_stmt_loc will point to 'bar'). The heuristics that the warning uses are not really valid in scenarios like these. ] In order to restore the column-tracking diagnostic, this patch moves the the diagnostic code out from get_visual_column to earlier in should_warn_for_misleading_indentation. Moreover, it tests the three locations for a zero column all at once, which I suppose should make us issue the diagnostic more consistently. gcc/c-family/ChangeLog: PR testsuite/97117 * c-indentation.c (get_visual_column): Remove location_t parameter. Move the column-tracking diagnostic code from here to ... (should_warn_for_misleading_indentation): ... here, before the early exit for when the loci are not all distinct. Don't pass a location_t argument to get_visual_column. (assert_get_visual_column_succeeds): Don't pass a location_t argument to get_visual_column. (assert_get_visual_column_fails): Likewise.
[Bug fortran/97768] [10/11 Regression] 32-bit f951 ICE on code from OpenMolcas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97768 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |10.3
[Bug fortran/97768] New: [10/11 Regression] 32-bit f951 ICE on code from OpenMolcas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97768
Bug ID: 97768
Summary: [10/11 Regression] 32-bit f951 ICE on code from
OpenMolcas
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
module fortran_strings
interface operator(.in.)
module procedure substr_in_str
end interface
contains
pure function to_upper (in_str) result (string)
character(len=*), intent(in) :: in_str
character(len=len(in_str)) :: string
string = in_str
end function to_upper
logical pure function substr_in_str(substring, string)
character(len=*), intent(in) :: string, substring
substr_in_str=.false.
end function
end module
subroutine foo ()
use fortran_strings, only : to_upper, operator(.in.)
character(len=8) str
logical l
str = 'abcdefgh'
l = 'I' .in. to_upper(str)
end subroutine foo
ICEs in f951 when it is built as 32-bit binary (e.g. on i686-linux) in 10 and
trunk (e.g. 10 snapshot from 25th August as well as current 10 branch and
current master) in gmp:
Program received signal SIGSEGV, Segmentation fault.
0xf7c196b5 in __gmpz_sizeinbase () from /lib/libgmp.so.10
(gdb) bt
#0 0xf7c196b5 in __gmpz_sizeinbase () from /lib/libgmp.so.10
#1 0x08f8b12a in wi::from_mpz (type=, x=0xa9ab710, wrap=true)
at ../../gcc/wide-int.cc:269
#2 0x08620751 in gfc_mpz_get_hwi (op=) at
../../gcc/fortran/misc.c:426
#3 gfc_typename (ex=0xa9a9db0) at ../../gcc/fortran/misc.c:228
#4 0x0865e80e in resolve_operator (e=0xa9a9e40) at
../../gcc/fortran/resolve.c:4309
#5 gfc_resolve_expr (e=0xa9a9e40) at ../../gcc/fortran/resolve.c:7081
#6 0x08667853 in gfc_resolve_expr (e=) at
../../gcc/fortran/resolve.c:7055
#7 gfc_resolve_code (code=, ns=) at
../../gcc/fortran/resolve.c:11806
#8 0x0866bc2b in resolve_codes (ns=ns@entry=0xa996160) at
../../gcc/fortran/resolve.c:17340
#9 0x08657ca6 in gfc_resolve (ns=0xa996160) at
../../gcc/fortran/resolve.c:17375
#10 gfc_resolve (ns=0xa996160) at ../../gcc/fortran/resolve.c:17354
#11 0x0864b76a in resolve_all_program_units (gfc_global_ns_list=) at ../../gcc/fortran/parse.c:6285
#12 gfc_parse_file () at ../../gcc/fortran/parse.c:6537
#13 0x0869b7c8 in gfc_be_parse_file () at ../../gcc/fortran/f95-lang.c:212
#14 0x08c4696e in compile_file () at ../../gcc/toplev.c:460
#15 0x085a39a2 in do_compile () at ../../gcc/toplev.c:2320
#16 toplev::main (this=0xc97e, argc=, argv=)
at ../../gcc/toplev.c:2459
#17 0x085a7d21 in main (argc=3, argv=0xca54) at ../../gcc/main.c:39
(gdb) p *ex->ts.u.cl->length
$4 = {expr_type = EXPR_FUNCTION, ts = {type = BT_INTEGER, kind = 4, u =
{derived = 0x0, cl = 0x0, pad = 0}, interface = 0x0, is_c_interop = 0,
is_iso_c = 0, f90_type = BT_INTEGER, deferred = false, interop_kind = 0x0},
rank = 0, shape = 0x0, symtree = 0xa996b70, ref = 0x0, where = {
nextc = 0xa98f7fc, lb = 0xa98f7d0}, base_expr = 0x0, is_snan = 0, error =
0, user_operator = 0, mold = 0, must_finalize = 0,
no_bounds_check = 0, external_blas = 0, do_not_resolve_again = 0, do_not_warn
= 0, from_constructor = 0, representation = {length = 0,
string = 0x0}, boz = {len = 0, rdx = 0, str = 0x0}, value = {logical =
177828352, iokind = 177828352, integer = {{_mp_alloc = 177828352,
_mp_size = -149074752, _mp_d = 0xa972250}}, real = {{_mpfr_prec =
177828352, _mpfr_sign = -149074752, _mpfr_exp = 177676880,
_mpfr_d = 0x0}}, complex = {{re = {{_mpfr_prec = 177828352, _mpfr_sign
= -149074752, _mpfr_exp = 177676880, _mpfr_d = 0x0}}, im = {{
_mpfr_prec = 0, _mpfr_sign = 0, _mpfr_exp = 0, _mpfr_d = 0x0,
op = {op = 177828352, uop = 0xf71d4cc0, op1 = 0xa972250,
op2 = 0x0}, function = {actual = 0xa997200, name = 0xf71d4cc0
"__len_1_i4", isym = 0xa972250, esym = 0x0}, compcall = {actual = 0xa997200,
name = 0xf71d4cc0 "__len_1_i4", base_object = 0xa972250, tbp = 0x0,
ignore_pass = 0, assign = 0}, character = {
length = -640271184321482240, string = 0xa972250}, constructor =
0xa997200}, param_list = 0x0}
I'd guess the problem is the negative value.integer._mp_size.
That value is set with:
3836 if (atom_string[0] == '\0')
3837e->value.function.name = NULL;
3838 else
3839e->value.function.name = gfc_get_string ("%s",
atom_string);
so I guess value.integer is not the right union member, value.function is
{actual = 0xa997200, name = 0xf71d4cc0 "__len_1_i4", isym = 0xa972250, esym =
0x0}
The reason why this doesn't ICE with 64-bit f951 is that both
value.function.actual and value.function.name are 64-bit pointers there, while
32-bit pointers in the 32-bit f951, but value.integer._mp_alloc and
value.integer._mp_size are 32-bit integers in all cases.
So on little-endian 64-bit that means integer._mp_size is the top 32
[Bug tree-optimization/97767] [11 Regression] ICE in extract_range_basic, at vr-values.c:1445 since r11-4532-g054d7b9f6f6816a8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97767 Martin Liška changed: What|Removed |Added CC||aldyh at gcc dot gnu.org, ||amacleod at redhat dot com, ||marxin at gcc dot gnu.org Status|UNCONFIRMED |NEW Summary|[11 Regression] ICE in |[11 Regression] ICE in |extract_range_basic, at |extract_range_basic, at |vr-values.c:1445|vr-values.c:1445 since ||r11-4532-g054d7b9f6f6816a8 Target Milestone|--- |11.0 Last reconfirmed||2020-11-09 Priority|P3 |P1 Known to fail||11.0 Ever confirmed|0 |1 Known to work||10.2.0 --- Comment #1 from Martin Liška --- Confirmed, started with r11-4532-g054d7b9f6f6816a8.
[Bug tree-optimization/97767] New: [11 Regression] ICE in extract_range_basic, at vr-values.c:1445
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97767 Bug ID: 97767 Summary: [11 Regression] ICE in extract_range_basic, at vr-values.c:1445 Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- g++-11.0.0-alpha20201101 snapshot (g:590febb5f6624f78b36402a7c9a9c318978f1efa) ICEs when compiling gcc/testsuite/gcc.dg/builtins-66.c w/ -O1 -fstrict-enums -ftree-vrp: % g++-11.0.0 -O1 -fstrict-enums -ftree-vrp -c gcc/testsuite/gcc.dg/builtins-66.c during GIMPLE pass: evrp gcc/testsuite/gcc.dg/builtins-66.c: In function 'int foo()': gcc/testsuite/gcc.dg/builtins-66.c:9:1: internal compiler error: in extract_range_basic, at vr-values.c:1445 9 | } | ^ 0x7fa858 vr_values::extract_range_basic(value_range_equiv*, gimple*) /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/vr-values.c:1445 0x19d1bf5 evrp_range_analyzer::record_ranges_from_stmt(gimple*, bool) /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/gimple-ssa-evrp-analyze.c:304 0x11cd124 substitute_and_fold_dom_walker::before_dom_children(basic_block_def*) /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/tree-ssa-propagate.c:1099 0x199be37 dom_walker::walk(basic_block_def*) /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/domwalk.c:309 0x11cc1b7 substitute_and_fold_engine::substitute_and_fold(basic_block_def*) /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/tree-ssa-propagate.c:1283 0x19cfabe execute_early_vrp /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/gimple-ssa-evrp.c:349
[Bug c++/97740] Weird error message about accessing a private member of my own class inside of std::string_view inside of constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97740 --- Comment #1 from Jonathan Wakely --- N.B. the "diagnostic" keyword is for poor quality diagnostics, not ones that shouldn't happen at all. Code that shouldn't give an error at all should use "rejects-valid" instead.
[Bug c++/97740] Weird error message about accessing a private member of my own class inside of std::string_view inside of constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97740 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords|diagnostic |rejects-valid Ever confirmed|0 |1 Last reconfirmed||2020-11-09
[Bug libstdc++/97731] terminate called in std::experimental::filesystem::recursive_directory_iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97731 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Jonathan Wakely --- Fixed for 8.5, 9.4, 10.3 and 11.1 The gcc-10 commit was r10-8982 but didn't get added above.
[Bug libstdc++/97731] terminate called in std::experimental::filesystem::recursive_directory_iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97731 --- Comment #4 from CVS Commits --- The releases/gcc-8 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:749cfa1f150d1e0749feb7aed8f68b8d0294b03f commit r8-10616-g749cfa1f150d1e0749feb7aed8f68b8d0294b03f Author: Jonathan Wakely Date: Thu Nov 5 17:26:13 2020 + libstdc++: Use non-throwing increment in recursive_directory_iterator [PR 97731] As described in the PR, the recursive_directory_iterator constructor calls advance(ec), but ec is a pointer so it calls _Dir::advance(bool). The intention was to either call advance() or advance(*ec) depending whether the pointer is null or not. This fixes the bug and renames the parameter to ecptr to make similar mistakes less likely in future. libstdc++-v3/ChangeLog: PR libstdc++/97731 * src/filesystem/dir.cc (recursive_directory_iterator): Call the right overload of _Dir::advance. * testsuite/experimental/filesystem/iterators/97731.cc: New test. (cherry picked from commit 2f93a2a03a343a29f614a530d7657f1ed6347ed5)
[Bug ipa/97565] -flto -ipa-pta ICE: at cgraph_node::get_untransformed_body()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97565 --- Comment #3 from Richard Biener --- So the odd thing is that PTA sees /* Nodes without a body are not interesting. Especially do not visit clones at this point for now - we get duplicate decls there for inline clones at least. */ if (!node->has_gimple_body_p () || node->inlined_to) continue; node->get_body (); (gdb) p node->debug () abort/0 (abort) @0x7661b000 Type: function definition Visibility: in_other_partition externally_visible prevailing_def_ironly_exp external public visibility_specified References: Referring: abort/2 (alias) Read from file: ./t.ltrans0.o Availability: available Unit id: 2 Function flags: count:1073741824 (estimated locally) nonfreeing_fn unlikely_executed Called by: Calls: but /* Return true when callgraph node is a function with Gimple body defined in current unit. Functions can also be define externally or they can be thunks with no Gimple representation. Note that at WPA stage, the function body may not be present in memory. */ inline bool has_gimple_body_p (void); where I assume that this means the current _LTRANS_ unit has the body defined. The other odd thing is that the node has ->used_from_other_partition false. Full initial symtab: Creating file ./t.ltrans0.o with sub id 0x7c0d6948e785db2d Symbol table: abort/0 (abort) @0x7f3431cf9000 Type: function definition Visibility: in_other_partition externally_visible prevailing_def_ironly_exp external public visibility_specified References: Referring: abort/2 (alias) Read from file: ./t.ltrans0.o Unit id: 2 Function flags: count:1073741824 (estimated locally) nonfreeing_fn unlikely_executed Called by: Calls: abort/2 (abort) @0x7f3431ef5ee0 Type: function definition analyzed alias transparent_alias Visibility: externally_visible external public visibility_specified References: abort/0 (alias) Referring: Read from file: ./t.ltrans0.o Unit id: 3 Function flags: Called by: main/1 (0 (precise),0.00 per call) (can throw external) Calls: main/1 (main) @0x7f3431ef5dd0 Type: function definition analyzed Visibility: externally_visible prevailing_def public References: Referring: Read from file: ./t.ltrans0.o Unit id: 3 Function flags: count:0 (precise) only_called_at_startup nonfreeing_fn unlikely_executed Called by: Calls: abort/2 (0 (precise),0.00 per call) (can throw external) oddly enough symbol and alias are in different partitions? Honza - is this a PTA bug (need to check in_other_partition?) or a IPA bug?
[Bug fortran/90111] Placement of Fortran OpenACC 'routine' directive inside 'specification-part'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90111 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #3 from Tobias Burnus --- FIXED on mainline (GCC 11). See also remarks in the patch email at: https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558460.html
[Bug fortran/90111] Placement of Fortran OpenACC 'routine' directive inside 'specification-part'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90111 --- Comment #2 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:f27a3b37b4805feba138dd421f039e3267b1c5f0 commit r11-4845-gf27a3b37b4805feba138dd421f039e3267b1c5f0 Author: Tobias Burnus Date: Mon Nov 9 16:16:44 2020 +0100 Fortran: Fix OpenACC in specification-part checks [PR90111] OpenACC's routine and declare directives can appear anywhere in the specification part, i.e. before/after use-stmts, import-stmt, implicit-part, or declaration-constructs. gcc/fortran/ChangeLog: PR fortran/90111 * parse.c (case_decl): Move ST_OACC_ROUTINE and ST_OACC_DECLARE to ... (case_omp_decl): ... here. (verify_st_order): Update comment. gcc/testsuite/ChangeLog: PR fortran/90111 * gfortran.dg/goacc/specification-part.f90: New test.
[Bug target/97535] [9/10 Regression] On AArch64 memcpy expansion cannot handle length > 32-bit signed int max
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97535 Richard Biener changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P2 CC||rguenth at gcc dot gnu.org Target Milestone|--- |9.4
[Bug tree-optimization/97761] [11 Regression] ICE in vectorizable_live_operation, at tree-vect-loop.c:8689 started with r11-4428-g4a369d199bf2f34e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97761 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Richard Biener --- Fixed.
[Bug tree-optimization/91355] [8/9/10/11 Regression] optimized code does not call destructor while unwinding after exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91355 Bill Torpey changed: What|Removed |Added CC||bill.torpey at ullink dot com --- Comment #12 from Bill Torpey --- According to this link (https://linux.oracle.com/errata/ELBA-2020-1683.html) it appears that this bug was fixed in gcc 9.2.1-2 (?), but I'm curious if this applies only to Oracle Linux, or whether this bug has been fixed anywhere in mainline gcc. We're experiencing runtime issues with gcc 8 that *may* be related to this bug. The issues do not occur with gcc 6, but we'd like to know if the bug has been fixed in *any* releases of gcc. TIA for any information you can provide.
[Bug c++/97762] [11 Regression] ICE: Segmentation fault (in warn_about_ambiguous_parse)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97762
Marek Polacek changed:
What|Removed |Added
Keywords|ice-on-invalid-code |ice-on-valid-code
--- Comment #3 from Marek Polacek ---
The code is valid.
// PR c++/97762
// { dg-do compile }
void
g ()
{
long a(); // { dg-warning "empty parentheses" }
signed b(); // { dg-warning "empty parentheses" }
unsigned c(); // { dg-warning "empty parentheses" }
short d(); // { dg-warning "empty parentheses" }
}
[Bug libstdc++/97731] terminate called in std::experimental::filesystem::recursive_directory_iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97731 --- Comment #3 from CVS Commits --- The releases/gcc-9 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:c9769a6eee38c396b797cffd819957fa9f1926b1 commit r9-9034-gc9769a6eee38c396b797cffd819957fa9f1926b1 Author: Jonathan Wakely Date: Thu Nov 5 17:26:13 2020 + libstdc++: Use non-throwing increment in recursive_directory_iterator [PR 97731] As described in the PR, the recursive_directory_iterator constructor calls advance(ec), but ec is a pointer so it calls _Dir::advance(bool). The intention was to either call advance() or advance(*ec) depending whether the pointer is null or not. This fixes the bug and renames the parameter to ecptr to make similar mistakes less likely in future. libstdc++-v3/ChangeLog: PR libstdc++/97731 * src/filesystem/dir.cc (recursive_directory_iterator): Call the right overload of _Dir::advance. * testsuite/experimental/filesystem/iterators/97731.cc: New test. (cherry picked from commit 2f93a2a03a343a29f614a530d7657f1ed6347ed5)
[Bug target/97638] aarch64: bti c is missing at function entry with branch-protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97638 --- Comment #2 from CVS Commits --- The releases/gcc-10 branch has been updated by Sudakshina Das : https://gcc.gnu.org/g:454702f5213a7a8b6b3581c29c817b952ce0f184 commit r10-8996-g454702f5213a7a8b6b3581c29c817b952ce0f184 Author: Sudakshina Das Date: Mon Nov 2 15:52:22 2020 + [PATCH] aarch64: Fix PR97638 Currently the testcase in the patch was failing to produce a 'bti c' at the beginning of the function. This was because in aarch64_pac_insn_p, we were wrongly returning at the first check! 2020-10-30 Sudakshina Das gcc/ChangeLog: PR target/97638 * config/aarch64/aarch64-bti-insert.c (aarch64_pac_insn_p): Update return value on INSN_P check. gcc/testsuite/ChangeLog: PR target/97638 * gcc.target/aarch64/pr97638.c: New test.a (cherry picked from commit ce99142c11b8090105cbf2aa853262f6d9abc0d3)
[Bug c++/57111] Generalize -Wfree-nonheap-object to delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57111 --- Comment #12 from Jonathan Wakely --- (In reply to Martin Sebor from comment #11) > It detects the bug in the test case in comment #0 but only with optimization > (to see through inlined calls) and with -Wsystem-headers. This seems like a warning that should not be suppressed in system headers. Diagnostic pragmas could be added to system headers to suppress false positives.
[Bug tree-optimization/97761] [11 Regression] ICE in vectorizable_live_operation, at tree-vect-loop.c:8689 started with r11-4428-g4a369d199bf2f34e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97761 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:96f315213f337c2d5a9268f2d3e8337bbdb71bfc commit r11-4842-g96f315213f337c2d5a9268f2d3e8337bbdb71bfc Author: Richard Biener Date: Mon Nov 9 14:32:41 2020 +0100 tree-optimization/97761 - fix SLP live calculation This removes a premature end of the DFS walk. 2020-11-09 Richard Biener PR tree-optimization/97761 * tree-vect-slp.c (vect_bb_slp_mark_live_stmts): Remove premature end of DFS walk. * gfortran.dg/vect/pr97761.f90: New testcase.
[Bug libstdc++/97758] [11 Regression] bits/std_function.h: error: unknown type name 'type_info' when using -fno-exceptions -fno-rtti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97758 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Jonathan Wakely --- Should be fixed now, thanks for the report.
[Bug ipa/97766] ipa/modref-2.c fails on 32 bits targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97766 --- Comment #2 from Richard Biener --- There's target_double64 at least, so dg-require-effective-target double64
[Bug c++/67453] vtable not emitted for class with no key method and defaulted destructor with attribute((used))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67453 --- Comment #6 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:0af3930a497e022597a08fa1bcef5e453bfa636f commit r11-4839-g0af3930a497e022597a08fa1bcef5e453bfa636f Author: Jonathan Wakely Date: Mon Nov 9 10:16:07 2020 + libstdc++: Use 'inline' consistently in std::exception_ptr [PR 97729] With PR c++/67453 fixed we can rely on the 'used' attribute to emit inline constructors and destructors in libsupc++/eh_ptr.cc. This means we don't need to suppress the 'inline' keyword on them in that file, and don't need to force 'always_inline' on them in other files. libstdc++-v3/ChangeLog: PR libstdc++/97729 * libsupc++/exception_ptr.h (exception_ptr::exception_ptr()) (exception_ptr::exception_ptr(const exception_ptr&)) (exception_ptr::~exception_ptr()): Remove 'always_inline' attributes. Use 'inline' unconditionally.
[Bug libstdc++/97758] [11 Regression] bits/std_function.h: error: unknown type name 'type_info' when using -fno-exceptions -fno-rtti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97758 --- Comment #1 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:99bf3a817b9d31905dd12448e853ad2685635250 commit r11-4838-g99bf3a817b9d31905dd12448e853ad2685635250 Author: Jonathan Wakely Date: Mon Nov 9 10:09:51 2020 + libstdc++: Include even for -fno-rtti [PR 97758] The std::function code now uses std::type_info* even when RTTI is disabled, so it should include unconditionally. Without this, Clang can't compile with -fno-rtti (it works with GCC because std::type_info gets declared automatically by the compiler). libstdc++-v3/ChangeLog: PR libstdc++/97758 * include/bits/std_function.h [!__cpp_rtti]: Include .
[Bug libstdc++/97729] [11 Regression] Link failure due to basic_stringbuf and others when building DLL on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97729 --- Comment #11 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:0af3930a497e022597a08fa1bcef5e453bfa636f commit r11-4839-g0af3930a497e022597a08fa1bcef5e453bfa636f Author: Jonathan Wakely Date: Mon Nov 9 10:16:07 2020 + libstdc++: Use 'inline' consistently in std::exception_ptr [PR 97729] With PR c++/67453 fixed we can rely on the 'used' attribute to emit inline constructors and destructors in libsupc++/eh_ptr.cc. This means we don't need to suppress the 'inline' keyword on them in that file, and don't need to force 'always_inline' on them in other files. libstdc++-v3/ChangeLog: PR libstdc++/97729 * libsupc++/exception_ptr.h (exception_ptr::exception_ptr()) (exception_ptr::exception_ptr(const exception_ptr&)) (exception_ptr::~exception_ptr()): Remove 'always_inline' attributes. Use 'inline' unconditionally.
[Bug other/55930] [8/9 Regression] libatomic build failure if configured with --disable-dependency-tracking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55930 --- Comment #23 from ninos --- Created attachment 49527 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49527=edit gfortran.do_configure this is the do_configure log where unrecognized disable-dependency-tracking occurs.
[Bug other/55930] [8/9 Regression] libatomic build failure if configured with --disable-dependency-tracking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55930 --- Comment #22 from ninos --- Created attachment 49526 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49526=edit gfortran config log
[Bug tree-optimization/97760] [10/11 Regression] GCC outputs wrong values when compiling the testcase with -O3 since r10-4200-gb7ff7cef5005721e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97760 --- Comment #5 from Richard Biener --- t.c:9:12: note: worklist: examine stmt: i_16 = PHI t.c:9:12: note: vect_is_simple_use: operand (int) _3, type of def: reduction t.c:9:12: note: reduc-stmt defining reduc-phi in the same nest. t.c:9:12: note: mark relevant 1, live 1: i_11 = (int) _3; so reduc PHI defs are marked live magically - that's obviously wrong here, the live stmt is one in the middle of the reduction path (which _is_ marked live). What happens is that we generate two vectorized epilogues and depending on the order we end up with the wrong result in b. Now, what's _also_ wrong is that we cannot handle this situation since the epilogue of the middle stmt fails to account for the all-but-the-last lane effect of the _not_ live stmt. While the former bug is easy to fix the latter is not. I have a patch.
[Bug other/55930] [8/9 Regression] libatomic build failure if configured with --disable-dependency-tracking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55930 ninos changed: What|Removed |Added CC||nju044 at hotmail dot com --- Comment #21 from ninos --- I'm compiling gfortran in yocto project, but during do_configure it throw out an error: unrecognized options: --disable-dependency-tracking I grep disable-dependency-tracking is yocto layer "core/meta/recipes-devtools/gcc" and find key-word "disable-dependency-tracking" in ./gcc-9.2/0020-gcc-4.8-won-t-build-with-disable-dependency-tracking.patch and ./gcc-9.2.inc. Followings are detailed output from grep: ./gcc-9.2/0020-gcc-4.8-won-t-build-with-disable-dependency-tracking.patch:Subject: [PATCH 20/36] gcc 4.8+ won't build with --disable-dependency-tracking ./gcc-9.2.inc: file://0020-gcc-4.8-won-t-build-with-disable-dependency-tracking.patch \ It seems do_configure use "--disable-dependency-tracking" to compile, but this option is unrecognized. So how to apply "0020-gcc-4.8-won-t-build-with-disable-dependency-tracking.patch" to do_configure? I'm new to yocto, please forgive my ignorance.
[Bug tree-optimization/97746] [11 Regression] ICE in vect_init_pattern_stmt, at tree-vect-patterns.c:115 since r11-4787-g22175d0dc6a89ddd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97746 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:ec735bc7646500570d9d6e45ef335e6d547b1433 commit r11-4835-gec735bc7646500570d9d6e45ef335e6d547b1433 Author: Richard Biener Date: Mon Nov 9 13:55:11 2020 +0100 tree-optimization/97746 - fix order of mask precision computes This fixes the order of walking PHIs and stmts for BB mask precision compute. 2020-11-09 Richard Biener PR tree-optimization/97746 * tree-vect-patterns.c (vect_determine_precisions): First walk PHIs. * gcc.dg/vect/bb-slp-pr97746.c: New testcase.
[Bug tree-optimization/97753] ICE in operator[], at vec.h:880 since r11-4714-g092cdbd919849759
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97753 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Richard Biener --- Fixed.
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 97746, which changed state. Bug 97746 Summary: [11 Regression] ICE in vect_init_pattern_stmt, at tree-vect-patterns.c:115 since r11-4787-g22175d0dc6a89ddd https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97746 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/97746] [11 Regression] ICE in vect_init_pattern_stmt, at tree-vect-patterns.c:115 since r11-4787-g22175d0dc6a89ddd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97746 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Biener --- Fixed.
[Bug c++/97762] [11 Regression] ICE: Segmentation fault (in warn_about_ambiguous_parse)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97762 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Mine.
[Bug tree-optimization/97753] ICE in operator[], at vec.h:880 since r11-4714-g092cdbd919849759
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97753 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:f5761c318a5a973ba2e4e5b09a5213f4e3ad0570 commit r11-4836-gf5761c318a5a973ba2e4e5b09a5213f4e3ad0570 Author: Richard Biener Date: Mon Nov 9 14:03:14 2020 +0100 tree-optimization/97753 - fix SLP induction vect This fixes updating of the step vectors when filling up to group_size. 2020-11-09 Richard Biener PR tree-optimization/97753 * tree-vect-loop.c (vectorizable_induction): Fill vec_steps when CSEing inside the group. * gcc.dg/vect/pr97753.c: New testcase.
[Bug tree-optimization/97764] [10/11 Regression] wrong code at -O1 and above on x86_64-pc-linux-gnu since r10-6809
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97764 --- Comment #2 from Jakub Jelinek --- Created attachment 49525 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49525=edit gcc11-pr97764.patch Untested fix.
[Bug tree-optimization/97760] [10/11 Regression] GCC outputs wrong values when compiling the testcase with -O3 since r10-4200-gb7ff7cef5005721e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97760
--- Comment #4 from Richard Biener ---
int b=1;
static int *g =
void __attribute__((noipa))
h (unsigned int n)
{
int i = 3;
int f = 3;
for (; f <= 50; f += 4) {
i += 4;
*g = i;
i += n;
}
}
int main ()
{
h (9);
if (*g != 150 || b != 150)
__builtin_abort ();
return 0;
}
[Bug tree-optimization/97736] [9/10/11 Regression] switch codegen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97736 Martin Liška changed: What|Removed |Added Status|RESOLVED|ASSIGNED Resolution|WONTFIX |--- --- Comment #5 from Martin Liška --- All right, let's prefer a bit-test over the jump table.
[Bug target/96835] Constructor in offload template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96835 --- Comment #5 from Tobias Burnus --- (In reply to Tobias Weinzierl from comment #4) > Created attachment 49339 [details] > Reproducer Compiles here with mainline (11.0.0 20201104) and nvptx offloading (-O0). I wonder whether that was fixed by: OpenMP: Handle cpp_implicit_alias in declare-target discovery (PR96390) r11-3505-g2a10a2c0689db280ee3a94164504b7196b8370f4 Thus, I think the issue of comment 0 (the internal compiler error) is fixed and the automatic 'declare target' works now on mainline. However, the run-time JIT fails here (with and without 'omp declare target) – as in comment 3: libgomp: Link error log ptxas application ptx input, line 255; error : Label expected for argument 0 of instruction 'call' ptxas application ptx input, line 255; error : Function '_ZN6vectorILi4EEC1ERKi' not declared in this scope ^-- this is "vector<4>::vector(int const&)" ^-- and 'C1' means that it is the "complete object constructor" My bet is that this is the nvptx alias issue PR 97106 (see also PR 97102 and, regarding a newer PTX ISA PR96005). Solution: Either resolving the alias in GCC (in mkoffload) or (conditionally) bumping the minimal CUDA version to 10.0 such that .alias is available (PTX ISA >= 6.3).
[Bug tree-optimization/97736] [9/10/11 Regression] switch codegen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97736 --- Comment #4 from Jakub Jelinek --- I disagree with that resolution, expanding it as a bit test is certainly better and shorter too. And it seems even switchconv pass says that it is preferrable to expand it as bit-test, but during expansion it used to be expanded as bit test, but now it just is not.
[Bug tree-optimization/97765] [11 Regression] ICE at -Os: in clear_slot, at hash-table.h:891 since r11-4796-g600be7f09ea1ea4b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97765 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Richard Biener --- Fixed.
[Bug tree-optimization/97765] [11 Regression] ICE at -Os: in clear_slot, at hash-table.h:891 since r11-4796-g600be7f09ea1ea4b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97765 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:17c25a454e056f4677649a5ed4a8b8587d29177c commit r11-4831-g17c25a454e056f4677649a5ed4a8b8587d29177c Author: Richard Biener Date: Mon Nov 9 11:09:01 2020 +0100 Use a per-edge PRE PHI translation cache This changes the phi translation cache to be per edge which pushes it off the profiling radar. For larger testcases the combined hashtable causes a load of cache misses and making it per edge allows to shrink the entry further. 2020-11-09 Richard Biener PR tree-optimization/97765 * tree-ssa-pre.c (bb_bitmap_sets::phi_translate_table): Add. (PHI_TRANS_TABLE): New macro. (phi_translate_table): Remove. (expr_pred_trans_d::pred): Remove. (expr_pred_trans_d::hash): Simplify. (expr_pred_trans_d::equal): Likewise. (phi_trans_add): Adjust. (phi_translate): Likewise. Remove hash-table expansion detection and optimization. (phi_translate_set): Allocate PHI_TRANS_TABLE here. (init_pre): Adjsust. (fini_pre): Free PHI_TRANS_TABLE.
[Bug bootstrap/97350] [11 Regression] Ada bootstrap fails with: self_referential_size, at stor-layout.c:172
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97350 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Martin Liška --- I guess it's fixed.
[Bug tree-optimization/97736] [9/10/11 Regression] switch codegen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97736 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Martin Liška --- All right. So for the mentioned test-case we can expand both as jump table and as a bit-test. Since the revision, we prefer the jump table. You can disable that with -fno-jump-tables for the interesting function.
[Bug middle-end/97326] [11 Regression] s390: ICE in do_store_flag after 10843f830350
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97326 --- Comment #2 from Andreas Krebbel --- Probably my fault. I did forget supporting floats in vec_cmp. I'm testing a patch.
[Bug c/29186] optimzation breaks floating point exception flag reading
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186
--- Comment #26 from Richard Biener ---
(In reply to Richard B. Kreckel from comment #25)
> (In reply to Richard Biener from comment #24)
> > So you're just lucky indeed ...
>
> This makes me wonder if there is still a way to trigger this.
>
> You suggest this has been fixed for the division (is there a PR or
> reference?) and I am not able to create a similar bug using addition,
> multiplication, etc. using GCC 10.
You just need to give GCC the incentive to break it. Like with
#include
#include
int main()
{
double x = (double)printf("") + 1.0; // one
double y = (double)printf(""); // zero
double breakme = x / y;
feclearexcept(FE_ALL_EXCEPT);
double z = x / y; // should set FE_DIVBYZERO
if (fetestexcept(FE_ALL_EXCEPT)) {
printf("flag set after call.\n");
}
printf("%f/%f==%f\n",x,y,z + breakme);
}
[Bug tree-optimization/97753] ICE in operator[], at vec.h:880 since r11-4714-g092cdbd919849759
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97753 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug ipa/97766] ipa/modref-2.c fails on 32 bits targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97766 Jan Hubicka changed: What|Removed |Added Last reconfirmed||2020-11-09 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Jan Hubicka --- That value is sizeof(double)*8. I tpicked double since we have builtin that writes it assumed it is 64 bits on all targets. Forgot that it can be 32bit. We could change it to float. Is float of same size everywhere? If not we could restrict test only to targets where size is known.
[Bug target/96770] -mpure-code produces suboptimal code for relocations with small offset for thumb-1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96770 Christophe Lyon changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Christophe Lyon --- Fixed on trunk
[Bug ipa/97766] New: ipa/modref-2.c fails on 32 bits targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97766 Bug ID: 97766 Summary: ipa/modref-2.c fails on 32 bits targets Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- The new test gcc.dg/ipa/modref-2.c fails on arm and other 32-bits targets: FAIL: gcc.dg/ipa/modref-2.c scan-ipa-dump modref "Parm 1 param offset:0 offset:0 size:-1 max_size:64"
[Bug tree-optimization/97764] [10/11 Regression] wrong code at -O1 and above on x86_64-pc-linux-gnu since r10-6809
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97764 Richard Biener changed: What|Removed |Added Priority|P3 |P2 CC||rguenth at gcc dot gnu.org Keywords||wrong-code
[Bug tree-optimization/97761] [11 Regression] ICE in vectorizable_live_operation, at tree-vect-loop.c:8689 started with r11-4428-g4a369d199bf2f34e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97761 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from Richard Biener --- Mine.
[Bug tree-optimization/97765] [11 Regression] ICE at -Os: in clear_slot, at hash-table.h:891 since r11-4796-g600be7f09ea1ea4b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97765 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Richard Biener --- Testing patch.
[Bug c++/96833] Functors within target offload code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96833 Tobias Weinzierl changed: What|Removed |Added Resolution|--- |WORKSFORME Status|UNCONFIRMED |RESOLVED --- Comment #2 from Tobias Weinzierl --- Likely bug in calling code: declare required in declaration and around definition
[Bug tree-optimization/97765] [11 Regression] ICE at -Os: in clear_slot, at hash-table.h:891 since r11-4796-g600be7f09ea1ea4b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97765 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Target Milestone|--- |11.0 Last reconfirmed||2020-11-09 Known to fail||11.0 Known to work||10.2.0 Priority|P3 |P1 Summary|ICE at -Os: in clear_slot, |[11 Regression] ICE at -Os: |at hash-table.h:891 |in clear_slot, at ||hash-table.h:891 since ||r11-4796-g600be7f09ea1ea4b Ever confirmed|0 |1 Keywords||ice-on-valid-code --- Comment #1 from Martin Liška --- Started with r11-4796-g600be7f09ea1ea4b.
[Bug target/96835] Constructor in offload template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96835 Jonathan Wakely changed: What|Removed |Added Status|WAITING |UNCONFIRMED Ever confirmed|1 |0
[Bug c/29186] optimzation breaks floating point exception flag reading
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186 --- Comment #25 from Richard B. Kreckel --- (In reply to Richard Biener from comment #24) > So you're just lucky indeed ... This makes me wonder if there is still a way to trigger this. You suggest this has been fixed for the division (is there a PR or reference?) and I am not able to create a similar bug using addition, multiplication, etc. using GCC 10.
[Bug tree-optimization/97764] [10/11 Regression] wrong code at -O1 and above on x86_64-pc-linux-gnu since r10-6809
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97764 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-11-09 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 Summary|wrong code at -O1 and above |[10/11 Regression] wrong |on x86_64-pc-linux-gnu |code at -O1 and above on ||x86_64-pc-linux-gnu since ||r10-6809 CC||jakub at gcc dot gnu.org Target Milestone|--- |10.3 --- Comment #1 from Jakub Jelinek --- Started with my r10-6809-g7f5617b00445dcc861a498a4cecc8aaa59e05b8c
[Bug tree-optimization/97765] New: ICE at -Os: in clear_slot, at hash-table.h:891
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97765
Bug ID: 97765
Summary: ICE at -Os: in clear_slot, at hash-table.h:891
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
The test is hard to reduce and is still quite hairy.
[534] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20201109 (experimental) [master revision
946b73c1132:a700e491347:dc7e8839c92c4bc3c3741cf27b0af81edb803fe7] (GCC)
[535] %
[535] %
[535] % gcctk -O1 -c -w small.c
[536] %
[536] % gcctk -Os -c -w small.c
during GIMPLE pass: pre
small.c: In function ‘ae’:
small.c:69:6: internal compiler error: in clear_slot, at hash-table.h:891
69 | void ae() {
| ^~
0xed6b05 hash_table::clear_slot(expr_pred_trans_d*)
../../gcc-trunk/gcc/hash-table.h:890
0xed6b05 phi_translate
../../gcc-trunk/gcc/tree-ssa-pre.c:1745
0xed6b6c phi_translate_set
../../gcc-trunk/gcc/tree-ssa-pre.c:1773
0xed6fea compute_antic_aux
../../gcc-trunk/gcc/tree-ssa-pre.c:2112
0xed6fea compute_antic
../../gcc-trunk/gcc/tree-ssa-pre.c:2458
0xedaf3a execute
../../gcc-trunk/gcc/tree-ssa-pre.c:4295
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[537] %
[537] % cat small.c
static short a, c;
char b, d;
static char e;
int f, h;
long g;
short *i;
unsigned j;
extern void ad ();
static unsigned aa() {
int l, m = l & e, n;
char o, p, r = j;
long q;
short s;
if (!d)
goto L2;
q = s = h;
L1:
b = -(e >> (h / ~0 & m + g) & ~s);
char v = ~(f % c);
unsigned short w = b | j < h | c;
char x = -c & b | h % l ^ e + g;
int y = ~(x | b > ((l | j) & g & h % f) ^ e);
unsigned long z = -(j & (l & a)) | ~f | ~(y % b) ^ g & (h ^ ~0) ^ v;
unsigned char k = ~(j | v + d | (b | ~(y % h)) + (-(x % g & ~c) ^ e ^ a) &
z);
short t = ~f & l ^ (g ^ -z & ~b & d >> ~0) + (v | h) & j ^ k ^ e & c ^ y;
int u = ~(~x & (f | h ^ -j & y >> e >> g % (l + c + b)));
int ab =
~(~(l ^ f ^ v & x) % (-k | z & y | b + a) % ((g & h) + u + -e) - (d & w)
&
j);
if (b && j) {
w = a;
e = -((-(w ^ -k & l) ^ x ^ ~g + h & y | (a ^ ab) + f) + (-e | v + j) & ~t);
a = -((a ^ y ^ (a ^ ~h ^ j % e ^ w + l) ^ g + t + ~(x ^ v)) %
(c ^ (b ^ ~0) | d));
d = -(-(k | j & ~(h << d)) << ~(e | v | (l | g ^ y) % -c ^ j) | ab);
f = l % d + ~a | x % h | -f ^ y & b ^ w | -v - j + (c | b < 0);
b = ~(~(a + ~e + ~v & b) %
~((b & g | j % w) + (-~j ^ h + d & -y % h ^ f & c + d)));
c = -((j ^ a + f ^ g + ~(h ^ x) % ~d | h & c) % d | e & b + j ^ (k | ~l));
h = -(b | a + (~t | d & (~(j > h) ^ v | j ^ f | x) % ~k) ^ h + c % l |
y & ~(-g % -d));
l = ~(~(g | e) % a ^ ~(-l & j) % ~b & c % d % ab & (~k ^ h & f) + (b + j));
if (a)
goto L1;
goto L3;
}
L2:
c = -(a && o & (b & d)) & ~(e && q) > ~g ^ p;
if (j || ab)
ad();
if (!(e || h || ab && c && (l = n) && n - 1 && s)) {
ad();
goto L1;
}
if (n || a >= d) {
ad((long)e);
goto L1;
}
p = h && r;
if (p)
o = ~(j | (d && c | e) | o);
*i += 1;
goto L1;
L3:;
}
void ae() {
aa();
for (;;)
;
}
[Bug tree-optimization/97764] New: wrong code at -O1 and above on x86_64-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97764
Bug ID: 97764
Summary: wrong code at -O1 and above on x86_64-pc-linux-gnu
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
[514] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20201109 (experimental) [master revision
946b73c1132:a700e491347:dc7e8839c92c4bc3c3741cf27b0af81edb803fe7] (GCC)
[515] %
[515] % gcctk -O0 small.c; ./a.out
[516] %
[516] % gcctk -O1 small.c
[517] % ./a.out
Aborted
[518] %
[518] % cat small.c
struct S {
int b : 3;
int c : 28;
int d : 1;
};
int main() {
struct S e = {1, -1};
if (e.d)
__builtin_abort();
return 0;
}
[Bug libstdc++/97759] Could std::has_single_bit be faster?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97759 --- Comment #6 from Jonathan Wakely --- As an aside, libstdc++ does already use the ((x-1) & x) == 0 idiom in where we are happy for zero to be treated as a power of two (because we call _Power_of_2(n+1) and we want the result to be true for n==numeric_limits::max()). We could replace _Power_of_2(n+1) with std::__has_single_bit(n+1) || (n+1)==0 but would need to define __has_single_bit for C++11 as well as C++14.
